1. 63nd IETF Paris August 2005 LSP Stitching with Generalized MPLS TE draft-ietf-ccamp-lsp-stitching-01.txt Arthi Ayyangar (arthi@juniper.net)arthi@juniper.net Jean Philippe Vasseur (jpv@cisco.com )jpv@cisco.com

2. 63nd IETF Paris August 2005 Changes from 00 version Editorial cleanup and rewrite Incorporated comments from WG –relevance of signaling adjacency between LSP segment end points –label allocation procedure over LSP segment for bidirectional LSPs –teardown procedures for e2e LSP over LSP segment –relationship between regions based on switching capabilities and LSP stitching –triggers for dynamic setup of LSP segment for LSP stitching

3. 63nd IETF Paris August 2005 Discussion on list Are the control plane procedures for LSP stitching REQUIRED for PSC and non-PSC LSPs ? –Yes Should we allow LSP stitching procedures (control & data planes) while traversing region boundaries ? –PSC-n to PSC-(n+1) : NO –Non-PSC: NO/YES ? –Different opinions on this Why not simply use LSP hierarchy in this case ? Is there any specific “benefit” of using LSP stitching instead of LSP hierarchy for this case (control & data plane) ? Would such nodes even use LSP stitching control plane procedures as described in this ID or would they simply use LSP hierarchy procedures in control plane but stitch in data plane? Does it affect anyone if LSP stitching between different SC’s were disallowed ?

4. 63nd IETF Paris August 2005 Issue of Bidirectional LSPs Jean Louis brought up this point –GMPLS nodes use Upstream Label to detect bi-directionality of the LSP –When no Upstream Label is exchanged over the LSP segment hop, the information conveying bi-directionality is lost Solution options 1.Some flag set by head end of e2e LSP to be used as an alternative to Upstream Label, when Upstream Label is missing –Two different signaling parameters to mean the same thing –Not compatible with existing procedures 2.Some flag/object set by the stitching node, only along the LSP segment hop 3.Continue to send Upstream Label in Path and Label in Resv over the LSP segment hop, but choose a “unique” label value to denote stitching –How does this affect Generalized Labels that have no restriction on value to be used ? E.g. Port Numbers 4.Should we even allow bidirectional LSP to traverse two different unidirectional LSP segments ? OR –Any label value (no need for “unique” value) and simply place the onus on the receiver to ignore any Label/Upstream Label in case of stitching This is already stated in the ID. Stricter rules.

5. 63nd IETF Paris August 2005 Next steps LSP stitching signaling procedures are currently “optional” for non-PSC –Make this a requirement, similar to PSC? Resolve rules for stitching between different SCs Fix the issue of absence of Upstream Label for bidirectional LSPs based on options listed before There has been more discussion/comments on list after version 01 Adopt additional comments and publish early revision