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

["Susan Hares" <[e-mail]>]

Bruno: 

 

On: 

“BGP-LS needs extended message support” probably needs to be refined” – I
can live with. 

 

Perhaps you define the word “needs” different that I do.   If BGP=LS
requires the use of extended-messages to work, then “requires” is the word.
If extended-messages will provide better support the growing number of
BGP-LS attributes, then “need” is to better support.  

 

If you wish to pick a better word for its marketing value, then pick a word.
The important part is the reality of the packing of an increasing number of
BGP-LS NLRIs and attributes into the BGP message. 

 

Cheers, 

 

Sue 

 

 

From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, January 29, 2019 8:55 AM
To: [e-mail]; 'Susan Hares'
Cc: [e-mail]
Subject: RE: [Idr] WG Last Call on Extened Message Support

 

 

From: Adrian Farrel [mailto:[e-mail]] 

 

The solution to:

*	BGP-LS needs extended message support
*	No one has implemented BGP extended message support

…would appear to be to have implementations of BGP-LS implement BGP extended
message support.

 

+1

Also, if there are implementations of BGP-LS but no implementation of BGP
extended message, the statement “•     BGP-LS needs extended message
support” probably needs to be refined.

--Bruno

 

Then everyone would be happy.

 

Adrian

 

From: Idr <[e-mail]> On Behalf Of [e-mail]
Sent: 29 January 2019 13:33
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] WG Last Call on Extened Message Support

 

Hi WG,

 

Please find below some comments.

As of today, I don’t believe this specification is ready to be progressed to
IESG/RFC, especially for a document updating RFC 4271 (core BGP spec).

 

> The WG chairs intend to forward this draft to the IESG with the current
level of implementation.  

 


https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementati
ons says : 5a 

Does not send Extended Message capability 

Yes 

Yes 

Yes 

 

I may be misunderstanding the implementation report, but my reading of the
above is that none of the reported implementations sends the capability
hence no implementation supports draft-ietf-idr-bgp-extended-messages.. Here
this document is updating RFC 4271, so it is not a minor extension for a
niche use case. So I don’t see the arguments for not requiring the IDR’s
usual two interoperable implementations.

 

----

§ 1

“ As BGP is extended to support newer AFI/SAFIs and

   newer capabilities (e.g., [
<https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#ref-I-D
.ietf-sidr-bgpsec-protocol> I-D.ietf-sidr-bgpsec-protocol]), there is

   a need to extend the maximum message size beyond 4096 octets.  “

 

https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#section-
1

 

 

[
<https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#ref-I-D
.ietf-sidr-bgpsec-protocol> I-D.ietf-sidr-bgpsec-protocol is now RFC 8205
(thanks for updating the reference). It has removed the normative/any
reference to draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec
does not need draft-ietf-idr-bgp-extended-messages.

Can we have an update on this?

Can the introduction of draft-ietf-idr-bgp-extended-messages be updated to
introduce on the real reasons/needs?

 

----

§4

§3 says “A peer which does not advertise this capability MUST NOT send BGP

   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

 

Fine. Text in §4 should probably be aligned with the above .e.g.

OLD: A BGP speaker

   MAY send Extended Messages to its peer only if it has received the

   Extended Message Capability from that peer.

 

NEW:

A BGP speaker

   MAY send Extended Messages to its peer only if it has sent and received
the

   Extended Message Capability to and from that peer.

 

----

“   Applications generating information which might be encapsulated

   within BGP messages MUST limit the size of their payload to take the

   maximum message size into account.”

 

I don’t see what new behavior is been defined here. If there is none, I
would suggest to remove this sentence

 

----

   A BGP announcement will, in the normal case, propagate throughout the

   BGP speaking Internet; and there will undoubtedly be BGP speakers

   which do not have the Extended Message capability.  Therefore,

   putting an attribute which can not be decomposed to 4096 octets or

   less in an Extended Message is a likely path to routing failure.

 

 

The issue is not specific to attributes bigger than 4096 octets, but to BGP
message whose length is bigger than 4096, irrespective of the size of each
attribute.

Please elaborate on what you mean by “an attribute which can not be
decomposed to 4096 octets”

 

---

“   It is RECOMMENDED that BGP protocol developers and implementers are

   conservative in their application and use of Extended Messages.”

 

What does this mean exactly? That they don’t use this extension? That they
don’t use this extension unless XX_TO BE SPECIFIED_XX?

 

---

  Future protocol specifications will need to describe how to handle

   peers which can only accommodate 4096 octet messages.

 

Why is this limited to future specifications? A priori, using existing BGP
mechanism (AFI/SAFI, attributes, * communities) one could exceed the size of
4096 octets. How does the BGP speaker supposed to behave in this case? This
should be described in this specification. Note that this is not a case of
error handling, as every BGP speaker is behaving as specified.

----

Depending on the above specification, a section describing the operational
consequences in a network (such as the Internet, BGP Enabled ServiceS/VPN
networks) is probably needed. Possible consequences could be BGP NLRI being
removed in the middle of such network, or (extended) community (such as
Route Targets) been removed. Both having significant consequences on the
availability provided by the network.

 

---

§4

OLD: The Extended Message Capability only applies to all messages except for
the OPEN message. 

Probably

NEW: The Extended Message Capability applies to all message types except for
the OPEN message (type 1). 

----

§8

“This extension to BGP does not change BGP's underlying security issues »
Before evaluating this, I think this document should first specified how a
BGP messages bigger than 4096 octets is handled when it needs to be sent to
a received not supporting this extension.

 

Nits:

OLD : to reduce compexity

NEW : to reduce complexity

 

Thanks,

--Bruno

 

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, January 29, 2019 12:33 PM
To: [e-mail]
Subject: [Idr] WG Last Call on Extened Message Support

 

 

This begins a 2 week WG LC on Extended Message Support for BGP
(draft-ietf-idr-bgp-extended-messages-27).  You can access the draft at: 

 

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

 

The authors should indicate whether they know of any IPR.   Implementers are
encouraged to update the  implementation data at: 

 

 
<https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementat
ions>
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementati
ons

 

The draft provides a means for expanding the BGP message to 65535 octets for
all messages except OPEN messages.  BGP message space is running short for
all of the potential attributes or additions proposed by BGP-LS features.  

 

The WG chairs intend to forward this draft to the IESG with the current
level of implementation.  

 

As you comment on the draft, please consider if: a) the technology is
mature, b) the additional space in a BGP message would be helpful for those
deploying BGP-LS or SR, and c) if the specification is ready for
publication.  

 

Sue Hares (WG Chair, Shepherd) 

 

 

____________________________________________________________________________
_____________________________________________
 
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.
____________________________________________________________________________
_____________________________________________
 
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.