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

From: Huaimo Chen <[email-masked]>
Date: Sun, 5 Oct 2014 18:44:43 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo
-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Wednesday, August 13, 2014 10:19 AM
To: Huaimo Chen
Cc: [email-masked]
Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt

Huaimo,

Please see below.

> -----Original Message-----
> 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,
> 
>     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,
> 
> 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?
> 
> 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?

Huaimo: We may use a separate mechanism outside the scope of this document. It seems that the alternative option proposed in this document may also be used since it may have some advantages. 

> 
> 
> 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: If we configure egress protection on egress, it seems that there are more work. For example, in order to protect the egresses of a P2MP LSP, we need configure egress protection on every egress of the P2MP LSP.

> 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

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 6 Oct 2014 03:32:50 +0000

Huaimo,

> Sent: Sunday, October 05, 2014 2:45 PM
> 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?
> 
> Huaimo: We may use a separate mechanism outside the scope of this
> document. It seems that the alternative option proposed in this document
> may also be used since it may have some advantages.

My point is that, what's proposed in this draft can't really work, because while the backup can learn the label relayed by the PLR, it still does not know what to do with it. Until you have a separate document to spell out that separate mechanism, there is no point for this spec to relay the label.

> 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: If we configure egress protection on egress, it seems that there
> are more work. For example, in order to protect the egresses of a P2MP
> LSP, we need configure egress protection on every egress of the P2MP LSP.

It's the same amount of information configured, either all on the ingress PE or separated on all egress PEs. The latter will have much lower signaling head.

Jeffrey

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 6 Oct 2014 12:55:58 +0000

Hi Jeffrey,

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

Best Regards,
Huaimo
-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Sunday, October 05, 2014 11:33 PM
To: Huaimo Chen
Cc: [email-masked]
Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt

Huaimo,

> > 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?
> >
> > 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 
> > 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.
> >
> >
> document. It seems that the alternative option proposed in this 
> document may also be used since it may have some advantages.

Huaimo: It seems that the alternative option proposed may work. The UA label with the forwarding information in TLV may be relayed to the backup egress. RSVP on the backup egress can pass the UA label with the information to a separated component handling the UA label. In fact, RSVP just relays the UA label and related information. The processing on UA label is done by the separated component outside of RSVP.

> > 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.
> >
> > 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.
> 
> Huaimo: If we configure egress protection on egress, it seems that 
> there are more work. For example, in order to protect the egresses of 
> a P2MP LSP, we need configure egress protection on every egress of the P2MP LSP.

Huaimo: It seems that there are more configurations. For example, we may need to configure one-to-one protection or facility protection for protecting the egresses of a P2MP LSP on every egress of the P2MP LSP if we limit egress protection configuration to the egresses. 

Jeffrey

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 6 Oct 2014 13:12:46 +0000

Huaimo,

... snipped ...

> My point is that, what's proposed in this draft can't really work,
> because while the backup can learn the label relayed by the PLR, it
> still does not know what to do with it. Until you have a separate
> document to spell out that separate mechanism, there is no point for
> this spec to relay the label.
> 
> Huaimo: It seems that the alternative option proposed may work. The UA
> label with the forwarding information in TLV may be relayed to the
> backup egress. RSVP on the backup egress can pass the UA label with the
> information to a separated component handling the UA label. In fact,
> RSVP just relays the UA label and related information. The processing on
> UA label is done by the separated component outside of RSVP.

Currently the draft does not specify that forwarding information is relayed to the backup egress. I don't see how the backup egress know what to do when it receives the packets w/o additional signaling. If you do specify the mechanisms and procedures in a separate spec on how that can be done, then it's fine; but until you do so, it should not be mentioned here. Chances are that, once you have a separate mechanism, you may not need the PLT to relay any more.

> It's the same amount of information configured, either all on the
> ingress PE or separated on all egress PEs. The latter will have much
> lower signaling head.
> 
> Huaimo: It seems that there are more configurations. For example, we may
> need to configure one-to-one protection or facility protection for
> protecting the egresses of a P2MP LSP on every egress of the P2MP LSP if
> we limit egress protection configuration to the egresses

The draft currently signals pairs of primary/egress from the ingress. That means configuration is needed for each egress anyway (though it's on ingress). If you do the configuration on egress, it's still the same amount, and you spare the transit routers from having to process the extra signaling.

Jeffrey

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 6 Oct 2014 13:36:49 +0000

Hi Jeffrey,

Best Regards,
Huaimo
-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Monday, October 06, 2014 9:13 AM
To: Huaimo Chen
Cc: [email-masked]
Subject: RE: Questions and comments on draft-ietf-mpls-rsvp-egress-protection-01.txt

Huaimo,

... snipped ...

> backup egress. RSVP on the backup egress can pass the UA label with 
> the information to a separated component handling the UA label. In 
> fact, RSVP just relays the UA label and related information. The 
> processing on UA label is done by the separated component outside of RSVP.

Huaimo: It seems that TLVs under the UA label are mentioned in the draft. They may contain the forwarding information, which may be opaque to RSVP.  

> Huaimo: It seems that there are more configurations. For example, we 
> may need to configure one-to-one protection or facility protection for 
> protecting the egresses of a P2MP LSP on every egress of the P2MP LSP 
> if we limit egress protection configuration to the egresses

Jeffrey