Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

[Brian Dickson <[e-mail]>]

On Mon, Nov 7, 2016 at 3:30 PM, Robert Raszuk <[e-mail]> wrote:

>
> FWIW Heas is extremely right here.
>
> > 1997 & LC are not the same.
>
> Indeed and those who claim to say so in order to progress Large under the
> cover of RFC1997 are just wrong (sorry).
>

RFC1997 is 32 bits, used as "16-bit ASN" : "local".

LC is 96 bits, defined as "Global Administrator (aka 32-bit
ASN)":"local1":"local2".

LC provides more than 4:4 (which would have been the absolute minimum for
parity), and that extra 4 is appreciated and noted.

Upgrading RFC1997 to give parity back to it, would require "2:2:2" or
"2:2:4", and might have been useful 15 years ago, but whatever.
Having 4:4:4 available gives somewhere for RFC1997 to move to, and it can
do so without any collisions.
Global Administrator for 16-bit ASNs works just fine.

Concerning my earlier brief description and explanation of why things like
"65501:2914:0" might be among the first LC values seen:

I think understanding the rationale will be helpful in understanding,
generally, why all operators want/need is "32-bit ASNs and 32-bits of
non-overloaded space to design their own methodology".

So, here goes, again, this time with more words and hopefully clearer logic
and explanations.
(I should have known better than to try to do this using my smartphone.
Apologies for the earlier cryptic explanation.)

The following "table" shows the minimum level of support for doing "generic
communities" across 16-/32-bit ASN:

SRC \ DST  16-bit 32-bit
16-bit       1997   LC
32-bit     1997/LC* LC

The following table shows an "upgrade" path for 16-bit ASNs peering with
16-bit ASNs, who want parity with LC:

SRC \ DST  16-bit 32-bit
16-bit        LC    LC
32-bit        LC    LC

(* NB: RFC1997 was really only feasible for use between 16-bit ASNs, or
where the destination ASN's "action" target was a third-party 16-bit ASN.)

1997 and LC are not "the same". 1997 is the predecessor, and a subset, of
LC, in the same sense that 16 bit ASNs are the predecessors of, and a
subset of, 32-bit ASNs.

Here's what the operator community wants:

   - 32-bit ASNs and an extra 32 bits to play with.


Here's what the operator community wants the Global Administrator field to
mean:

   - The ASN of the entity defining the values and semantics for Local1 and
   Local2.


Here's what the operator wants the meanings of Local1 and Local2 to be:

   - <whatever the Global Administrator says>


This is not new functionality; it is parity with RFC1997, with more bits
(32 more bits, after expanding the second 16 bits of 1997 to 32 bits).

The semantics of RFC1997 were tortured to death, often by abusing the
private ASN values, which had the potential for causing communities
collisions.

It should be obvious that the availability of LC provides the means to end
this overloading, by providing enough room in Local1:Local2 to handle
any/all use cases that any 16-bit ASN requires.
(I say 16-bit ASN here, because, by definition, they are the only
globally-unique ASNs that were able to make use of RFC1997, without
squatting.)

Moving from RFC1997->LC give the potential to do more -- but to state the
obvious, does not require one to do more, or at least not in any specific
timeframe.

Suppose I am a 16-bit ASN, and I was using private ASNs in order to handle
use cases that exceeded the overall capacity of the lower 16-bits of
RFC1997.
So, I had two sets of RFC1997 communities:
MY_ASN:xxxx
yyyy:zzzz
(for many private ASNs yyyy)

The very first thing I would want to do is to get away from private-ASN
RFC1997 values, and I would deploy LC for those:
MY_ASN:yyyy:zzzz
I might also want to provide:
yyyy:zzzz:0
to ensure less-capable customers are able to make the right thing happen,
even if that LC is likely to collide with anyone else using it.

But now I am doing both RFC1997 and LC, which complicates my route
processing, and increases my maintenance.
So, I am going to migrate the rest of my RFC1997 communities, by some kind
of transliteration:
MY_ASN:0:xxxx
 or
MY_ASN:xxxx:0

Once, and only after, I have all my customers migrated, I can (and would)
decommission RFC1997 entirely (in my network, that is).

Now I can begin improving the capabilities offered, and migrate off of
overloaded xxxx's and yyyy:zzzz values.

HOWEVER, and this is really important, LC gives me the right NOT to do so,
or to do anything I want, no matter how foolish it is, so long I use
MY_ASN:Local1:Local2.

As an operator, I am not asking the IETF-IDR WG to do anything other than
give me the tools to do whatever I want, however I want.

This gives me independence from vendor lock-in, and the ability to switch
vendors without pain or delay.

This gives me the ability to operate a multi-vendor network, and to
interoperate with other operators' networks regardless of vendor.

This gives me the ability to acquire another operators' network, and
integrate it without significant problems

In this regard, this is precisely WHY the operator community only wants
parity with RFC1997.

The limited capabilities offered by vendors for fancy things was a FEATURE
of RFC1997, not a bug.

We had kind of hoped you (collective you, meaning all the vendors) had
learned this lesson over the last 20 years...


> We are defining a new world wide functionality in BGP and we should take
> all what it takes to do it right.
>

Give us MY_ASN:Local1:Local2.

That is what it takes to do it right. Anything else would be an abject
failure.

(We're fine if you insist on calling it Global Administrator:Local1:Local2.)


>
> If some folks want parity with RFC1997 Large should be 4:4 no more.
>

Wanting parity doesn't mean wanting _only_ parity. You can build a house
"to code" by building substantially better than "code". ("Code" means
minimum code.)


> It is not 4:4 and it is a new attribute so
>

(IMHO this whole "it is a new attribute" is a non sequitur...)


> whoever in their policy decides to use new attribute to modify routes
> he/she better understands what are the consequences.
>

I fail to see how that is any different than the implicit rules for RFC1997.


>
> While this may be taken as "distraction" or attempt to "derail" large I am
> spending my private time on this list to make the best for BGP as protocol
> realizing how hard it is to deploy new BGP extension worldwide.
>
> And if so progressing large should be able to accommodate operators voice
> captured in this document:
>

Irrelevant to LC...

"Have fun storming the castle!"

The massive -wide- thing fails to understand the fundamentals of operators'
reality:

   - Avoiding vendor lock-in
   - Avoiding vendor implementation delay
   - Avoiding vendor heterogenous version issues
   - Avoiding heterogenous-vendor networks issues
   - Speed to deployment of differentiating services based on RFC1997 (now
   LC) capabilities
   - One size never fits all
   - Customer size does not correlate to customers' importance to the
   Internet
      - For example, consider the relative number of routers for ICANN,
      IETF, ISOC, etc. versus a regional fast-food chain.
   - The IETF, in the vendor hardware/firmware space, operates so slowly
   that most features are already obsolete by the time they reach full
   standard. Sorry.
      - Large Communities has been the exception that proves the rule.

No offense intended towards anyone, just trying to make the operators'
position and reasoning as clear as possible, to those who aren't or haven't
been.

Sincerely,
Brian