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

[Huaimo Chen <[e-mail]>]

Hi Tarek,

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

Best Regards,
Huaimo
From: Tarek Saad (tsaad) [mailto:[e-mail]]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; [e-mail]
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

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

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