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

From: Andrew Alston <[email-masked]>
Date: Tue, 11 Jan 2022 14:28:56 +0000

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

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Jan 2022 14:03:03 -0500

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 AS6939
TO: 128.223.51.102 AS6447
ORIGIN: IGP
ASPATH: 6939 39386 25019
NEXT_HOP: 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
  176.32.220.0/22
  212.215.240.0/22
  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=[email-masked]> 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.
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Job Snijders <[email-masked]>
Date: Wed, 12 Jan 2022 01:22:25 +0100

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

---

From: Job Snijders <[email-masked]>
Date: Wed, 12 Jan 2022 01:43:20 +0100

On Tue, Jan 11, 2022 at 02:28:56PM +0000, Andrew Alston wrote:
> 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.

Yes, worth it.

Longer elaboration here: https://mailarchive.ietf.org/arch/msg/idr/1UXeHXaSZGFixrtDTFt92soauso/

Kind regards,

Job

---

From: Andrew Alston <[email-masked]>
Date: Wed, 12 Jan 2022 10:55:51 +0000

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 <[email-masked]> On Behalf Of Job Snijders
Sent: Wednesday, January 12, 2022 3:22 AM
To: [email-masked]
Subject: Re: [Idr] draft-haas-idr-extended-experimental usage

Hi all,

https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers<https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers>

Kind regards,

Job

On Tue, Jan 11, 2022 at 02:03:03PM -0500, Jared Mauch wrote:
> 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>
> 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>
>
> > On Jan 11, 2022, at 9:28 AM, Andrew Alston <Andrew.Alston=[email-masked]<mailto:Andrew.Alston=[email-masked]>> wrote:
> >
> > Hi All,
> >
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jan 2022 06:48:26 -0500

"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=[email-masked]> wrote:
> 
> Thanks Job,
>  
> https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers <https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers>
> 
> > 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/>
> > 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>
> > 
> > > On Jan 11, 2022, at 9:28 AM, Andrew Alston <Andrew.Alston=[email-masked] <mailto:Andrew.Alston=[email-masked]>> wrote:
> > > 
> > > Hi All,
> > > 
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>_______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Keyur Patel <[email-masked]>
Date: Mon, 17 Jan 2022 20:14:13 +0000

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

-- Jeff

Thanks Job,

Thanks

Andrew

Hi all,

Kind regards,

Job

On Tue, Jan 11, 2022 at 02:03:03PM -0500, Jared Mauch wrote:
> 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/>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 31 Jan 2022 12:07:20 +0000

Keyur Patel wrote on 17/01/2022 20:14:
> Quick curious question.  IANA already marks 255 reserved. Shouldn’t we 
> have a default attribute filtering for type 255 implemented in networks?

this should a recommended operational default for ebgp sessions, yes, 
but we've managed to get away without formally documenting this since 
rfc2042 was published, so it's not of burning importance.

Nick