Subject: [Isis-wg] draft-ietf-isis-mpls-elc

From: <[email-masked]>
Date: Tue, 22 Sep 2015 15:12:32 +0000

Hi authors, all,

1) I wish the draft gave a precise definition of the RLSDC (Readable Label Stack Deepth Capability). (1)
It's not clear to me whether RLSDC is the number of labels before the ELI label, or the position of the ELI label in the stack, or the position of the EL label in the stack.

2) Also, if the ingress node has limitations in term of the number of labels that it can push (e.g. in the context of SPRING), it could potentially be useful to advertise whether the (EL, ELI) labels may be omitted. i.e. advertising the Readable Label Stack Depth before the IP header can be read for load-balancing purpose. Unfortunately the latter may be dependent on the type of protocol/header following the last MPLS label (e.g. IPv4, IPv6, control word...) but it may be good to have a discussion on this.

Thanks,
Regards,
Bruno

(1) Alternatively, the definition could be provided in draft-ietf-mpls-spring-entropy-label, but this draft is informational. Also it uses a slightly different term: RLD (Readable Label Depth)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 23 Sep 2015 02:17:50 +0000

Hi Bruno,

Thanks a lot for your comments. Please see my response inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 22, 2015 11:13 PM
> To: [email-masked]
> Cc: ISIS-WG
> Subject: draft-ietf-isis-mpls-elc
> 
> Hi authors, all,
> 
> 1) I wish the draft gave a precise definition of the RLSDC (Readable Label Stack
> Deepth Capability). (1) It's not clear to me whether RLSDC is the number of
> labels before the ELI label, or the position of the ELI label in the stack, or the
> position of the EL label in the stack.

It said in the Introduction section that

  " ...it would be useful for ingress LSRs to know each LSR's capability of
   reading the maximum label stack deepth.  This capability, referred to
   as Readable Label Stack Deepth Capability (RLSDC) can be used by
   ingress LSRs to determine whether it's necessary to insert an EL for
   a given LSP tunnel in the case where there has already been at least
   one EL in the label stack [I-D.ietf-mpls-spring-entropy-label]..."

The RLSDC is used to indicate how many labels the advertising router could read (from top to bottom) at most on the label stack of a received MPLS packet. It's one of the basic data-plane parameters for LSRs. As for how to apply this parameter to the EL usage, it's expected that the EL should occur within the RLD of all LSRs if possible and therefore multiple ELI/EL pairs may be inserted to the label stack of a given MPLS packet. For more details, please refer to [I-D.ietf-mpls-spring-entropy-label].

> 2) Also, if the ingress node has limitations in term of the number of labels that it
> can push (e.g. in the context of SPRING), it could potentially be useful to
> advertise whether the (EL, ELI) labels may be omitted. i.e. advertising the
> Readable Label Stack Depth before the IP header can be read for load-balancing
> purpose. Unfortunately the latter may be dependent on the type of
> protocol/header following the last MPLS label (e.g. IPv4, IPv6, control word...)
> but it may be good to have a discussion on this.

I agree it may be good to have a discussion on this in related WGs. However, since this draft is focused only on how to apply the EL concept to MPLS-SPRING networks, I wonder whether it's proper to include such discussion in this draft.

> Thanks,
> Regards,
> Bruno
> 
> (1) Alternatively, the definition could be provided in
> draft-ietf-mpls-spring-entropy-label, but this draft is informational. Also it uses a
> slightly different term: RLD (Readable Label Depth)

RLSD and RLD mean the same thing. "RLSD" would be replaced by "RLD" in the next version of draft-ietf-isis|ospf-mpls-elc.

Best regards,
Xiaohu

> 
> _____________________________________________________________
> ____________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute responsabilite
> si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 23 Sep 2015 05:21:31 +0000

Bruno,

I have published idr draft where BGP-LS is used to signal MSD (Max SID Depth - same terminology as in PCEP SR draft which defines MSD)of an ingress node, will publish IGP drafts in a week

Regards,
Jeff

> On Sep 22, 2015, at 7:18 PM, Xuxiaohu <[email-masked]> wrote:
> 
> Hi Bruno,
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: <[email-masked]>
Date: Wed, 23 Sep 2015 07:42:46 +0000

Hi Xuxiaohu,

Thanks for your answer.
Please see inline. #Bruno

> From: Xuxiaohu [mailto:[email-masked]] > Sent: Wednesday, September 23, 2015 4:18 AM
> 
> Hi Bruno,
> 
> The RLSDC is used to indicate how many labels the advertising router could
> read (from top to bottom) at most on the label stack of a received MPLS
> packet. It's one of the basic data-plane parameters for LSRs.

