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: Mon, 24 Oct 2016 08:18:56 -0400

IDR Working group: 

Thank you for your input on the question of whether Large communities should
be reassigned another attribute number due to Huawei squatting on attribute
30.  The WG consensus is that the IDR WG wishes to have IANA deprecate
attribute 30, and reassign large communities another attribute number for
its early allocation.    

Alvaro should request a new attribute number for wide communities. 

If wide communities implementers request an early allocation, the WG
consensus was unclear.  Therefore,  the code point of 129 is deprecated for
now.  The full discussion on this point is at: 

https://www.ietf.org/mail-archive/web/idr/current/msg16556.html

The following other attributes were seen in the wild with the comments we
saw: 

#        BGP function                                      Reference 

----    -----------------------------------------------   ---------------

20     Connector Attribute (deprecated)   [RFC6037]  

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

30     (deprecated)                                       [variant of
draft-ietf-tunnel-encaps, Huawei router]

129   (deprecated)
[draft-ietf-idr-wide-bgp-communities, Huawei router] 

Attribute  AS Attribute Observed                           

-----------   --------------------------------

20           AS 22742  (Peter Hessler)                        

21           AS 14706, AS 11720, AS 22490 

https://www.ietf.org/mail-archive/web/idr/current/msg16583.html

30   -  in trials reported by Job 

129 -  self-reported by Huawei 

Sue Hares

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 24 Oct 2016 15:10:36 +0000

Sue:

Hi!  Thanks for the summary!

I think you meant “request a new attribute number for *large* communities” below.

Please follow the process in rfc7120: you send me the formal request, I approve, and then you (Chairs) request the allocation from IANA.  Now that -04 was published we should be ready to go.  We should be able to include the 2 deprecated values in the same request.

Thanks!

Alvaro.

On 10/24/16, 8:18 AM, "Susan Hares" <[email-masked]<mailto:[email-masked]>> wrote:

Thank you for your input on the question of whether Large communities should be reassigned another attribute number due to Huawei squatting on attribute 30.  The WG consensus is that the IDR WG wishes to have IANA deprecate attribute 30, and reassign large communities another attribute number for its early allocation.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Oct 2016 11:18:16 -0400

Yes, I meant request a new attribute number for large communities. 

Sue 

From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: Monday, October 24, 2016 11:11 AM
To: Susan Hares; [email-masked]
Cc: 'John G. Scudder'
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:

Thanks!

Alvaro.

On 10/24/16, 8:18 AM, "Susan Hares" <[email-masked]> wrote:

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 25 Oct 2016 22:27:17 +0000

I have discovered that Cisco has used BGP attribute code 31
for an internal experiment in certain NXOS routers,
but unfortunately some of the code leaked into production.
The code does not send the attribute,
but it receives it incorrectly. We are creating patches for the
faulty code, but cannot guarantee that all affected routers will
be patched. Consequently, we request deprecation of attribute
code 31 as well.

I apologize on behalf of Cisco for the oversight.

Thanks,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, October 24, 2016 5:19 AM
To: [email-masked]
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)

IDR Working group:

If wide communities implementers request an early allocation, the WG consensus was unclear.  Therefore,  the code point of 129 is deprecated for now.  The full discussion on this point is at:

The following other attributes were seen in the wild with the comments we saw:

#        BGP function                                      Reference
----    -----------------------------------------------   ---------------
20     Connector Attribute (deprecated)   [RFC6037]
21      AS_PATHLIMIT (deprecated)           [draft-ietf-idr-as-pathlimit, unknown]
30     (deprecated)                                       [variant of draft-ietf-tunnel-encaps, Huawei router]
129   (deprecated)                                       [draft-ietf-idr-wide-bgp-communities, Huawei router]

Sue Hares

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 25 Oct 2016 21:50:45 -0400

So, what's the downside to having IANA pick the next available (from the
current list, prior to the 2 squatting incidents) value in cases like this?

