Subject: [Idr] community of the day - common header

From: Jeffrey Haas <[email-masked]>
Date: Thu, 8 Sep 2016 17:40:31 -0400

[A portion of this conversation was held not only in the halls at the recent
Berlin IETF, but at the IDR mic.]

I'm generally agnostic about the idea of the encoding of a 4:4 style
community.  The fact that the 4:4 encoding in the wide-comms draft was able
to shift from TLV (atom) based to flattened as seen in -03 should make it
obvious that the wide comms draft authors also sees that particular point
agnosticly.

The one point that I did push on heavily in earlier discussions is that
future community (route coloring) mechanisms should stop burning path
attributes for each new type.  I strongly believe that a new common header
for future community mechanisms is needed:

- We shouldn't be burning path attributes for it.  While the code space for
  it isn't being exhausted fast, it means the only way to discard
  unparseable attributes (implementation doesn't support) is a general path
  attribute filtering mechanism.  Such filtering mechanisms are hazardous to
  the incremental deployment of new BGP features.
- By using a common header, undesireable classes of communities can be
  filtered simply by type.  This can be done without any knowledge of the
  format.

To offer an example of why such behaviors are desirable, early deployments
of extended communities caused unfortunate effects far away from the
attaching router because intermediate routers didn't understand the
attributes.  This is a fundamental deployment issue of optional-transitive
unknown attributes.

I'm not particularly fond of the theater that has gone into this discussion
- and good will has been burned by that theater.  But regardless of the
proposal to implement 4:4, 4:4:4, N:4 ipv6:4 or whatever we invent next
month, let's nip this bit of deployment madness.

A proposal for a common header is contained in section 3.1 of the wide
communities draft.

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Thu, 8 Sep 2016 19:18:40 -0400

>   the incremental deployment of new BGP features.

	Is there a particular shortcoming in rfc7606 that creates this
[moral] hazard, or are you speaking of the difficulty of writing
the code as referenced below?

>   filtered simply by type.  This can be done without any knowledge of the

	We already have the collateral damage of filtering of attributes
in the operational space.  The cut+paste SDN model employed by most
providers results in things like the filtering of attribute 128 which will
effectively be permanent for networks.  The same is true for the maximum
as-path limits in place.  BGP fails fast and fails hard, but as the networks
became harder for operators to upgrade the ability to deploy fixed code
is extremely limited.  A 15 year old router could be upgraded much
faster than most modern devices.
	
> attributes.  This is a fundamental deployment issue of optional-transitive

	There is inherent risk when introducing anything new.  Bugs happen
and they get fixed, this is part of the process.  As networks became more
business critical and are depended upon, it's much harder to make changes.

> A proposal for a common header is contained in section 3.1 of the wide

	If the document has converged, what review is still necessary?
The comments in the past 24-48 hours on-list have made it apparent
to me much of the existing wide work was "field of dreams", if we can
inventory it, they will come [and use it].  This has not seen a benefit
for those networks facing the need, and resulted in extra efforts for
people who did not get a 2-byte ASN to use common tools.

<operational reality follows>

Any code received today will take me ~12 months to deploy.  If wide
communities is ready to WGLC and ship with 3.1, I'd like to see movement
immediately so we can test and plan accordingly.  ~6+ years is quite a
long gestation period for the IETF.

	- Jared

P.S. Jeff, lets get together in person next week if you have time.

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 09 Sep 2016 12:57:28 +0100

> month, let's nip this bit of deployment madness.

Jeff,

most people who have chimed in on this conversation understand the
underlying issues here:

- is -large- useful enough to dedicate an entire path attribute to it?
- do we try to merge with wide or something equivalent?
- do we aim for perfection or good enough?

Balanced against this, IANA allocated their last 16-bit ASNs at the end
of July this year, which means that the RIR tanks are nearly dry.  The
operator community has desperately needed >= 32b:32b for several years,
but no-one has made progress fixing this problem, until a couple of
months ago.

Our situation now is:

- the operational people who have contributed to this conversation think
that large is going to work for their requirements, and is worth deploying.

- there is running code (xr, bird and exabgp) which implements the large
proposal, and commitments from a bunch of other stacks, including non
open-source vendors.

- when you add new community subtypes, the point of diminishing returns
associated with the extra functionality is reached very quickly indeed.

- the existing 6-octet path attribute is still sufficient to deal with
signaling stuff that it was designed to handle.

- there has been no substantial progress on wide in 6 years.

There is nothing wrong with planning a kitchen sink approach.  The wide
draft has been adopted by IDR and nothing is stopping people from
working on it.  But in the best-case situation, it is still many years
away from wide-scale deployment.

If we were having this conversation in 2008-2009, which was the first
time that lack of >= 32b:32b communities started causing serious
operational problems, I'd be a good deal more sanguine about things.
But that time is over: it's 7 years later, and the entire operational
community is now staring at a fast-approaching brick wall.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Fri, 9 Sep 2016 14:17:20 +0200

Hi Nick,

> proposal, and commitments from a bunch of other stacks, including non

Sounds like this is close to rough consensus and running code...

> community is now staring at a fast-approaching brick wall.

And demonstrated need...

There may be better, nicer, cooler, more flexible solutions. But the large proposal seems to be good enough for the foreseeable operational requirements. Operators need feature parity for 16 and 32 bit ASN now.

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Sep 2016 15:38:36 +0200

Nick,

I think no one within operational community or IETF is questioning if large
has a use case which is needed. To me the answer is clear - YES.

The only question which stands and which seems to be still open and very
important how to proceed with large is if large community will be good
enough on its own till wide get's implemented across number of operating
systems.

Yesterday you said that you would *not like* to see an attribute for large
community (fixed 4:4:4), an attribute for Nx4, an attribute for 16+Nx4 and
an attribute for wide. You assume it is large & wide only.

Well if this is so how are you planning to address all of the use cases
folks expressed which just do not fit to either existing shipping
communities or will not fit to large communities either?

Extended communities are 2+6 octets. With large AS:4:4 what we are really
adding is extra two octets of space. And complains about too little space
in extended communities are so common that I have already stopped counting.

In my view the TLV format for sending such opaque to protocol data has been
proven in action all over the place so why not to use it also here ?

The best way forward I propose would be to use one attribute as define in
wide comm draft, use common header  from section 3.1 just as a TLV wrapper
and place there as first large community as type X (maybe type 1 if it is
first one to get shipped).

Then whoever needs new type adds a TLV and moves on. Easy filtering by type
is addressed and extensible format is addressed as well as all operational
needs folks already expressed.

And as stated earlier if that means that wide draft will needs to be
splitted into 4 (currently there are 4 major TLV types defined) so be it -
that no one will block any other work to go to RFC status.

Very best,
Robert.

On Fri, Sep 9, 2016 at 1:57 PM, Nick Hilliard <[email-masked]> wrote:

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

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 09 Sep 2016 15:59:58 +0100

Robert,

Robert Raszuk wrote:
> Yesterday you said that you would *not like* to see an attribute for
> large community (fixed 4:4:4), an attribute for Nx4, an attribute for
> 16+Nx4 and an attribute for wide. You assume it is large & wide only. 

As I mentioned yesterday, there was a misunderstanding on both our parts:

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

Let me clarify:

- I am happy for -large- to have its own path attribute, but haven't
said anything about path attributes for any other proposal.

- let's discuss -wide- as a separate issue to -large- so that neither of
them is dependent on the other.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Sep 2016 11:28:42 -0400

Nick,

> away from wide-scale deployment.

Stop conflating my desire for a common header with my support for wide
communities.  As I mentioned in the base message for this thread, I don't
give a darned whether it's wide, 4:4, 16:4 or the future plethora.

Stop allocating path attributes and forcing people to filter attributes
rather than just add a blanket "drop community type" policy mechanism.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Sep 2016 11:33:17 -0400

> the code as referenced below?

You cite the issue yourself below with the example of attr 128.  In the
absence of any ability to parse the attribute, your choice is to blindly
pass it along or to drop it.

We know these things are community-like.  Stick them under a common type and
let people's policy engines filter them.

> long gestation period for the IETF.

This thread isn't about wide communities.  Stop making it about that.

> P.S. Jeff, lets get together in person next week if you have time.

I'm available, but at this point it's unclear if you can afford that much
beer.

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Fri, 9 Sep 2016 11:44:13 -0400

> On Sep 9, 2016, at 11:33 AM, Jeffrey Haas <[email-masked]> wrote:
> 

Sure, implementations compliant with 7606 should do
treat-as-withdrawl if they encounter something they
can recover from.

> This thread isn't about wide communities.  Stop making it about that.

Well, is it about rate of consumption of attributes, any new
route coloring/community-type thing?  It’s clear from me watching
the live stream of operator events today account teams are going to face
a number of requests about implementation details.

Please don’t trim too much of my operational grouse here, we should seek
consensus on *something* without prescribing what it is, wide, jumbo,
skinny or otherwise.  We as operators need something, i’m less worried
about the wire encoding than a viable solution.

> I'm available, but at this point it's unclear if you can afford that much

I’ll take on this challenge. :)  I’ll message you privately about details
and if you’re local to me, feel free to inquire as well.

- Jared

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Sep 2016 11:59:53 -0400

> treat-as-withdrawl if they encounter something they

Right, but the filtering mechanism you're familiar with (which we strongly
recommend against as common practice) means you're applying the filter
potentially on nodes that are ignorant of internal contents.  I.e. you're
filtering - and my point about the common filter is to permit filtering.

> a number of requests about implementation details.

It's about providing a filtering knob that doesn't go into throwing out
entire path attribute sets.

> about the wire encoding than a viable solution.

I'm the one that's agnostic on wire encoding and not allergic to TLVs. :-)

Turned around, this is mostly about providing an operational tool.  A big
portion of the extended discussions not only at this last IETF but among
authors of wide and the older flex comms proposal was the fact that once
format flexibility becomes easy, we're likely to see a plethora of proposals
covering local use cases.  The push for BGP as a general signaling mechanism
for non ISP uses has been a large motivator there.

As one example, Enke's geo-tagging for routes was proposed as yet another
attribute.  It fits into a "community" bucket just as readily.

As an operator, do you want to play long-term whack-a-mole with the
attribute set of the week, worrying about whether something you filter today
may need to get through later, or would you prefer we make that job easier
but trying to move "color" into a common bucket?

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Fri, 9 Sep 2016 17:39:13 +0100 (BST)

