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

From: Huaimo Chen <[email-masked]>
Date: Tue, 2 Jul 2013 03:28:12 +0000

Hi Lizhong,

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

Best Regards,
Huaimo
From: Lizhong Jin [mailto:[email-masked]]
Sent: Friday, June 28, 2013 11:22 AM
To: Huaimo Chen
Cc: Ross Callon; [email-masked]; Raveendra Torvi; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

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]<mailto:[email-masked]>> wrote:
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,
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?
[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.
[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.

[Huaimo 3] Regarding to the synchronization between the primary egress node such as A and the backup egress node such as C, do you mean the synchronization about the service label used by the primary egress (e.g., A) and the backup egress (e.g., C)?
For a service carried by a P2MP LSP, the service labels should be the same for all the primary egresses and backup egresses. When the ingress of the LSP allocates an upstream assignment label for the service, it sends this service label to all the primary egresses and the backup egresses of the LSP for the service to be carried by the LSP. When a primary egress fails, the previous hop of the primary egress switches the traffic to the backup egress through a backup LSP to the backup egress. The service label in the traffic stays unchanged. Thus we may not need any synchronization about the service label between a primary egress and its backup egress.
For a service carried by a P2P LSP, the synchronization about the service label between a primary egress and its backup egress is required.  The objective of the synchronization should be to make  the backup egress to send the same service traffic to the same receiver as the primary egress (through using a backup service label, which may not be the same as the primary service label used by the primary egress. These two labels indicate the same service and the same service traffic receiver). There are a few of ways to achieve this.
One way is that the backup egress allocates a backup service label and sends the ingress this label with the service identification information (note that primary egress and backup egress have the same service identification information for a same service) in a similar way as the primary egress. The ingress sends the backup service label paired with the primary service label (i.e., the service label allocated by the primary egress for the same service and receiver) to the previous hop of the primary egress in a PATH message. When the primary egress fails, the previous hop switches the traffic to the backup egress through a backup LSP to the backup egress. The primary service label in a packet to be sent to the primary egress is replaced with the backup service label when the packet is switched to the backup egress, which sends the traffic to the same receiver as the primary egress through using the backup service label.
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.

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.
[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)
[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.

[Huaimo 3] You are right. We can investigate more to get a better solution.

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
On Wed, Jun 12, 2013 at 10:16 AM, Ross Callon <[email-masked]<mailto:[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)