I think it's: "Some routers somewhere do bad things"
  (or sometimes cause other remote people to do 'bad things' .. where
sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid the 'bad
things'"
(presuming that the code is available, I mean... and I do hope that
vendors, all of them, are telling their DE folk: "Hey, don't do this, it's
super painful...srsly!")

Is that about it? Why don't we just go back to assigning the next available
and deal with the problem(s) as they arise?

-chris

On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Monday, October 24, 2016 5:19 AM
> *To:* [email-masked]
> *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)
>
>
>
> IDR Working group:
>
>
>
> Thank you for your input on the question of whether Large communities
> should be reassigned another attribute number due to Huawei squatting on
> attribute 30.  The WG consensus is that the IDR WG wishes to have IANA
> deprecate attribute 30, and reassign large communities another attribute
> number for its early allocation.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 26 Oct 2016 06:17:18 +0200 (CEST)

On Tue, 25 Oct 2016, Christopher Morrow wrote:

> Is that about it? Why don't we just go back to assigning the next 
> available and deal with the problem(s) as they arise?

Unless you can find someone huge to start announcing prefixes with -large, 
there is little incentive for people to upgrade their code.

So what you're proposed means thereis a "first mover disadvantage", just 
like it was in the beginning of DNSSEC and IPv6 deployment.

If you have connectivity to an ISP, then that's that ISPs problem. If you 
have connectivity problems to hundreds of ISPs, then that's your problem.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Oct 2016 00:49:41 -0400

> there is little incentive for people to upgrade their code.
It sounded (to me) like there were folk at 2-3 large providers looking for
this community configuration to be available 'now'. I figured once things
hit standard/code/test&deploy we'd would have 2-3 large providers trying to
offer this community mapping for their customer's uses.

> like it was in the beginning of DNSSEC and IPv6 deployment.
maybe? I suppose if the provider(s) start offering this option and you as a
customer want to use it... you'll find out quickly: "Oops! I should
upgrade" (which you'd have to do anyway to take advantage of this community
mapping system.. at which point you'd also probably get away from the squat
problem).

> have connectivity problems to hundreds of ISPs, then that's your problem.
possibly, yes.

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Oct 2016 13:49:54 +0900

> available and deal with the problem(s) as they arise?

another reason i think this may be a prudent path is that squatting
should not be condoned; the result would be entropic.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Oct 2016 01:13:37 -0400

> should not be condoned; the result would be entropic.
this was my point, sorry for getting a bit lost along the way; "If we keep
letting squatting be successful we're boned."

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 26 Oct 2016 05:51:44 +0000

Because then we wouldn't own up to it and innocents would suffer.
We would hope we could fix as much of it as possible and hope the rest wouldn't notice.
Actually, the intended purpose of the NXOS line is for the data center, not the Internet and we can very likely fix all of the deployed ones. However, users have a right to deploy them wherever they want without notifying us and they have the right not to apply patches, so I chose to own up to the problem.
Honest, we didn't mean it. Sorry.

Thanks,
Jakob.

On Oct 25, 2016, at 6:50 PM, Christopher Morrow <[email-masked]<mailto:[email-masked]>> wrote:

So, what's the downside to having IANA pick the next available (from the current list, prior to the 2 squatting incidents) value in cases like this?

I think it's: "Some routers somewhere do bad things"
  (or sometimes cause other remote people to do 'bad things' .. where sometimes that other person is 'me')

and when that happens: "some people quickly upgrade code to avoid the 'bad things'"
(presuming that the code is available, I mean... and I do hope that vendors, all of them, are telling their DE folk: "Hey, don't do this, it's super painful...srsly!")

Is that about it? Why don't we just go back to assigning the next available and deal with the problem(s) as they arise?

-chris

On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Jakob.

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Susan Hares
Sent: Monday, October 24, 2016 5:19 AM
To: [email-masked]<mailto:[email-masked]>
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)

IDR Working group:

#        BGP function                                      Reference

Sue Hares

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

---

From: Brian Dickson <[email-masked]>
Date: Wed, 26 Oct 2016 00:43:23 -0700

Rather than deprecate the two sequential values, why not reserve a small range which includes those values, for non-permanent reservations for vendor development use? Say 30-35 inclusive?

A fixed range would be not much worse in terms of consumed code points than a few more squatting incidents. However, it would allow defensive coding against known bad code points.

The idea of temporary reservations by vendors (e.g. For 6 month intervals) would allow easier identification of vendors that leak their test stuff. It would encourage vendors to use the range set aside. And the temporary nature would make deliberate squatting inside that range a doomed effort.

Easing the rules for reservations would help the squatting issue generally. The easier it is to reserve , the harder it would be to justify squatting.

Maybe have another small range for no-reservations use, with no guarantee of global uniqueness? Maybe re-purpose 129-130 for that?

Those code points are already toast, this would give them an alternative use. 

Thoughts?

Brian

Sent from my iPhone