> proposal to implement 4:4, 4:4:4, N:4 ipv6:4 or whatever

I think a common header would be good too.

Going with a fixed size 4:4 new community has its attractions from a 
protocol POV, and implenting the wire side.

However, on more user/automation bits of the implementation side, 
preserving type information as much as possible (certainly for the 
obvious stuff) would help with UI/APIs around setting and displaying 
communities. Also, it'd be good to minimise pain for the next time we 
find out we specced too few bits, and an explicit structure approach at 
least would allow (e.g.) a value field to be extended without affecting 
the parsing of things like, say, an ASN-typed originator field.

regards,
-- 
Paul Jakma | [email-masked] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Snow Day -- stay home.

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Sep 2016 18:46:40 +0200

Hi,

> but trying to move "color" into a common bucket?

I'd love to have something minimal ASAP, and the kitchen sink bucket thingie
can then take until I'm retired to materialize.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Sep 2016 13:05:13 -0400

> can then take until I'm retired to materialize.

I suspect your 3 implementations in flight can add 64 bits of header on top
of the existing code without too much headache.  They should already have
transitivity checks in the code for extended communities they can lift.

And if those 3 implementations in flight ship on squatted code points
without appropriate plans to change per IDR standardization, they've learned
nothing about the foibles of what happens when you ship too early.

-- Jeff

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Sep 2016 19:11:10 +0200

Hi,

> nothing about the foibles of what happens when you ship too early.

We're not talking about "too early" here.  We're talking about "5 years
too late" vs. "at some future point of perfection, when nobody alive today
cares anymore".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Sep 2016 19:36:06 +0200

Hi,

On Fri, Sep 09, 2016 at 01:16:36PM -0400, Jeffrey Haas wrote:
> On Fri, Sep 09, 2016 at 07:11:10PM +0200, Gert Doering wrote:
> Not my network that crashes.  Enjoy. :-)

Actually, this is exactly the point: due to lack of a proper standard for
communities to support 4-byte-ASNs, people have to resort to various hacks
to achieve the required functionality.  *This* is where instability and
lack of sustainability comes from.

Not from shipping a simple and to the point standard that solves operational
needs in a straightforward way.

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Sep 2016 19:46:50 +0200

Hi Gert,

This thread is not about delaying anything. How did you get such impression
?

It all about putting the large community into proper envelope as opposed to
sending it as a postcard. It is NOT about trashing large community AS:4:4
and say oh folks wait few more years for universal type 1. Not at all.

>From code perspective adding a common header to a given type is no reason
for any delay. Then other types can get introduced as TLVs at their own
pace.

The only open question to WG is to agree on format of the common header
which could serve not only to large community type but also to other TLVs.

If WG agrees on attribute + common header as described in current -03
version of wide community draft with perhaps additional comments to be
incorporated in it - then we are done.

Best,
R.

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Sep 2016 19:49:43 +0200

Hi,

> incorporated in it - then we are done.

