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

[Keyur Patel <[e-mail]>]

Quick curious question.  IANA already marks 255 reserved. Shouldn’t we have a default attribute filtering for type 255 implemented in networks?

Best Regards,
Keyur

From: Idr <[e-mail]> on behalf of Jeffrey Haas <[e-mail]>
Date: Wednesday, January 12, 2022 at 3:48 AM
To: Andrew Alston <Andrew.Alston=[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Job Snijders <job=[e-mail]>
Subject: Re: [Idr] draft-haas-idr-extended-experimental usage

"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

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
>
> _______________________________________________
> Idr mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr