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

From: Lizhong Jin <[email-masked]>
Date: Sun, 23 Jun 2013 22:26:45 +0800

Hi authors,
I have been asked to review draft-chen-mpls-p2mp-egress-protection-09.
Overally, there are some points that need to be discussed before WG
adoption. And I would appreciate if the authors could help to clarify.

1. If I understand the draft correctly, the primary and backup egress node
address should be two different address. But actually, the egress node is
closely related with many customer service configurations (e.g, mvpn and
p2mp pw). Anycast address based protection has been proved to be an
efficient way for MVPN and other service over RSVP-TE P2MP. Then if anycast
address is applied for egress node protection, FRR defined in RFC4090 could
be reused, right?
2. section 7.2.2. I doubt if the facility proction could work in the egress
protection. The backup egress node does not know the P2MP lable allocated
by the primary egress node. And it is very likely that the P2MP lable
received by backup egress node has already been allocated for other
purpose. Or is there any sychronization mechanism between primary and
backup node.

Regards
Lizhong

On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <[email-masked]> wrote:

> Ravi, Eric, Tarek, Lizhong;
>
> You have been selected as MPLS Review team reviewers for
> draft-chen-mpls-p2mp-egress-protection-09.
>
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
>
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound?  Also, is the text
> and grammar understandable (it doesn't need to be perfect at this
> point, but should be reasonably clear). We are interested in knowing
> whether the document is ready to be considered for WG adoption (ie,
> it doesn't have to be perfect at this point, but should be a good
> start).
>
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary,
> Comments may be sent privately to only the WG chairs.
>
> Are you able to review this draft by June 26, 2013?
>
> Thanks, Ross
> (as MPLS WG chair)
>
>
>
>
>

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 24 Jun 2013 16:17:48 +0000

Hi Lizhong,

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

Best Regards,
Huaimo
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: [email-masked]; Raveendra Torvi; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi authors,
I have been asked to review draft-chen-mpls-p2mp-egress-protection-09. Overally, there are some points that need to be discussed before WG adoption. And I would appreciate if the authors could help to clarify.

1. If I understand the draft correctly, the primary and backup egress node address should be two different address. But actually, the egress node is closely related with many customer service configurations (e.g, mvpn and p2mp pw). Anycast address based protection has been proved to be an efficient way for MVPN and other service over RSVP-TE P2MP. Then if anycast address is applied for egress node protection, FRR defined in RFC4090 could be reused, right?

Huaimo: It seems that anycast address based protection depends on IP routing. Thus the traffic interruption (or switch over)  time will be much longer when the primary egress fails since it relies on the IP routing convergence. If it is applied for egress node protection, both the primary egress and the backup egress should have a same anycast IP address, a CE should connect to these two egresses and have a routing table entry with two items. One item for the route (i.e., the anycast IP address) to the primary egress  with a smaller metric, the other for the route to the backup egress with a bigger metric. Thus, the CE receives the traffic from the primary egress in normal operations.  When the primary egress fails, the route to the backup egress becomes the best one after IP routing convergence and the CE switches to receive the traffic from the backup egress.  In order for the CE to get the traffic from the backup egress after the primary egress fails, the traffic should be sent to the backup egress before or when the primary egress fails. A P2MP LSP with these two egresses (i.e., the primary egress and the backup egress as its normal two egresses) can send the traffic to both the primary egress and the backup egress at the same time. It seems that FRR defined in RFC 4090 can not be reused directly here to switch the traffic to the backup egress from the primary egress when the primary egress fails. Using the egress node protection proposed in the draft have two advantages over the anycast address based protection. One is that the traffic interruption (or switch over)  time will be much shorter (tens of ms) when the primary egress fails; the other is that the bandwidth used for sending the traffic to the backup egress is saved.  Is my understanding of anycast based protection consistent with yours?

2. section 7.2.2. I doubt if the facility proction could work in the egress protection. The backup egress node does not know the P2MP lable allocated by the primary egress node. And it is very likely that the P2MP lable received by backup egress node has already been allocated for other purpose. Or is there any sychronization mechanism between primary and backup node.

