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

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

Bruno: 

 

I’d like to answer some of the questions you sent Randy based on comments
(public and private) the chairs and I as the shepherd received on this draft
in our last WG LCs.   

 

Several of the comments you questioned were put in to answer other
questions.   This gets into a catch-22… problem – where you put changes in
for one person/take out the changes out for another.  In academic circles
this is called the reviewer #2 problem (reviewer 1 insists changes go in,
reviewer 2 insists changes go out) during publication.  Therefore, I’m I am
going to answer most of your questions where this is the case.  

 

I believe that Randy has new version with the changes I’ve indicated.  I’m
hoping he’ll just post that version.  AFAILK, we do have 2 compliant
implementations. 

 

Sue 

 

 

<shepherd hat on> 

This draft’s technology provides efficient processing for some application
by allow a huge BGP message size.  Whether “chunking” BGP to 4096 byte
messages or packing large amounts of data into 65,000 byte message is more
effective for a particular application is something only an implementer of a
particular BGP implementation  can decide.   This draft simply gives freedom
for applications to not be restrict to an artificially small message size.
The market place will choose whether this technology is used or not.   

 

As Jakob pointed out, changing a highly tuned BGP implementation which
“chunks” BGP data into 4096 byte messages may involve substantial rework of
the implementation.  

 

 

(snip) 

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-
<https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-%3eimplemen
tations> >implementations 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.

 

>In our mail thread, we discovered that the implementation report should
have indicate

>full support.   I’m waiting for Olivier to update based on the last point,
but my understanding is that 

All implementations have full support.  

 

>----

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

 

SIDR gave up waiting on IDR’s work and took a reduced size of encryption.
The security people were very sad about the reduction.  How is this working
in practice? WG sidrops can answer this question.  

 

The real problem is there is finite message space.  

 

There are two ways to send lots of BGP routes and/or attributes – to “chunk”
these into small message sizes or place these into a large message.    Some
applications may always want to “chunk” into message sizes smaller than
4096.   Some application make work more efficiently utilizing large message
size.  As the potential number of NLRI and BGP attributes grows, new
applications may consider large message sizes to a more reasonable way to
exchange amounts of BGP data.    

 

The decision on how to send BGP messages over the wire is a peer-by-peer
decision in a network.   Each BGP peer is in charge of reformatting the BGP
message it sends to the remote BGP peer.   The BGP capabilities in this
draft represent an agreement between two BGP peers.  These are facts of
basic BGP implementations – so I do not believe adding these facts to
Randy’s draft is useful.  In fact, in the previous rounds of review this
point was made. 

 

Your question (and perhaps Jakob’s) is whether we have reached a time/place
where the “chunking” approach will fail on a peer-by-peer basis?   This
draft does not make this statement.  

 

The point of this draft is to enable more efficient processing by increasing
the message size for BGP peers that send a lot of data (e.g. BGP-LS) .   The
choice to “chunk” or stream in large BGP message is an implementation choice
for a particular BGP application.  

 

----

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

 

[I believe randy accepted this change with the following text in version 4
[upcoming below]]/. 

 

--------------

 

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

 

Bruno – people asked to put this text in as an operational warning.  At this
point, I’m going to say unless there is harm it should remain.  

 

----

>   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 cannot be decomposed to 4096 octets”

 

An attribute which cannot be decomposed to 4096 is an attribute with length
6000 inside of a BGP message which requires the entire attribute to be
included.   No such attribute exists today.   If a small BGP peers create a
“killer application” that uses a 6000 byte attribute, the rest of the
Internet does not have to use it.   However, the person defining that
attribute must carefully specify it must go with Extended BGP messages. 

 

This text was added during an earlier discussion where the error cases of a
large BGP attribute was given.  The originator of the common could not
provide the exact description, but we agreed to put this  “warning label”
into the draft.   This is one of the cases where adding/removing text gets
to be problematic. 

 

>---

>“   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?

 

This warning was text that other participants asked to be added. 

 

It is a common sense warning.  Extended messages are enabled on a peer by
peer basis as all BGP capabilities are.  If you run into a Peer that does
not support the larger sizes, the BGP messages will need to be reformatted
to the smaller size.   Running immediately to the Extended messages as the
default could cause problems. 

 

---

  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.

 

I fail to see your logic.  At this point, all BGP data (AFI/SAFI and
attributes) must fit within a 4096 message.   Therefore, a BGP peer A which
connects on link 1 to BGP peer B with 4096 message and on link to a BGP peer
C with extended messages only has to worry about reformatting the data.  

 

In the future, the first group that defines attribute or an NLRI that does
not fit within a 4096 BGP message and cannot be split, will need to define
how that works in the specification.  There is no need to refine the current
set of specifications.   

 

>----

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

 

At this point, there are no attributes or NLRI groupings that do not fit
within 4096.   If you define one (as SIDR did), then you will need to have
it reviewed by IDR, BESS, SPRING, and operational groups (GROW, etc).  

 

---

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