And if the WG does not agree, then -large is blocked?  Or how do I have
to read this statement?

Seems you and Jakob have been discussing this for years now, while the
operator community is waiting for something they can *just use*, no matter
whether it's brilliant or extensible or perfect.

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Sep 2016 20:01:43 +0200

Well ... if WG does not agree to use common header then it is up to the WG
to decide how to proceed otherwise. Luckily this is IDR chairs decision how
to structure the next steps.

> Seems you and Jakob have been discussing this for years now

Not at all ... Jakob never came to any wide community authors before last
IETF. So this topic is as old as last Berlin IETF.

Thx,
R.

---

From: Jared Mauch <[email-masked]>
Date: Fri, 9 Sep 2016 14:03:19 -0400

> On Sep 9, 2016, at 1:49 PM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

there was a semi-decent timeline covered at NLNOG today, going back to 2002,
namely an attempt to do something here:

https://tools.ietf.org/html/draft-lange-flexible-bgp-communities

Here’s the presentation slides:

https://nlnog.net/static/nlnogday2016/14_NLNOG_large_communities.pdf

I’m hoping there is an archive of the video, as there was palpable
frustration from the operator community at the microphone which may
help inform the frustration which is here on-list.

- jared

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Sep 2016 14:08:41 -0400

> And if the WG does not agree, then -large is blocked?  Or how do I have

Gert, while this is directed to you, this also applies to any operators
who've joined the list recently who aren't familiar with IETF process.

Minimally, please recent the tao of the ietf:
https://www.ietf.org/tao.html

The IETF works via rough consensus.  That consensus includes "letting go",
as seen in the tao. The IETF doesn't work through squatting on code point
and shipping early terrorism.  That leads to crashing the Internet.

If the WG says "no common header", we move forward with that proposal, code
happens and we move to interoperate.  In that case, the 4:4 type in wide
comms is likely removed from that proposal.

If the WG says "common header", ditto.  In that case, we have the following
possibilities in terms of documents:
1. It stays in the wide comm doc.  This is unlikely since the wide comm
feature is clearly moving at too slow of a pace.
2. We split the 4:4 case into a separate document.  Similarly, we likely
split out the common header to a separate document.  This permits the
documents (common, 4:4, wide) to move at separate speeds through the
standardization process.

2 is likely.  The use case of 4:4 is *already* covered in a WG document,
thus adoption of the case isn't necessary.  The chairs had explicitly asked
for documents to be published for the WG to comment on.  This means separate
wide comms, common header and 4:4.  The split was arguably gated on agreeing
on the common header comments.

> whether it's brilliant or extensible or perfect.

Years?  I'm not even sure I met Jakob nor heard about this draft until
last month.

The operational community?  Sure.  That's why the 4:4 case was originally in
the wide document.

Moving to a denser format?  PDUs are the *boring* part of standardization.
Drama aside, this is converging no worse than any other proposal in IDR.

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Fri, 9 Sep 2016 14:07:55 -0400

> On Sep 9, 2016, at 1:05 PM, Jeffrey Haas <[email-masked]> wrote:
> 

I similarly speculate you are correct.

> nothing about the foibles of what happens when you ship too early.

Honestly, I’ll take shipped in this case, but that is perhaps a topic for over
drinks in Seoul.  “Too early” here is flame bait, which may have been earned
but should not cloud the technical discussion.

I will say presuming that large is adopted by the WG (either with or without
the header as part of that draft or some other ..) this is near the top of
my list to discuss with my routing software and hardware suppliers next month.

- jared

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Sep 2016 20:17:23 +0200

> I will say presuming that large is adopted by the WG (either
> with or without the header as part of that draft or some other ..)

But isn't it why we are discussing it now ?

Btw ... Jakob already has a version with just the TLV listed referring to
externally defined common community header.

I think it may be good to post it as well so WG could see both versions of
large comms docs.

I would vote with both hands for adoption of the latter draft. Then we can
focus full discussion on the format of the common header.

Otherwise if the current draft asking for separate attribute get's adopted
and then WG decides to go with common community header it will be just a
bigger mess to clean up.

Thx,
R.

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Sep 2016 20:24:49 +0200

Hi,

> who've joined the list recently who aren't familiar with IETF process.

Oh, I do very well understand how consensus works, especially *rough*
consensus (as do most other folks that are active in the RIPE community,
like Nick and Sander).  

I was just wondering whether Robert intended to imply anything in the 
sentence above.

[..]
> and shipping early terrorism.  That leads to crashing the Internet.

