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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> wrote:

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