Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

[Robert Raszuk <[e-mail]>]

Hi Jeff,

> We *MUST* be normative about the treat as withdraw behavior.

This does provide one way to address my main point that the draft MUST be
updated to define what to do when you get to a bottleneck. Otherwise each
implementation will try to do their own thing which will be a disaster.

However your suggestion creates troubleshooting nightmare. How does a
sender is to know that some routers 3 ASes away did not get his prefix ?
How does the receiver is to know that because he is running older device
with no software upgrade possible he will be potentially missing some
routes ?

Do we no longer care that any BGP4 proposal no matter how great and useful
it is MUST be incrementally deployable ?

Thx,
R.


On Tue, Nov 28, 2017 at 7:33 PM, Jeffrey Haas <[e-mail]> wrote:

> [I'm choosing this message as my response point, but not intending to
> suggest that other bits of the thread weren't relevant.]
>
> On Wed, Nov 22, 2017 at 11:26:32PM +0000, Jakob Heitz (jheitz) wrote:
> > If router A follows this draft, then it can quite legitimately send an
> update with 16000 communities. If router B cannot receive and process it,
> then it’s broken.
> >
> > If path attribute size is not addressed, then this draft will cause
> inoperable implementations. As such, it is not fit for standardization.
> Either we assume the maximum possible size for all attributes or specify
> shorter maximum sizes. Anything less leads to failure to interoperate.
>
> BGP has always had an issue with features that had the risk of overflowing
> the Path Attributes.  I've seen this (as likely have others supporting
> implementations) with odd combinations of AS_PATH, communities, etc.
> Extended communities and new features simply make this more likely.
>
> My take on the issue is this:
> - If you've selected a route and are attempting to send it to a neighbor
> and
>   you are unable to format a valid BGP PDU containing only a single NLRI,
>   you MUST NOT try to send it.
> - If you previously sent reachability for that NLRI, and are unable to send
>   it as above, you MUST withdraw it.  Otherwise you run the risk of
>   improper reachability or forwarding.
>
> Basically, "treat as withdraw" applies here.
>
> IMO, it's no different for extended messsages.  If I receive a > 4k message
> and I can't format it for a subsequent peer, treat as withdraw for those
> peers.
>
> Where we've had good room for discussion has been what to do in order to
> avoid these sort of things:
> - Are there circumstances where we might be able to drop an optional
>   attribute?  Maybe.  This seems messy to me.
> - Are there circumstances where we might be able to limit the size of large
>   attributes?  (E.g. communities.)  Possibly.  But this may be unsafe and
>   would be highly circumstantial.  Whose route-target do you drop from a
> VPN
>   route as an example?
> - Is there wisdom in suggesting "old world" path attributes shouldn't be
>   allowed to overflow the 4k limit?  Possibly.  Then you start getting into
>   interesting mixes of combinatorics.  For example, long AS_PATH and a long
>   community list together.  Implementations already do things like limit
>   maximum AS_PATH length.
>
> My personal opinion on the mitigations is that we shouldn't try to be
> normative about them in the spec.  As noted in the AS_PATH example, vendors
> already limit some attributes to be shorter than what the protocol might
> maximally allow.  Leave it to the implementations to provide knobs
> appropriate to those implementations.  There may be room in the spec
> suggesting that such things are possible.
>
> We *MUST* be normative about the treat as withdraw behavior.
>
> -- Jeff
>