"Not being able to agree on anything for 14 years" also leads to 
"crashing the Internet".

The tao is "rough consensus and running code".  We seem to have 3 
interoperable implementations, and all but two voices on the list 
recently have argued in favour of -large.  Which makes a fairly strong
consensus, per RFC7282.

[..]
> Drama aside, this is converging no worse than any other proposal in IDR.

If 10+ years is the *norm* for geting something done, this is worse than
I assumed.

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Sep 2016 20:48:02 +0200

> If 10+ years is the *norm* for geting something done, this is worse than

​All I can say that regardless if this is 5 years or 10 years new
functionality in BGP take that long when you add IETF process, vendor's
priorities and deployment rollout all together.

And that is why I was hoping that at least for communities with wide
proposal we can do one thing in a flexible format and address operational
needs for years to come.

If you are going to keep having similar discussions about fixed format of
communities and new attributes over and over again every few years - did we
really learned from the past mistakes ?

r.

​

---

From: Andrew Lange <[email-masked]>
Date: Fri, 9 Sep 2016 13:59:41 -0700

Hi Jared,

I’m glad you looked at the history!

When I was an operator, and wrote that original draft, which then became wide-comms, the motivation was the same as it is now.  

4-bytes ASNs were coming, and there are a lot of use cases that require not just a bigger community space, but a flexible community space.  It makes policy expressions MUCH easier and more powerful.  I still have an occasional nightmare about the manipulations Ed Crabbe and I had to go through to make the Exodus BGP policy work and parse correctly with fixed-length communities.  Just making the space larger propagates all the ugly that we have today.

After I moved to the dark side and started working for a vendor, other operators didn’t take up the baton, so getting implementations was tough — you know how vendors are coin-operated!  Now, the issue has become urgent.  I love the enthusiasm from the operator community!  

The right thing to do is to use a common header, that offers TLV capabilities.  Don’t let anyone whine that TLVs are “tough to implement”, it’s nonsense.  Every major BGP implementation can and does handle TLVs today.  

The consensus I see emerging is we advance a common header.  And, then put the interesting use cases like policy algebra, route-origin geolocation, etc. in separate docs. 

Andrew

P.S. I’m happy to have a beer BOF and we can go through some of the other use cases.  They are motivated by operational experience, and making policies we implement today faster and easier.   A lot of the use-case verbiage got trimmed in favor of implementation clarity.  Neighbor classes, for example, make policy expression a lot easier. 

> On Sep 9, 2016, at 11:03 AM, Jared Mauch <[email-masked]> wrote:
> 
>> 
> https://tools.ietf.org/html/draft-lange-flexible-bgp-communities <https://tools.ietf.org/html/draft-lange-flexible-bgp-communities>
> 
> https://nlnog.net/static/nlnogday2016/14_NLNOG_large_communities.pdf <https://nlnog.net/static/nlnogday2016/14_NLNOG_large_communities.pdf>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Jared Mauch <[email-masked]>
Date: Mon, 12 Sep 2016 09:30:30 -0400

> help inform the frustration which is here on-list.

here's the video link.

https://www.youtube.com/watch?v=5lM0KwBwBR4

I'd like to point people to the microphone comments to perhaps get
the perspective from folks running the code that gets standardized as
a result of the work here.

Comments start shortly after here:

https://youtu.be/5lM0KwBwBR4?t=12m47s

	- Jared

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 12 Sep 2016 14:39:09 +0000

Very good historical perspective - especially for someone who was focused
more on OSPF until last year.
Thanks,
Acee 

