Re: [Idr] WG adoption for draft-kumari-deprecate-as-set-confed-set - 8/16 to 8/30/2019

[Jeffrey Haas <[e-mail]>]

On Fri, Aug 16, 2019 at 07:24:30PM +0200, Job Snijders wrote:
> On Fri, Aug 16, 2019 at 05:22:08PM +0000, john heasley wrote:
> > Fri, Aug 16, 2019 at 10:13:36AM -0700, Randy Bush:
> > > > imo, wg discussion of this should address how the complete removal
> > > > will proceed, such that implementations can drop support entirely,
> > > > which this draft does not address.
> > > 
> > > could you explain a bit more?  e.g. do you mean how a conforming
> > > speaker, i.e. one which does not support sets, should act when
> > > receiving a set?
> > 
> > yes; wouldnt one respond with an unknown/malformed attribute
> > notification, unless some alternative were prescribed.
> 
> 'treat as withdraw' would seem more appropriate

That's one way to do this.  But as stands, simply saying "deprecated/don't
do this" and urging "don't support" in future implementations will get you
errors at some point if we're not careful.

Right now, we still have BGP speakers on the Internet that are speaking
largely raw RFC 1771.  It largely still works since a lot of the nits that
got addressed between 1771 and 4271 (and related modification RFCs like
confederations) have internal impact to a given AS and don't bleed into the
wider Internet.

It's necessary to presume we SHALL see SET elements in AS_PATHs for the
foreseeable future.  Deprecating needs to be explicit what to do when you
see them.  Treat as withdraw is a fine way to do it.  Encouraging existing
implementations to make sure their policy algebras are sophisticated enough
to match on set elements so you can do discard is another.  (Multiple
implementations are policy ignorant with regard to set matching.)

Saying "I don't recognize these" is not a viable incremental implementation
strategy.

-- Jeff