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

[Brian Dickson <[e-mail]>]

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.



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

>
> > 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?
Does AS1 send RFC1997 communities to AS2?
Is the reason AS1 isn't sending RFC1997, that AS3 is a 32-bit ASN?
Presumably AS2 doesn't send RFC1997 to AS3 either, for the same 32-bit ASN
reason.

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