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

Robert Raszuk <robert@raszuk.net> Mon, 07 November 2016 23:30 UTC

Return-Path: <rraszuk@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 E643A129450 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 15:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 3D0eJJmPtnnH for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 15:30:05 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 033CF129443 for <idr@ietf.org>; Mon, 7 Nov 2016 15:30:05 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id p190so213941663wmp.1 for <idr@ietf.org>; Mon, 07 Nov 2016 15:30:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wq2PkAtecVgt/nTvyY6ih4TYvluUNLaVJm3HsCOJD9s=; b=f6Y5o1arKZiLVbT+5n/zc8scBpGI6ASe46KtDLnxLMGQPejDXa57PCf/XefIvEVJcD 2BRxjHBWU3lFCE4dEy+ssjCrKhxJFzDEFOdbRbdBfet6reXbMK7+bw9BMpAiPc4VF1Yu VNffn7prfn8iQDXQ7qSRtc2wRYW4/nAxHQatGnAPwuoXZgJ6U+4mwViyinxb2mlAfwdf Ug8voi7y/90vdaZK65A+hzP5QOQ9uZiEadFY89RWslP7OLcXM9kLfUc/6DUi5bFqeJYt GNLpAzgkz2tzFrTMX3hj3qabjz0nGIdb4oK5Xi5kAuQo0xNraG6D7Znqq5PckWCRyxdJ RifA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wq2PkAtecVgt/nTvyY6ih4TYvluUNLaVJm3HsCOJD9s=; b=MAyc4BGmrm0jap7JObpuYePW3sL1HBLIC/ybF1LGp/ZXWjP2/YzCCoUpmwnAZVJ74l 8dXLNumpft0yGovNUBIcY7RNtKeHhOkojyJt+CXSbZ68GAlx8N+KnIvzg8tGl7RjZsNb cxkKM6+aCu5Jcj5Zmnh6V08XUNeH9Azmzkt83yR5db2wDi/ePVJW1JzqaKdOvpTFGz1Z LoET/5wa0VX2sL0h+UyNHVOWj/GSzxX64ABo3EDHWhwh6Yf1V8uDIwORMkWAKbXJYjPN G84LjHgxmevvnYz1XhXC2nh//p55j9hqH1mltIzp8a88Pnk0a63+EDisuR4A03oRcwNG SR9g==
X-Gm-Message-State: ABUngvdisCKhtXGvlALowXHWCE2JHOcNMU8Fg5dEOFevu2w5HWb3FJ933sVYNsdenA0EfVwRcAEDnFJT49l9TA==
X-Received: by 10.28.185.203 with SMTP id j194mr8886192wmf.73.1478561403435; Mon, 07 Nov 2016 15:30:03 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Mon, 7 Nov 2016 15:30:01 -0800 (PST)
In-Reply-To: <20161107225417.GA67860@shrubbery.net>
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>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 8 Nov 2016 00:30:01 +0100
X-Google-Sender-Auth: vtZP9lN5fj52XiSBVzr3wEKjjrY
Message-ID: <CA+b+ERmPr_1FvZYKVopewag4av_g7CqO-b1zfFhKgKtc+L-qNw@mail.gmail.com>
To: heasley <heas@shrubbery.net>
Content-Type: multipart/alternative; boundary=001a1148ebca3b1d230540be6799
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zGFPV25BsqK2nsY1y7QKnqpP6nw>
Cc: "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: Mon, 07 Nov 2016 23:30:07 -0000

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).

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

If some folks want parity with RFC1997 Large should be 4:4 no more. It is
not 4:4 and it is a new attribute so whoever in their policy decides to use
new attribute to modify routes he/she better understands what are the
consequences.

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:

https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

... and we are just few millimeters far from addressing 90% of those use
cases if we would not take a selfish view and turn large into 4:4:4:4.

With respect to all,
Robert.


On Mon, Nov 7, 2016 at 11:54 PM, heasley <heas@shrubbery.net> wrote:

