Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00

[Huaimo Chen <[e-mail]>]

Hi Adam,

Thanks for your comments!
My answers/explanations are inline below.

Best Regards,
Huaimo
From: Vitkovský Adam [mailto:[e-mail]]
Sent: Friday, May 09, 2014 8:38 AM
To: Huaimo Chen; Autumn Liu; Yimin Shen; Ross Callon; [e-mail]
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hello Huaimo,

I'd like to discuss some thoughts regarding the very much appreciated rsvp egress protection idea.

5.2. Intermediate Node and PLR Behavior
   The PLR (upstream node of the primary egress) tries to get the backup
   egress from EGRESS_BACKUP in the egress backup descriptor list if the
   Path message contains the list.  If the PLR can not get it, the PLR
   tries to find the backup egress, which is not the primary egress but
   has the same IP address as the destination IP address of the LSP.

-maybe the procedures  proposed in:

Segment Routing Use Cases

           draft-filsfils-rtgwg-segment-routing-use-cases-02

               3.2.  Protecting a node segment upon the failure of its

-can be leveraged to determine all the backup egress candidates for the particular LSP primary egress node.
Or the VPN backup label can be used to signal backup egress candidate capability to the LSP head-end
LSP head-end can than include this list of candidates in the EGRESS_BACKUP object of the PATH msg.
So this list can be then used by the PLR to select one or multiple best backup egress nodes.
The constrained SPF could be run to determine one or multiple backup egress nodes among all the backup egress node candidates.
The particular PLR can tan build backup LSPs to one or multiple backup egress nodes

[Huaimo]:  It seems that section 3.2. in draft-filsfils-rtgwg-segment-routing-use-cases-02 talks about a similar case, and provides protection against end point failure in the context of segment routing.
Regarding to determining a backup egress for a primary egress node of an LSP, it may be given by a user through configuration; it may also be selected/computed automatically by another component such as PCE.


5.2.2. Signaling for Facility Protection

   For a number of primary P2P LSPs going through the same PLR to the

   same primary egress, the primary egress of these LSPs may be

   protected by one backup LSP from the PLR to the backup egress

   designated for protecting the primary egress

With multiple backup egress candidates:
For the P2P LSPs going through the same PLR to the same primary egress node
-the PLR could distribute these onto several backup egress nodes based on the LSP constrains satisfied by the path to each of the backup egress nodes.

 [Huaimo]: It seems that the facility protection is normally used to provide protection against link/node failure for multiple LSPs going through the same link/node using one backup LSP (i.e., using one backup LSP to protect multiple primary LSPs).
It is also possible to use one backup LSP to protect one primary LSP against a node/link failure.

5.2.4. PLR Procedures during Local Repair

   Moreover, the PLR lets the upstream part of the primary LSP stay

   after the primary egress fails.  The downstream part of the primary

   LSP from the PLR to the primary egress SHOULD be removed.

Please consider topology:
[CE]$$$$[PE1]*****[P1]****[PLR]****[PE2]$$$$[CE]
                   |-------|              $
                   |                     $
                  [P2]------[PE3]$$$$$$$$

In the above topology for the primary path from PE1 to PE2 via P1 and PLR
A backup path is built from PLR to PE3 via P1 and P2
In case the PE2 fails the traffic destined for PE2 has to go via P1 to PLR and then back to P1 and then to P2 and PE3
In this case it is desirable for the LSP head-end PE1 to signal a new path from PE1 to PE4 via P and PE3

[Huaimo]: This is an interesting scenario. Local protection is normally temporary. After receiving the notification of the failure, the ingress node of the LSP may re-compute a path and setup a new LSP along the path, which is globally optimal.


Adam Vitkovsky CCIP® CCNP® Certified
Network Architecture Department
SWAN a.s.
Borská 6, 841 04 Bratislava 4
[e-mail]<mailto:[e-mail]>
GSM: + 421 903 423 800
www.swan.sk<http://www.swan.sk>






From: mpls [mailto:[e-mail]] On Behalf Of Huaimo Chen
Sent: Monday, May 05, 2014 11:06 PM
To: Autumn Liu; Yimin Shen; Ross Callon; [e-mail]<mailto:[e-mail]>
Subject: [mpls] draft-ietf-mpls-rsvp-egress-protection-00

Hi Autumn,

Can you elaborate a little bit on "the egress protection of p2p LSP needs to be addressed specifically with the draft."?

Best Regards,
Huaimo
From: mpls [mailto:[e-mail]] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11


I am ok with the name change, and agree with Yimin that the egress protection of p2p LSP needs to be addressed specifically with the draft.
-Autumn

From: mpls [mailto:[e-mail]] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption draft-chen-mpls-p2mp-egress-protection-11

Hi chairs, authors,

To help make this draft more generic to cover P2P LSPs, I'd like to suggest the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed by inner labels (i.e. service labels).

Of course, a complete solution for P2P LSP egress protection will require extensions to Layer-2/3 VPN service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have already been addressed by some existing IETF work and drafts, this draft could refer to them in the text.

Thanks,

/Yimin