1. 1 Path-decoupled signaling - towards a BOF in SF sven.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. 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 domains applying forwarding planes other than IP or using private addressing schemes. More arguments are documented in draft-schelen-nsis-opopsig- 01.txt

3. 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. 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. 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. 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