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

[Susan Hares <[e-mail]>]

 Randy and Bruno:

Thanks for the hard work.  This document has past WG LC.

 However, I'd like to finalize these last last nits quickly so I can 
send it to the IESG this week.


Sue



On Tuesday 12/03/2019 at 10:00 am, [e-mail] wrote:
> Randy,
>
> Thank you for the update.
> -29 looks go to me but I still have the following comments:
>
> §4
>
> "treat as withdraw' (see [RFC7606]) a BGP attribue/NLRI pair which is 
> too large to be sent to a peer which does not support BGP Extended 
> Messages.
>
> It's not clear to me whether the specification means sending the 
> withdraw on all BGP sessions or only on the BGP sessions which do not 
> support BGP Extended Message.
> I can live with both choices but have a preference for the latter. I'd 
> like the behavior be clarified in the specification.
> In my understanding:
> - For this draft, sending the withdraw only on the sessions not 
> supporting BGP Extended Message would be enough, and would avoid 
> disruption if someone enable a new BGP session not supporting BGP 
> Extended Message
> - RFC7606 is dealing with BGP update being received, hence does a 
> withdrawn on all BGP sessions (including in the Loc-RIB of the 
> speaker)
>
> Hence there is a possible mismatch that people could try to interpret 
> resulting in different behaviors.
>
> -----
> §6
> OLD:
> For all messages except the OPEN
>      message, if the receiver has advertised the capability to receive
>      Extended Messages, this document raises that limit to 65535.
>
> NEW:
> For all messages except the OPEN
>      message, if the receiver has sent and advertised the BGP Extended 
> Message Capability, this document raises that limit to 65535.
The wording "sent and advertised" is redundant.  I've provided an 
alternative
/replacement:/

   For all messages
     except the OPEN message, if the receiver has advertised the 
receiver has
  advertised the BGP Extended Messages Capability, this
     document raises that limit to 65535.
/
>
> ---
> §3
> OLD: A BGP speaker
>      MAY send Extended Messages to its peer only if it has fully 
> exchanged
>      the Extended Message Capability with that peer.
>
>
> I think me mean
> NEW: A BGP speaker MUST NOT send Extended Messages to its peer if it 
> has not fully exchanged
>      the Extended Message Capability with that peer.
Bruno:  Your sentence uses a "double negative" (aka Must not if ...  
it has not fully exchanged).
The double negatives cause implementation issues. You may suggest 
another phrase, but
I feel Randy's phrase provides a clear path.
>
> ---
> 1 feedback FYI,
> In §5, you have changed
> from OLD:
> 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.
>
> to NEW:
> A speaker
>      SHOULD NOT implement a more liberal policy accepting BGP Extended
>      Messages.
>
> But section 8 still says:
>      "Section 5 allowed a receiver to accept an Extended Message even
>      though it had not advertised the capability.  This slippery slope
>      could lead to sloppy implementations sending Extended Messages 
> when
>      the receiver is not prepared to deal with them, e.g. to peer 
> groups.
>      At best, this will result in errors; at worst, buffer overflows."
>
> Strictly speaking, this is still correct, but significantly changing 
> §5 without changing §8 might also be an oversight.
Bruno - I found the combination to be correct (as well), and the best 
compromise
in the proposals.  If you are OK with the text, I will send this off 
to
Alvaro's review.   He will read this email message and may think of an 
alternative.
>
>
> Typo
> :s/BGP attribue/BGP attribute
>
> Thank you,
> --Bruno
>
> -----Original Message-----
> From: Randy Bush [mailto:[e-mail]]
> Sent: Sunday, March 10, 2019 10:17 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: Susan Hares; Interminable Discussion Room
> Subject: Re: [Idr] WG Last Call on Extened Message Support
>
> 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.
>
> randy
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
>