On 9/12/16, 9:30 AM, "Idr on behalf of Jared Mauch" <[email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Sep 2016 12:54:36 +0200 (CEST)

On Fri, 9 Sep 2016, Gert Doering wrote:

> too late" vs. "at some future point of perfection, when nobody alive 
> today cares anymore".

I have to agree with Gert here. The time to engineer a great, nice 
future-proof mechanism was 10 years ago, so it would have running code 
widely deployed 5 years ago.

Since we don't have that, then now is the time to standardize a "does the 
same as we have today for 16bitAS but for 32bitAS" which involves as small 
code, operational and standardization changes as possible, so code can 
get into operator routers ASAP.

So get it out the door now. Not in 6-12 months time. Now. ASAP.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Martin Millnert <[email-masked]>
Date: Wed, 14 Sep 2016 13:32:51 +0200

On Fri, 2016-09-09 at 20:48 +0200, Robert Raszuk wrote:
> All I can say that regardless if this is 5 years or 10 years new
> functionality in BGP take that long when you add IETF process,
> vendor's priorities and deployment rollout all together. 

Robert, I believe your explanation is correct.

It could probably be mentioned in the footprint somewhere that
interdependencies of protocol changes are often complex, and some times
the changes themselves become complex as a result.

To combat that, minimizing cognitive load and complexities helps. As a
guide line:
    "A designer knows he has achieved perfection not when there is
    nothing left to add, but when there is nothing left to take away."
      -- Antoine de Saint-Exupery

I believe the thinking such as behind this particular change in Large
[1] is a good example of this in action, and encouraging to see.

Best,
Martin 
[1] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community-02.txt

---

From: <[email-masked]>
Date: Wed, 14 Sep 2016 12:47:11 +0000

> From: Martin Millnert  > Sent: Wednesday, September 14, 2016 1:33 PM

One could also read this as a call for a single BGP attribute, a single (common) header and a single/few type(s) of community (rather than a multiplication of community attributes: regular, extended, large, extra-large, wide/flexible...)

IOW, minimizing the complexity for a specific use case is different from minimizing the total complexity for all uses cases.

Bruno

PS: As French quotes gain popularity in IDR, I can also quote Antoine de Saint-Exupery: "Chacun est responsable de tous. Chacun est seul responsable. Chacun est seul responsable de tous."
Which, according to Lewis Galantière, translates as "Each is responsible for all. Each is by himself responsible. Each by himself is responsible for all."

https://books.google.fr/books?id=Ulh-yhlmN8cC&pg=PT141&lpg=PT141&dq=%E2%80%9CEach+by+himself+is+responsible+for+all%E2%80%9D&source=bl&ots=nOo0yvpOGe&sig=xRFvCCNE8cf9ZcY0cTDrjaA8VzA&hl=fr&sa=X&ved=0ahUKEwiZ77iv7o7PAhXGlxoKHcNvAS4Q6AEIJjAB#v=onepage&q=%E2%80%9CEach%20by%20himself%20is%20responsible%20for%20all%E2%80%9D&f=false

 > [1] https://tools.ietf.org/rfcdiff?url2=draft-heitz-idr-large-community-02.txt

_________________________________________________________________________________________________________________________

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: Robert Raszuk <[email-masked]>
Date: Wed, 14 Sep 2016 15:07:16 +0200

Mikael,

> So get it out the door now. Not in 6-12 months time. Now. ASAP.

Get what out of the door ? Are you asking IDR to give you code to run in
your network ?

Operators where not sufficiently asking vendors for last few years to
implement solution accepted long time as IETF IDR WG document .. so vendors
never prioritized to implement it.

No one from mobilized *NOG community also provided any feedback to IDR WG
that solution which we have as working group document is too complex or is
missing something ... contrary when we first defined wide community spec I
had a lot of operators contributing to it and providing their requirements
to what communities should be useful.

All of that is publicly available as again IDR WG document.

IDR has no power to tell any vendor to implement anything. It can only try
to issue BGP extensions which are to be in the best interest of the
protocol. And vendors as past experience shows can and do ship pre-standard
features to gain operational experience and win time to market.  Why the
latter in the recent years has been slower then before ... well you need to
ask vendors for that or move to opensource and start implementations
yourself.

Cheers,
R.

On Wed, Sep 14, 2016 at 12:54 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> code, operational and standardization changes as possible, so code can get
> into operator routers ASAP.
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Sep 2016 09:28:28 -0400

> So get it out the door now. Not in 6-12 months time. Now. ASAP.

+1.

Seeing as pithy French quotes appear to be the hotness this week:
"Le mieux est l'ennemi du bien." (The perfect is the enemy of the good.)
- Voltaire

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Sep 2016 16:09:42 +0200 (CEST)

> Get what out of the door ? Are you asking IDR to give you code to run in 

I'm asking IDR to get the document out the door. We can hit the vendors 
over the head for implementations after that just fine, thank you.

And having worked at operators since 1999, I can tell you that getting 
through the account teams is designed to be hard. The answer is always 
"you're the only one asking for this". I've been told this so many times 
(which usually was a lie) it's very upsetting to read your text about 
operators not trying hard enough. What should we have done? All camped 
outside John Chambers office with banners demanding this, or what?

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 14 Sep 2016 16:22:12 +0200

Hi Mikael,

Being nearly 17 year a vendor I can tell you that nothing works better for
the account team then fear of loosing a customer or at min part of their
business.

Introducing a second vendor always raises the alarm even if customers do
not always see it :)

