Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 11:01:20 -0400

WG: 

Early testing of the Large Communities draft
(draft-ietf-idr-large-community-03.txt)  with attribute value of 30 detect
that we had an implementation squatting on attribute 30 by a Huawei router.
"Squatting" on an attribute is anti-social behavior in the Internet in any
release of software.  

The individuals who did in Huawei have been contacted by Jie Dong, and
"asked" if they had made this mistake in any other attribute.   These
individuals confessed to Attribute 129 (for wide communities).  These
individuals apologize to the Working group.  

Now what shall we do? The large community draft is critical for several
networks. After talking with the developers and operators, John and I would
like to recommend we do the following: 

IDR should recommend that the following attribute numbers be deprecated:  

BGP Attribute 30 

BGP attribute 129 

IDR should ask IANA to assign BGP Large Communities (currently Attribute 30)
to a new attribute number.  This is a 1 week call to determine if the IDR
approves this action.   This call will allow the large communities draft to
still continue with the 2 week WG LC.  

John, Alvaro, and I have check the early allocation rules.  Implementations
should ask for early allocation prior to releasing, and they do not need to
be interoperability testing to request the early allocation for the
attribute. 

Sue Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Oct 2016 11:19:22 -0400

Sue,

If 129 is not otherwise contended for, it may be reasonable to simply request early allocation for the wide communities code point.

-- Jeff

> On Oct 18, 2016, at 11:01 AM, Susan Hares <[email-masked]> wrote:
> 
> WG: 
>  
> Early testing of the Large Communities draft (draft-ietf-idr-large-community-03.txt)  with attribute value of 30 detect that we had an implementation squatting on attribute 30 by a Huawei router.   “Squatting” on an attribute is anti-social behavior in the Internet in any release of software.  
>  
> The individuals who did in Huawei have been contacted by Jie Dong, and “asked” if they had made this mistake in any other attribute.   These individuals confessed to Attribute 129 (for wide communities).  These individuals apologize to the Working group.  
>  
> Now what shall we do? The large community draft is critical for several networks. After talking with the developers and operators, John and I would like to recommend we do the following: 
>  
> IDR should ask IANA to assign BGP Large Communities (currently Attribute 30) to a new attribute number.  This is a 1 week call to determine if the IDR approves this action.   This call will allow the large communities draft to still continue with the 2 week WG LC.  
>  
> John, Alvaro, and I have check the early allocation rules.  Implementations should ask for early allocation prior to releasing, and they do not need to be interoperability testing to request the early allocation for the attribute. 
>  
> Sue Hares 
>  
>  
> _______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 10:24:34 -0500

On Tue, Oct 18, 2016 at 11:19:22AM -0400, Jeffrey Haas wrote:
> If 129 is not otherwise contended for, it may be reasonable to simply
> request early allocation for the wide communities code point.

and in doing so encourage early self-allocation? :)

At this point it is not even clear what exactly has been implemented,
the wide communities effort might suffer from an incompatible deployment
in the wild. I'd steer clear from this.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 10:30:47 -0500

On Tue, Oct 18, 2016 at 11:01:20AM -0400, Susan Hares wrote:
> (draft-ietf-idr-large-community-03.txt)  with attribute value of 30
> detect that we had an implementation squatting on attribute 30 by a
> Huawei router.  "Squatting" on an attribute is anti-social behavior in
> the Internet in any release of software.  
> 
> IDR should ask IANA to assign BGP Large Communities (currently
> Attribute 30) to a new attribute number.  This is a 1 week call to
> determine if the IDR approves this action.   This call will allow the
> large communities draft to still continue with the 2 week WG LC.  

I support this course of action.

background: Some in the working group might wonder why Large should
change instead of Huawei.

Huawei routers are treating routes with Large BGP Communities as
"withdraw", which makes Large BGP Communities deployments suffer. Large
BGP Communities users become unreachable on attribute 30.

Had the squatting resulted in Huawei routers crashing or some other form
of damage on the Huawei side, the onus would be on Huawei users. This is
not the case unfortunatly.

There are no winners if either side holds their ground and remains on
the codepoint. For Large BGP Communities it is still early enough to
update the implementations. Changing the Large BGP Communities path
attribute value is a risk adverse strategy.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Oct 2016 11:32:04 -0400

> On Oct 18, 2016, at 11:24 AM, Job Snijders <[email-masked]> wrote:
> 

Or avoid burning a code point when it may simply be asked for formally again.

> in the wild. I'd steer clear from this.

With regard to the feature maturity discussion, I tend to agree.  But there's still the general issue about how to pick a code point to do any sort of testing.  We have internal guidelines for such things, but once you get into early deployment scenarios, it gets complicated.

Conversation on this obviously should continue.

-- Jeff

---

From: <[email-masked]>
Date: Tue, 18 Oct 2016 15:41:24 +0000

