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

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 20 Jun 2013 22:52:19 +0000

Hi all,

I have been asked to the review the below document/draft:

Extensions to RSVP-TE for P2MP LSP Egress Local Protection,
http://www.ietf.org/id/draft-chen-mpls-p2mp-egress-protection-09.txt

Overall, the draft is well written, the motivation is clear, and the
proposal is sound. I think the document should be considered for WG
adoption, but more discussions and input will be needed from
the group on the proposed mechanisms.

More comments below:
1. Suggest a change to the draft outline for easier flow of the draft,
e.g.:
- Applicability of Local Repair Techniques
    - One-to-one Backup
    - Facility Backup
- RSVP extensions
- Headend Behavior
- PLR behavior
  - Signaling of Backup sub-LSP
  - ..
- Behavior of All LSRs

2. Is the draft also intendeds to cover locally protecting egress nodes
that act as transits/mids (aka P2MP bud LSR nodes)? Either way, could be
helpful if it mentioned it.

3. Section 1:
"An existing method for protecting the egress nodes of a P2MP LSP sets up
a backup P2MP LSP from a backup ingress node to the backup egress nodes."
* the backup P2MP LSP can also originate from same ingress node to the set
of backup egress nodes.
* a variant would be to graft another primary S2L sub-LSP to the "backup"
egress node. Traffic flows on to both egress nodes, and receiver can
select traffic from either based on route to source via RPF.

4. Section 4.1:
Typo: follwing -> following

5. Consider
        PLR
      +--+--+
      |  |  |
      A  B  C
    /    |   \
   /     +    \
  /     / \    \
CE1---+    +--- CE2
 
* If the same backup egress node (e.g. B) is used to protect two or more
primary egress nodes (e.g. A and C), when PLR reroutes traffic onto the
backup (detour or bypass tunnel via B) due to a failure of one of the
primary egress nodes (eg. A), the receiver(s) connected to other primary
egress node(s) (e.g. CE2) starts to receive duplicated traffic (via C and
via B).

6. Section 4.2:
"The previous hop node of the primary egress node sets up a backup sub LSP
from itself"
* Arguably, a PLR is one that usually provisions/assigns backup (detour or
bypass). Personally, favour using the term upstream node PLR over previous
hop node (used extensively in the draft).

7. Section 4.3:
"After receiving the RSVP-TE RESV message for the backup sub LSP, the
previous hop node creates a forwarding entry with an inactive state or
flag called inactive forwarding entry."
* which flag is being referred to? I presume non-signalled flag, or mere
implementation detail?

8. Section 4.4:
" The previous hop node of the primary egress node SHALL detect the
failure of the link between the primary egress node and its destination
node (e.g. the failure of the link between L1 and CE1 in Figure 1).
 
..   
Failure of the destination node and the link between the primary egress
node and the destination node CAN be detected by a BFD session between the
previous hop node and the destination node."
* Not typical to trigger TE FRR on failures beyond the TE (sub)LSP path
(beyond the PE egress node).. Is it meant to cover slow routing
convergence (from PE to CE)?
* AFAIK, the multihop BFD session will detect reachability from prev hop
node to the destination node (not just L1-CE1 link liveliness).
 
"
   When we use the egress local protection to protect a primary egress
   node, we SHOULD NOT use any fast re-route to protect the link between
   the primary egress node and its previous hop node.  The failure of
   the link is protected by the egress protection.
"
* While this may work for protecting subLSPs terminating on the primary
egress node, there's still need to protect subLSPs transitting the primary
egress node (in case of primary bud node). For example, consider case of
facility bypass, one could potentially have 2 bypass tunnels (1 terminates
on backup egress node) and another on PLR NHOP (regular NHOP pass) to
protect the transit subLSPs.

9. Section 5:
* Typo: FFR -> FRR

10. Section 6:
"6. Representation of a Backup Sub LSP"
* rfc4090 defines two ways to identify backup subLSP (sender-template and
path specific).. I assume both apply, if so could mention this
* What about the backup subLSP sub-group fields (sub-group ID and
sub-group originator)?
  Are these assigned/set by the PLR since it originates the Path message?
 
"
   An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to
   specify the explicit route of a backup sub LSP that is from a
   previous hop node to a backup egress node.  The EB-SERO is defined in
   the following section.
"
* I'm not sure if the ingress really needs to compose and signal the
backup subLSP SERO, given:
  1. From rf4090, a PLR can independently (and optionally using
constraints set in the FAST_REROUTE object) route and signal the detour or
bypass tunnel.
  2. In some cases (ingress resides in a different IGP area/domain), the
