Path-decoupled signaling - t owards a BOF in SF sven.van_den_bosch@alcatel.be

1. Path-decoupled signaling - towards a BOF in SFsven.van_den_bosch@alcatel.be • NSIS working group context • Path-decoupled signalling - definition • Path-oriented signaling for which the signaling path doesn’t necessarily coincide with the data path of the signaled flow • Examples: signaling is not initiated by end hosts, or when signaling is directed to NSIS forwarders that are not on the data path. • It is not signalling to arbitrary entities in the Internet • Several people are interested in path-decoupled signalling • Mailing discussions • Related drafts • Draft-schelen-nsis-opopsig-01.txt • Draft-declercq-vsn-arch-00.txt • Draft-vandenbosch-nsis-resilience-00.txt • Draft-hancock-nsis-fw-outline-00.txt

2. Why path-decoupled signalling? • It facilitates deployment • Flexibility in signaling entity deployment • Easier migration path for early adopters • Allows continued use of legacy equipment • It is a useful alternative when a ‘path’ is not a stable concept • Mobility: context transfer, seamless handover • BGP route changes • Some product implementations are already available • Risk for incompatible solutions • It simplifies interworking with domainsapplying forwarding planes other than IP orusing private addressing schemes. • More arguments are documented in draft-schelen-nsis-opopsig-01.txt

3. Path-decoupled signalling does raise some concerns … • Addressing • Comparison to what is being proposed in the BGP community may be helpful • We are still talking about path-related signalling not signalling to arbitrary entities • Self-healing properties • Path-decoupled signalling is likely to be focused on QoS • IGP/BGP convergence times may not be sufficient for some services • Data plane and control plane cannot be assumed to share fate • Resilience will be an important issue • Security • Path-decoupled signalling is not necessarily harder than path-coupled signalling but it poses different security issues • additional security threat classes should be investigated

4. … and requires some additional issues to be solved • Determination of next control plane hop • It does not necessarily correspond to the next data plane hop • Alignment with routing tables • Identification of the ingress and egress point in the controlled domain is required • Potentially requires knowledge about the route followed between ingress and egress in the domain

5. We believe this work should be done in the IETF • It may be separated from but should be coordinated with NSIS • It needs to be interoperable with the NSIS solution in order not to mandate a particular approach along the path

6. What should we focus on? • Indicate how a path-decoupled solution could be built reusing the NSIS work, addressing the additional issues to be solved • Addressing • Resilience (fate sharing) • Security • Determination of next control plane hop • Alignment with routing tables • Provide input to NSIS to avoid decisions from being taken that unnecessarily complicate path-decoupled signalling • Some topics are explicitly identified as out of scope • NTLP/NSLP separation (NSIS) • Interaction with routers • QoS class negotiation