Huaimo: In some cases, there is no need for any label. For example, if the second last hop label pop is enabled, the previous hop (or upstream) node of the primary egress does not need any P2MP LSP label from the backup egress. In the case that the previous hop (or upstream) node of the primary egress needs a P2MP LSP label from the backup egress, there are a few of ways to get the label. One way is to let the previous hop (or upstream) node send the object containing the backup egress to the primary egress,  which "extends" the P2MP LSP to the backup egress. It sends a path message to the backup egress, gets a resv message with a P2MP LSP label from the backup egress and then sends a resv message with this label to the previous hop (or upstream) node.  Note that the primary egress will not create any forwarding entry with this label for sending the traffic to the backup egress. The previous hop (or upstream) node can provide the primary egress node protection using this label in a way similar to the one that it provides an intermediate node protection. We will address this in the next version of the draft.

Regards
Lizhong
On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
Ravi, Eric, Tarek, Lizhong;

Thanks, Ross
(as MPLS WG chair)

---

From: Raveendra Torvi <[email-masked]>
Date: Mon, 24 Jun 2013 21:57:12 +0000

I have finished first round of review of this draft. In short, WG should explore use cases and see whether signaling procedure mentioned in the draft are applicable in real world, before accepting this as WG draft.   I do not think this draft is readily usable.

Following are some issues with draft:

[1] Unlike other local protection this is an ingress driven, not PLR.  In inter-domain scenario, ingress may not have the visibility of entire network to figure out the complete primary path, not to mention the bypass path.

[2] In the presence of loose-hops, this may also yield to wrong selection of PLR by ingress, as one may have several hops between ingress designated PLR and protected PE. There is no indication from Egress to ingress that egress is protected.

[3] 1:1 relationship between primary egress and backup egress. This will be scalability issues especially with ring topologies.
   This solution is NOT extensible to 1:N protection.

[4] This draft does not address interoperability with 1:N protection..

[5] Local reversion does not work

 Consider following example:

S2L 1 :  I - PH1-PE- Primary
S2L 1 Backup:  I - PH3 - PE-Backup
S2L 2: I - PH2 - PE-Other

      I----PH1--------PE-Primary
                ||
               PH2--------PE-Other
                |
               PH3---------- PE Backup

PH - PE link comes back, PH1 sends traffic PE Primary and how & when does PH2 stop sending traffic to PH3?

[6] According to Section 4.4,  in order to detect PE-CE link down, this solution needs a BFD session from a P router to CE device, which is a non-starter as P router may not have any state to reach CE, at least draft does not go deep enough to explain this point.

[7] This solution addresses P2MP LSPs only. The approach cannot be extended to apply for P2P LSPs, in which case it must be ensured that the back egress know how to handle inner label (i.e. service label).

Regards
Ravi
From: Huaimo Chen [mailto:[email-masked]]
Sent: Monday, June 24, 2013 12:18 PM
To: Lizhong Jin; Ross Callon
Cc: [email-masked]; Raveendra Torvi; [email-masked]; [email-masked]
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Lizhong,

Best Regards,
Huaimo

Hi authors,

Regards
Lizhong

Thanks, Ross
(as MPLS WG chair)

---

From: Lizhong Jin <[email-masked]>
Date: Tue, 25 Jun 2013 23:10:35 +0800

Hi Huaimo,
Please see inline below.

Regards
Lizhong

On Tue, Jun 25, 2013 at 12:17 AM, Huaimo Chen <[email-masked]>wrote:

