GMPLS Recovery Signaling Issues

draft-rhodes-rsvp-recovery-signaling-01Nic Neate

Data Connection Ltd (DCL)

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

Association procedures for Segment Recoveryhttp://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

Association procedures for Segment Recoveryhttp://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

LSR A

LSR E LSR F

LSR D

LSR B

LSR G

LSR C

Protected LSP; LSP ID 5 Recovery LSP; Assoc ID 5; Assoc Src B

Protected LSP; LSP ID 5 Recovery LSP; Assoc ID 5; Assoc Src B

LSR H

RFC 4873 s3: ASSOCIATION Object3.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.

RFC 4873 s3: ASSOCIATION Object3.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.

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

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

Option 2http://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 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Overlapping Segment Recovery LSPshttp://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

Protected LSP Recovery LSP 1

LSR DLSR C

LSR G

LSR ELSR A

LSR H

LSR I LSR J

LSR FLSR B

Recovery LSP 2

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?

Recovery LSPs that are themselves protectedhttp://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?

segment-recording-desired flag is undefinedhttp://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?

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

Extra slides

Example of issues in option 1LSR A

LSR E LSR F

LSR DLSR G

Segment Protected LSP

Segment Protected LSP

Segment Recovery LSP

LSP ID 1

LSP ID 2

LSP ID 11

Assoc ID 21

Assoc ID 22

Assoc ID 21

LSR H

Segment Recovery LSP LSP ID 12 Assoc ID 22

LSR B LSR C

Example of issues in option 1LSR A

LSR E LSR F

LSR DLSR G

Segment Protected LSP

Segment Protected LSP

Segment Recovery LSP

LSP ID 1

LSP ID 2

LSP ID 11

Assoc ID 21

Assoc ID 22

Assoc ID 21

LSR H

Segment Recovery LSP LSP ID 12 Assoc ID 22

e2e Protected (1:n) Assoc ID 13

e2e Protected (1:n) Assoc ID 13

LSR B LSR C

e2e Recovery LSP LSP ID 13 Assoc ID 11

Example of issues in option 1

• 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