ingress may not have the visibility to compute the path from PLR to the
backup egress node; however, the PLR could (provided backup egress node is
in its TED).

11. Section 6.1.1 
* Suggest rename "Egress IPv4 address" to Egress Primary Sub LSP IPv4
destination address

12. Section 7.2.1. Backup LSP for One-to-One Protection:
* It's not clear what goes on from the signalling perspective post the
egress node
  failure.
    - will the primary S2L subLSP (to the failed egress node) persist
after the egress node failure? If so,
    - will the fault (as detected by PLR) be notified back to the ingress
node, how?
    - How will the change of path (after reroute) of the primary S2L
subLSP be propagated
      back to the ingress?
    - What happens if the primary egress node (previously failed) recovers?
    - Would the backup egress node remain backup egress post the failure?

13. Section 7.2.1
"
   When a primary egress node of the LSP receives the Path message with
   an egress backup sub LSP descriptor list, it SHOULD ignore the egress
   backup sub LSP descriptor list and generate a PathErr message.
"
* I presume a transit/mid won't be allowed to act as a backup egress node
too (i.e. become
  bud after FRR)? If so, can be clarified
 
"
   If an intermediate node receives the Path message with an egress
   backup sub LSP descriptor list, it MUST put the EGRESS_BACKUP_SUB_LSP
   containing a backup egress into a Path message to be sent towards the
   backup egress.  This SHALL be done for each EGRESS_BACKUP_SUB_LSP
   containing a backup egress node in the list.
"
* Not clear? is what's intended to say that intermediate node forwards
EGRESS_BACKUP_SUB_LSP in the Path unchanged?

14. Section 7.2.2:
* Typo: satisifies -> satisfies
* The mechanisms proposed here are in violation of RFC4090
    (section 3.1): " 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."
    (section 3.2): "The bypass tunnel must intersect the path of the
original LSP(s) somewhere downstream of the PLR."
 
"
   When the previous hop node detects a failure in the primary egress,
   it has to imports the traffic for the protected P2MP LSP into the
   backup bypass tunnel using the backup label as the top label.
"
* statement not clear, suggest rewording.
* Not clear what's really involved in making local egress node protection
work with
  facility bypass tunnel
    Prior to the fault (egress node down):
        1. Will there be an S2L subLSP signaled to the backup egress node
or
           not?
    Post the fault (egress node down):
        2. For link-protection, the top (outer) label will be the bypass
tunnel label, and
           the inner label will be the label allocated by the next hop
(backup egress
           node (?)). It's not clear how this inner label is learnt back
at the PLR?
        3. If multiple primary egress nodes are being protected by same
backup egress node
           and same bypass tunnel, does the backup egress node allocate a
unique label for
           each?
        4. After the fault (egress node down), what happens to the primary
subLSP?

Thanks,
Tarek

On 2013-06-11 10:16 PM, "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: Fri, 21 Jun 2013 13:40:24 +0000

Hi Tarek,

    Thanks much for very useful comments. We will wait until we see the comments from all the MPLS-RT reviewers before updating the draft.

    Could you please give us a hint which of your comments you think are necessary to address before this document becomes a working group document?

Best Regards,
Huaimo

-----Original Message-----
From: Tarek Saad (tsaad) [mailto:[email-masked]] 
Sent: Thursday, June 20, 2013 6:52 PM
To: Ross Callon; Raveendra Torvi; Eric Gray; Lizhong Jin
Cc: [email-masked]; [email-masked]; Martin Vigoureux; [email-masked]
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi all,

Extensions to RSVP-TE for P2MP LSP Egress Local Protection, http://www.ietf.org/id/draft-chen-mpls-p2mp-egress-protection-09.txt

Overall, the draft is well written, the motivation is clear, and the proposal is sound. I think the document should be considered for WG adoption, but more discussions and input will be needed from the group on the proposed mechanisms.

More comments below:

2. Is the draft also intendeds to cover locally protecting egress nodes that act as transits/mids (aka P2MP bud LSR nodes)? Either way, could be helpful if it mentioned it.

3. Section 1:
"An existing method for protecting the egress nodes of a P2MP LSP sets up a backup P2MP LSP from a backup ingress node to the backup egress nodes."
* the backup P2MP LSP can also originate from same ingress node to the set of backup egress nodes.
* a variant would be to graft another primary S2L sub-LSP to the "backup"
egress node. Traffic flows on to both egress nodes, and receiver can select traffic from either based on route to source via RPF.

