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

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 08 November 2016 01:33 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22061294D6 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 17:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpzZPShuLggt for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 17:33:54 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8F5127071 for <idr@ietf.org>; Mon, 7 Nov 2016 17:33:53 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id f82so152308483wmf.1 for <idr@ietf.org>; Mon, 07 Nov 2016 17:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gmq/R45r6X5gsUrKXYOEu4IgmOp1WfhHz6Qtmf5p6sM=; b=m9VcCG9JOo7520IaoaZbESO6LhTQfQbuk4sHVoXemR88GVJXZFzQiP4oLwcjb8Z8m5 0OlNdqgQKU2CiaSLW3Ja/jPw7sWGZjY1USYG69b45Otg9rsmFnmOVYXYZLPXR6RebTgG P6fRZ2YAqJ+wuweQ0qgNW6yoXVxXe+7EcQI/mPWE+a/xuJO9rXlKEJhktq9f5vRRsFmk 0BkgF0CGPNvAWD4GnCmehy6OOrIwXoK36+4RBy4pFk+PCcbomxsmIOHnIno3fjFvWyQb OfksN2Xx8pQfWFR/29ajJV+59YxVdDpnsoGEspo2ZQvOLc0XtMwWetrRLM86wWYpY6Sz cD+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gmq/R45r6X5gsUrKXYOEu4IgmOp1WfhHz6Qtmf5p6sM=; b=ij9TjDdolShF4frdm84OZXyQmSoK0QwkpAi+TSo48f0gihV1ZpNjwzu81Qf5Yz8oDJ 7ZyUK3A6uNRPX/+fre1e8YghUbz3w0EMSdSavA2pJgTzpCpreM3Mj3Qv+Ja7PZKC04XR w+CPwwuSjozseDTRyewrBZPLXaC1uPOADq36aZ67+D2P+2w/eX9HrT7H9Q4Am82KwMjZ 54QELKKGF7m730qSI9U9Kqby5TfR5VPL1tk4BUZKFXDs2S/tMQ7tIjqnL750tYAqdLR8 3PO2mlOJ91Fhq24GGC3PMOMJZ40TkE+vClBKyeNNkd9IyOGzt/h0pJ0wFWR7+NXUwpXJ BlFQ==
X-Gm-Message-State: ABUngvddL8q6jTKxBa+bMYjGKHKjSEGMcUou3YWw5aqmf7Few9EI9f5mrIv6NXf5O0se9wd6ragJdoOoRKOSDg==
X-Received: by 10.194.78.195 with SMTP id d3mr7682221wjx.96.1478568832381; Mon, 07 Nov 2016 17:33:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.197.132 with HTTP; Mon, 7 Nov 2016 17:33:50 -0800 (PST)
In-Reply-To: <CA+b+ERmPr_1FvZYKVopewag4av_g7CqO-b1zfFhKgKtc+L-qNw@mail.gmail.com>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com> <CA+b+ERm5VVz520OhgXYTFOt9_M6_=MHLE9M-=1T+wnfw7RY83Q@mail.gmail.com> <C2C26B2F-75A0-49FB-B947-4B957611A23E@cisco.com> <CA+b+ERkieHXpXQxjGnU+dGAz2nbNzWb6DxHG6vB7X5bp9VD3+Q@mail.gmail.com> <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com> <20161107202554.GI62252@shrubbery.net> <CAH1iCipFL3BGKRzz+LfbkOAPePsGBLdRo0HBCjTFwnMC1+-+eA@mail.gmail.com> <20161107225417.GA67860@shrubbery.net> <CA+b+ERmPr_1FvZYKVopewag4av_g7CqO-b1zfFhKgKtc+L-qNw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 7 Nov 2016 17:33:50 -0800
Message-ID: <CAH1iCiryEw3fLQ3dcN7fhHm6mx8=AP9y2TMDGdeuZHa_67PqWA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary=047d7bfd001007ba270540c0225f
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-9_vszwPoxVFVYHXgUvkIAtowK0>
Cc: heasley <heas@shrubbery.net>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2016 01:33:57 -0000

On Mon, Nov 7, 2016 at 3:30 PM, Robert Raszuk <robert@raszuk.net> 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