> On Oct 25, 2016, at 10:51 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> On Oct 25, 2016, at 6:50 PM, Christopher Morrow <[email-masked]> wrote:
> 
>>> On Tue, Oct 25, 2016 at 6:27 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Oct 2016 09:38:35 -0400

> Because then we wouldn't own up to it and innocents would suffer.

I totally agree that owning up is good here.
I imagine that when other squatted values are discovered either in the
field or in tests the same: "oops!" email/etc will happen... but I don't
want us to end up just excluding forever the squatted
attributes/value/numbers, that'll be super painful in very short order.

> Actually, the intended purpose of the NXOS line is for the data center,
> not the Internet and we can very likely fix all of the deployed ones.
> However, users have a right to deploy them wherever they want without
> notifying us and they have the right not to apply patches, so I chose to
> own up to the problem.
>

yup, I think it's nice to see folk stand up and say: "DOH! we screwed up,
sorry! we're now making our best effort to fix this, too." thanks!

---

From: heasley <[email-masked]>
Date: Wed, 26 Oct 2016 16:57:10 +0000

> Rather than deprecate the two sequential values, why not reserve a small range which includes those values, for non-permanent reservations for vendor development use? Say 30-35 inclusive?

isnt this bgp path attribute 255?

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 26 Oct 2016 17:08:29 +0000

Yes, it is. However, sometimes we have multiple projects going on at the asme time.

Thanks,
Jakob.

> -----Original Message-----
> From: heasley [mailto:[email-masked]]
> Sent: Wednesday, October 26, 2016 9:57 AM
> To: Brian Dickson <[email-masked]>
> Cc: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
> > Rather than deprecate the two sequential values, why not reserve a small range which includes those values, for
> non-permanent reservations for vendor development use? Say 30-35 inclusive?
>

---

From: Job Snijders <[email-masked]>
Date: Wed, 26 Oct 2016 19:13:32 +0200

> Yes, it is. However, sometimes we have multiple projects going on at

just like we print money, you can tunnel as much path attributes as you
need through 255 right? :)

Kind regards,

Job

---

From: heasley <[email-masked]>
Date: Wed, 26 Oct 2016 17:24:43 +0000

> Yes, it is. However, sometimes we have multiple projects going on at the asme time.

You develop each on a separate branch, right?  so, they could use the same
attribute #.  i'm poking fun; I dont care if more are reserved.

---

From: [email-masked]
Date: Wed, 26 Oct 2016 17:32:10 +0000

October 26, 2016 6:57 PM, "heasley" <[email-masked]> wrote:
>> Rather than deprecate the two sequential values, why not reserve a small range which includes those
>> values, for non-permanent reservations for vendor development use? Say 30-35 inclusive?
> 

I was suggesting the same thing out-of-list today.
We should really assign ~5 values to experimental/development puroposes

---

From: Sander Steffann <[email-masked]>
Date: Thu, 27 Oct 2016 11:20:38 +0200

Hi,

> We should really assign ~5 values to experimental/development puroposes

I think this would be useful both to allow for larger-scale testing of new attributes, and for vendors to be more easily be able to test multiple new attributes in-house.

Cheers,
Sander

---

From: Job Snijders <[email-masked]>
Date: Thu, 27 Oct 2016 11:54:04 +0200

On Thu, Oct 27, 2016 at 11:20:38AM +0200, Sander Steffann wrote:
> >>> Rather than deprecate the two sequential values, why not reserve a
> >>> small range which includes those values, for non-permanent
> >>> reservations for vendor development use? Say 30-35 inclusive?
> >> 
> I think this would be useful both to allow for larger-scale testing of
> new attributes, and for vendors to be more easily be able to test
> multiple new attributes in-house.

The problem here is that people are not abiding the rules, and offering
more codepoints will only work if people abide those rules. I have no
confidence that more dev codepoints resolve the issue.

Kind regards,

Job

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 27 Oct 2016 12:01:26 +0200 (CEST)

> confidence that more dev codepoints resolve the issue.

Perhaps we could ask the squatters why they didn't use 255 for their 
development testing?

If this was because they already used 255 for some other project, then it 
might make sense to have more code points. If it was because they weren't 
aware of it, then that's a problem and assigning more code points wouldn't 
help, agreed.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 27 Oct 2016 12:05:05 +0200

Hi,

Op 27 okt. 2016, om 12:01 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
>> The problem here is that people are not abiding the rules, and offering more codepoints will only work if people abide those rules. I have no confidence that more dev codepoints resolve the issue.
> 
> Perhaps we could ask the squatters why they didn't use 255 for their development testing?
> 
> If this was because they already used 255 for some other project, then it might make sense to have more code points. If it was because they weren't aware of it, then that's a problem and assigning more code points wouldn't help, agreed.