4. Section 4.1:

5. Consider
        PLR
      +--+--+
      |  |  |
      A  B  C
    /    |   \
   /     +    \
  /     / \    \
CE1---+    +--- CE2
 
* If the same backup egress node (e.g. B) is used to protect two or more primary egress nodes (e.g. A and C), when PLR reroutes traffic onto the backup (detour or bypass tunnel via B) due to a failure of one of the primary egress nodes (eg. A), the receiver(s) connected to other primary egress node(s) (e.g. CE2) starts to receive duplicated traffic (via C and via B).

6. Section 4.2:
"The previous hop node of the primary egress node sets up a backup sub LSP from itself"
* Arguably, a PLR is one that usually provisions/assigns backup (detour or bypass). Personally, favour using the term upstream node PLR over previous hop node (used extensively in the draft).

7. Section 4.3:
"After receiving the RSVP-TE RESV message for the backup sub LSP, the previous hop node creates a forwarding entry with an inactive state or flag called inactive forwarding entry."
* which flag is being referred to? I presume non-signalled flag, or mere implementation detail?

8. Section 4.4:
" The previous hop node of the primary egress node SHALL detect the failure of the link between the primary egress node and its destination node (e.g. the failure of the link between L1 and CE1 in Figure 1).
 
..   
Failure of the destination node and the link between the primary egress node and the destination node CAN be detected by a BFD session between the previous hop node and the destination node."
* Not typical to trigger TE FRR on failures beyond the TE (sub)LSP path (beyond the PE egress node).. Is it meant to cover slow routing convergence (from PE to CE)?
* AFAIK, the multihop BFD session will detect reachability from prev hop node to the destination node (not just L1-CE1 link liveliness).
 
"
* While this may work for protecting subLSPs terminating on the primary egress node, there's still need to protect subLSPs transitting the primary egress node (in case of primary bud node). For example, consider case of facility bypass, one could potentially have 2 bypass tunnels (1 terminates on backup egress node) and another on PLR NHOP (regular NHOP pass) to protect the transit subLSPs.

9. Section 5:
* Typo: FFR -> FRR

10. Section 6:
"6. Representation of a Backup Sub LSP"
* rfc4090 defines two ways to identify backup subLSP (sender-template and path specific).. I assume both apply, if so could mention this
* What about the backup subLSP sub-group fields (sub-group ID and sub-group originator)?
  Are these assigned/set by the PLR since it originates the Path message?
 
"
   An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to
   specify the explicit route of a backup sub LSP that is from a
   previous hop node to a backup egress node.  The EB-SERO is defined in
   the following section.
"
* I'm not sure if the ingress really needs to compose and signal the backup subLSP SERO, given:
  1. From rf4090, a PLR can independently (and optionally using constraints set in the FAST_REROUTE object) route and signal the detour or bypass tunnel.
  2. In some cases (ingress resides in a different IGP area/domain), the ingress may not have the visibility to compute the path from PLR to the backup egress node; however, the PLR could (provided backup egress node is in its TED).

11. Section 6.1.1
* Suggest rename "Egress IPv4 address" to Egress Primary Sub LSP IPv4 destination address

12. Section 7.2.1. Backup LSP for One-to-One Protection:
* It's not clear what goes on from the signalling perspective post the egress node
  failure.
    - will the primary S2L subLSP (to the failed egress node) persist after the egress node failure? If so,
    - will the fault (as detected by PLR) be notified back to the ingress node, how?
    - How will the change of path (after reroute) of the primary S2L subLSP be propagated
      back to the ingress?
    - What happens if the primary egress node (previously failed) recovers?
    - Would the backup egress node remain backup egress post the failure?

13. Section 7.2.1
"
* I presume a transit/mid won't be allowed to act as a backup egress node too (i.e. become
 
"
* Not clear? is what's intended to say that intermediate node forwards EGRESS_BACKUP_SUB_LSP in the Path unchanged?

14. Section 7.2.2:
* Typo: satisifies -> satisfies
* The mechanisms proposed here are in violation of RFC4090
    (section 3.1): " 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."
    (section 3.2): "The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR."
 
"
   When the previous hop node detects a failure in the primary egress,
   it has to imports the traffic for the protected P2MP LSP into the
   backup bypass tunnel using the backup label as the top label.