What about assigning attribute 30 and 139 for "Experimental" use? Especially since this registry has none currently.

      Experimental: Available for experimental use as described in
            [EXPERIMENTATION<https://tools.ietf.org/html/rfc5226#ref-EXPERIMENTATION>].  IANA does not record specific
            assignments for any particular use.

https://tools.ietf.org/html/rfc5226#section-4

[EXPERIMENTATION<https://tools.ietf.org/html/rfc5226#ref-EXPERIMENTATION>] "Assigning Experimental and Testing Numbers Considered Useful" https://tools.ietf.org/html/rfc3692

Obviously this assumes that people do use this value for experimentation, i.e. follow the rule...

Regards,
--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, October 18, 2016 5:01 PM
To: 'IETF IDR WG'
Cc: 'Kristian Larsson'
Subject: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)

WG:

Early testing of the Large Communities draft (draft-ietf-idr-large-community-03.txt)  with attribute value of 30 detect that we had an implementation squatting on attribute 30 by a Huawei router.   "Squatting" on an attribute is anti-social behavior in the Internet in any release of software.

The individuals who did in Huawei have been contacted by Jie Dong, and "asked" if they had made this mistake in any other attribute.   These individuals confessed to Attribute 129 (for wide communities).  These individuals apologize to the Working group.

BGP Attribute 30
BGP attribute 129

Sue Hares

_________________________________________________________________________________________________________________________

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: Michael H Lambert <[email-masked]>
Date: Tue, 18 Oct 2016 11:44:44 -0400

> On 18 Oct 2016, at 11:30, Job Snijders <[email-masked]> wrote:
> 

Would the same course of action be recommended if it were an open-source project (eg bird or quagga), rather than a commercial router vendor, squatting on attribute 30?  If the answer is an unequivocal yes, then I agree with the proposed course of action.  Otherwise, I think the burden falls on the vendor to fix their (with respect to standards) broken implementation.

Michael

---

From: Jared Mauch <[email-masked]>
Date: Tue, 18 Oct 2016 11:48:56 -0400

> On Oct 18, 2016, at 11:44 AM, Michael H Lambert <[email-masked]> wrote:
> 

Yes.

As Job said, there is no winning move here.  I’d like to see the vendor taken to the woodshed as well, but without a new allocation everyone suffers.

- Jared

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 18 Oct 2016 11:51:01 -0400

> If 129 is not otherwise contended for, it may be reasonable to simply request early allocation for the wide communities code point.

The two courses of action are not mutually exclusive -- the code point can be marked "deprecated" right now and can later be {early} allocated. It's just a degenerate case of reusing the code point, which is expected in the case of deprecation -- we just normally expect it to take longer. Of course if we have working group consensus to request the early allocation right now, we can skip a step, but generally step-skipping has not worked well in my experience. :-(

--John

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 10:52:26 -0500

On Tue, Oct 18, 2016 at 11:44:44AM -0400, Michael H Lambert wrote:
> Would the same course of action be recommended if it were an
> open-source project (eg bird or quagga), rather than a commercial
> router vendor, squatting on attribute 30?  If the answer is an
> unequivocal yes, then I agree with the proposed course of action.
> Otherwise, I think the burden falls on the vendor to fix their (with
> respect to standards) broken implementation.

Yes. I don't think the project's license has anything to do with this.

I started testing Large BGP Communities in the wild [1], and attached a
Large BGP Community to my home LAN prefixes. My significant other
discovered that we can't reach parts of the internet. It doesnt matter
which vendor caused the unreachability - the fact that there is a
reachability problem is sufficient reason for this course of action.

Kind regards,

Job

[1]: http://largebgpcommunities.net/2016/beacon/

---

From: Kristian Larsson <[email-masked]>
Date: Tue, 18 Oct 2016 17:49:03 +0200

> respect to standards) broken implementation.

I think the issue is that we might have a lot of Huawei routers deployed
on the Internet with this code so in practical terms it's probably 12-18
months away to have all of them upgraded to a version where they will
not drop prefixes with large BGP communities.

This will leave networks that want to use large BGP communities with the
choice of
  * using large and not becoming reachable from networks that use Huawei
  * OR not use large and reach the whole Internet

I think a lot of network operators will choose the latter so in the end
we'd be slowing down the implementation speed of large rather than
punishing Huawei.

Kind regards,
    Kristian.

---

From: "Dickinson, Ian" <[email-masked]>
Date: Tue, 18 Oct 2016 15:50:37 +0000

Michael H Lambert wrote:
> Otherwise, I think the burden falls on the vendor to fix their
> (with respect to standards) broken implementation.

Whilst I have some sympathy with this view, this issue came to light because the Huawei implementation is deployed in the Internet, and hence it would require changes by operators to fix. Given my wish for timeliness for large, I support the proposed action as the least risk approach. What should happen with regard to the squatting usage, I shall leave to others to comment on.

Ian
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Julian Seifert <[email-masked]>
Date: Tue, 18 Oct 2016 16:01:49 +0000