Full agreement
Sander

---

From: [email-masked]
Date: Thu, 27 Oct 2016 10:22:26 +0000

> confidence that more dev codepoints resolve the issue.

Job,

I am just trying to cope with the status quo.
Vendors are squatting codepoints for their own purposes, it is obviously is bad and they shouldn't, but they do.

I can understand how a single value may not be enough for large environments with multiple development processes.
So i think that we should try address the "unpleasant" habit of squatting what they should ask for by giving them enough room to work with.

My *wish* is in that way vendors will use experimental space in development phase and get back to the community to get an assignment when ready.

Regards

---

From: Job Snijders <[email-masked]>
Date: Thu, 27 Oct 2016 12:41:58 +0200

On Thu, Oct 27, 2016 at 10:22:26AM +0000, [email-masked] wrote:
> I am just trying to cope with the status quo.  Vendors are squatting
> codepoints for their own purposes, it is obviously is bad and they
> shouldn't, but they do.
> 
> I can understand how a single value may not be enough for large
> environments with multiple development processes.  So i think that we
> should try address the "unpleasant" habit of squatting what they
> should ask for by giving them enough room to work with.

If you can't isolate your features in development branches, something is
strange in your development process. This is of course a subjective
statement, I'd like to hear from more fulltime implementors what their
take on this is.

> My *wish* is in that way vendors will use experimental space in
> development phase and get back to the community to get an assignment
> when ready.

If you look at the numbers that have been used so far: 30, 31, 129 -
those are all square in the middle. If you have concurrent projects and
need multiple bgp path attributes, I'd expect someone to squat on the
high numbers: 254, 253, 252, etc - because IANA, obviously is counting
upwards. The presence of low (not yet used) squatted codepoints, shows
me that the social contract is not followed, so making more rules won't
address that.

Kind regards,

Job

---

From: t.petch <[email-masked]>
Date: Thu, 27 Oct 2016 12:33:29 +0100

----- Original Message -----
From: <[email-masked]>
Sent: Thursday, October 27, 2016 11:22 AM

> Vendors are squatting codepoints for their own purposes, it is
obviously is bad and they shouldn't, but they do.
> I can understand how a single value may not be enough for large
environments with multiple development processes.
> So i think that we should try address the "unpleasant" habit of
squatting what they should ask for by giving them enough room to work
with.

Marco

This is an issue that has come up many times,for many protocols,in the
IETF.

The issue that vendors raise is that having got everything tested and
working on an experimental code point, everything has to be changed to a
standard one and that introduces errors (well, I could write code to
minimise the risk of that, but suspect that not all do and even then,
there is non-code like documentation that needs fixing).

So the IETF introduced early assignment and made it quite easy to use.

The issue that vendors raise is that an early allocation early in their
process discloses to competitors what they are up to which loses the
vendor their commercial advantage.

So they squat, and hope that when they are ready to disclose what they
have done, then that code point will still be available for use.  I
think it not  a coincidence that the squats are in the 'next available'
range and not in some dark corner where noone else will go.

This sort of dance has been going on for at least 20 years because there
is no good answer and the experimental option remains little used (at
least in some registries).

Experiments that fail to turn into production code are fine; those that
do are problematic.

Tom Petch

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Oct 2016 13:22:51 +0000

Hi Job, Marco, 

>statement, I'd like to hear from more fulltime implementors what their

In our case (Cisco NX-OS), the code point was used for the BGP Remote Next
Hop attribute (draft-vandevelde-idr-remote-next-hop). When the approach
was abandoned, the mistake made was not to remove the attribute handling
and validation. Hence, NX-OS switches will not propagate the 31 attribute
(assuming validation failure and an optional transitive attribute). As you
would guess, this is not something that would show up in normal regression
or feature testing since attribute 31 was unallocated. We debated the
severity of this problem given NX-OS’s Place In Network (PIN) but decided
it was better to disclose the problem. As Jakob already indicated, we are
sorry for the oversight.

Thanks,
Acee

---

From: [email-masked]
Date: Thu, 27 Oct 2016 18:39:22 +0000

Job,

I would say that your reasoning is based on speculations, but also is mine as none of us works for a vendor.
I take your point and wait for others to comment.

Regards

---

