Subject: [mpls] Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 8 Aug 2014 19:45:11 +0000

Huaimo,

I have some questions and comments on the draft. I only started looking into this now so some of these might have been discussed before. In that case, you can just refer me to some old email in the archive for me to go through.

One big question I have is about the following:

   After receiving the Path message with the EGRESS_BACKUP, the primary
   egress includes the information about the primary LSP label in the
   Resv message with an EGRESS_BACKUP object as UA label.  When the PLR
   receives the Resv message with the information about the UA label, it
   includes the information in the Path message for the backup LSP to
   the backup egress.  Thus the primary LSP label as UA label is sent to
   the backup egress 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.

In the above text, the inner label is not service label like VPN/PWE3 label. It is the transport label assigned by the primary egress and relayed by the PLR to egress. How does the backup know what to do with that transport label and the application (e.g. vpn) label that follows it?

In other places, it talks about using BGP or some other protocols to distribute service labels and that seems reasonable. I suppose the above text is not correct?

The other big question is, compared to ingress signaling those additional flags and backup egress address via PATH messages, wouldn't it be easier for the primary egress to signal via RESV message to the PLR that it wants egress protection, and optionally specify the backup egress address? That way, the ingress and transit nodes are not bothered at all.

I'll leave out some smaller questions/comments for now.

Thanks.
Jeffrey

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 10 Aug 2014 19:59:08 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo
-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Friday, August 08, 2014 3:45 PM
To: Huaimo Chen
Cc: [email-masked]
Subject: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt

Huaimo,

Huaimo: The inner label here is not service label such as VPN label. It is the transport label allocated by the primary egress for the primary LSP. This part is added according to some comments. At the primary egress, the transport label may be used for some things. For example, it may be used for counting the number of packets received from the LSP. Thus it is better to stack the transport label for the primary LSP in the backup LSP when the primary egress fails if the label is used for some purposes. In the backup LSP, there may be three labels: the backup LSP label, the transport label for the primary LSP, and the service label such as VPN label.
At the backup egress, the backup LSP label is used as a context label, under this context, the transport label for the primary LSP and the service label are processed as upstream assigned labels. 

Huaimo: The above text talks about sending the transport label allocated by the primary egress for primary LSP to the backup egress as a UA label. There may be two UA labels in a backup LSP: one is the transport label, the other is the service label under the transport label.

Huaimo: This is a good question. Currently controlling and signaling the attributes (including flags) of backup LSPs for protecting a primary LSP against link and intermediate node failures starts from the ingress of the primary LSP via PATH messages. We follow this for the egress protection. 
There may be some advantages for the primary egress to signal/driven the egress protection. But there may be some disadvantages. For example, to protect a primary LSP against intermediate node and egress node failures, we need to do configurations on multiple places: one is on the ingress to configure intermediate node protection, the others are on the egresses to configure egress node protection. We can discuss on this in more details. 
It seems that some people proposed that a primary LSP set up is signaled/driven by the egress of the LSP. In this case, the egress protection signaled/driven by the egress seems a very good fit.

Thanks.
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 13 Aug 2014 14:18:47 +0000

Huaimo,

Please see below.

> From: Huaimo Chen [mailto:[email-masked]]
> Sent: Sunday, August 10, 2014 3:59 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: [email-masked]
> Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-
> protection-01.txt
> 
> Hi Jeffrey,
> 
> I have some questions and comments on the draft. I only started looking
> into this now so some of these might have been discussed before. In that
> case, you can just refer me to some old email in the archive for me to
> go through.
> 
> In the above text, the inner label is not service label like VPN/PWE3
> label. It is the transport label assigned by the primary egress and
> relayed by the PLR to egress. How does the backup know what to do with
> that transport label and the application (e.g. vpn) label that follows
> it?
> 
> Huaimo: The inner label here is not service label such as VPN label. It
> is the transport label allocated by the primary egress for the primary
> LSP. This part is added according to some comments. At the primary
> egress, the transport label may be used for some things. For example, it
> may be used for counting the number of packets received from the LSP.
> Thus it is better to stack the transport label for the primary LSP in
> the backup LSP when the primary egress fails if the label is used for
> some purposes. In the backup LSP, there may be three labels: the backup
> LSP label, the transport label for the primary LSP, and the service
> label such as VPN label.
> At the backup egress, the backup LSP label is used as a context label,
> under this context, the transport label for the primary LSP and the
> service label are processed as upstream assigned labels.
> 
> 
> In other places, it talks about using BGP or some other protocols to
> distribute service labels and that seems reasonable. I suppose the above
> text is not correct?
> 
> Huaimo: The above text talks about sending the transport label allocated
> by the primary egress for primary LSP to the backup egress as a UA label.
> There may be two UA labels in a backup LSP: one is the transport label,
> the other is the service label under the transport label.

While the PLR can relay the transport label from the primary egress to the backup egress, the forwarding behavior is not (at least not according to the spec). For example, in VPN case, the backup egress learns from the primary egress not just the values of VPN labels but also how to forward based on those labels (i.e. label to prefix bindings).

If there will be a separate mechanism outside the scope of this doc to be used, then there is no need for the PLR to relay the label via RSVP?

> 
> 
> The other big question is, compared to ingress signaling those
> additional flags and backup egress address via PATH messages, wouldn't
> it be easier for the primary egress to signal via RESV message to the
> PLR that it wants egress protection, and optionally specify the backup
> egress address? That way, the ingress and transit nodes are not bothered
> at all.
> 
> Huaimo: This is a good question. Currently controlling and signaling the
> attributes (including flags) of backup LSPs for protecting a primary LSP
> against link and intermediate node failures starts from the ingress of
> the primary LSP via PATH messages. We follow this for the egress
> protection.
> There may be some advantages for the primary egress to signal/driven the
> egress protection. But there may be some disadvantages. For example, to
> protect a primary LSP against intermediate node and egress node failures,
> we need to do configurations on multiple places: one is on the ingress
> to configure intermediate node protection, the others are on the
> egresses to configure egress node protection. We can discuss on this in
> more details.

Egress protection really has to be tied to the service so there likely to be service related configuration on the egress after all (and the ingress would need to learn/configure that). Using the ingress configuration for the regular link/node protection but limit egress protection configuration and signaling to the egress would be better.

> Huaimo: It seems that some people proposed that a primary LSP set up is
> signaled/driven by the egress of the LSP. In this case, the egress
> protection signaled/driven by the egress seems a very good fit.

The two topics should be separated :-)

Jeffrey