Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

["Keyur Patel (keyupate)" <[e-mail]>]

Hi Bruno,

Many thanks for the review. Comments inlined #Keyur

From: Bruno Decraene <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 25, 2016 at 3:04 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>, Keyur Patel <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Hi,


1)      Support.


2)      Question, for my own information: why does the capability mean that the BGP speaker is capable of _both_  receiving _and sending_ extend message? (vs capable of receiving (only)). IOTW, what is the motivation to advertise the capacity to send extended message?


3)      Please find below some possible comments:


“4.  Operation”

Suppose that I receive an extended BGP message (e.g. update) that I can’t relay to some peers because they don’t support such extension, while I “should” have relayed it. Is there an expected behavior? Should it be standardized? Can this create issues (e.g. inconsistent routing with an AS)? Should this be considered in the security considerations? (e.g. I deliberately send an extended message, and benefit from its/the NLRI not being propagated as expected. e.g. to influence routing policy)


#Keyur: Clients would receive internal routes as long as a RR can announce prefixes using existing message length (of 4K). It would be using multiple messages limited to 4K length.  Alternatively, if the attribute size is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should be logged (existing case).


--

“A BGP speaker may send extended messages to its peer only if it has received the Extended Message Capability from its peer.”

May be :s/received/sent and received
---
#Keyur: A capability announcement indicates an ability to "receive and parse" extended messages. In that context “receive” is good enough?



“   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 that has not advertised the capability.”

I would a priori have assumed that both sentences be related. But in fact they are not since the first sentence only refers to the sending of the capability, while the second only refers to the reception of the capability. Shouldn’t both sentences be extended to cover both the sending and the receiving?
--
#Keyur: We wanted to be explicit in error handling section. :) Again, the capability meaning is to be able to “receive and parse”.



“A speaker that treats an improper extended message as a

   fatal error, as described in the preceding paragraph, MUST do

   likewise. »
I’m sorry but I don’t understand this sentence. What does that mean to “treat an improper extended message as a fatal error”? e.g. If I receive an extended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI)  is this considered an improper extended message with a fatal error? If so the text seems wrong as bgp speaker must not do “likewise” (seems to refer to “reset the session   with a Bad Message Length NOTIFICATION”)

Also “as described in the preceding paragraph, MUST do likewise” seems not precise enough to me (at least as a non-native English speaker). Which exactly is this preceding paragraph describing this “treats an improper extended message as a fatal error”

---

#Keyur:  The text is meant for a BGP speaker that doesn’t announce extended message capability AND doesn’t support extended messages implementation (old style peer). Such a peer would consider a receipt of an extended message as a malformed message.


7.  IANA Considerations

“The IANA is requested to register a new BGP Capability Code to be named BGP Extended Message Capability »

I’m not sure about the formulation since IANA has already registered this capability as TEMPORARY.



“TBD      BGP-Extended Message”

At least I would expect that the document ask for the _same_ value (6) rather than TBD.

#Keyur: Ack.

Regards,
Keyur




Thanks,

Regards,

Bruno


From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, May 24, 2016 10:42 PM
To: [e-mail]<mailto:[e-mail]>
Cc: 'Keyur Patel (keyupate)'; 'David Ward'
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

In your comments please provide the following information:

1)      Support/”no-support” of this draft being ready for publication,

2)      You know of an implementation for this draft, please report the implementation to the IDR Wiki

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-implementations


3)      Do you have any concerns about extending the BGP messages.

Sue Hares and John Scudder

_________________________________________________________________________________________________________________________

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.