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

[heasley <[e-mail]>]

Mon, Nov 07, 2016 at 01:06:17PM -0800, Brian Dickson:
> On Mon, Nov 7, 2016 at 12:25 PM, heasley <[e-mail]> wrote:
> > Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > > > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <[e-mail]> 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