Re: [Idr] WG Last Call on Extened Message Support

[Claudio Jeker <[e-mail]>]

On Sun, Mar 10, 2019 at 02:17:13PM -0700, Randy Bush wrote:
> i found your and susan's extended messages rather hard to follow and
> therefore hard to apply to the once simple draft.  i have done what i
> could.  simple comments, without quoting so much that it is impossible
> to decode, appreciated.
> 

I appreciate the new paragraph since it seems to be very clear:

   If a BGP update with a payload longer than 4096 octets is received by
   a BGP listener who has neither advertised nor agreed to accept BGP
   Extended Messages, the listener MUST treat this as a malformed update
   message, and MUST raise an UPDATE Message Error (see [RFC4271] Sec
   6.3).

but it seems to be contradicting section 5. Error Handling a bit:

   A BGP speaker that has the ability to use Extended Messages but has
   not advertised the BGP Extended Messages capability, presumably due
   to configuration, SHOULD NOT accept an Extended Message.  A speaker
   MAY implement a more liberal policy and accept Extended Messages,
   even from a peer to which it has not advertised the capability, in
   the interest of preserving the BGP session if at all possible.

As somebody who would be implementing this I'm rather confused and in my
opinion the interpretation of these paragraphs is to open.
I would prefer if it is clear that only if both BGP speakers advertised
and agreed on extended messages they will accept them. Any other
combination should result in RFC4271 behaviour and a payload longer than
4096 octets will be treated as an error. Adding more optional behaviours
increases (testing) complexity and honestly I would prefer to keep this
as simple as possible.

I was hoping that draft 28 would also include something along the lines of
Susan's proposal to be explicit about how to handle over sized messages
(treat as withdraw or attribute discard as per RFC7606). For me this is a
requirement to be able to implement this into OpenBGPD since without this
defined the error handling is unclear.

-- 
:wq Claudio