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

From: Randy Bush <[email-masked]>
Date: Sun, 10 Mar 2019 14:17:13 -0700

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 11 Mar 2019 09:18:42 -0400

Randy:

Thank you for your hard work on this draft.   I will review what you updated
and discuss this with Bruno in person at IETF. 

Sue 

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Sunday, March 10, 2019 5:17 PM
To: Bruno Decraene
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

---

From: Claudio Jeker <[email-masked]>
Date: Tue, 12 Mar 2019 14:26:12 +0100

> could.  simple comments, without quoting so much that it is impossible

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

---

From: <[email-masked]>
Date: Tue, 12 Mar 2019 14:00:00 +0000

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.
---
§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.
---
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.   

Typo
:s/BGP attribue/BGP attribute

Thank you,
--Bruno

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
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

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.

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 13 Mar 2019 09:40:38 +0100

> 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