>  Hi Lizhong,****
>
> ** **
>
> Thanks much for your good comments and questions!****
>
> My answers/explanations are inline below.****
>
> ** **
>
> Best Regards,****
>
> Huaimo****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Lizhong Jin
> *Sent:* Sunday, June 23, 2013 10:27 AM
> *To:* Ross Callon
> *Cc:* [email-masked]; Raveendra Torvi;
> [email-masked];
> [email-masked]
> *Subject:* Re: [mpls] MPLS-RT review of
> draft-chen-mpls-p2mp-egress-protection****
>
> ** **
>
> Hi authors,****
>
> adoption. And I would appreciate if the authors could help to clarify.****
>
>  ****
>
> 1. If I understand the draft correctly, the primary and backup egress
> node address should be two different address. But actually, the egress node
> is closely related with many customer service configurations (e.g, mvpn and
> be reused, right? ****
> ** **
> Huaimo: It seems that anycast address based protection depends on IP
> routing. Thus the traffic interruption (or switch over)  time will be much
> longer when the primary egress fails since it relies on the IP routing
> convergence. If it is applied for egress node protection, both the primary
> egress and the backup egress should have a same anycast IP address, a CE
> should connect to these two egresses and have a routing table entry with
> two items. One item for the route (i.e., the anycast IP address) to the
> primary egress  with a smaller metric, the other for the route to the
> backup egress with a bigger metric. Thus, the CE receives the traffic from
> the primary egress in normal operations.  When the primary egress fails,
> the route to the backup egress becomes the best one after IP routing
> convergence and the CE switches to receive the traffic from the backup
> egress.  In order for the CE to get the traffic from the backup egress
> after the primary egress fails, the traffic should be sent to the backup
> egress before or when the primary egress fails. A P2MP LSP with these two
> egresses (i.e., the primary egress and the backup egress as its normal two
> egresses) can send the traffic to both the primary egress and the backup
> egress at the same time. It seems that FRR defined in RFC 4090 can not be
> reused directly here to switch the traffic to the backup egress from the
> primary egress when the primary egress fails. Using the egress node
> protection proposed in the draft have two advantages over the anycast
> address based protection. One is that the traffic interruption (or switch
> over)  time will be much shorter (tens of ms) when the primary egress
> fails; the other is that the bandwidth used for sending the traffic to the
> backup egress is saved.  Is my understanding of anycast based protection
> consistent with yours?
>
[Lizhong] After more consideration, let me explain my understanding in
detail. The previous node will see the primary and backup egress as one
egress node with the anycast address. Since there is one egress node for
the previous node, then FRR defined in RFC4090 could be reused. But there
should be some synchronization mechanism between primary and backup egress,
to negotiate a common label that could be used by both primary and backup
egress. That could be potentially achieved by MP-BGP. The switching time
and BW usage would be the same as FRR. Using anycast address would ease the
implementation of the client service (e.g mvpn).

>   ****
>
> ** **
>
> 2. section 7.2.2. I doubt if the facility proction could work in the
> egress protection. The backup egress node does not know the P2MP lable
> allocated by the primary egress node. And it is very likely that the P2MP
> lable received by backup egress node has already been allocated for other
> backup node.****
>  ****
> Huaimo: In some cases, there is no need for any label. For example, if the
> second last hop label pop is enabled, the previous hop (or upstream) node
> of the primary egress does not need any P2MP LSP label from the backup
> egress. In the case that the previous hop (or upstream) node of the primary
> egress needs a P2MP LSP label from the backup egress, there are a few of
> ways to get the label. One way is to let the previous hop (or upstream)
> node send the object containing the backup egress to the primary egress,
>  which “extends” the P2MP LSP to the backup egress. It sends a path message
> to the backup egress, gets a resv message with a P2MP LSP label from the
> backup egress and then sends a resv message with this label to the previous
> hop (or upstream) node.  Note that the primary egress will not create any
> forwarding entry with this label for sending the traffic to the backup
> egress. The previous hop (or upstream) node can provide the primary egress
> node protection using this label in a way similar to the one that it
> provides an intermediate node protection. We will address this in the next
> version of the draft.
>
[Lizhong] But why do you think there is a link between the primary and
backup egress? What if there is no directly connection between the two?

>   ****
> ** **
> Regards****
> Lizhong****
> ****
> ****
> ** **

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 27 Jun 2013 23:31:13 +0000

Hi Lizhong,

    Thanks much for your second round comments!
My responses are inline below.

Best Regards,
Huaimo
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lizhong Jin
Sent: Sunday, June 23, 2013 10:27 AM
To: Ross Callon
Cc: [email-masked]<mailto:[email-masked]>; Raveendra Torvi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi authors,

Huaimo: It seems that anycast address based protection depends on IP routing. Thus the traffic interruption (or switch over)  time will be much longer when the primary egress fails since it relies on the IP routing convergence. If it is applied for egress node protection, both the primary egress and the backup egress should have a same anycast IP address, a CE should connect to these two egresses and have a routing table entry with two items. One item for the route (i.e., the anycast IP address) to the primary egress  with a smaller metric, the other for the route to the backup egress with a bigger metric. Thus, the CE receives the traffic from the primary egress in normal operations.  When the primary egress fails, the route to the backup egress becomes the best one after IP routing convergence and the CE switches to receive the traffic from the backup egress.  In order for the CE to get the traffic from the backup egress after the primary egress fails, the traffic should be sent to the backup egress before or when the primary egress fails. A P2MP LSP with these two egresses (i.e., the primary egress and the backup egress as its normal two egresses) can send the traffic to both the primary egress and the backup egress at the same time. It seems that FRR defined in RFC 4090 can not be reused directly here to switch the traffic to the backup egress from the primary egress when the primary egress fails. Using the egress node protection proposed in the draft have two advantages over the anycast address based protection. One is that the traffic interruption (or switch over)  time will be much shorter (tens of ms) when the primary egress fails; the other is that the bandwidth used for sending the traffic to the backup egress is saved.  Is my understanding of anycast based protection consistent with yours?
[Lizhong] After more consideration, let me explain my understanding in detail. The previous node will see the primary and backup egress as one egress node with the anycast address. Since there is one egress node for the previous node, then FRR defined in RFC4090 could be reused. But there should be some synchronization mechanism between primary and backup egress, to negotiate a common label that could be used by both primary and backup egress. That could be potentially achieved by MP-BGP. The switching time and BW usage would be the same as FRR. Using anycast address would ease the implementation of the client service (e.g mvpn).

[Huaimo] Physically the primary egress node and the backup egress node are two different nodes even though they have a same anycast address. To protect the primary egress node of a primary (P2MP or P2P) LSP, the previous hop (or upstream) node of the primary egress node needs to create a backup LSP to the backup egress node (i.e., the physical backup egress node, which is different from the physical primary egress node).  Since there is not any primary LSP path segment after the primary egress node, the FRR defined in RFC4090 could not be reused directly. In order to use the FRR defined in RFC4090 for protecting a node B, the previous hop (or upstream) node (say node A) of the node B needs to create a backup LSP that intersects the primary LSP somewhere downstream of the node B. See the following descriptions from RFC4090:
    In section 3.1 One-to-One Backup, "In the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure. ... "
In section 3.2 Facility Backup, the second paragraph: "The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. ... "
In the case that the node B is the primary egress node, node A (i.e., the previous hop/upstream node of the primary egress node) can not create any backup LSP intersecting the primary LSP somewhere downstream of the node B (i.e., the primary egress node). There is not any primary LSP after the node B (i.e., the primary egress node).
To protect the primary egress node of a primary LSP, some special protocol extensions are needed. The objective of this draft is to define these special extensions.
Regarding to the service label, it seems out scope of this draft. The service label such as VPN label should be handled by others such as BGP. We will provide some descriptions about this in details in the next version of the draft.
In the client side, using anycast address may be easier.  The egress node protection in the core side should work with the anycast address protection in the client side. We will address this in the next version of the draft.

Huaimo: In some cases, there is no need for any label. For example, if the second last hop label pop is enabled, the previous hop (or upstream) node of the primary egress does not need any P2MP LSP label from the backup egress. In the case that the previous hop (or upstream) node of the primary egress needs a P2MP LSP label from the backup egress, there are a few of ways to get the label. One way is to let the previous hop (or upstream) node send the object containing the backup egress to the primary egress,  which "extends" the P2MP LSP to the backup egress. It sends a path message to the backup egress, gets a resv message with a P2MP LSP label from the backup egress and then sends a resv message with this label to the previous hop (or upstream) node.  Note that the primary egress will not create any forwarding entry with this label for sending the traffic to the backup egress. The previous hop (or upstream) node can provide the primary egress node protection using this label in a way similar to the one that it provides an intermediate node protection. We will address this in the next version of the draft.
[Lizhong] But why do you think there is a link between the primary and backup egress? What if there is no directly connection between the two?

[Huaimo] We can have another way for the previous hop (or upstream) node of the primary egress to get the label from the backup egress node. The previous hop (or upstream) node may "extend" the P2MP LSP to the backup egress. It sends a path message to the backup egress, gets a resv message with a P2MP LSP label from the backup egress and then provides the primary egress node protection using this label.  Note that the previous hop (or upstream) node will not create any forwarding entry with this label for sending the traffic to the backup egress. We may call the LSP (segment) extended from the primary LSP an empty primary LSP since it will not transport any traffic.
The first way requires that there be a link between the primary egress and the backup egress. The second way does not have this requirement. The first way may reuse the existing FRR procedures more. The figures below show some details about these two ways.

The first way:

     Link                                       **** Primary LSP

     $                                          ---- Backup LSP

    $         [R2]****[R3]*****[L1]             Empty Primary LSP

   $          *          \     *)$  $            *)

             *            \    *)$    $[CE1]     *)

            *              \   *)$  $            *)

           *                \__[La]

          *

       [R1]****[R4]***[R5]*****[L2]

      $                  \     *)$  $

     $                    \    *)$    $[CE2]

  [S]                      \   *)$  $

                            \__[Lb]

