Re: [Idr] One week extension to WGLC for draft-ietf-idr-large-community

[Job Snijders <[e-mail]>]

On Sun, Nov 20, 2016 at 10:17:20AM +0000, t.petch wrote:
> > t.petch wrote:
> > > An issue that came up earlier and that I did not see resolved was
> > > what constitutes a duplicate.  This is binary so we don't have the
> > > issues that character comparisons do but is it the same bit pattern
> > > from start to finish, the same semantics or something between the
> > > two?  A case I have in mind is when the same semantics appear in
> > > RFC1997 format and also in LC format; is that a duplicate?.
> >
> > rfc1997 and LC being different namespaces, no.
> 
> So you have someone been happily using RFC1997 for years with success
> when one of their pesky peers goes and gets a 32-bit ASN and suddenly
> they cannot use RFC1997 any more and have to start using LC, to do
> exactly the same thing as they have been doing for ages.
> 
> We are now saying 'ah no, this is two separate unrelated bits of
> technology that cannot be compared and you must treat as different'.
> Someone with a 32-bit ASN is in a different universe to someone with a
> 16-bit ASN.
> 
> Mmmm not very friendly.

I find it disingenuous to refer to 32-bit ASNs as 'pesky peers', you
very well know that the 16-bit pool has been depleted: IANA no longer
has 16-bit ASNs. Most RIRs are almost out or sitting on small reserves
of 16-bit ASns. Soon there simply won't be any choice but to use 32-bit
ASNs. 

When RFC 4893 was introduced, it was obvious that there would be gaps in
terms of feature parity, such as BGP Communities and GLOP space. Things
would not be the same. Within RFC 4893 itself, there is transition
measure involving the 23456 ASN. This transition measure did not allow
for actual policy transition, as the information it communicated added
up to what was essentially "here be dragons". Until operators upgraded
to firmware with RFC4893 support, crafting uniform policy for 16-bit and
32-bit AS paths was not feasible.

In this proposal, we've chosen not to introduce such a measure, as
generic approach to mapping 96 bits into 32 bits simply isn't
reasonable, and can't be done meaningfully.

Just as the case was with RFC 4893, RFC 1997 and Large Communities will
coexist side by side for some time. Vendors can implement mapping
primitives at the router level which would allow for mapping and
transformation. But these are local considerations.

I am disappointed that you _again_ bring up the topic of mapping between
RFC 1997 and Large Communities, which has already been discussed and
concluded as out-of-scope for this draft.

The most unfriendly thing we can do now is leave our 32-bit peers out in
the cold, without functional community space they can use for
implementing policy. Please just get out of the way.

Regards,

Job