Hi, 

> not drop prefixes with large BGP communities.

I think 12-18 months is even too short of an estiomate - it's hard to make any predictions about that
but it might take a significant longer time until that happens.
So I see no other feasable way than to allocate/request another 
numeric attribute and continue from there.

(While simultaneously the vendor in question should be pushed to 
fix his implementation anyway)

kind regards,

 Julian

---

From: Peter Hessler <[email-masked]>
Date: Tue, 18 Oct 2016 18:03:27 +0200

On 2016 Oct 18 (Tue) at 17:49:03 +0200 (+0200), Kristian Larsson wrote:
:On 2016-10-18 17:44, Michael H Lambert wrote:
:>Would the same course of action be recommended if it were an
:>open-source project (eg bird or quagga), rather than a commercial
:>router vendor, squatting on attribute 30?  If the answer is an
:>unequivocal yes, then I agree with the proposed course of action.
:>Otherwise, I think the burden falls on the vendor to fix their (with
:>respect to standards) broken implementation.
:
:I think the issue is that we might have a lot of XXXX routers deployed
:on the Internet with this code so in practical terms it's probably 12-18
:months away to have all of them upgraded to a version where they will
:not drop prefixes with large BGP communities.

This is a bad justification, imho.

The number of routers deployed is not relevant.  That the code shipped
to non-testers in a general release is relevent.  _And_ that the failure
case is Withdraw, as opposed to Crash.  If this was just a crasher for
vendor Y, I would oppose a renumber.

I reluctantly support a renumber.

(I'm an open source dev, working on OpenBGPD)

-- 
Jacquin's Postulate on Democratic Government:
	No man's life, liberty, or property are safe while the
	legislature is in session.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Oct 2016 17:05:35 +0100

> IDR should recommend that the following attribute numbers be deprecated:  

unless this is a temporary deprecation, I'm not sure if this is a good
idea, as it could be interpreted as sending a message to vendors that
squatting path attribute code points will result in being told, "that's
very naughty and we're going to punish you by ensuring that no-one else
gets these numbers, so don't do it again!"

There is an objective problem here, namely that there is no
vendor-specific range for path attributes.  Given the nature of path
attribute interpretation, it could be argued that this might be a good
thing because different vendors will interpret TLVs in different ways,
which is a potential source of bgp session instability.  On the other
hand, it means that if vendors need to go off and do something new,
there are no options other than squatting.  A vendor-specific range will
at least contain this problem, so that IANA won't run into the same
problem in future.

On a related issue, it would probably be a good idea to run beacon tests
with other path attributes to see how they affect reachability, i.e.
have any other vendors squatted any other path attribute values, and if
large-communities is moved to 31 or 32, will it suffer the same problem?

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Oct 2016 12:28:09 -0400

Nick (and others),

> On Oct 18, 2016, at 12:05 PM, Nick Hilliard <[email-masked]> wrote:

FWIW, there's a lot of discussion related to this in the RFC 5226 bis related discussions.

Part of the issue with vendor space for standards features has to do with renumbering issues.  A short summary of the prior discussions:
- Vendor space makes it easy to prototype.
- Once you get a feature beyond a certain point, if there was a particular first mover, one basically is forced into using that vendor's space.  That makes some implementors uncomfortable because it's under the control of that party.
- There's no strong incentive and several disincentives to renumber feature code points.  Historical example in BGP-land, why SAFI 128 is used for BGP VPNs. 

I believe the bigger discussion is how you handle early code point allocation and, more importantly, versioning features as development continues.

> large-communities is moved to 31 or 32, will it suffer the same problem?

Even passive monitoring is a good start.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 18 Oct 2016 12:35:08 -0400

On Oct 18, 2016, at 12:05 PM, Nick Hilliard <[email-masked]> wrote:
> unless this is a temporary deprecation,

All deprecation is temporary. It means "you shouldn't use this, and by the way we might reuse it for something in the future" where "in the future" probably/usually means "when we run out of unused space" (modulo my earlier remark to Jeff). Deprecation is therefore the first step in reusing a code point.

I looked for a supporting citation and didn't find one, though. :-(

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 13:14:21 -0400

Jeff: 

This is a good idea to just make 129 an early allocation for wide communities. 

Sue 

From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2016 11:19 AM
To: Sue Hares
Cc: IETF IDR WG; Kristian Larsson
Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)

Sue,

-- Jeff

WG: 

BGP Attribute 30 

BGP attribute 129 

Sue Hares 

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

---

From: Peter Hessler <[email-masked]>
Date: Tue, 18 Oct 2016 19:25:38 +0200

On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote:
:> On Oct 18, 2016, at 12:05 PM, Nick Hilliard <[email-masked]> wrote:
:> On a related issue, it would probably be a good idea to run beacon tests
:> with other path attributes to see how they affect reachability, i.e.
:> have any other vendors squatted any other path attribute values, and if
:> large-communities is moved to 31 or 32, will it suffer the same problem?
:
:Even passive monitoring is a good start.