Worst case is vendor lock .. in such a case indeed you can't do much.

- - -

Bottom line - no one here is trying to delay or deny urgent need for large
comms. We are just trying (and trust me there is daily a lot of
conversations about it) to pack it in the proper envelope.

Considering the speed of standardization process itself and various phases
current discussion is really in the best interest to make it as fast as
possible an RFC.

Imagine that now working group just blindly passes it though then
directorate review or IESG review will reject it - as not discussed in the
WG. So it will go back to where we are today and it will not be in any
interest of the community.

As John already said the other day seeing few emails from those who were
not even subscribed to IDR - IETF WG rough consensus is really not about
counting "+1s" from folks who never actively participate in the IDR WG work
or mailing list discussions.

Cheers,
R.

---

From: "Dickinson, Ian" <[email-masked]>
Date: Wed, 14 Sep 2016 15:02:58 +0000

?  As John already said the other day seeing few emails from those who were not even subscribed to IDR - IETF WG rough consensus is really not about counting "+1s" from folks who never actively participate in the IDR WG work or mailing list discussions.

I used to consume the idr list via the web - like many ietf lists - and joined explicitly to participate. In this case my primary reason for participation is primarily to signal that there is operator demand and that a simple large community is what I need. Are you saying this is inappropriate?

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: Robert Raszuk <[email-masked]>
Date: Wed, 14 Sep 2016 17:36:17 +0200

Hi Ian,

No - not at all. All voices from the community indicating need for given
protocol extensions are IMHO very precious to everyone.

All what I was trying to indicate was that suggesting to speed up and
accept proposal as WG item and immediately go to last call is not what IETF
process is all about.

And even if IDR WG would do that (meaning if a WG draft would be last
called this week) it still takes many months to get via IETF review and
approval and editor queue process for it to become a standards track
published RFC.

Cheers,
R.

On Wed, Sep 14, 2016 at 5:02 PM, Dickinson, Ian <[email-masked]>
wrote:

> Ø  As John already said the other day seeing few emails from those who
> were not even subscribed to IDR - IETF WG rough consensus is really not
> about counting "+1s" from folks who never actively participate in the IDR
> WG work or mailing list discussions.
>
>
>
> I used to consume the idr list via the web – like many ietf lists – and
> joined explicitly to participate. In this case my primary reason for
> participation is primarily to signal that there is operator demand and that
> a simple large community is what I need. Are you saying this is
> inappropriate?
>
>
>
> 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: Jared Mauch <[email-masked]>
Date: Wed, 14 Sep 2016 12:05:59 -0400

> interest of the community.

	In my opinion there is some emergening consensus on a few topics.
I'm hoping we can optimize on a minimum set of document(s) that have broad
support.

> or mailing list discussions.

	I think there is danger here we should clearly avoid.  Counting +1's
is valuable for some definition of value, but we must drive for consensus
in the WG.  This means not everyone may be happy, be it Me, Jeff, Job, Jakob,
Keyur, Robert, Bruno, Mikael, Gert or anyone else.

	having watched this pot be stirred, i'm seeing enough people
motivated to do something, which I think will drive the necessary review
of any documentes adopted in the WG.

	- Jared

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Sep 2016 16:45:13 -0700

> Since we don't have that, then now is the time to standardize a "does
> the same as we have today for 16bitAS but for 32bitAS" which involves
> as small code, operational and standardization changes as possible, so
> code can get into operator routers ASAP.
> 

yes!

---

From: Andrew Lange <[email-masked]>
Date: Wed, 14 Sep 2016 17:14:52 -0700

This assumes that we don’t have perfect (or at least better) already. There are existing idr drafts that do everything large does.  In fact, by using the common header it can behave exactly like large with an opaque payload you can interpret as 4+4 or any other way local policy allows.  The common header is already defined, has been vetted by becoming an IDR draft and being examined over the years.  Existing drafts are farther ahead in the standards process.

If it’s implementations you want, then ask your vendors!

Having been on both sides, there is no magic to the standard PLM process at vendors.  Customers ask for features, the account teams and regions bring this back to PLM where it’s aggregated.  At some interval PLM gets together and decides what the priorities are for the next release (and the release thereafter for big features).  Number of customers, amount of revenue and feature size are the main considerations.  A common header and opaque body for communities is a small feature.  

Andrew 