> Mon, Nov 07, 2016 at 01:06:17PM -0800, Brian Dickson:
> > On Mon, Nov 7, 2016 at 12:25 PM, heasley <heas@shrubbery.net> wrote:
> > > Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <robert@raszuk.net>
> wrote:
> > > > It might be the case that initial deployment could incorporate 16-bit
> > > ASNs in 32-bit fields, including private ASNs.
> > >
> > > What?  is there a case where a 16bit ASN doesnt fit in 32bits?
> >
> > No, what I am saying is, it might be the case that the very first LCs
> seen
> > are "65501:3356:0" (which, in my hypothetical scenario, are
> transliterated
> > RFC1997 communities, understood by both AS2914 and AS49544)
> >
> > The difference being:
> >
> >    - RFC1997 propagation might be affected by some implementations of
> >    RFC1997 defaulting to "do not send" and router configurations relying
> on
> >    that default.
> >    - LC propagation, if not consistent with RFC1997 propagation, might
> >    result in the LC community going where the RFC1997 has not gone, and
> might
> >    result in changes to routing.
>
> Everyone involved would have to actively change their policy to add that
> LC and to take action on it.
>
> And, why would an operator expend the effort to use 1997 communities in LCs
> with an extra 0 field?  Leave the 1997s alone, add LCs specified to take
> advantage of LCs (no over-loading, AS4) and stop taking action on and/or
> marking routes with 1997s after some transition period.
>
> > > > 20 years of  RFC1997. All with default off. 20 years of industry
> > > consolidation, staff turnover, undocumented implementations.
> > >
> > > 20 years in that implementation...
> >
> > ... which should not REQUIRE implementation/configuration changes
> > overnight, IMHO.
>
> it doesnt; LCs dont exist yet.
>
> > > > Assuming that no migration will occur, isn't helpful. Changing the
> > > default behavior across such migration is the risk.
> > > >
> > > > Having the same behavior for large guarantees zero incremental risk,
> > > which is why I am advocating for it.
> > >
> > > given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs
> and
> > > AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
> > > potentially break when AS2 updates to an o/s that recognizes LCs.
> > > surprise!
> >
> > There are 3 ASNs involved, and two peering connections.
> > Does AS2 already do RFC1997?
>
> whatever - that's irrelevant in my PoV; 1997 & LC are not the same.
>
> > Does AS1 send RFC1997 communities to AS2?
>
> irrelevant.
>
> > Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?
>
> maybe.  maybe AS3 never supported 1997.  maybe they have transitioned
> away from 1997.  maybe its an "action" community with a "target" ASN
> (AS3:prependonce:AS4).  or AS3 marks their routes with LC in some manner
> that interests AS1, such the rt's region origin and AS4's path between two
> regions is routinely congested.
>
> > Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit
> ASN
> > reason.
>
> irrelevant.
>
> fact is that it would work until AS2 upgrades, unless AS2 adds the config
> to disable to default filtering - that is assuming that they are clueful
> enough to do so.  that's an element of surprise.  vs. AS2 deciding that
> they will start using LCs and discovering that their customers & transits
> are already using them.
>
> > I think the scenarios boil down to:
> >
> >    - AS2 already does RFC1997, and does its upgrade with LC as part of
> the
> >    plan.
> >       - I would expect AS2 to monitor for LCs in their BGP updates before
> >       upgrading, and use an upgrade config that passes LCs.
> >    - AS2 does not do RFC1997, in which case expecting it to do LCs is not
> >    entirely reasonable on the part of AS1.
> >       - AS1 should discuss their expectations with AS2, and encourage
> them
> >       to do LCs AND RFC1997.
> >
> > In other words, in neither case should the breakage be a surprise; it
> > either should not break, or should be expected to break.
> >
> > I'm not advocating for breakage, obviously, and am a big advocate of both
> > RFC1997 and LC.
> >
> > But, vendor code isn't best place to try to get communities propagated -
> > the contracts or peering agreements between ASNs is a much better place.
> >
> > Brian
>