Link between primary egress (L1) and backup egress (La) is required

Primary egress (L1) signals empty primary LSP to backup egress (La)

Previous hop (R3) reuses FRR to protect primary egress (L1)

The second way:

     Link                                       **** Primary LSP

     $                                          ---- Backup LSP

    $         [R2]****[R3]*****[L1]             Empty Primary LSP

   $          *        *)\          $            *)

             *          *)\           $[CE1]     *)

            *            *)\        $            *)

           *              *)\__[La]

          *

       [R1]****[R4]***[R5]*****[L2]

      $                *)\          $

     $                  *)\           $[CE2]

  [S]                    *)\        $

                          *)\__[Lb]

Previous hop (R3) signals empty primary LSP to backup egress (La)

Previous hop (R3) uses a bypass LSP to protect primary egress (L1)

Regards
Lizhong

Thanks, Ross
(as MPLS WG chair)

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 28 Jun 2013 01:58:06 +0000

Hi Ravi,

     Thanks much for your very helpful comments!
     My responses are inline below.

Best Regards,
Huaimo

From: Raveendra Torvi [mailto:[email-masked]]
Sent: Monday, June 24, 2013 5:57 PM
To: Huaimo Chen; Lizhong Jin; Ross Callon
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

[Huaimo] This draft is initially written for a real use case, which has been presented in the WG meetings. A prototype has been developed to verify some of the ideas in the draft. The running results have showed that they work as expected.