> On Sep 14, 2016, at 6:28 AM, Warren Kumari <[email-masked]> wrote:
> 
> On Wed, Sep 14, 2016 at 6:54 AM, Mikael Abrahamsson <[email-masked] <mailto:[email-masked]>> wrote:
>> Mikael Abrahamsson    email: [email-masked] <mailto:[email-masked]>
>> 
>>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 22 Sep 2016 01:58:30 +0000

https://tools.ietf.org/html/draft-heitz-idr-large-community-04
as approved by the WG for adoption does not share a common header
with any other BGP attribute. Judging from emails to the list,
there is widespread support for keeping it that way.

The first 7 attributes were added to BGP by RFC 1654 in 1994.
2 are reserved. 24 attributes have been added in the 22 years since.
There are 223 attribute codes left. At that rate we will run out in
over 200 years. And then we can define a common header under which
to define another 200 years of attributes.

I understand that there have been 3 "incidents" in the past,
caused by BGP bugs regarding attribute handling:
 o Corruption of unknown attributes,
 o Attr 128 ATTR_SET handling,
 o leak of confed ASN in AS4-PATH.
This has lead to many ASes filtering all unrecognized or unnecessary
BGP attributes.
RFC7606 will now prevent session resets under these and similar conditions.

If we define a header today under which to group a set of new 
BGP attributes, then if there is a bug in just one of them,
then ASes will filter the common header, thus filtering every
attribute under it.

I think large communities should be a BGP attribute not under
another header.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: Wednesday, September 14, 2016 4:45 PM
> To: Mikael Abrahamsson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] community of the day - common header
>

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Thu, 22 Sep 2016 07:29:02 +0000

+1 
Keep it as simple as possible

Bertrand
Best Regards Bertrand Duvivier
https://wiki.cisco.com/display/SLA/Segment%20Routing

---

From: Gert Doering <[email-masked]>
Date: Thu, 22 Sep 2016 11:20:01 +0200

Hi,

> Keep it as simple as possible

+2

Gert Doering
        -- NetMaster

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 22 Sep 2016 07:48:57 -0700

Support Jakob’s position.
 
Cheers,
Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 22 Sep 2016 12:06:38 -0400

Folks, the adoption call for large has completed, the result has been announced, there is not really any need to continue to debate this. If you have a point to make that you think will make people smarter and hasn't been made five or six times already in the last two weeks, go for it, but IMHO we especially don't need "+1" messages.

TYVM.

--John

> On Sep 22, 2016, at 10:48 AM, Jeff Tantsura <[email-masked]> wrote:
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 22 Sep 2016 20:30:15 +0200

Hi,

> Folks, the adoption call for large has completed, the result has been announced, there is not really any need to continue to debate this. If you have a point to make that you think will make people…

my +1 was not on "adoption" but on Jakob's position regarding common header,
after WG adoption.

Gert Doering
        -- NetMaster

---

From: Job Snijders <[email-masked]>
Date: Thu, 22 Sep 2016 20:33:03 +0200

Hi Gert,

On Thu, Sep 22, 2016 at 08:30:15PM +0200, Gert Doering wrote:
> > Folks, the adoption call for large has completed, the result has
> > been announced, there is not really any need to continue to debate
> > this. If you have a point to make that you think will make people
> > smarter and hasn't been made five or six times already in the last
> > two weeks, go for it, but IMHO we especially don't need "+1"
> > messages.
> 
> my +1 was not on "adoption" but on Jakob's position regarding common
> header, after WG adoption.

Yes, that was clear. I think that John is encouraging the working group
to provide new arguments or new information (or new counter arguments)
rather than upvote posts made by others.

Thanks!

Kind regards,

Job

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Sep 2016 18:56:55 +0000

Hi John, 
But it would be better to have the common header discussion now rather
than during WGLC. Can we then assume that the discussion has concluded and
that the requirement for a common header is off the table?
Thanks,
Acee 

On 9/22/16, 2:33 PM, "Idr on behalf of Job Snijders" <[email-masked]

---

From: John Scudder <[email-masked]>
Date: Thu, 22 Sep 2016 19:38:22 +0000

Acee,

Of course not. I think Job summarized it admirably. 

I do encourage people to take a deep breath, gather their thoughts, and wait for the -00 of the WG draft to be posted before piling on. And of course, to make new points rather than reiterating old ones -- we have a mailing list archive, we know what you already said, there is no need to repeat. 

Finally, IMHO "+1" posts add nothing at all to the conversation with the possible exception of when we are doing a formal consensus call -- which we currently are not. (Even then they're marginal.) 

--John

> On Sep 22, 2016, at 2:56 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi John,