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

From: Huaimo Chen <[email-masked]>
Date: Tue, 10 Jun 2014 20:45:10 +0000

Hi Autumn,

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

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

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]<mailto:[email-masked]>
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

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]<mailto:[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.

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.

[Huaimo 2] The inner label is processed by rsvp on the upstream node of the primary egress in a way similar to the existing way for the intermediate node protection.  For protecting an intermediate node such as node X using facility backup, the upstream node of the node X will use the label allocated by the next hop node of X as the inner label . For protecting the primary egress node, the upstream node of the primary egress will use the label allocated by the primary egress as the inner label . There is an object called EGRESS_BACKUP object, which contains the primary egress IP address and the backup egress IP address. This object will be sent to the primary egress by rsvp. At the primary egress, this information can be sent to any protocol, which is responsible for delivering the inner label as a upstream assigned label to the backup egress. The rsvp will not program any forwarding entries on the backup egress for this inner label as a UA label.

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.

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.

[Huaimo 2] The PLR computes a shortest constrained path to that address. Since the cost to that address from the primary egress node is much bigger, the PLR will get the path to that address through the backup egress node.

3)      Does PLR sends the PATH message for primary LSP to backup egress node?
[Huaimo] No.

Then how the state of primary LSP on upstream node of the primary egress node is maintained after failure occurs?
[Huaimo 2] The upstream node may continue to send the resv message to its upstream node along the primary LSP after the failure of the primary egress.

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,

    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]<mailto:[email-masked]>
Subject: 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:[email-masked]] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 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

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: Autumn Liu <[email-masked]>
Date: Thu, 12 Jun 2014 14:10:37 +0000

Hi Huaimo,

Thanks for your reply. Please see my comment inline.
Autumn

Hi Huaimo,

I have some questions.

I don't think this is the similar case as the protection on intermediate node. Intermediate node would not look at the inner label at all while egress node would because the outer label is popped on the egress node. If there is no entry on the forwarding entries, how traffic is going forward from backup egress node?

Why PLR does not choose the path to primary egress node, the cost is not lower?

Which upstream node continues send resv message when primary egress fails?

Thanks,
Autumn

Hi Autumn,

Best Regards,

Huaimo
From: Huaimo Chen

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 29 Jun 2014 19:18:16 +0000

Hi Autumn,

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

Best Regards,
Huaimo
From: Autumn Liu [mailto:[email-masked]]
Sent: Thursday, June 12, 2014 10:11 AM
To: Huaimo Chen; Yimin Shen; Ross Callon; [email-masked]
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

Hi Huaimo,

Hi Huaimo,

I have some questions.

[Huaimo3] There may be some forwarding entries on the backup egress node. These forwarding entries will be used to deliver the traffic from the backup LSP. These forwarding entries are created/inserted by the component on the backup egress that is responsible for handling the inner label as a UA label from the primary egress even though the RSVP will not program any forwarding entries on the backup egress for this inner label as a UA label.

[Huaimo3] When a PLR computes a backup path for protecting a node (e.g., the primary egress node) on the primary LSP, the PLR will exclude that node (e.g., the primary egress node) to be protected. Thus the PLR will not select the path to the primary egress node.

[Huaimo3] The direct upstream node of the primary egress node continues to send resv message to its upstream node along the primary LSP. Thus any upstream node (except for the ingress node) of the primary egress node will continue to send the resv message to its upstream node.

Thanks,
Autumn

Hi Autumn,

Best Regards,

Huaimo
From: Huaimo Chen

Hi Autumn,

Best Regards,
Huaimo

Hi chairs, authors,

Thanks,

/Yimin