I just did a check of the DFZ, both IPv4 and IPv6, and these are the
unknown/deprecated attributes on paths that I can see.

20 	Connector Attribute (deprecated) 	[RFC6037]
21 	AS_PATHLIMIT (deprecated) 	[draft-ietf-idr-as-pathlimit]

count                      type      flags  len    data in hex
--------------------------------------------------------------
  43     Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 02 8e cf d2 8d b5
   2     Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da
   4     Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8
   2     Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 18 Oct 2016 13:25:25 -0400

OK, if we're going straight to the early allocation request, let's fork the thread. Subject updated.

As a reminder, RFC 7120 gives the criteria for early allocation. The ones I think are relevant for this discussion:

   b.  The format, semantics, processing, and other rules related to
       handling the protocol entities defined by the code points
       (henceforth called "specifications") must be adequately described
       in an Internet-Draft.

IMO (speaking as a WG member) the current wide communities draft does this.

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

I am not sure this is true. Is it? 

   d.  The Working Group chairs and Area Directors (ADs) judge that
       there is sufficient interest in the community for early (pre-RFC)
       implementation and deployment, or that failure to make an early
       allocation might lead to contention for the code point in the
       field.

We can judge this based on response to this thread.

Thanks,

--John

On Oct 18, 2016, at 1:14 PM, Susan Hares <[email-masked]> wrote:
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/idr
>  
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 13:27:37 -0400

Nick:

In my understanding, all deprecations are temporary.   A vendor range for
attributes is something that is possible if the working group wishes.  

I do agree operators should beacon 31 or 32.  

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Tuesday, October 18, 2016 12:06 PM
To: Susan Hares
Cc: 'IETF IDR WG'; 'Kristian Larsson'
Subject: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was
squatted on - Let's get a new attribute number (1 week WG call (10/18 to
10/25)

> IDR should recommend that the following attribute numbers be deprecated:  

unless this is a temporary deprecation, I'm not sure if this is a good idea,
as it could be interpreted as sending a message to vendors that squatting
path attribute code points will result in being told, "that's very naughty
and we're going to punish you by ensuring that no-one else gets these
numbers, so don't do it again!"

There is an objective problem here, namely that there is no vendor-specific
range for path attributes.  Given the nature of path attribute
interpretation, it could be argued that this might be a good thing because
different vendors will interpret TLVs in different ways, which is a
potential source of bgp session instability.  On the other hand, it means
that if vendors need to go off and do something new, there are no options
other than squatting.  A vendor-specific range will at least contain this
problem, so that IANA won't run into the same problem in future.

Nick

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 13:38:51 -0400

John:

Another question is important, are there other wide-communities implementations.  Has anyone else implemented flowspecification? 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Tuesday, October 18, 2016 1:25 PM
To: Susan Hares
Cc: IETF IDR WG
Subject: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)]

Thanks,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 13:43:34 -0400

John: 

On #2, (handle attribute #129 attribute and handle new one) - Jie Dong can probably ask the developers. 

Sue 

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2016 1:25 PM
To: Susan Hares
Cc: Jeffrey Haas; IETF IDR WG
Subject: Early allocation for wide communities [was: Re: [Idr] BGP Attribute for Large communities (Attribute 30) was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)]

Thanks,

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 13:48:10 -0400

Do we know which routers are sending path attributes with 20 or 21?  

Sue

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Peter Hessler
Sent: Tuesday, October 18, 2016 1:26 PM
To: [email-masked]
Subject: [Idr] Unknown Attributes seen in the wild

  43     Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00
02 8e cf d2 8d b5

---

From: Jared Mauch <[email-masked]>
Date: Tue, 18 Oct 2016 13:52:13 -0400

route-views>sh ip bgp path-attribute unknown 
Network            Next Hop
134.89.0.0         216.218.252.164 
185.104.128.0/24   129.250.0.11    
185.104.129.0/24   129.250.0.11    
185.104.130.0/24   129.250.0.11    
185.104.131.0/24   129.250.0.11    
192.147.168.0      129.250.0.11    
198.17.60.0        216.218.252.164 
198.17.61.0        216.218.252.164 
204.62.150.0/23    208.51.134.254  

e.g.:

134.89.0.0
      unknown transitive attribute: flag 0xE0 type 0x15 length 0x5
        value 1400 0039 72

- Jared

> On Oct 18, 2016, at 1:48 PM, Susan Hares <[email-masked]> wrote:
>

---

From: 'Peter Hessler' <[email-masked]>
Date: Tue, 18 Oct 2016 19:55:03 +0200

For #20, all are coming from AS 22742

For #21, 2 are from AS 14706, 4 are from AS 11720, and 2 from AS 22490.

-peter

