Re: [Idr] draft-haas-idr-extended-experimental usage

[Jeffrey Haas <[e-mail]>]

"Shipping" this feature at path attribute code point 255 is honestly the least anti-social thing that implementor could have done.  Otherwise, they're just squatting. :-)

But yes, it's not a safe place to leave anything that needs to be operational.

I'm quite happy to dust off this draft and move it through adoption for IDR.  The Working Group will want to help finalize some of the issues raised by the initial discussion.  This is archived in the Appendices:
- Do we want to leverage this mechanism for private path attributes or solely for experiments?
- The filtering procedures in the specification heavily lean toward throwing everything out that you don't explicitly permit.  This intentionally makes the feature hard to use.  If this is to be used for anything besides experiments, we should discuss those procedures.

Original slides from IETF-97.
https://www.ietf.org/proceedings/97/slides/slides-97-idr-extended-experimental-path-attributes-00.pdf

-- Jeff


> On Jan 12, 2022, at 5:55 AM, Andrew Alston <Andrew.Alston=[e-mail]> wrote:
> 
> Thanks Job,
>  
> Just for the sake of clarity for the list to avoid misunderstanding – I was in no way advocating keeping this on code point 255, but rather, as you state, getting a new code point for this.  My statements about it being in use were merely about the fact that the format as specified in the draft is clearly being used in the wild, not that the code point was “in use and should therefore continue being used”
>  
> So yes, I fully support getting a code point for this.
>  
> Thanks
>  
> Andrew
>  
>  
> From: Idr <[e-mail]> On Behalf Of Job Snijders
> Sent: Wednesday, January 12, 2022 3:22 AM
> To: [e-mail]
> Subject: Re: [Idr] draft-haas-idr-extended-experimental usage
>  
> Hi all,
> 
> draft-haas-idr-extended-experimental is quite explicit about not using
> 255, it specifies "Path Attribute with a code of TBD". "TBD" != 255.
> 
> If we view Jared's hexadecimal dump through the eye of RFC 2042, and
> then through the eye of draft-haas-idr-extended-experimental-01... If
> I'm reading this correctly, 00 00 07 db == would represent Huawei's PEN
> according to draft-haas-idr-extended-experimental-01 Section 2 and
> https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers <https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers>
> 
> I'd be careful to use 255 in the wild Internet because it is meaningless
> forever: RFC 2042 does not have pointers to the TLV format specified in
> draft-haas-idr-extended-experimental.
> 
> The "Extended Experimental" concept would benefit from a *new* BGP Path
> Attribute. This makes debugging easier: a new unique BGP path attribute
> value allows BGP implementers to log/print information structured as
> described in draft-haas-idr-extended-experimental, whereas tools like
> bgpdump have to print something like "UNKNOWN_ATTR(X, 255, X): 0x 0x 0x"
> 
> Whatever happens 'behind' path attribute 255 is covered through RFC
> 2042. When introducing a TLV into the BGP ecosystem at this level, I
> think one a new BGP Path Attribute codepoint is required (a different
> one than 255).
> 
> In other words: draft-haas-idr-extended-experimental is NOT being used
> on the Internet, but if people wish to start using
> draft-haas-idr-extended-experimental on the Internet, a new codepoint
> should be requested through IANA Early Allocation. Also, two
> implementations should demonstrate an ability to interoperate with each
> other according to the normative terms in draft-haas-idr-extended-experimental,
> in order for the extended-experimental draft to progress to RFC.
> 
> Kind regards,
> 
> Job
> 
> On Tue, Jan 11, 2022 at 02:03:03PM -0500, Jared Mauch wrote:
> > It looks like it started to appear on the global table in these messages:
> > 
> > TIME: 03/09/21 21:08:40.553215
> > TYPE: BGP4MP_ET/MESSAGE/Update
> > FROM: 64.71.137.241 <http://64.71.137.241/> AS6939
> > TO: 128.223.51.102 <http://128.223.51.102/> AS6447
> > ORIGIN: IGP
> > ASPATH: 6939 39386 25019
> > NEXT_HOP: 64.71.137.241 <http://64.71.137.241/>
> > UNKNOWN_ATTR(224, 255, 22): 00 00 07 db 00 00 00 01 00 01 00 0a ff 08 00 00 00 00 86 de d1 b8
> > ANNOUNCE
> > 176.32.216.0/22 <http://176.32.216.0/22>
> > 176.32.220.0/22 <http://176.32.220.0/22>
> > 212.215.240.0/22 <http://212.215.240.0/22>
> > 212.215.244.0/22 <http://212.215.244.0/22>
> > 
> > I’ve not yet found any evidence of something earlier, but I didn’t do a comprehensive search.
> > 
> > - Jared
> > 
> > > On Jan 11, 2022, at 9:28 AM, Andrew Alston <Andrew.Alston=[e-mail] <mailto:Andrew.Alston=[e-mail]>> wrote:
> > > 
> > > Hi All,
> > > 
> > > I just happened to notice that there seems to be use of draft-haas-idr-extended-experimental on the open internet – interestingly using attribute code point 255.
> > > 
> > > Looking back at various dumps – it seems to have been there consistently for a good while as well – and this does seem to indicate that there is use case for this draft, to the point where at least one vendor based on the encoding is actively using this. Would it be worth applying for a proper code point for this though so that we’re not in a situation where we have an attribute sitting on the developmental code point for more than a year across multiple asn’s.
> > > 
> > > Perhaps an early allocation code point since the draft does seem to be in active use?
> > > 
> > > Thanks
> > > 
> > > Andrew
> > > 
> > > _______________________________________________
> > > Idr mailing list
> > > [e-mail] <mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> > 
> > _______________________________________________
> > Idr mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> _______________________________________________
> Idr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>_______________________________________________
> Idr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>