"
* statement not clear, suggest rewording.
* Not clear what's really involved in making local egress node protection work with
  facility bypass tunnel
    Prior to the fault (egress node down):
        1. Will there be an S2L subLSP signaled to the backup egress node or
           not?
    Post the fault (egress node down):
        2. For link-protection, the top (outer) label will be the bypass tunnel label, and
           the inner label will be the label allocated by the next hop (backup egress
           node (?)). It's not clear how this inner label is learnt back at the PLR?
        3. If multiple primary egress nodes are being protected by same backup egress node
           and same bypass tunnel, does the backup egress node allocate a unique label for
           each?
        4. After the fault (egress node down), what happens to the primary subLSP?

Thanks,
Tarek

On 2013-06-11 10:16 PM, "Ross Callon" <[email-masked]> wrote:

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

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Mon, 24 Jun 2013 04:20:19 +0000

Hi Huaimo,

On 2013-06-21 9:40 AM, "Huaimo Chen" <[email-masked]> wrote:

>Hi Tarek,
>
>    Thanks much for very useful comments. We will wait until we see the
>comments from all the MPLS-RT reviewers before updating the draft.
>
>    Could you please give us a hint which of your comments you think are
>necessary to address before this document becomes a working group
>document?
Ideally all; otherwise, an agreed roadmap on how the remaining items will
be addressed.

Regards,
Tarek

>Cc: [email-masked];
>[email-masked]; Martin Vigoureux;
>[email-masked]
>adoption, but more discussions and input will be needed from the group on
>the proposed mechanisms.
> 
>
>More comments below:
>* Arguably, a PLR is one that usually provisions/assigns backup (detour
>or bypass). Personally, favour using the term upstream node PLR over
>previous hop node (used extensively in the draft).
> 
>
>7. Section 4.3:
>node and the destination node CAN be detected by a BFD session between
>the previous hop node and the destination node."
>egress node, there's still need to protect subLSPs transitting the
>primary egress node (in case of primary bud node). For example, consider
>case of facility bypass, one could potentially have 2 bypass tunnels (1
>terminates on backup egress node) and another on PLR NHOP (regular NHOP
>pass) to protect the transit subLSPs.
> 
>
>9. Section 5:
>* Typo: FFR -> FRR
> 
> 
>
>10. Section 6:
>constraints set in the FAST_REROUTE object) route and signal the detour
>or bypass tunnel.
>backup egress node; however, the PLR could (provided backup egress node
>is in its TED).
> 
>
>11. Section 6.1.1

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 28 Jun 2013 02:42:40 +0000

Hi Tarek,

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

Best Regards,
Huaimo
-----Original Message-----
From: Tarek Saad (tsaad) [mailto:[email-masked]] 
Sent: Thursday, June 20, 2013 6:52 PM
To: Ross Callon; Raveendra Torvi; Eric Gray; Lizhong Jin
Cc: [email-masked]; [email-masked]; Martin Vigoureux; [email-masked]
Subject: Re: MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi all,

More comments below:
 
Huaimo: We will re-organize the next version of the draft accordingly.

Huaimo: Yes. We will add descriptions about this in the next version.

3. Section 1:

Huaimo: You are right. We will mention these in the next version.

4. Section 4.1:
 
Huaimo: Thanks much for your very careful reading! We will correct it.

5. Consider
        PLR
      +--+--+
      |  |  |
      A  B  C
    /    |   \
   /     +    \
  /     / \    \
CE1---+    +--- CE2

Huaimo: We may try to avoid this case. For a primary egress node of a P2MP LSP, there will be a different backup egress node dedicated to protect it. Thus two different primary egress nodes (e.g., A and C) of the LSP will have two different backup egress nodes (e.g., B and another node D). See figure below for reference.

         (P L R)
        / |   | \
       /  |   |  \
      /   |   |   \
     A    B   C    D
     \   /     \   /
      \ /       \ /
      CE1       CE2 

6. Section 4.2:
 
Huaimo: We will consider this in the next version.

7. Section 4.3:

Huaimo: You are right. The forwarding entry for a backup LSP is a local implementation issue. It is not related to signaling protocol. In one device, it may have an inactive state or flag. In another device, the implementation may be different. We will re-write this part in the next version.  

8. Section 4.4:
 
..   

Huaimo: We will focus on the failure in the primary egress in the next version. We were thinking to cover slow routing convergence.

"