On 2016 Oct 18 (Tue) at 13:48:10 -0400 (-0400), Susan Hares wrote:
:Do we know which routers are sending path attributes with 20 or 21?  
:
:Sue
:
:-----Original Message-----
:From: Idr [mailto:[email-masked]] On Behalf Of Peter Hessler
:Sent: Tuesday, October 18, 2016 1:26 PM
:To: [email-masked]
:Subject: [Idr] Unknown Attributes seen in the wild
:
:On 2016 Oct 18 (Tue) at 12:28:09 -0400 (-0400), Jeffrey Haas wrote:
::> On Oct 18, 2016, at 12:05 PM, Nick Hilliard <[email-masked]> wrote:
::> On a related issue, it would probably be a good idea to run beacon tests
::> with other path attributes to see how they affect reachability, i.e.
::> have any other vendors squatted any other path attribute values, and if
::> large-communities is moved to 31 or 32, will it suffer the same problem?
::
::Even passive monitoring is a good start.
:
:I just did a check of the DFZ, both IPv4 and IPv6, and these are the
:unknown/deprecated attributes on paths that I can see.
:
:20 	Connector Attribute (deprecated) 	[RFC6037]
:21 	AS_PATHLIMIT (deprecated) 	[draft-ietf-idr-as-pathlimit]
:
:count                      type      flags  len    data in hex
:--------------------------------------------------------------
:  43     Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00 02 8e cf d2 8d b5
:   2     Unknown Attribute #21 flags [OTP] len 5: 02 00 00 57 da
:   4     Unknown Attribute #21 flags [OTP] len 5: 07 00 00 2d c8
:   2     Unknown Attribute #21 flags [OTP] len 5: 14 00 00 39 72

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 12:57:53 -0500

> This is a good idea to just make 129 an early allocation for wide communities. 

I have to disagree.

It is not known what version of the wide communities draft has been
implemented. This code is deployed in the wild, there are no guarantees
that those routers will ever be upgraded.

I think the -wide- deployment effort will shoot itself in the foot by
using 129.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 13:06:50 -0500

> I am not sure this is true. Is it? 

I do not believe that to be true.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Oct 2016 20:14:33 +0200

I would tend to agree with Job here.

I see no point to reserve already known to be "overloaded" code point for
wide or for that matter any new BGP attribute.

That's the price we pay for no BGP Police or BGP FBI/GBI  ... (G=global)

r.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 18 Oct 2016 14:15:39 -0400

Peter: 

A set of ASes, I did not expect.  

AS 22742 = CT-ED-NET (State of Connecticut) 
AS14706 = Monterey Bay Aquarium Research Institute 
AS22490 = The Nerdery, LLC

Caida info: 
http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=22742
http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=14706
http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=22490

Hmm.  This is the wild, wild bgp world.  Hmm. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of 'Peter Hessler'
Sent: Tuesday, October 18, 2016 1:55 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] Unknown Attributes seen in the wild

-peter

:  43     Unknown Attribute #20 flags [OTP] len 14: 00 01 00 00 58 d6 00 00

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 18 Oct 2016 19:28:35 +0000

I have no objection to letting "wide" have a codepoint.
Even if it is not stable.
Wide comms could add a version number into the header to satisfy (c),
but even if it doesn't, I won't object.

Thanks,
Jakob.

