Subject: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt

From: "John G. Scudder" <[email-masked]>
Date: Wed, 18 Jun 2014 16:06:38 -0400

Folks,

I would like to request MPLS WG adoption of this draft. I'm hoping we can progress it expeditiously. The only action it takes is to deprecate the BGP Entropy Label Capabilty path attribute as defined in RFC 6790 S. 5.2.

Note that it's extremely short (3 pages including the usual boilerplate, so about one page of content).

Thanks,

--John

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt
> Date: June 18, 2014 at 2:11:36 PM EDT
> To: John G.Scudder <[email-masked]>, Kireeti Kompella <[email-masked]>, Kireeti Kompella <[email-masked]>, John Scudder <[email-masked]>
> 
> 
> A new version of I-D, draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt
> has been successfully submitted by John G. Scudder and posted to the
> IETF repository.
> 
> Name:		draft-scudder-mpls-deprecate-bgp-entropy-label
> Revision:	00
> Title:		Deprecation of BGP Entropy Label Capability Attribute
> Document date:	2014-06-17
> Group:		Individual Submission
> Pages:		3
> URL:            http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entropy-label/
> Htmlized:       http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-label-00
> 
> 
> Abstract:
>   RFC 6790 defines the BGP Entropy Label Capability attribute.
>   Regrettably, it has a bug: although RFC 6790 mandates that Entropy
>   Label-incapable routers must remove the attribute, in practice this
>   requirement can't be guaranteed to be fulfilled.  This specification
>   deprecates the attribute.  A forthcoming document will propose a
>   replacement.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 18 Jun 2014 20:58:33 +0000

Hi John, et. al,
if the problem been identified, ELC may not be removed by EL-incapable router, and the fix is on its way, why not to address the issue through errata process? Or the plan is not to have BGP ELC attribute altogether?

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Wednesday, June 18, 2014 1:07 PM
To: [email-masked]; [email-masked]
Subject: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt

Folks,

Thanks,

--John

Begin forwarded message:

> Subject: New Version Notification for 
> draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt
> To: John G.Scudder <[email-masked]>, Kireeti Kompella 
> <[email-masked]>, Kireeti Kompella <[email-masked]>, John 
> Scudder <[email-masked]>
> 
> 
> A new version of I-D, 
> draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 18 Jun 2014 17:12:08 -0400

Hi Greg,

The guidance I got from the ADs was that an erratum isn't suitable for this kind of issue. It's to be used for stuff more like a typographical error, or at worst an omission of the authors to properly express what the WG consensus was. 

The reason for having a "deprecate" draft to be followed by a fix draft, instead of combining the two, is that it seems time is of the essence for the "deprecate" step (to make sure implementors know there is an issue) and it seems reasonable to hope for quick WG consensus and advancement of that step, which would let IANA update the registry. It will probably take somewhat longer -- though I hope not too long -- to advance a replacement. 

(In the past I have watched an AD try to "save work" by getting IANA to update a registry without an enabling RFC. Suffice it to say the AD did not save any work.)

The plan is still to have a BGP ELC attribute, but one that doesn't have the bug described in the deprecate draft.

Thanks,

--John

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 19 Jun 2014 03:30:50 +0000

Hi John,

If I understand it correctly, the BGP EL capability is only applicable to labeled BGP [RFC3701], it means the EL will be always inserted below the label advertised by the labeled BGP, rather than the label of the LSP destined for the intermediate BGP nexthop. In other words, the label advertised by the labeled BGP would not be popped by the intermediate node modifying the next hop of a labeled bgp route, as a result, it doesn't require that node to process the EL. Hence, no matter the intermediate node modifying the next hop of a labeled bgp route is capable of processing ELs or not, it's safe for it to process the EL attribute as a normal optional, transitive attributes. Did I miss something?

Best regards,
Xiaohu

