CURRENT_MEETING_REPORT_ Reported by Tony Li/cisco Systems Minutes of the Source Demand Routing Working Group (SDR) SDR Status SDR Status was presented by Deborah Estrin. The document has been submitted as an Experimental RFC. The protocol remains tied solely to IPv4 and demand in quiescent. Vendor support is needed to produce more implementations so that special services can be supported over SDR, but vendors are hesitant because it is still hard to present a clear business case. ERP Draft The current ERP draft was presented by Peter Ford. ERP is the follow on from GRE and SDR specifically targeted for IPv6. There is an existing Internet-Draft on the protocol, as well as a related draft on the concept of ``packs.'' The primary change from SDR is that ERP is carried as an IPv6 option. There are still several open issues related to the mechanisms for nested source routing. One mechanism is to perform explicit recursive tunneling, invoking a new packet header and ERP option for each layer of tunneling. Alternatively, the previous source route information can be nested within the ERP option. This can be viewed as a space-time tradeoff, with explicit recursive tunneling being high space low time, while stacking information within ERP is low space and high time. There is not yet consensus on how to proceed on this issue, but it is hoped that implementation experience will drive the decision. Work In Progress On Route Construction Work in progress on route construction was presented by Kannan Varadhan and Deborah Estrin. The primary thrust here is to develop additional hooks into IDRP for SDR/ERP and route server support. In the longer term several people are working on path explorers with constraints (Hotz, Rekhter, Estrin, Brijesh). Route servers maintain multiple views of the routing infrastructure, one view per desired perspective. These systems are being deployed at the NAPs, and will hopefully help scale the number of external connections that a router will need. Route servers can also assist route computation for explicit routes by providing remote data services to base the computation on. There are already some mechanisms for obtaining information from a route server, such as performing a RIB query. There is also interest in generating a path explorer, which would cause a particular special route to be introduced and propagated into the normal routing fabric, however, its scope would be constrained so that there would be no scaling issues. Another mechanism for extracting data from the route server is a Routing Information Filter. Each filter element consists of a tuple (action, NLRI, scope, Base). Actions are ALLOW (add an NLRI to the reported ones), RESTRICT (ignore an NLRI), or REMOVE (remove a restriction). Scope can be EXACT (exact match), REFINE (longer matches), NORMAL (exact or longer) and REACHABILITY (longest match). Base is the information base to select data from. There was some concern that this mechanism needs to be more extensible so that more complex data filtering can be performed. Other Issues Deborah Estrin closed the session by listing a number of other issues which need attention. More work needs to be done on interactions between SDR and multicast. Currently, PIM is being designed to support SDR routes to guide joins, thereby passing an explicit route to the multicast tree. Installing this route and using it and preventing looping, however is an open issue. There is significant work to be done on how RSVP would interact with SDR. For a note describing preliminary work in this area contact zappala@isi.edu. There was also a discussion of what security and authentication needs to be present in SDR. The group came to the conclusion that it was a nontrivial problem, as simple end-to-end authentication is insufficient. And, as always, we need to have someone work on the MIB.