1. GMPLS Recovery Signaling Issues draft-rhodes-rsvp-recovery-signaling-01 Nic Neate Data Connection Ltd (DCL)

2. Overview Four issues identified in 4873/4872 procedures Segment recovery Association ID is ambiguous – data could be switched onto the wrong LSP Overlapping segment recovery LSPs can cause data loss Signaling for recovery LSPs that are themselves protected isn’t defined The segment-recording-desired flag hasn’t been assigned Potentially serious problems if not fixed Also relevant to MPLS-TP

3. Association procedures for Segment Recovery http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.1 http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.1 Segment recovery (4873) Association ID usage is defined to be identical to that for e2e recovery (4872) Association ID is an LSP ID Working LSP “points at” recovery LSP Recovery LSP “points at” working LSP That works for e2e recovery because the working and recovery LSPs are in the same Session It doesn’t work for segment recovery

4. Association procedures for Segment Recovery http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.1 http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.1 No way to match each recovery LSP to the correct protected LSP at merge node C Data could be switched onto the wrong LSP

5. RFC 4873 s3: ASSOCIATION Object 3.2.2. Resource Sharing Association Type Processing The ASSOCIATION object with an Association Type with the value Resource Sharing is used to enable resource sharing during make- before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before- break. A node includes an ASSOCIATION object with a Resource Sharing Association Type in an outgoing Path message when it wishes to indicate resource sharing across an associated set of LSPs. The Association Source is set to the originating node's router address. The Association ID MUST be set to a value that uniquely identifies the association of LSPs. This MAY be set to the working LSP's LSP ID. Once included, an ASSOCIATION object with a Resource Sharing Association Type SHOULD NOT be removed from the Path messages associated with an LSP.

6. RFC 4873 s3: ASSOCIATION Object 3.2.1. Recovery Type Processing Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. Note that this means that multiple ASSOCIATION objects of type recovery may be present on an LSP.

7. Solution: Change Association ID usage Branch node sets the Association ID to an identifier that is unique within the scope of the Association Source Original intent of 4873 Segment Recovery only – avoid disrupting e2e deployments But how does the merge node know whether to process the Association ID as a segment or an e2e association? This defines one Association object with two different sets of semantics Could look at the Protection object to discover whether it is segment or e2e But even that won’t work if a segment recovery LSP is itself e2e protected (or the other way around) – both e2e and segment Protection objects are present

8. Option 1 (Suggested by Adrian Farrel in Minneapolis) Branch node divides LSP ID and segment recovery Association ID spaces to avoid clashes Can’t offer full range of LSP IDs to management tool Merge node Association object processing first assumes segment Association ID, and if no match is found, tries e2e Association ID But note that an e2e Association can look a bit like a segment Association (1:n protection) See example at end of this presentation illustrating the issues

9. Option 2 http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00#section-3.3 http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00#section-3.3 Define a new Association Type for segment recovery Not back-compatible with 4873 But… Neither is the change to the usage of the Association ID This avoids the clash between the LSP ID and segment Association ID spaces Merge node processing becomes much simpler 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type (3) | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10. Option 3 (Output of discussions this week) Deprecate multiple levels of protection Can’t signal a segment recovery LSP that is itself e2e protected Can achieve the same function with LSP stitching Stick with type 1 Association for segment recovery Set the Association ID to a unique identifier as described earlier (not an LSP ID) Merge node looks at the single Protection object to decide whether it is e2e or segment association

11. Overlapping Segment Recovery LSPs http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.4 http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.4 No protocol mechanism is defined for choosing which segment recovery LSP is used for repair Following 4873/4872 procedures leads both trying to repair, and results in data loss

12. Overlapping Segment Recovery LSPs Solution may include some of the following Making the SRRO mandatory, to allow informed decisions of whether to use a given recovery LSP for repair Always using the branch node nearest the failure to initiate repair Allowing 4873/4872 procedures to be overridden by configuration of which nodes initiate repairs (c.f. 4426) Signaling in the SERO whether the branch or merge node initiates repairs Timers to allow second recovery LSP to be used if first fails Some overlap with draft-takacs-ccamp-revertive-ps?

13. Recovery LSPs that are themselves protected http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.3 http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.3 RFC 4873 states that segment recovery LSPs can themselves be e2e or segment protected, but doesn’t define signaling Currently, 4873/4872 only allow a single Protection object in the Path message Could allow two Protection objects Could deprecate this function, as discussed earlier Use LSP hierarchy or LSP stitching instead What have other implementations done?

14. segment-recording-desired flag is undefined http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.5 http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-01#section-4.5 Used to request that the SRRO object is signaled What value have implementers used? A bit in the Session Attribute object? A bit in the LSP Attributes object? Something else?

15. Summary Updates required to 4873 Don’t use LSP IDs as segment Association IDs Define a way to distinguish e2e and segment Association IDs Prevent overlapping segment recovery LSPs both being used for repair (make the SRRO mandatory?) Allow multiple Protection objects in the Path message? Or deprecate multi-level protection function? Assign the segment-recording-desired flag Do people agree that these are problems that need fixing? Could progress draft-rhodes-ccamp-rsvp-recovery-fix, or another draft Could use RFC errata for some or all

16. Extra slides

17. Example of issues in option 1

19. In e2e 1:n protection, all n working LSPs set their Association ID to the protected LSP ID (13) When merge node C processes segment recovery LSP 11 it will find Association object {Assoc ID 13, Assoc Src B} it will find a matching Association object on segment recovery LSP 12 but it would be mistaken to conclude that the two LSPs alone form a segment recovery association rather, they form an e2e 1:n protection association also in combination with the e2e recovery LSP 13, which has a different Association object {Assoc ID 11, Assoc Src B} Implementation is not easy