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

[Jeffrey Haas <[e-mail]>]

[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