#Bruno: many LSR are capable of doing Load-Balancing (LB) based on the following IP packet. Hence the maximum number of readable labels could be understood as "before the IP header used for LB". In which case, one could "expect" that the ELI, EL labels are equally easy to hash than an IP header, hence the LEI, EL labels could be placed behind the RLSDC.

> As for how to
> apply this parameter to the EL usage, it's expected that the EL should occur
> within the RLD of all LSRs 

#Bruno: Sorry but "it's expected" and "should" does not seem specific enough to me for a standard track document.
Given that the purpose of this document is specifically to handle load-balancing with the entropy label, I think it should be better to indicate that both ELI and EL labels needs to be within the RLSDC. I've seen interop issues with more specific text.
I'm just asking for a normative text clarifying the meaning of RLSDC. No change on implementation.

> if possible and therefore multiple ELI/EL pairs may
> be inserted to the label stack of a given MPLS packet. For more details,
> please refer to [I-D.ietf-mpls-spring-entropy-label].
> 
> I agree it may be good to have a discussion on this in related WGs. However,
> since this draft is focused only on how to apply the EL concept to MPLS-
> SPRING networks, I wonder whether it's proper to include such discussion in
> this draft.

#Bruno: I think your draft would be a good home for this addition, but I can understand that this is a change and considered out of scope.

Thanks
-- Bruno

> RLSD and RLD mean the same thing. "RLSD" would be replaced by "RLD" in
> the next version of draft-ietf-isis|ospf-mpls-elc.
> 
> Best regards,
> Xiaohu
> 
> >
> > If you have received this email in error, please notify the sender and delete
> this
> > message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been
> > modified, changed or falsified.
> > Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 24 Sep 2015 02:10:01 +0000

Hi Bruno,

> Sent: Wednesday, September 23, 2015 3:43 PM
> To: Xuxiaohu
> Cc: ISIS-WG; [email-masked]
> Subject: RE: draft-ietf-isis-mpls-elc
> 
> Hi Xuxiaohu,
> 
> Thanks for your answer.
> > > 1) I wish the draft gave a precise definition of the RLSDC (Readable
> > > Label
> > Stack
> > > Deepth Capability). (1) It's not clear to me whether RLSDC is the
> > > number of labels before the ELI label, or the position of the ELI
> > > label in the stack, or
> > the
> > The RLSDC is used to indicate how many labels the advertising router
> > could read (from top to bottom) at most on the label stack of a
> > received MPLS packet. It's one of the basic data-plane parameters for LSRs.
> 
> #Bruno: many LSR are capable of doing Load-Balancing (LB) based on the
> following IP packet. Hence the maximum number of readable labels could be
> understood as "before the IP header used for LB". In which case, one could
> "expect" that the ELI, EL labels are equally easy to hash than an IP header, hence
> the LEI, EL labels could be placed behind the RLSDC.
> 
> > As for how to
> > apply this parameter to the EL usage, it's expected that the EL should
> > occur within the RLD of all LSRs
> 
> Given that the purpose of this document is specifically to handle load-balancing
> with the entropy label, I think it should be better to indicate that both ELI and EL
> labels needs to be within the RLSDC. I've seen interop issues with more specific
> text.

Understood. Would you please provide any text for clarifying the meaning of RLSDC?

> > if possible and therefore multiple ELI/EL pairs may be inserted to the
> > label stack of a given MPLS packet. For more details, please refer to
> > [I-D.ietf-mpls-spring-entropy-label].
> >
> > > 2) Also, if the ingress node has limitations in term of the number
> > > of labels
> > that it
> > > can push (e.g. in the context of SPRING), it could potentially be
> > > useful to advertise whether the (EL, ELI) labels may be omitted.
> > > i.e. advertising the Readable Label Stack Depth before the IP header
> > > can be read for load-
> > balancing
> > > protocol/header following the last MPLS label (e.g. IPv4, IPv6,
> > > control
> > word...)
> > I agree it may be good to have a discussion on this in related WGs.
> > However, since this draft is focused only on how to apply the EL
> > concept to MPLS- SPRING networks, I wonder whether it's proper to
> > include such discussion in this draft.
> 
> #Bruno: I think your draft would be a good home for this addition, but I can
> understand that this is a change and considered out of scope.

If I understood your point correctly, you wanted to make the ingress to take into account the MPLS payload inspection-based load-balancing capabilities of all other LSRs when inserting ELs into the label stack of a given packet. If so, wouldn't it make the EL insertion algorithms [I-D.ietf-mpls-spring-entropy-label] more complex?

Best regards,
Xiaohu

