Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

From: Huaimo Chen <[email-masked]>
Date: Thu, 12 Dec 2013 13:20:44 +0000

draft-chen-mpls-p2mp-egress-protection was reviewed by the MPLS Review team prior to being polled for WG adoption. The authors have updated the draft according to the comments. We have had responses from some of the reviewers that they are comfortable with how the comments have been addressed. We would like to have the same response from the other two reviewers.

Best Regards,
Huaimo

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Mon, 16 Dec 2013 03:08:48 +0000

Hi Huaimo,

Thanks for making the changes. I still have the following comments:
1. Section 3.1: it is not still clear why the ingress has to specify the backup path (in form of EB-SERO) from previous hop PLR to the backup egress node
2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not need any downstream label…"
    i. What if the LSP is carrying non-IP traffic?
    Ii. There are cases where non-NULL label is needed at the egress— e.g., for collecting rx stats, for doing RPF check, etc.-- hence above statement is not necessarily true
3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also proposing a mechanism to achieve this protection using proxy/virtual egress node - although little mention to P2MP. Have you considered if there's any overlap there?

Regards,
Tarek

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 12 December, 2013 8:20 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Tarek Saad <[email-masked]<mailto:[email-masked]>>, Raveendra Torvi <[email-masked]<mailto:[email-masked]>>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 17 Dec 2013 03:55:47 +0000

Hi Tarek,

Thank you very much for your comments!
My answers/explanations are inline below.

Best Regards,
Huaimo
From: Tarek Saad (tsaad) [mailto:[email-masked]]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; [email-masked]
Cc: Raveendra Torvi
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Huaimo,

Thanks for making the changes. I still have the following comments:
1. Section 3.1: it is not still clear why the ingress has to specify the backup path (in form of EB-SERO) from previous hop PLR to the backup egress node
Huaimo: The ingress does not have to specify the backup path (in form of EB-SERO) from previous hop PLR to the backup egress node. We will revise the draft accordingly.

2. Section 3.2.2: "For a primary LSP carrying IP packets, the PLR does not need any downstream label..."
    i. What if the LSP is carrying non-IP traffic?
Ii. There are cases where non-NULL label is needed at the egress- e.g., for collecting rx stats, for doing RPF check, etc.-- hence above statement is not necessarily true
Huaimo:  This ("For a primary LSP carrying IP packets, the PLR does not need any downstream label...") may be changed to something like:  "For a primary LSP, if the PLR (the upstream node of the primary egress of the LSP) does the PHP  for the LSP, it redirects the traffic from the primary LSP into the backup LSP to the backup egress when it detects the failure of the primary egress; otherwise, it redirects the packets from the primary LSP into the backup LSP to backup egress using the primary LSP label from the primary egress as an inner label. (At the backup egress, it uses the backup LSP label as a context label to find the LFIB for the primary egress and uses the inner label under the context to handle the packets such as collecting rx stats and forwarding the packets, which are similar to the behaviors at the primary egress.)" What are your suggestions and comments on this?

3. Incidentally, "draft-minto-rsvp-lsp-egress-fast-protection-03" is also proposing a mechanism to achieve this protection using proxy/virtual egress node - although little mention to P2MP. Have you considered if there's any overlap there?
Huaimo: This draft tries to provide the P2P TE LSP egress protection using proxy/virtual egress node (proxy method). It needs extensions to the IGP (ISIS and OSPF) in addition to extensions to RSVP-TE and has a number of limitations (The top of page 9 in the draft lists four limitations/caveats).

Regards,
Tarek

Best Regards,
Huaimo

---

From: Yimin Shen <[email-masked]>
Date: Tue, 17 Dec 2013 16:54:05 +0000

Hi Huaimo,

In the traditional RSVP FRR (RFC 4090), an ingress router requests link protection, node protection and/or bandwidth protection by setting some flags in the Path message, and it's the decision of a transit router whether to actually set up FRR, based on its capability, local policy and local topology.

In this draft, the model seems completely ingress-driven. The ingress not only requests FRR, but also pushes an explicit bypass route to the PLR to force to set it up. So I have a doubt whether this is always desirable and possible? IMO, we may not assume that the ingress router can always  have the visibility of the topology of entire network (including the location of protected node, PLR and protector) and the knowledge of local policies of each PLR. For example, there are cases where a P2MP LSP needs to traverse multiple domains, some kind of topology abstraction/hiding is required between domains, and loose hop expansion has to be performed at domain boundaries.

Thanks,

/Yimin

From: mpls [mailto:[email-masked]] On Behalf Of Huaimo Chen
Sent: Thursday, December 12, 2013 8:21 AM
To: [email-masked]
Cc: Raveendra Torvi
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 18 Dec 2013 20:21:05 +0000

Hi Yimin,

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

Best Regards,
Huaimo
From: Yimin Shen [mailto:[email-masked]]
Sent: Tuesday, December 17, 2013 11:54 AM
To: Huaimo Chen; [email-masked]
Cc: Raveendra Torvi
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Huaimo,

Huaimo: An explicit bypass or backup route is not required. It is optional. The ingress router does not have  to put any explicit bypass or backup route into a Path message to be sent to the PLR.  We will revise the draft accordingly.

Thanks,

/Yimin

From: mpls [mailto:[email-masked]] On Behalf Of Huaimo Chen
Sent: Thursday, December 12, 2013 8:21 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Raveendra Torvi
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Best Regards,
Huaimo