> Sent: Thursday, June 19, 2014 4:07 AM
> Subject: [mpls] adoption request for
> I would like to request MPLS WG adoption of this draft. I'm hoping we can
> progress it expeditiously. The only action it takes is to deprecate the BGP Entropy
> Label Capabilty path attribute as defined in RFC 6790 S. 5.2.
> 
> > URL:
> http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-entropy
> -label-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entropy-lab
> el/
> > Htmlized:
> http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-label-00
> >
> >
> > Abstract:

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 19 Jun 2014 03:56:53 +0000

Hi John,

"For correct operation, it
   is necessary that an intermediate node modifying the next hop of a
   route must remove the ELCA unless the node so doing is able to
   process entropy labels."

The above argument quoted from your above draft seems not in accordance with that of RFC6790 (see below):

"However, if T changes the NEXT_HOP attribute for U and in the data
   plane pops the entire label stack to process the payload, T MAY
   include an ELC attribute for UPDATE U' if both of the following are
   true:

   C1:  T sets the NEXT_HOP attribute of U' to itself AND

   C2:  T can process entropy labels.

   Otherwise, T MUST remove the ELC attribute."

BTW, I'm wondering in which REAL case an intermediate node modifying the next hop of a labeled BGP route needs to pop the entire label stack.

Best regards,
Xiaohu

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Thursday, June 19, 2014 4:07 AM
To: [email-masked]; [email-masked]
Subject: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt

Folks,

Thanks,

--John

---

From: <[email-masked]>
Date: Thu, 19 Jun 2014 10:11:56 +0000

Hi Xiaohu,

Please see some comments inline

> From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu > Sent: Thursday, June 19, 2014 5:31 AM
> 
> Hi John,
> 
> If I understand it correctly, the BGP EL capability is only applicable to labeled
> BGP [RFC3701],

Which includes 6PE routes (as per RFC 4798) which could be used by AS1. Such labeled routes may be transported unlabeled in the Internet across AS2. And then labeled back in AS3 also using 6PE.
As per RFC 6790, if AS2 and the egress ASBR in AS3 do not support BGP EL attribute, the BGP attribute will be tunneled up to the ingress ASBR in AS3.
If the ingress supports EL, it will add the EL labels and the egress ASBR in AS3 will drop the traffic, even though all ASes did valid things.

Possibly same issues with IP VPNs (customer/CE using 6PE routes, SP/PE using VPN routes)

Best regards,
Bruno

> it means the EL will be always inserted below the label
> advertised by the labeled BGP, rather than the label of the LSP destined for
> the intermediate BGP nexthop. In other words, the label advertised by the
> labeled BGP would not be popped by the intermediate node modifying the
> next hop of a labeled bgp route, as a result, it doesn't require that node to
> process the EL. Hence, no matter the intermediate node modifying the next
> hop of a labeled bgp route is capable of processing ELs or not, it's safe for it to
> process the EL attribute as a normal optional, transitive attributes. Did I miss
> something?
> 
> Best regards,
> Xiaohu
> 
> 
> > I would like to request MPLS WG adoption of this draft. I'm hoping we
> > can progress it expeditiously. The only action it takes is to
> > deprecate the BGP Entropy Label Capabilty path attribute as defined in RFC
> 6790 S. 5.2.
> >
> > Note that it's extremely short (3 pages including the usual
> > boilerplate, so about one page of content).
> >
> > Thanks,
> >
> > --John
> >
> > Begin forwarded message:
> >

_________________________________________________________________________________________________________________________

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: "John G. Scudder" <[email-masked]>
Date: Thu, 19 Jun 2014 15:35:56 -0400

Hi Xiaohu,

Bruno has already replied to your first comment regarding applicability. I agree with his remarks.

As regards the below "not in accordance", that's exactly the point -- 6790 says "Otherwise, T MUST remove the ELC attribute."" But as Bruno observes in his email, and as the Internet Draft points out, if T doesn't support EL (and ELCA) then even though 6790 says "T MUST remove the ELC attribute", in reality T will NOT remove it. Thus we have a contradiction between the (per-spec) operation of the BGP protocol, and the correctness assumptions of 6790 S. 5.2. In such a contradiction between noble aspirations (6790) and deployed code (what BGP actually does) the deployed code wins. :-/

Thanks,

--John