> Sent: Tuesday, October 18, 2016 10:25 AM
> To: Susan Hares <[email-masked]>
> Cc: IETF IDR WG <[email-masked]>
> Subject: [Idr] Early allocation for wide communities [was: Re: BGP Attribute for Large communities (Attribute 30)
> was squatted on - Let's get a new attribute number (1 week WG call (10/18 to 10/25)]
> 
> >> Early testing of the Large Communities draft (draft-ietf-idr-large-community-03.txt)  with attribute value of 30
> detect that we had an implementation squatting on attribute 30 by a Huawei router.   “Squatting” on an attribute is
> anti-social behavior in the Internet in any release of software.
> >>
> >> The individuals who did in Huawei have been contacted by Jie Dong, and “asked” if they had made this mistake in
> any other attribute.   These individuals confessed to Attribute 129 (for wide communities).  These individuals
> apologize to the Working group.
> >>
> >> Now what shall we do? The large community draft is critical for several networks. After talking with the
> developers and operators, John and I would like to recommend we do the following:
> >>
> >> IDR should ask IANA to assign BGP Large Communities (currently Attribute 30) to a new attribute number.  This is
> a 1 week call to determine if the IDR approves this action.   This call will allow the large communities draft to
> >> John, Alvaro, and I have check the early allocation rules.  Implementations should ask for early allocation prior
> to releasing, and they do not need to be interoperability testing to request the early allocation for the attribute.
> >>
> >> Sue Hares
> >>
> >>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Oct 2016 16:27:13 -0400

> On Oct 18, 2016, at 2:06 PM, Job Snijders <[email-masked]> wrote:
> 

Wide comms was spec-wise pretty stable until recently when we tried to accommodate large comms as a header.  The amount things were perturbed wasn't much but still was still incompatible.

But I agree with the general sentiment: We want it to be at that stability point before proceeding with the actual early allocation.  

This also hits the interesting question about versioning to accept my own criticisms about incremental deployment.

What would be nice would be to hear the feedback from the implementors at Huawei as to their experiences in implementing the spec.  This would give insight to the level of maturity of the draft, along with being a lot more careful to avoid spec churn if it's actually getting traction.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 15:32:15 -0500

On Tue, Oct 18, 2016 at 04:27:13PM -0400, Jeffrey Haas wrote:
> Wide comms was spec-wise pretty stable until recently when we tried to
> accommodate large comms as a header.  The amount things were perturbed
> wasn't much but still was still incompatible.
> 
> But I agree with the general sentiment: We want it to be at that
> stability point before proceeding with the actual early allocation.  
> 
> This also hits the interesting question about versioning to accept my
> own criticisms about incremental deployment.
> 
> What would be nice would be to hear the feedback from the implementors
> at Huawei as to their experiences in implementing the spec.  This
> would give insight to the level of maturity of the draft, along with
> being a lot more careful to avoid spec churn if it's actually getting
> traction.

Yes, implementor feedback before an early allocation makes a lot of
sense.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Oct 2016 16:42:56 -0400

Robert,

> On Oct 18, 2016, at 2:14 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> I see no point to reserve already known to be "overloaded" code point for wide or for that matter any new BGP attribute. 
> 

To clarify my original point, I think holding onto it for early allocation makes sense.

Whether or not the code Huawei is working on is ready for such an allocation is a different matter.  But if the code point is otherwise associated with the feature, incremental rollout issues aside, seems reasonable to not waste that code point.

-- Jeff (I don't feel super strong about this, but see other threads)

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Oct 2016 22:50:14 +0200

Hi Jeff,

IDR has a rule to progress any doc which demonstrates two implementations.
That means that each draft which requires new BGP attribute and is accepted
as an IDR WG doc should get IANA code point such that implementations could
be delivered without risking any further inter-operability or deployment
issues.

Not sure how long WG should wait before such code point is depreciated
though ... but without it being allocated in some way it is going to always
be a challenge.

/RR.

On Tue, Oct 18, 2016 at 10:42 PM, Jeffrey Haas <[email-masked]> wrote:

> Whether or not the code Huawei is working on is ready for such an
> allocation is a different matter.  But if the code point is otherwise
> associated with the feature, incremental rollout issues aside, seems
> reasonable to not waste that code point.
>

---

From: [email-masked]
Date: Wed, 19 Oct 2016 07:25:26 +0000

> at least contain this problem, so that IANA won't run into the same

Scary

> large-communities is moved to 31 or 32, will it suffer the same problem?

Definitely a good idea, but to handle with care.
URL: https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment

---

From: [email-masked]
Date: Wed, 19 Oct 2016 07:35:59 +0000

As there is strong consensus that the community should not allow to vendors to pick up codepoints on their own, i think that the best course of actions is to assign a fresh (not-squatted) number to this draft.

For what concerns 30 and 129, i suggest to mark them as deprecated with a reference to this thread.

October 18, 2016 8:14 PM, "Robert Raszuk"  wrote:

   I would tend to agree with Job here.  I see no point to reserve already known to be "overloaded" code point for wide or for that matter any new BGP attribute.  That's the price we pay for no BGP Police or BGP FBI/GBI ... (G=global)  r.  
On Tue, Oct 18, 2016 at 7:57 PM, Job Snijders  wrote:

I have to disagree.

Kind regards,

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

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Oct 2016 10:27:59 -0500

> On 19 Oct. 2016, at 2:35 am, [email-masked] wrote:
> 
> i think that the best course of actions is to assign a fresh (not-squatted) number to this draft.
> 

fwiw, I agree with this expedient approach.

  Geoff

---

From: t.petch <[email-masked]>
Date: Wed, 19 Oct 2016 17:58:32 +0100

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
Sent: Tuesday, October 18, 2016 5:35 PM

> All deprecation is temporary. It means "you shouldn't use this, and by
the way we might reuse it for something in the future" where "in the
future" probably/usually means "when we run out of unused space" (modulo
my earlier remark to Jeff). Deprecation is therefore the first step in
reusing a code point.
> I looked for a supporting citation and didn't find one, though. :-(

Mmm so RFCs

3879 Deprecating Site Local Addresses

4159 Deprecation of "ip6.int".

5095 Deprecation of Type 0 Routing Headers in IPv6.

6633 Deprecation of ICMP Source Quench Messages.

6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic
Algorithms  in Kerberos

6814 Formally Deprecating Some IPv4 Options.

6918 Formally Deprecating Some ICMPv4 Message Types.

6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH
/CLUSTER_ID

7447 Deprecation of BGP Entropy Label Capability Attribute

7526 Deprecating the Anycast Prefix for 6to4 Relay Routers.

7568 Deprecating Secure Sockets Layer Version 3.0.

are all temporary and we should look forward their resurrection in
future; source quench from site local with SSL3 protection via the 6to4
anycast:-)

