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

From: Huaimo Chen <[email-masked]>
Date: Mon, 5 May 2014 21:06:01 +0000

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:[email-masked]] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; [email-masked]
Cc: [email-masked]; [email-masked]
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:[email-masked]] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 6 May 2014 12:19:55 +0000

Hi Autumn,

    It is not clear for me what you mean with "the egress protection of p2p LSP needs to be addressed specifically with the draft."

    Can you please supply some text that addresses the issue(s) you mentioned.

Best Regards,

Huaimo
From: Huaimo Chen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; [email-masked]
Subject: draft-ietf-mpls-rsvp-egress-protection-00

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin

---

From: Autumn Liu <[email-masked]>
Date: Fri, 9 May 2014 00:44:19 +0000

Hi Huaimo,

I have some questions.

1)      How Inner label (vpn label) acquired on primary egress node is sent to backup egress node? Via PATH message for backup LSP? which object is used? How this label is processed? How this label is maintained?

2)      How PLR can acquire a path to backup egress node, its address is the same as primary egress node?

3)      Does PLR sends the PATH message for primary LSP to backup egress node?
Thanks,
Autumn

From: Huaimo Chen [mailto:[email-masked]]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; [email-masked]
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hi Autumn,

Best Regards,

Huaimo
From: Huaimo Chen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-mpls-rsvp-egress-protection-00

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin

---

From: Vitkovský Adam <[email-masked]>
Date: Fri, 9 May 2014 12:38:17 +0000

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

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.

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

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

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

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 15 May 2014 03:16:43 +0000

Hi Autumn,

Thanks for your questions!
My answers are inline below.

Best Regards,
Huaimo
From: Autumn Liu [mailto:[email-masked]]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; [email-masked]
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hi Huaimo,

I have some questions.

1)      How Inner label (vpn label) acquired on primary egress node is sent to backup egress node? Via PATH message for backup LSP? which object is used? How this label is processed? How this label is maintained?
[Huaimo] An inner label (such as VPN label) allocated on the primary egress node may be sent to the backup egress node in one of a few ways. One way is to use BGP to send the inner label to the backup egress node from the primary egress node. Alternatively, the inner label may be sent from the primary egress node to the upstream node of the primary egress node through an EGRESS-BACKUP object in RESV message and then the upstream node sends the inner label to the backup egress node via  an EGRESS-BACKUP object in the PATH message for the backup LSP. When the backup egress node receives the inner label as a UA label originally from the primary egress, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the backup egress node receives a packet from the backup LSP, it uses the top label as a context label to find the LFIB for the primary egress node and the inner label to deliver the packet to the same destination as the primary egress node according to the LFIB.
Note that exactly how the inner label is sent from the primary egress node to the backup egress node is out of scope for this document.

2)      How PLR can acquire a path to backup egress node, its address is the same as primary egress node?
[Huaimo] PLR gets the backup egress node first and then computes a path from the PLR to the backup egress node. The backup egress node may be configured by an operator on the ingress of the primary LSP. If it is configured, the ingress will include the backup egress node in the PATH message through using EGRESS_BACKUP object. If the backup egress node is not given by the operator, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP address as the destination IP address of the LSP.  Note that the primary egress node and the backup egress node SHOULD have a same local address configured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local address on the primary egress node.

[Huaimo] No.
Thanks,
Autumn

From: Huaimo Chen [mailto:[email-masked]]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hi Autumn,

Best Regards,

Huaimo
From: Huaimo Chen

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 28 May 2014 19:22:44 +0000

Hi Adam,

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

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

Hello Huaimo,

[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.

 [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.

[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

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin

---

From: Autumn Liu <[email-masked]>
Date: Fri, 30 May 2014 00:21:49 +0000

Hi Huaimo,

Thanks for your reply. Please see my comments inline.
-Autumn

From: Huaimo Chen [mailto:[email-masked]]
Sent: Wednesday, May 14, 2014 8:17 PM
To: Autumn Liu; Yimin Shen; Ross Callon; [email-masked]
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hi Autumn,

Best Regards,
Huaimo
From: Autumn Liu [mailto:[email-masked]]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hi Huaimo,

I have some questions.

I understand that this is out of scope of this document, but it is still not clear to me how inner label is going to be processed, maintained and programmed. If bgp is used to send the inner label from primary egress node to backup egress node, how bgp know there is backup egress node? Even this is possible, the egress protection on the rsvp level should make this transparent to bgp and any other applications using rsvp. If the alternative way you described is used, it seems that rsvp will program a bgp entry in forwarding plane, I don't think this is desired behavior either.

The question is not about knowing the backup egress node, it is how to get a route to backup egress node given the fact that the backup egress node has the same address of the primary egress node.

Then how the state of primary LSP on upstream node of the primary egress node is maintained after failure occurs?
Thanks,
Autumn

Hi Autumn,

Best Regards,

Huaimo
From: Huaimo Chen

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin