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

[Yimin Shen <[e-mail]>]

Hi,

I concur with Tarek's comment on this. In fact, the following drafts have been proposed to provide egress protection for the inner labels (i.e. layer-2/3 VPN service labels). These drafts solve egress protection from a different angle, i.e. on a per-service basis, because ultimately it is the service label that must be protected. As I've communicated with Huaimo, this is an important piece that is missing in his draft. Also, once service labels can be protected, there is no need for an RSVP (or LDP) extension for bypass tunnel signaling. This is  because upstream labels, UHP, context label switching, etc have already been defined by MPLS WG, and hence the existing bypass path computation and signaling mechanisms are already sufficient.

http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-00
http://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-02

Thanks,

/Yimin


From: mpls [mailto:[e-mail]] On Behalf Of Tarek Saad (tsaad)
Sent: Friday, January 03, 2014 11:45 AM
To: Huaimo Chen; [e-mail]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Huaimo,

Thanks. See inline below.

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?
[TS]: yes, using the primary egress label as inner label after rerouting (local repair) over the facility bypass may work. However, additional mechanics will be required to synchronize the label assignment between the primary and backup egress nodes. Also, will necessitate backup egress node to support upstream assigned labels, and facility bypass must be UHP to provide context for the upstream label.

Regards,
Tarek

From: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Date: Monday, 16 December, 2013 10:55 PM
To: Tarek Saad <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

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