[Huaimo] Can we focus on one domain scenario for our discussions first? Other local protection and the egress node protection may need help from others such as PCE in inter-domain scenarios.
The ingress of an LSP just provides the minimum amount of information for protecting primary egress nodes. The protection for every primary egress node is then driven by the PLR (i.e., the previous hop node of the primary egress node).
For facility backup protection, the ingress of the LSP just needs to give a backup egress node for every primary egress node to be protected (plus some constraints if needed, which are the same as other local protection defined in RFC4090). The previous hop node (i.e., PLR) selects or creates a bypass backup tunnel from itself to the backup egress node for protecting the primary egress node. If there is a bypass backup tunnel from the PLR to the backup egress node that satisfies the constraints, then this tunnel is selected; otherwise, a new bypass backup tunnel to the backup egress node will be created. A path for the backup bypass tunnel will be computed by the PLR and then the backup bypass is signaled along the path computed.
If a backup S2L sub LSP is used to protect a primary egress node of a P2MP LSP, the ingress of the LSP needs to provide a path from the previous hop of the primary egress to the backup egress node. In one domain scenario, there is no issue for the ingress to provide this path.

[Huaimo] The ingress of an LSP does not select any PLR (i.e., the previous hop node of the primary egress node) for protecting the primary egress node. In order to protect a primary egress node of the LSP, the ingress just gives the backup egress (designated to protect the primary egress). When a node determines that it is the previous hop node of the primary egress node, it will act as the PLR to provide protection for the primary egress node.
The status of the egress node protection is sent to the ingress in the RRO of the RESV message. There are some descriptions about this in the draft (see the paragraph below).

"The previous hop node of the primary egress node sets the protection flags in the RRO IPv4/IPv6 Sub-object for the primary egress node according to the status of the primary egress node and the backup LSP protecting the primary egress node. For example, it will set the node protection bit to one indicating that the primary egress node is protected when the backup LSP to the backup egress node is set up for protecting the primary egress node."

