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

["Toy, Mehmet" <[e-mail]>]

Locally protecting egress nodes of a P2MP LSP reduces the time for protection switching and resources required for the protection. The proposal has been verified in a prototype. As one of the authors of this draft, I support its adaptation.
Thanks
Mehmet


From: Huaimo Chen
Sent: Thursday, June 27, 2013 9:58 PM
To: 'Raveendra Torvi'; Ross Callon
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-egress-protection

Hi Ravi,

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

Best Regards,
Huaimo

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

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.

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

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.

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


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

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


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

[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."?


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

[Huaimo] Can you give some more details about "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?

[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



      I----PH1--------PE-Primary

           |  \

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


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

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


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

[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