Huaimo: You are right. In the case that the primary egress node is also a transit node, the previous hop (or upstream) node of the primary egress node MUST provide protections for those subLSPs going through the primary egress node. We will address this in the next version.

9. Section 5:
* Typo: FFR -> FRR
 
Huaimo: Thanks much for your very careful reading! We will correct it.

10. Section 6:

Huaimo: We will mention this in the next version.

Huaimo: Yes. They are assigned/set by the PLR. We will add descriptions about this in the next version.

"

Huaimo: The ingress does not need to provide any explicit path for the bypass or detour tunnel (defined in RFC4090) from a previous hop node to a backup egress node. The PLR (i.e., the previous hop node) of the primary egress can compute a path for the tunnel. 
Another option is that PLR may use a sub LSP from the PLR to the backup egress. This sub LSP is a special branch of the primary P2MP LSP. Except for that the PLR does not forward any traffic to this branch in normal operation, this special branch is the same as a regular branch of the primary P2MP LSP. If this option is used, the ingress needs to provide an explicit path from the PLR to the backup egress because the ingress knows the path that P2MP LSP traverses and can provide the explicit path not intersecting the P2MP LSP path. The PLR may not have the information about the P2MP LSP path. The path computed by the PLR may intersect with the P2MP LSP path.
In the case that the ingress resides in a different IGP area/domain, it may need help from others such as PCE. With the help from PCE, the ingress can get the whole path crossing different areas/domains. It can also get the path from the previous hop node to a backup egress node.

11. Section 6.1.1

Huaimo: We will consider renaming it in the next version.

Huaimo: The upstream part of the primary S2L subLSP will stay after the primary egress fails. The part downstream from the previous hop to the primary egress should be removed.

Huaimo: Yes. The PLR will notify the ingress about the fault of the primary egress node in the same way as a PLR notifies the ingress about the fault of an intermediate node. 

Huaimo: The PLR (i.e., the upstream node of the primary egress node) will update the RRO in the resv message to be sent upwards to the ingress. The path change is in the RRO.

Huaimo: This depends on the revertive behavior. In local revertive mode, the PLR re-signals the primary LSP (i.e., the S2L sub LSP to the primary egress node) after the primary egress node recovers and switches the traffic back to the primary LSP. We will add some detailed descriptions about this in the next version.

13. Section 7.2.1
"

Huaimo: We will add more descriptions to clarify this in the next version.

"
 
Huaimo: When an intermediate node splits the Path message into a few of Path messages to be sent downstream, it MUST split the backup sub LSP descriptor list accordingly. (e.g., when the Path message is split into two Path messages, one goes to a downstream node A towards a primary egress node PEa and the other goes to another downstream node B towards another primary egress node PEb, the intermediate node MUST put the EGRESS_BACKUP_SUB_LSP for the primary egress node PEa into the first Path message and the one for the primary egress node PEb into the second Path message.) We will re-write this to make it clear. 

14. Section 7.2.2:

Huaimo: Thanks much for your very careful reading! We will correct it.

Huaimo: The mechanisms proposed here can be considered as some special extensions to RFC4090. RFC4090 covers protections for intermediate nodes of an LSP. For protecting any intermediate node, the above two statements apply. A primary egress node without any next hops (i.e., a non bud egress) does not have any original LSP somewhere downstream the primary egress node. Thus RFC4090 can not be directly applied to protect the primary egress.

"

Huaimo: One way to get a label from the backup egress node is to signal an empty S2L subLSP to the backup egress node before the primary egress node fails. 
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 this S2L sub LSP (segment) extended from the primary LSP an empty primary LSP since it will not transport any traffic. See the figure below for reference.

One 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)
Previous hop (R3) does not sends control traffic by bypass LSP when primary egress fails

Another 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) partially reuses FRR to protect primary egress (L1)
Previous hop (R3) does not sends control traffic by bypass LSP when primary egress fails

Huaimo:  The previous hop (or upstream) node gets a label from the backup egress node in one of the ways mentioned above before the primary egress node fails. 
It will use this label as the inner label after the primary egress node fails. 

Huaimo: It is not allowed for one (same) backup egress node to protect multiple primary egress nodes of one (same) LSP. As you mentioned in comment 5, there will be duplicated traffic on CEs when one of the primary egress nodes fails. We will add some descriptions about this in the next version.

Huaimo: The upstream part of the primary subLSP will stay after the primary egress node fails. The part downstream from the previous hop of the primary egress node should be removed.

Huaimo: We will add more details about all these in the next version.

Thanks,
Tarek