[Huaimo] It seems typical that one primary egress (PE) pairs with a backup egress (PE) and a CE is dual home to two egresses (PEs). I do not see any scalability issue here. Can you give more details about the scalability issues regarding to the 1:1 relationship between primary egress and backup egress?
The facility backup protection proposed in the draft can provide 1:N protection. Multiple (N) LSPs going through the previous hop node to the primary egress node can be protected for their primary egress node failure at the same time by one (1) bypass tunnel from the previous hop node to the backup egress node. Does this address the issue "This solution is NOT extensible to 1:N protection."?

[Huaimo] Can you give some more details about "interoperability with 1:N protection"?

[Huaimo] For using backup S2L sub LSP to protect the primary egress node, the path from the previous hop node of the primary egress node to the backup egress node will not intersect with the path of the LSP. For the example above, S2L 1 Backup will not go through PH2 (see figure below). Thus local reversion may work.

S2L 1:  I -- PH1 -- PE-Primary

S2L 1 Backup:  I -- PH1 -- PH3 -- PE-Backup

S2L 2: I -- PH1 -- PH2 -- PE-Other

           |  \

           |   PH2--------PE-Other

            \__

               PH3---------- PE-Backup

When PE-Primary (i.e., the primary egress node) fails, PH1 switches the traffic to the PE-Backup (i.e., the backup egress node).
When PE-Primary comes back, PH1 may switch the traffic back to PE-Primary after re-signaling S2L 1 if the local revertive mode is used.

[Huaimo] We will focus on detecting the failure of the primary egress node in the next version of the draft.

[Huaimo] The following is a possible approach in which the solution proposed in the draft is "extended" to protect the egress of a P2P LSP.
To protect the primary egress node of a P2P LSP, the ingress of the LSP adds the object containing the primary egress and the backup egress in the PATH message. This object has the same format as the object EGRESS_BACKUP_SUB_LSP used for protecting a primary egress node of a P2MP LSP.
If one-to-one backup is used, the previous hop node of the primary egress node creates a backup LSP from itself to the backup egress for protecting the primary egress of the P2P LSP in a way similar to the one for creating a backup sub LSP to protect a primary egress of a P2MP LSP.
If facility backup is used, the previous hop node of the primary egress node selects or creates a backup bypass tunnel from itself to the backup egress for protecting the primary egress.
In the case that the previous hop (or upstream) node of the primary egress needs a P2P LSP label from the backup egress (i.e., the inner label used by the PLR to put into the bypass tunnel), there are a few of ways to get the label. One way is that the previous hop (or upstream) node "extends" the P2P LSP to the backup egress. It sends a path message towards the backup egress along the path computed and gets a resv message with a P2P LSP label from the backup egress.  Note that the previous hop (or upstream) node will not create any forwarding entry with this label for sending the traffic to the backup egress. The previous hop (or upstream) node can provide the primary egress node protection using this label in a way similar to the one that it provides an intermediate node protection.
Regarding to the service label, it seems that it is out scope of this draft. The service label such as VPN label should be handled by others such as BGP.

Regards
Ravi

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 28 Jun 2013 23:22:00 +0800

Hi Huaimo,
Thank you for the detail discussion. See inline below.

Regards
Lizhong

On Fri, Jun 28, 2013 at 7:31 AM, Huaimo Chen <[email-masked]> wrote:

>  Hi Lizhong,****
>
> ** **
>
>     Thanks much for your second round comments!****
>
> My responses are inline below.****
>
> ** **
>
> Best Regards,****
>
> Huaimo****
>
> consistent with yours? ****
>
> implementation of the client service (e.g mvpn).****
>
>  ****
>
> [Huaimo] Physically the primary egress node and the backup egress node are
> two different nodes even though they have a same anycast address. To
> protect the primary egress node of a primary (P2MP or P2P) LSP, the
> previous hop (or upstream) node of the primary egress node needs to create
> a backup LSP to the backup egress node (i.e., the physical backup egress
> node, which is different from the physical primary egress node).  Since
> there is not any primary LSP path segment after the primary egress node,
> the FRR defined in RFC4090 could not be reused directly. In order to use
> the FRR defined in RFC4090 for protecting a node B, the previous hop (or
> upstream) node (say node A) of the node B needs to create a backup LSP that
> intersects the primary LSP somewhere downstream of the node B. See the
> following descriptions from RFC4090:****
>
>     In section 3.1 One-to-One Backup, “In the one-to-one backup method, a
> label-switched path is established that intersects the original LSP
> somewhere downstream of the point of link or node failure. … “****
>
> In section 3.2 Facility Backup, the second paragraph: “The bypass tunnel
> must intersect the path of the original LSP(s) somewhere downstream of the
> PLR. … “****
>
> In the case that the node B is the primary egress node, node A (i.e., the
> previous hop/upstream node of the primary egress node) can not create any
> backup LSP intersecting the primary LSP somewhere downstream of the node B
> (i.e., the primary egress node). There is not any primary LSP after the
> node B (i.e., the primary egress node).****
>
> To protect the primary egress node of a primary LSP, some special protocol
> extensions are needed. The objective of this draft is to define these
> special extensions.
>
[Lizhong] It seems we are not aligned yet here. Let's say node C as the
backup node. Since node A and C has same anycast address, node B will see
the two nodes as one in its TE-DB (a virtual node). Then B will have a
backup path to this virtual node (node C), which is the end-point of the
primary LSP. And as I said in previous email, there should be a
synchronization mechanism existed between A and C.