> > > draft-ietf-mpls-spring-entropy-label, but this draft is
> > > informational. Also it
> > uses a
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > > diffuses,
> > exploites ou
> > > copies sans autorisation. Si vous avez recu ce message par erreur,
> > > veuillez
> > le
> > > signaler a l'expediteur et le detruire ainsi que les pieces jointes.
> > > Les
> > messages
> > > This message and its attachments may contain confidential or
> > > privileged information that may be protected by law; they should not
> > > be distributed,
> > used

---

From: <[email-masked]>
Date: Thu, 24 Sep 2015 13:03:53 +0000

Hi Xuxiaohu,

Please see inline. #Bruno2

[...]

> > > > From: [email-masked] > [mailto:[email-masked]]
> > #Bruno: Sorry but "it's expected" and "should" does not seem specific
> enough to
> > me for a standard track document.
> > I'm just asking for a normative text clarifying the meaning of RLSDC. No
> change
> > on implementation.
> 

#Bruno2
I'd propose to define it in §4, following "The  Value field is set to the maximum readable label stack deepth in the range between 1 to 255."
By adding: "Both ELI and EL labels needs to be within the RLSD in order for the load-balancing to use the Entropy Label."

Note: given this definition, the value "1" (may be even "2") looks possibly invalid. Indeed, if you support EL as egress, you're supposed to be able to receive a  tunnel termination packet with label stack < ELI, EL, TL> <remaining  packet header> and forward it based on the TL label. Hence you need to read 3 labels.

> If I understood your point correctly, you wanted to make the ingress to take
> into account the MPLS payload inspection-based load-balancing capabilities of
> all other LSRs when inserting ELs into the label stack of a given packet. If so,
> wouldn't it make the EL insertion algorithms [I-D.ietf-mpls-spring-entropy-
> label] more complex?

#Bruno2
I wanted ingress to be able to know the MPLS payload inspection-based load-balancing capabilities of all other LSRs.
(Just like your draft advertises the MPLS EL based load-balancing capability).
That way, the ingress has additional information that it may use (or not, this is fully optional).

That way, the ingress is able to know that downstream LSR are capable of loadbalancing:
- based on the EL if EL is below RSLD labels
- based on payload if payload is below RSLD2 labels

If RSLD2>= (RSLD-2) (e.g. if RSLD2=RSLD) then the ingress may push less labels by not sending the ELI, EL labels (given that the downstream are capable of Load Balancing without EL). As a consequence, it saves 2 labels which may be used for other purposes (service, explicit routing in the spring context...)

Thanks,
Best regards,
Bruno

> _
> _

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 29 Sep 2015 06:33:08 +0000

Hi Bruno,

Sorry for my late response. 

> Sent: Thursday, September 24, 2015 9:04 PM
> To: Xuxiaohu
> > > > > 1) I wish the draft gave a precise definition of the RLSDC
> > > > > (Readable Label
> > > > Stack
> > > > > Deepth Capability). (1) It's not clear to me whether RLSDC is
> > > > > the number of labels before the ELI label, or the position of
> > > > > the ELI label in the stack, or
> > > > the
> > > > The RLSDC is used to indicate how many labels the advertising
> > > > router could read (from top to bottom) at most on the label stack
> > > > of a received MPLS packet. It's one of the basic data-plane
> > > > parameters for
> > LSRs.
> > >
> > > #Bruno: many LSR are capable of doing Load-Balancing (LB) based on
> > > the following IP packet. Hence the maximum number of readable labels
> > > could
> > be
> > > understood as "before the IP header used for LB". In which case, one
> > > could "expect" that the ELI, EL labels are equally easy to hash than
> > > an IP header,
> > hence
> > > > apply this parameter to the EL usage, it's expected that the EL
> > > > should occur within the RLD of all LSRs
> > >
> > > Given that the purpose of this document is specifically to handle
> > > load-
> > balancing
> > > with the entropy label, I think it should be better to indicate that
> > > both ELI
> > and EL
> > > labels needs to be within the RLSDC. I've seen interop issues with
> > > more
> > specific
> > > text.
> I'd propose to define it in §4, following "The  Value field is set to the maximum
> readable label stack deepth in the range between 1 to 255."
> By adding: "Both ELI and EL labels needs to be within the RLSD in order for the
> load-balancing to use the Entropy Label."

That text looks good to me.

> Note: given this definition, the value "1" (may be even "2") looks possibly invalid.
> Indeed, if you support EL as egress, you're supposed to be able to receive a
> tunnel termination packet with label stack < ELI, EL, TL> <remaining  packet
> header> and forward it based on the TL label. Hence you need to read 3 labels.

