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

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 3 Jan 2014 16:44:31 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, 16 December, 2013 10:55 PM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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:[email-masked]]
Sent: Sunday, December 15, 2013 10:09 PM
To: Huaimo Chen; [email-masked]<mailto:[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

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

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: Yimin Shen <[email-masked]>
Date: Fri, 3 Jan 2014 17:53:35 +0000

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:[email-masked]] On Behalf Of Tarek Saad (tsaad)
Sent: Friday, January 03, 2014 11:45 AM
To: Huaimo Chen; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Huaimo,

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

Hi Tarek,

Best Regards,
Huaimo

Hi Huaimo,

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?

Regards,
Tarek

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 3 Jan 2014 19:24:32 +0000

Hi Tarek,

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

Best Regards,
Huaimo

Hi Huaimo,

[Huaimo]: There are a couple of ways to synchronize the label assignment between the primary and backup egress nodes. One way is to use BGP or another protocol for the primary egress to send the primary LSP label to the backup egress as upstream assigned (UA) label. Another way is that the primary egress sends the primary LSP label as UA label to the backup egress via the PLR through RSVP-TE extensions.
Basically, the PLR includes an EGRESS_BACKUP_SUB_LSP object in the Path message to the primary egress, containing the backup egress and the backup LSP ID. The primary egress sends the backup egress the primary LSP label as UA label via the PLR after receiving the Path message with the EGRESS_BACKUP_SUB_LSP. The backup egress adds a forwarding entry with the label into the LFIB for the primary egress when receiving a UA label from the primary egress.
When the PLR detects the failure of the primary egress, 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. The backup egress delivers the packets to the same destinations as the primary egress using the backup LSP label as context label and the inner label as UA label.
    This needs backup egress support upstream assigned labels and facility bypass must be UHP as you mentioned. It seems that this is not a big issue since the upstream label assignment and UHP have been defined by MPLS WG.

Regards,
Tarek

Hi Tarek,

Best Regards,
Huaimo

Hi Huaimo,

Regards,
Tarek

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 3 Jan 2014 20:10:21 +0000

Hi Yimin,

Thanks for your comments!
It seems that an LSP may carry the traffic without any service label. In this case, how do you protect its egress failure using its service label as you mentioned that your service protect drafts solve egress protection?
Yimin, our egress local protect draft has section 4 "Considering Application Traffic" talking about how to provide the service protection.
In fact, with the egress local protection proposed in our draft, the service traffic with a service label can be easily protected against the failure of the primary egress. Thus both the traffic without any service label and the traffic with a service label are protected for the failure of the primary egress.
BTW, the service protection  proposed in your service protection draft   http://tools.ietf.org/search/draft-minto-2547-egress-node-fast-protection-02
needs another LSP egress protection draft raft-minto-rsvp-lsp-egress-fast-protection-01, which requires both IGP and RSVP-TE extensions.

Best Regards,
Huaimo
From: Yimin Shen [mailto:[email-masked]]
Sent: Friday, January 03, 2014 12:54 PM
To: Tarek Saad (tsaad); Huaimo Chen; [email-masked]
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi,

Thanks,

/Yimin

Hi Huaimo,

Regards,
Tarek

Hi Tarek,

Best Regards,
Huaimo

Hi Huaimo,

Regards,
Tarek

Best Regards,
Huaimo

---

From: Yimin Shen <[email-masked]>
Date: Mon, 6 Jan 2014 17:23:44 +0000

Huaimo,

In context label switching, if traffic doesn't have a service label, a protector can simply perform IP lookup as default.

Thanks,

/Yimin

From: Huaimo Chen [mailto:[email-masked]]
Sent: Friday, January 03, 2014 3:10 PM
To: Yimin Shen; Tarek Saad (tsaad); [email-masked]
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Yimin,

Best Regards,
Huaimo
From: Yimin Shen [mailto:[email-masked]]
Sent: Friday, January 03, 2014 12:54 PM
To: Tarek Saad (tsaad); Huaimo Chen; [email-masked]<mailto:[email-masked]>
Subject: RE: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi,

Thanks,

/Yimin

Hi Huaimo,

Regards,
Tarek

Hi Tarek,

Best Regards,
Huaimo

Hi Huaimo,

Regards,
Tarek

Best Regards,
Huaimo