From: Brian Dickson <[email-masked]>
Date: Thu, 27 Oct 2016 12:04:12 -0700

> confidence that more dev codepoints resolve the issue.

The counter argument is very simple: If we don't offer more code points,
they *definitely* won't use them (and thus abide by the rules).

The consequence of offering already-squatted code points for this purpose,
is that it makes it possible to abide by the rules (if they need multiple
code points
simultaneously).

If the number of squatted code points was truly significant, compared to
the pool
of code points, I'd say concern would be warranted, but we aren't at that
point,
IMHO.

 (Significant, by my estimate, would be ~10% total, or ~10% of remaining,
or at a run-rate of > 5% of remaining per year. Those are roughly 25, 20,
and
10/yr respectively. We've seen 3/yr this year, but it is anomalous when we
consider the last 20 years.)

Providing a non-trivial, but small, fixed pool, would not be harmful, and
would
provide both a good way of enabling those who want to play by the rules, and
greater visibility to who the parties are. If squatting continues after
that pool
is established, then we should think about what to do. Doing so now, is
probably
premature.

Brian

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Oct 2016 13:08:51 +0200

On Fri, Oct 28, 2016 at 11:29:51AM +0100, Thomas Mangin wrote:
> Finally, should a document be also published to officially kill
> attributes 30 and 31 asking implementations to treat as withdraw (or
> discard) any routes using them ?

I've asked the chairs for guidance whether that should be part of the
IANA considerations in the large communities draft or whether it should
be a separate document.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Oct 2016 20:24:19 +0900

> IANA considerations in the large communities draft or whether it
> should be a separate document.

no brainer.  this now has nothing to do with large communities.

randy

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Oct 2016 14:24:02 +0200

> no brainer.  this now has nothing to do with large communities.

https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00

---

From: Thomas Mangin <[email-masked]>
Date: Fri, 28 Oct 2016 13:59:38 +0100

So... Should it recommend treat as withdraw if seen in the wild wild DFZ ?

Thomas
---
from my iPhone

> On 28 Oct 2016, at 13:24, Job Snijders <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 28 Oct 2016 15:05:10 +0200 (CEST)

> So... Should it recommend treat as withdraw if seen in the wild wild DFZ 

What's the benefit of that? Why make these codepoints unusable forever?

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Oct 2016 15:08:24 +0200

And it would be more work for everyone.

Job

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Oct 2016 16:25:07 +0200

On Thu, Oct 27, 2016 at 12:04:12PM -0700, Brian Dickson wrote:
> > > > I was suggesting the same thing out-of-list today.  We should
> > > > really assign ~5 values to experimental/development puroposes
> > >
> > > I think this would be useful both to allow for larger-scale
> > > testing of new attributes, and for vendors to be more easily be
> > > able to test multiple new attributes in-house.
> >
> > The problem here is that people are not abiding the rules, and
> > offering more codepoints will only work if people abide those rules.
> > I have no confidence that more dev codepoints resolve the issue.
> 
> The counter argument is very simple: If we don't offer more code
> points, they *definitely* won't use them (and thus abide by the
> rules).

On the other hand, they weren't using today's 255 codepoint either.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 28 Oct 2016 16:26:30 +0200

> https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00

pls specify timeout in deprecation:

https://www.ietf.org/mail-archive/web/idr/current/msg16576.html

Nick

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 28 Oct 2016 10:40:21 -0400

> https://www.ietf.org/mail-archive/web/idr/current/msg16576.html

(Individual contributor hat)

Ha, and I was just about to send a message saying I couldn't imagine needing to polish this document. Obviously, my imagination needs an upgrade.

I'm not aware of a precedent for specifying a timeout in a deprecation, in fact I'm not sure what it means. I'm not sure what benefit it would bring either. I do see Sue's message you referenced, but the point of that, and also my own message around the same time, is that deprecation is one step in the state machine, necessary before code point reuse. I don't think we need to either specify either a minimum, nor a maximum, time the code point may spend in that state.

I note that in parallel the working group has been discussing the idea of reusing these code points to expand the Experimental range (currently called "reserved for development"), so we may end up reusing them rather soon. In any case, deprecation is the first step toward doing that, so I think we may as well just get on with it with a minimum of fuss.

--John

---

From: Job Snijders <[email-masked]>
Date: Fri, 28 Oct 2016 16:45:17 +0200

If values are picked for development, I'd pick them closer to 255 rather
then apply a degenerate distribution.