****
>
> Regarding to the service label, it seems out scope of this draft. The
> service label such as VPN label should be handled by others such as BGP. We
> will provide some descriptions about this in details in the next version of
> the draft.****
>
> In the client side, using anycast address may be easier.  The egress node
> protection in the core side should work with the anycast address protection
> in the client side. We will address this in the next version of the draft.
>

> version of the draft.****
>
> backup egress? What if there is no directly connection between the two? **
> **
>
> ** **
>
> [Huaimo] We can have another way for the previous hop (or upstream) node
> of the primary egress to get the label from the backup egress node. The
> previous hop (or upstream) node may "extend" the P2MP LSP to the backup
> egress. It sends a path message to the backup egress, gets a resv message
> with a P2MP LSP label from the backup egress and then provides the primary
> egress node protection using this label.  Note that the previous hop (or
> upstream) node will not create any forwarding entry with this label for
> sending the traffic to the backup egress. We may call the LSP (segment)
> extended from the primary LSP an empty primary LSP since it will not
> transport any traffic.****
>
> The first way requires that there be a link between the primary egress and
> the backup egress. The second way does not have this requirement. The first
> way may reuse the existing FRR procedures more. The figures below show some
> details about these two ways.****
>
> ** **
>
> The first way:****
>
> ** **
>
>      Link                                       **** Primary LSP****
>
>      $                                          ---- Backup LSP****
>
>     $         [R2]****[R3]*****[L1]             Empty Primary LSP****
>
>    $          *          \     *)$  $            *) ****
>
>              *            \    *)$    $[CE1]     *)****
>
>             *              \   *)$  $            *)****
>
>            *                \__[La]****
>
>           *****
>
>        [R1]****[R4]***[R5]*****[L2] ****
>
>       $                  \     *)$  $    ****
>
>      $                    \    *)$    $[CE2]****
>
>   [S]                      \   *)$  $ ****
>
>                             \__[Lb]****
>
> ** **
>
> Link between primary egress (L1) and backup egress (La) is required****
>
> Primary egress (L1) signals empty primary LSP to backup egress (La)****
>
[Lizhong] My concern for the empty LSP is the waste of signaling resources
in the network. The RSVP is a soft-state protocol hop by hop and relies on
the refresh of signaling message. We could investigate it in more detail to
see if any better solution exists.

> ****
>
> ** **
>
> ** **
>
> The second way:****
>
> ** **
>
>      Link                                       **** Primary LSP****
>
>      $                                          ---- Backup LSP****
>
>     $         [R2]****[R3]*****[L1]             Empty Primary LSP ****
>
>    $          *        *)\          $            *) ****
>
>              *          *)\           $[CE1]     *)****
>
>             *            *)\        $            *)****
>
>            *              *)\__[La]****
>
>           *****
>
>        [R1]****[R4]***[R5]*****[L2] ****
>
>       $                *)\          $    ****
>
>      $                  *)\           $[CE2]****
>
>   [S]                    *)\        $ ****
>
>                           *)\__[Lb]****
>
> ** **
>
> ** **
>
> Previous hop (R3) signals empty primary LSP to backup egress (La)****
>
> Previous hop (R3) uses a bypass LSP to protect primary egress (L1)****
>
>      ****
>
>    ****
>
> Regards****
>
> Lizhong****
>