Subject: Re: [spring] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Jun 2014 11:46:39 +0200

<IS-IS WG chair hat off>

i'm discomfortable with the *granularity* of the cap-advertisement:

rather than saying:

"i can crawl as deep as you like on any of my interfaces"

  i'd like to announce:

"i can crawl for EL <N> up to labels deep on interface XYZ"

/hannes

On Jun 3, 2014, at 2:17 PM, <[email-masked]> <[email-masked]> wrote:

> Hi,
> 
> IMHO, before defining the capability, I would be more interrested on seeing some progress on a solution for EL over SPRING. A draft exists with multiple options, maybe we should wait for one option to have consensus before worrying about ELC encoding (quite easy part of the EL for SPRING).
> 
> 
> Stephane
> 
> -----Message d'origine-----
> De : Isis-wg [mailto:[email-masked]] De la part de Xuxiaohu
> Envoyé : samedi 31 mai 2014 10:05
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
> 
> Hi WG co-chairs,
> 
> This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) describes how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRING networks. Since (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00) has been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption for this draft as well.
> 
> Best regards,
> Xiaohu (on behalf of all-authors)  
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 13:34:04 +0000

Hi Hannes,

I agree with you but if draft-kini-mpls-spring-entropy-label evolve to the option where entropy label is always behind top label, there is no need to encode such granularity.
That's why I think it's too early to progress the capability document.

Thoughts ?

Stephane

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]] 
Sent: Thursday, June 05, 2014 11:47
To: Xuxiaohu
Cc: [email-masked]; [email-masked]; [email-masked] list; LITKOWSKI Stephane SCE/IBNF; <[email-masked]>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

<IS-IS WG chair hat off>

rather than saying:

  i'd like to announce:

/hannes

On Jun 3, 2014, at 2:17 PM, <[email-masked]> <[email-masked]> wrote:

> Envoyé : samedi 31 mai 2014 10:05 À : [email-masked] Cc : 
> [email-masked]; [email-masked] Objet : 
> [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
> 
> Hi WG co-chairs,
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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: Xuxiaohu <[email-masked]>
Date: Fri, 6 Jun 2014 02:28:56 +0000

Hi Hannes,

It seems that you are not talking about the particular ELC concept as defined in RFC6790 (i..e, the capability of recognizing the ELI and popping that ELI and the following EL). Instead, it seems that you are talking about something else related to the capability of accessing the maximum label stack depth.

As for the granularity of the ELC advertisement (i.e., per-node basis or per-interface-board basis), it has been discussed before. Although the ELC is interface-board related, since it's almost impossible to determine at which interface a packet destined for one of the router's addresses would arrive (e.g., a MPLS packet with the top label being a node segment ID of a given LSR), the feasible way of advertising the ELC is: the egress LSR SHOULD not advertise its ELC unless all of its interface-boards have the ELC. By the way, this is exactly the same way that can be supported by RFC6790, IMHO.

Best regards,
Xiaohu 

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Hannes Gredler
> Sent: Thursday, June 05, 2014 5:47 PM
> To: Xuxiaohu
> Cc: [email-masked]; <[email-masked]>;
> [email-masked]; [email-masked] list
> > IMHO, before defining the capability, I would be more interrested on seeing
> some progress on a solution for EL over SPRING. A draft exists with multiple
> options, maybe we should wait for one option to have consensus before
> worrying about ELC encoding (quite easy part of the EL for SPRING).
> >
> >
> > Stephane
> >
> > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) describes how
> to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRING
> networks. Since
> (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00) has
> been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, we hope
> you could consider the WG adoption for this draft as well.
> >
> > Best regards,
> > 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.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 6 Jun 2014 02:37:05 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 05, 2014 9:34 PM
> To: Hannes Gredler; Xuxiaohu
> Cc: [email-masked]; [email-masked];
> [email-masked] list; <[email-masked]>
> Subject: RE: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
> 
> Hi Hannes,
> 
> I agree with you but if draft-kini-mpls-spring-entropy-label evolve to the option
> where entropy label is always behind top label, there is no need to encode such
> granularity.

Whether or not delay the adoption of the ELC advertisement doc, I have to point out the fact that the ELC advertisement DOESN'T impact the EL insertion solution, and vice versa. If you disagree, please give a concrete example.

Best regards,
Xiaohu

> Cc: [email-masked]; [email-masked];
> [email-masked] list; LITKOWSKI Stephane SCE/IBNF; <[email-masked]>
> _____________________________________________________________
> ____________________________________________________________
> 
> 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: Xuxiaohu <[email-masked]>
Date: Fri, 6 Jun 2014 03:52:37 +0000

Stephane ,

Oh, I finally realized the reason why we have different opinions on whether the ELC advertisement is orthogonal to the EL insertion solution. That's because we have different understanding of the concept of the "ELC". My understanding of the "ELC" is in accordance with the particular ELC concept as defined in RFC6790 (i.e., the capability of recognizing the ELI and popping ELI and EL, in addition, this is the capability of the EGRESS LSR). Your understanding of the "ELC" looks like a mix of the particular ELC concept as defined in RFC6790 and something else (e.g., the capability of accessing the max label stack deepth)

Best regards,
Xiaohu

> From: Xuxiaohu
> Sent: Friday, June 06, 2014 10:37 AM
> To: [email-masked]'; Hannes Gredler
> > I agree with you but if draft-kini-mpls-spring-entropy-label evolve to
> > the option where entropy label is always behind top label, there is no
> > need to encode such granularity.
> Whether or not delay the adoption of the ELC advertisement doc, I have to point
> out the fact that the ELC advertisement DOESN'T impact the EL insertion solution,
> and vice versa. If you disagree, please give a concrete example.
> 
> Best regards,
> Xiaohu
> 
> > Thoughts ?
> >
> > Stephane
> >
> > some progress on a solution for EL over SPRING. A draft exists with
> > multiple options, maybe we should wait for one option to have
> > consensus before worrying about ELC encoding (quite easy part of the EL for
> SPRING).
> > >
> > >
> > > Stephane
> > >
> > > De : Isis-wg [mailto:[email-masked]] De la part de
> > > Xuxiaohu Envoyé : samedi 31 mai 2014 10:05 À : [email-masked]
> Cc :
> > to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in
> > SPRING networks. Since
> > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions
> > -00) has been adopted as a WG draft, as co-authors of
> > draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption for
> this draft as well.
> > >
> > > Best regards,
> > _________
> > > 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,
> > > 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.
> > >
> > 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.
> >
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Jun 2014 09:14:31 +0200

valid point - i am not terribly happy with the EL behind the top label as it may require
new data plane capabilities (you need to retain the EL label while the
SR stack gets POPed off). - not sure if all existing MPLS HW does
support that.

/hannes

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 07:38:04 +0000

You are right, I think EL processing in SPRING is mainly an implementor discussion about what is possible to do, what's the impact on legacy HWs ...

Some HW may also never be able to look at EL if it's 7 or 8 labels after the top one ... and FAT PW solution (FAT label at bottom of stack) may not work anymore. 

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]] 
Sent: Friday, June 06, 2014 09:15
To: LITKOWSKI Stephane SCE/IBNF
Cc: Xuxiaohu; [email-masked]; [email-masked]; [email-masked] list; <[email-masked]>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

valid point - i am not terribly happy with the EL behind the top label as it may require new data plane capabilities (you need to retain the EL label while the SR stack gets POPed off). - not sure if all existing MPLS HW does support that.

/hannes 

On Jun 5, 2014, at 3:34 PM, <[email-masked]> wrote:

>> _____________________________________________________________________
>> _ ___________________________________________________
>>