It is my understanding too that deprecation is temporary in that the
working group can undeprecate them in the future.

Kind regards,

Job

On Friday, 28 October 2016, John G. Scudder <[email-masked]> wrote:

> On Oct 28, 2016, at 10:26 AM, Nick Hilliard <[email-masked]
> <javascript:;>> wrote:
> >
> > Job Snijders wrote:
> Ha, and I was just about to send a message saying I couldn't imagine
> needing to polish this document. Obviously, my imagination needs an upgrade.
>
> I'm not aware of a precedent for specifying a timeout in a deprecation, in
> fact I'm not sure what it means. I'm not sure what benefit it would bring
> either. I do see Sue's message you referenced, but the point of that, and
> also my own message around the same time, is that deprecation is one step
> in the state machine, necessary before code point reuse. I don't think we
> need to either specify either a minimum, nor a maximum, time the code point
> may spend in that state.
>
> I note that in parallel the working group has been discussing the idea of
> reusing these code points to expand the Experimental range (currently
> called "reserved for development"), so we may end up reusing them rather
> soon. In any case, deprecation is the first step toward doing that, so I
> think we may as well just get on with it with a minimum of fuss.
>
> --John
> [email-masked] <javascript:;>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 28 Oct 2016 10:54:13 -0400

On Fri, Oct 28, 2016 at 10:40:21AM -0400, John G. Scudder wrote:
> need to either specify either a minimum, nor a maximum, time the code
> point may spend in that state.

A somewhat relevant analogy is that toxic spills tend to last in the
environment a rather long time, even with active cleanup work.  This has
been the thought behind most of my prior comments about avoiding the need to
burn attributes.

And while...

> think we may as well just get on with it with a minimum of fuss.

I think we'll find that using the existing attribute range in such a way
simply will leave further toxic waste.  We're simply causing people
different sorts of pain as we move around the contamination.

For example, vendor A uses 30 for testing a feature and it escapes into the
wild.  It runs into the existing issue.

The issue is really more to do with development and testing practices than
code points in particular.  Code point hygeine simply helps mitigate issues
in those practices.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 28 Oct 2016 10:54:22 -0400

On Oct 28, 2016, at 10:45 AM, Job Snijders <[email-masked]> wrote:
> If values are picked for development, I'd pick them closer to 255 rather then apply a degenerate distribution. 

And the fact that there is a diversity of opinions about which values to pick for development, if any, is exactly why I think your deprecation draft shouldn't be cluttered by this consideration. Everyone agrees (at least, I hope so) that the values need to be deprecated, so let's make progress on that.

--John

---

From: Thomas Mangin <[email-masked]>
Date: Fri, 28 Oct 2016 16:36:20 +0100

> On 28 Oct 2016, at 14:05, Mikael Abrahamsson <[email-masked]> wrote:
> 

Yes, make sure that they are not uselessly carried on the DFZ.
I can see the argument for ‘doing nothing’ tho.

Thomas

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 28 Oct 2016 16:41:46 +0000

If they are optional transitive, then they should be treated like any other optional transitive attributes.

Many BGP implementations have a way to configure attribute filtering.
In IOS-XR, you configure an "attribute-filter group" and then apply it in "update in filtering".

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Thomas Mangin
> Sent: Friday, October 28, 2016 8:36 AM
> To: [email-masked]
> Cc: heasley <[email-masked]>; IETF IDR <[email-masked]>; Susan Hares <[email-masked]>
> Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)
> 
>

---

From: heasley <[email-masked]>
Date: Fri, 28 Oct 2016 16:54:25 +0000

> > I can see the argument for ‘doing nothing’ tho.

how would you, or how long would it take to, un-deprecate these attributes
if vendors were to hard-code filtering of them?

---

From: Brian Dickson <[email-masked]>
Date: Fri, 28 Oct 2016 10:23:41 -0700

Sent from my iPhone

> if vendors were to hard-code filtering of them?

In the case of "deprecated->testing", the hard-coded filtering would still be desirable.

I.e. there are other kinds of un-deprecation than "available for new allocation".

Brian

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 28 Oct 2016 18:46:42 +0000

There is NO WAY we are going to hard code filter anything. Forgetaboutit. See my earlier email about configuring filters.

Thanks,
Jakob.

> On Oct 28, 2016, at 10:23 AM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
>

---

From: [email-masked]
Date: Sat, 29 Oct 2016 11:52:13 +0000

> On the other hand, they weren't using today's 255 codepoint either.

Again: you can't be sure!