I note that RFC5226 does not mention the term while RFC5226bis has
' "deprecated" (use is not recommended). '

But then RFC7120 has

' The WG chairs are responsible for informing IANA
   that the expired assignments are not required and that the code
   points are to be marked "deprecated".

   A deprecated code point is not marked as allocated for use as
   described in any document (that is, it is not allocated) and is not
   available for allocation in a future document.  The WG chairs may
   inform IANA that a deprecated code point can be completely
   de-allocated (i.e., made available for new allocations) at any time
   after it has been deprecated'

So I think that deprecation is permanent until you say otherwise so I
guess that makes you right!

Tom Petch

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 19 Oct 2016 14:37:43 -0400

> guess that makes you right!

Could be even clearer, but as you say if closely parsed it does agree with what I reckoned it meant.

Thanks!

--John

---

From: Paul Jakma <[email-masked]>
Date: Fri, 21 Oct 2016 22:32:39 +0100 (BST)

> Do we know which routers are sending path attributes with 20 or 21?

I don't know about #20, but Quagga had support for AS_PATHLIMIT for a 
while. I added it in '07 and removed it from the upstream code in '11.

> 21 	AS_PATHLIMIT (deprecated) 	[draft-ietf-idr-as-pathlimit]

regards,
-- 
Paul Jakma | [email-masked] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
"Look, Daddy, a whale egg!"

 	--Ralph Wiggum
 	  Make Room for Lisa (Episode AABF12)

---

From: Colin Petrie <[email-masked]>
Date: Sun, 30 Oct 2016 14:52:25 +0100

>> 21     AS_PATHLIMIT (deprecated)     [draft-ietf-idr-as-pathlimit]

At RIPE NCC, we searched our RIS raw data for the last 12 months to see
what unknown attributes we could find.

We found the following ones that Peter mentions:
20:   Connector Attribute (deprecated)
21:   AS_PATHLIMIT (deprecated)	

We also found:
28: BGP Entropy Label Capability Attribute (deprecated)
128: ATTR_SET (not deprecated but probably shouldn't be leaking into the
DFZ)

In the last month we also saw:
30: LARGE_COMMUNITY (old)
32: LARGE_COMMUNITY (new)

We also found an interesting unknown attribute, code 243. This appeared
at all our collectors but only during June 2016. We're not sure what it
is. We saw it for 4500 different prefixes, but all of them had the
following sequence of AS_PATH:
"7018 4466 5673"

Looking at the AS graphs on bgp.he.net, at a guess, it was probably
either AS5673 or AS4466 who originated this.

A bit of googling also reveals a mention of it here:
https://bugs.launchpad.net/juniperopenstack/+bug/1599588
"
   Unknown Attribute (243), length: 8, Flags [OT]:
     no Attribute 243 decoder
     0x0000: 8071 369b 0000 0007
"

Perhaps this is some internal SDN thing that leaked publicly?

Anyway, hope this information is useful - if anyone needs any more
details please let me know.

Kind Regards,

Colin

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Oct 2016 19:05:49 +0100

Colin,

> ​
Perhaps this is some internal SDN thing that leaked publicly ?

You are right ... attribute 243 is Contrail's OriginVnPath attribute useful
for more complex service chaining scenarios.

https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/bgp/bgp_attr_base.h

With that let's also not forget about attributes 241 and 242 used for
multicast edge replication. The work on draft describing those last two
temporarily allocated attribute codes is currently being resubmitted. The
good news is that they should not be leaked as they are to be send in their
dedicated SAFIs so unless peer exchanges right capabilities they should be
quite contained.

https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/net/bgp_af.h

Thx,
R.

> ​​

---

From: Job Snijders <[email-masked]>
Date: Sun, 30 Oct 2016 19:22:34 +0100

On Sun, Oct 30, 2016 at 07:05:49PM +0100, Robert Raszuk wrote:
> You are right ... attribute 243 is Contrail's OriginVnPath attribute
> useful for more complex service chaining scenarios.
> 

So this is a case of path attribute squatting, with code deployed in the wild?

> https://github.com/Juniper/contrail-controller/blob/82cdb6afee49b39e54364f18be8eeca725dd76f4/src/net/bgp_af.h

Would this be a (partial?) implementation of
https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01 or is
there another draft?

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Oct 2016 19:25:56 +0100

Hi Job,

Yes the last two are exactly as defined by this draft. There is an effort
in place to update it and resubmit in IETF. Perhaps to BESS.

Thx,
r.

On Sun, Oct 30, 2016 at 7:22 PM, Job Snijders <[email-masked]> wrote:

> > https://github.com/Juniper/contrail-controller/blob/
> 82cdb6afee49b39e54364f18be8eeca725dd76f4/src/bgp/bgp_attr_base.h
>
> > https://github.com/Juniper/contrail-controller/blob/
> 82cdb6afee49b39e54364f18be8eeca725dd76f4/src/net/bgp_af.h
>

---

From: Colin Petrie <[email-masked]>
Date: Sun, 30 Oct 2016 20:16:12 +0100

On 30/10/16 19:05, Robert Raszuk wrote:
> The good news is that they should not be leaked as they are to be send
> in their dedicated SAFIs so unless peer exchanges right capabilities
> they should be quite contained.

In this case, we see them appear on BGP sessions that only negotiate
IPv4/Unicast or IPv6/Unicast.

Cheers,
Colin

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 30 Oct 2016 19:40:18 +0000

There is no concept of a BGP attribute being "restricted" to a safi. If that were the case, then you could use a single attribute code for completely different attributes in different safis. An attribute that is understood in one safi, but nonsense in a second safi will cause a malformed update rather than an unknown attribute when received in the second safi. 

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Oct 2016 21:05:03 +0100

Jakob,

contained != restricted

Moreover there is number of overlay solutions in the wild which run under
the cover BGP with various self defined attributes and safis. Just think
about SD-WAN or DC overlay solutions.

Some of them tried to take IETF path some never bothered seeing how hard is
to get early IANA allocations or being aware of multiple implementation
requirement.

Some are limited to contained deployments some are encrypted. It is close
to impossible to now list all of those.

It was pretty clear this is coming ... one strategic solution was an
attempt 6 years back to separate BGP into BGP used for transport for all of
the application and services (new BGP port) and BGP used for Internet
routing (179). That would allow complete separation of the two.

https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Thx,
r.

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> There is no concept of a BGP attribute being "restricted" to a safi. If
> that were the case, then you could use a single attribute code for
> completely different attributes in different safis. An attribute that is
> understood in one safi, but nonsense in a second safi will cause a
> malformed update rather than an unknown attribute when received in the
> second safi.
>
> Thanks,
> Jakob.
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 30 Oct 2016 20:26:13 +0000

Send them one of those attributes in a different safi. What do you think will happen?
Will they pass it on harmlessly, like any unknown optional transitive attribute?

Thanks,
Jakob.

On Oct 30, 2016, at 1:05 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Jakob,

contained != restricted

Moreover there is number of overlay solutions in the wild which run under the cover BGP with various self defined attributes and safis. Just think about SD-WAN or DC overlay solutions.

Some of them tried to take IETF path some never bothered seeing how hard is to get early IANA allocations or being aware of multiple implementation requirement.

Some are limited to contained deployments some are encrypted. It is close to impossible to now list all of those.

It was pretty clear this is coming ... one strategic solution was an attempt 6 years back to separate BGP into BGP used for transport for all of the application and services (new BGP port) and BGP used for Internet routing (179). That would allow complete separation of the two.

Thx,
r.

On Sun, Oct 30, 2016 at 8:40 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
There is no concept of a BGP attribute being "restricted" to a safi. If that were the case, then you could use a single attribute code for completely different attributes in different safis. An attribute that is understood in one safi, but nonsense in a second safi will cause a malformed update rather than an unknown attribute when received in the second safi.

Thanks,
Jakob.

> On Oct 30, 2016, at 12:16 PM, Colin Petrie <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 30 Oct 2016 21:37:30 +0100

Those self invented attributes will not be passed/leaked as such safi they
are to be part of will not be capability negotiated in the first place with
any Internet router.

Thx,
R.

On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> On Oct 30, 2016, at 1:05 PM, Robert Raszuk <[email-masked]> wrote:
>
> Jakob,
>
> contained != restricted
>
> Some of them tried to take IETF path some never bothered seeing how hard
> is to get early IANA allocations or being aware of multiple implementation
> requirement.
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 30 Oct 2016 21:07:37 +0000

Robert,

That does not answer my question.

Thanks,
Jakob.

On Oct 30, 2016, at 1:37 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Those self invented attributes will not be passed/leaked as such safi they are to be part of will not be capability negotiated in the first place with any Internet router.

Thx,
R.

On Sun, Oct 30, 2016 at 9:26 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Send them one of those attributes in a different safi. What do you think will happen?
Will they pass it on harmlessly, like any unknown optional transitive attribute?

Thanks,
Jakob.

Jakob,

contained != restricted

Thx,
r.

Thanks,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 31 Oct 2016 00:34:25 +0000

Just to clarify, it's not just about sending an attribute, its also about receiving it.

Thanks,
Jakob.

On Oct 30, 2016, at 2:08 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Robert,

Thanks,
Jakob.

Thx,
R.

Thanks,
Jakob.

Jakob,

contained != restricted

Thx,
r.

Thanks,
Jakob.