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

[Claudio Jeker <[e-mail]>]

On Tue, Mar 12, 2019 at 02:26:12PM +0100, Claudio Jeker wrote:
> 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.
> 

Ha, there is draft 29 which I missed and there it seems all this issues
are addressed. Thanks :)

-- 
:wq Claudio