IMHO, the RLD value of 1 or 2 should be valid for some particular LSRs. Of course, those LSRs could not support EL-based load-balancing. In other words, the RLD is an intrinsic property of any LSR regardless of its load-balancing capability.

> > > > if possible and therefore multiple ELI/EL pairs may be inserted to
> > > > the label stack of a given MPLS packet. For more details, please
> > > > refer to [I-D.ietf-mpls-spring-entropy-label].
> > > >
> > > > > 2) Also, if the ingress node has limitations in term of the
> > > > > number of labels
> > > > that it
> > > > > can push (e.g. in the context of SPRING), it could potentially
> > > > > be useful to advertise whether the (EL, ELI) labels may be omitted.
> > > > > i.e. advertising the Readable Label Stack Depth before the IP
> > > > > header can be read for load-
> > > > balancing
> > > > > purpose. Unfortunately the latter may be dependent on the type
> > > > > of protocol/header following the last MPLS label (e.g. IPv4,
> > > > > IPv6, control
> > > > word...)
> > > #Bruno: I think your draft would be a good home for this addition,
> > > but I can understand that this is a change and considered out of scope.
> >
> > If I understood your point correctly, you wanted to make the ingress
> > to take into account the MPLS payload inspection-based load-balancing
> > capabilities of all other LSRs when inserting ELs into the label stack
> > of a given packet. If so, wouldn't it make the EL insertion algorithms
> > [I-D.ietf-mpls-spring-entropy- label] more complex?
> 
> #Bruno2
> I wanted ingress to be able to know the MPLS payload inspection-based
> load-balancing capabilities of all other LSRs.

> If RSLD2>= (RSLD-2) (e.g. if RSLD2=RSLD) then the ingress may push less labels
> by not sending the ELI, EL labels (given that the downstream are capable of Load
> Balancing without EL). As a consequence, it saves 2 labels which may be used for
> other purposes (service, explicit routing in the spring context...)

If the MPLS WG community could reach a consensus on the above change to the EL insertion algorithm as described in [I-D.ietf-mpls-spring-entropy- label], it makes sense to extend IGP to advertise the MPLS payload inspection-based load-balancing capability.

Best regards,
Xiaohu

> > > > RLSD and RLD mean the same thing. "RLSD" would be replaced by
> > > > "RLD" in the next version of draft-ietf-isis|ospf-mpls-elc.
> > > >
> > > > Best regards,
> > > > Xiaohu
> > > >
> > > > >
> > > > >
> > >
> >
> > > > > Ce message et ses pieces jointes peuvent contenir des
> > > > > informations confidentielles ou privilegiees et ne doivent donc
> > > > > pas etre diffuses,
> > > > exploites ou
> > > > > copies sans autorisation. Si vous avez recu ce message par
> > > > > erreur, veuillez
> > > > le
> > > > > electroniques etant susceptibles d'alteration, Orange decline
> > > > > toute
> > > > responsabilite
> > > > > privileged information that may be protected by law; they should
> > > > > not be distributed,
> > > > used
> > > veuillez le signaler a l'expediteur et le detruire ainsi que les
> > > pieces jointes. Les
> > messages
> > > As emails may be altered, Orange is not liable for messages that
> > > have been modified, changed or falsified.
> > > Thank you.
> 
>

---

From: <[email-masked]>
Date: Tue, 29 Sep 2015 07:13:58 +0000

Hi Xuxiaohu,

Thanks for your answer.
Please see inline.  #Bruno3

> From: Xuxiaohu [mailto:[email-masked]] > Sent: Tuesday, September 29, 2015 8:33 AM
> 
> Hi Bruno,
> 

#Bruno3 ok, thanks

> IMHO, the RLD value of 1 or 2 should be valid for some particular LSRs. Of
> course, those LSRs could not support EL-based load-balancing. In other words,
> the RLD is an intrinsic property of any LSR regardless of its load-balancing
> capability.

#Bruno3 ok
 
> > That way, the ingress has additional information that it may use (or not, this
> is
> > fully optional).
> >
> If the MPLS WG community could reach a consensus on the above change to
> the EL insertion algorithm as described in [I-D.ietf-mpls-spring-entropy- label],

#Bruno3  I'm not sure that we need to change the above draft:
- mpls draft is mostly discussing how to insert the EL labels (in the spring context). Here my proposition is about not inserting it. So it could be seen as independent of this mpls draft
- mpls draft is informational only. Here the proposition is to advertise some additional information. Ingress _doesn't have_ to use it.

But discussion within the MPLS WG would indeed be good.

> it makes sense to extend IGP to advertise the MPLS payload inspection-based
> load-balancing capability.

#Bruno3 ok, thanks
 
Best regards,
Bruno

> > > > > > have