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.