Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

[Jared Mauch <[e-mail]>]

On Thu, Sep 15, 2016 at 01:23:49PM +0200, Robert Raszuk wrote:
> Hi Nick,
> 
> Just a bit side question ...
> 
> If this is so urgent have you considered to use extended community which
> within 6 octets allow you to put both 4 octet AS and 2 octet for meaningful
> marker ? From that thread I got that context-as is not so critical for
> large communities.
> 
> All implementations support that already in all deployed gear so you can
> get 32:16 essentially now - even without any IDR and IETF process.

	This doesn't let me target 32-bit ASNs so misses the mark.

	- jared

> On Thu, Sep 15, 2016 at 1:13 PM, Nick Hilliard <[e-mail]> wrote:
> 
> > Jeffrey Haas wrote:
> > > Any reason to not throw a common header on this one as the first and stop
> > > kicking this football down the field another round?
> >
> > yes - an extensible communities framework capable of handling >= 32b:32b
> > has not materialised since support for 4-octet AS numbers was formalised
> > in 2007.  This issue is now burning hot in the operational community: we
> > are scraping the bottom of the barrel with asn16 pools at the RIRs and
> > we are no longer in the position that we can wait until consensus is
> > reached on a common header.
> >
> > If we go for a common header, this does two things: first, it will take
> > inherently longer to get something out the door due to the usual
> > consensus bashing and secondly, whatever appears will be more complex.
> > This isn't about PDU encoding: it's a matter of overall systems
> > complexity: defining flexible grammars to handle the complexity
> > introduced by a TLV based common header, coding, documentation,
> > training, inter vendor compatibility, testing, etc, right down to
> > operational complexity.  This raises the bar significantly in terms of
> > both vendor and to a slightly lesser extent, operator adoption.  Raising
> > the bar for vendor implementation means that timeframes will be pushed
> > down the road.
> >
> > We need something now and it needs to be simple.  The decision about
> > using a common header is something that ought to have taken place years
> > ago, and we no longer have the luxury of waiting.
> >
> > Nick
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >

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


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