Path-decoupled signaling - t owards a BOF in SF [email protected]
description
Transcript of Path-decoupled signaling - t owards a BOF in SF [email protected]
1
Path-decoupled signaling - towards a BOF in [email protected]
• 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 domains applying forwarding planes other than IP or using 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