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

[<[e-mail]>]

Sue,

Thank you for your reply.
Overall, looks good to me.
More inline [Bruno3]

From: Susan Hares [mailto:[e-mail]]
Sent: Thursday, February 21, 2019 4:24 PM
To: DECRAENE Bruno TGI/OLN
Cc: [e-mail]; 'Robert Raszuk'
Subject: RE: [Idr] WG Last Call on Extened Message Support

Bruno:

Thank you for your specific suggestion.   It helps us work through the specifics of the changes to the BGP specification.  I do not see the  text in draft-ietf-idr-bgp-extended-messages-28.txt changing section 6.3 of RFC4271.   I've included my understanding of how draft-ietf-idr-bgp-extended-messages-28.txt changes RFC4271 in the detailed comments below.

Your suggestion to improve section 6.3 of RFC4271 to handle the case where a BGP speaker peers with two different messages sizes (4096, 65,535) has operational merit.   Would you mind this modification to you text:



"A BGP speaker which peers with some peers with extended message capability and other peers without extended message capability, MUST do both of the following things:

-          The BGP speaker MUST support [RFC7606], and

-          The BGP speaker MUST handle a BGP Route (attribute, NLRI pair) that is too large to be sent to a BGP peer without the extended message capability using the "treat-as-withdraw" approach defined in [RFC7606].


The BGP speaker, MAY remove some BGP attributes which are eligible to use the Attribute discard approach [RFC7606]. "
[Bruno3] Looks good to me. Thanks.
One detail: IMHO, the text could be understood in two different ways:

-          a) Withdraw the NLRI on the sessions without the extended message capability

-          b) Withdraw the NLRI on all sessions

IMHO we want "a" (although I can live with "b"). In all cases I'd prefer that the specification clear this ambiguity. E.g. :s/ using the "treat-as-withdraw" approach defined in [RFC7606]/ using, for this BGP peer, the "treat-as-withdraw" approach defined in [RFC7606].

This would be added to section 5 of draft-idr-bgp-extended-messages-25.txt.   See my suggested RFC4271 text changes for a logical placement within RFC4271.
[Bruno3] Looks good.

If this change to your text is agreeable, then section 8 would need to change to:

/New text for the end of section 8/

This draft requires support for RFC7606 update error handling and as such inherits the security considerations of RFC7606. This draft also recommends BGP peers avoid such issues by using Authenticated Encryption with additional Data (AEAD) ciphers [RFC5116] and thus to discard messages that do not verify.  It also recommends that IBGP peers all support extended message capability and [RFC7606].

During the transition to deploy extended messages and RFC7606 on an IBGP cloud, operators should monitor any routes dropped as "treat as withdraw".

One example of a RFC7606 attack profile using the extended message is if the remote attacker is able that to craft a large BGP route to send along a BGP path in which at least one peer does not support extended messages. This peer which does not support extended message capability may encounter a drain on internal resources (processing, message sizes) if it continually reformats the large messages.  If the "treat as withdraw" feature of RFC7606 is utilized, some routes may be consistently withdrawn at this point causing inconsistent routing.

BGP routes are filtered by policies set by the operators.  Implementations may provide policies to filter routes that would cause the "treat as withdraw" from being pass by an extended message speaker.
[Bruno3] + "Network operators may enable such policies on EBGP sessions"
(as enabling this on IBGP session does not provide improvement compared to the default "treat as withdraw".)
And I would rather move that sentence at the end of the first paragraph. As this solution is only useful when the recommended approach is not used (deploy first on all IBGP sessions, then you can use large message within the AS and/or enable extended message capability over EBGP sessions"

/

Please let me know I understand your suggested changes.
[Bruno3] Looks good. Thanks

Sue Hares

From: Idr [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, February 15, 2019 5:25 AM
To: Susan Hares
Cc: [e-mail]; Robert Raszuk
Subject: Re: [Idr] WG Last Call on Extened Message Support

Susan,

We now agree that the problem can happen with existing BGP attributes. Good. So the argument to postpone the error handling discussion for future specification defining large attributes does not hold anymore.

Coming back to the draft,

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


1)      As a minor comment, the error is not limited to an (one single) attribute (type) which size is bigger than 4096 octets. The error happens when the Total Path Attribute Length (for all attributes) is bigger than 4096 octets.

[Sue]: My understanding of the Extended message draft is that it is not dealing with section 6.3 of RFC4271.
[Bruno3] I agree. Section 6.3 of RFC4271 handles error when receiving a BGP update message. While BGP Extended Message create error when sending a BGP update message.
My comment was not related to section 6.3 or RFC 4271, but to the text of draft-ietf-idr-bgp-extended-messages which I have cited above. I don't see what could be unclear in my comment.

 Here's my understanding of the

RFC4271 states:

"All Errors detected while processing the Message header must be indicated by sending a NOTIFICATION message with the Message Header error.  The Error subcode elaborates on the specific nature of the error. "

One of the errors is a message header length:  "If the length field of the message header is less than 19 or greater than 4096."  If any of these super large attributes causes the message length to be greater than 4096, then with RFC4271, the error code sent would be "Bad Message length."

If the message length is switch from 4096 to 65535 octets, the RFC4271 error handling would allow the message length to be 65,535.


After the section 6.1 text RFC4271 is changed to the following:
[Bruno3] Idem, section 6.1 of RFC4271 handles error when _receiving_ a BGP update message. While draft-ietf-idr-bgp-extended-messages generate an error condition when sending a BGP update.

    If at least one of the following is true:

-          If the Length field of the message header is less than 19 or greater than 4096

for OPEN message,


-          If BGP Extended Messages capability is not set, the length field of any other BGP message other than an OPEN message is less than 19 or greater than 4095,


-          If the BGP Extended Message capability is set for a BGP peer, if the length field is less than 19 or greater than 65,535.  (See the error handling below for the setting of this function.)



-          If the length field of an UPDATE message is less than the minimum field of the UPDATE message, or



-          If the length field of a KEEPALIVE message is not equal to 19, or



-          If the length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message.



Then the Error Subcode MUST Be set to Bad Message Length.  The Data field MUST contain the erroneous length field.
[
     6.9) Extended Message Capability

   To advertise the BGP Extended Message Capability to a peer, a BGP
   speaker uses BGP Capabilities Advertisement [RFC5492<https://tools.ietf.org/html/rfc5492>].  By
   advertising the BGP Extended Message Capability to a peer, a BGP
   speaker conveys that it is able to send, receive, and properly handle
   BGP Extended Messages.

   A peer which does not advertise this capability MUST NOT send BGP
   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.

   The BGP Extended Message Capability is a new BGP Capability [RFC5492<https://tools.ietf.org/html/rfc5492>]
   defined with Capability code 6 and Capability length 0.

    6.9.1) Operation:


      A BGP speaker that is capable of sending and receiving BGP Extended
   Messages SHOULD advertise the BGP Extended Message Capability to the
   peer using BGP Capabilities Advertisement [RFC5492<https://tools.ietf.org/html/rfc5492>].  A BGP speaker
   MAY send Extended Messages to its peer only if it has sent and
   received the Extended Message Capability from that peer.

   The Extended Message Capability applies to all messages except for
   the OPEN message.  This exception is made to reduce complexity of
   providing backward compatibility


     An implementation that advertises support for BGP Extended Messages
   MUST be capable of receiving a message with a length up to and
   including 65535 octets.

   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.

   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 section 6.3).


   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 cannot be decomposed to 4096 octets or
   less in an Extended Message is a likely path to routing failure.

[Bruno3] the error is not limited to an (one single) attribute (type) which size is bigger than 4096 octets. The error happens when the Total Path Attribute Length (for all attributes) is bigger than 4096 octets

   It is RECOMMENDED that BGP protocol developers and implementers are
   conservative in their application and use of Extended Messages.

   6.9.2 Error Handling for the Extended messages


     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.
[Bruno3] The texts highlighted in blue are contradicting. I would suggest removing the blue text from §4 which the behavior is related to error handling conditions described in section 5. (note that your coded text have changed the section numbers. I'm referring to the section numbers in the draft)

   A BGP speaker that does not advertise the BGP Extended Messages
   capability might also genuinely not support Extended Messages.  Such
   a speaker MUST follow the error handling procedures of section 6.1
   regarding message length.
[Bruno3] Agreed, but that text is not very logical: you can't define a new behavior for an old speaker. At minimum, I would propose the following change:
OLD: Such
   a speaker MUST follow the error handling procedures of section 6.1
   regarding message length.

NEW: Such
   a speaker will follow the error handling procedures of [RFC4271] section 6.1
   regarding message length.



   The inconsistency between the local and remote BGP speakers MUST be
   flagged to the network operator through standard operational
   interfaces.  The information should include the NLRI and as much
   relevant information as reasonably possible.

[End of text change from draft ]


===============


2)      As a major comment, I am asking for the specification to specify how it handles that failure, which is not the result of a possible bug, but created by design by the solution. It will happen.


Your proposition to "raise an alarm" is required but not sufficient as we still need to specify what we do with this "big" route. One option could be "treat as withdraw", another option suggested by Robert is to propagate the NLRI with subset of attributes plus an indication of the failure ("a short attribute BGP_PIPE_TOO_THIN"). There may be others options.



[Sue]: Robert's option is a fine idea, but the WG did not accept this option in the past so I cannot force this option into the specification.  I hope that Robert will propose this option again.

[Bruno3] Agreed. I'm perfectly with "treat-as-withdraw"



To trigger the discussion on the resolution, I would propose the following text "One BGP Route too large to be propagated to a BGP receiver not supporting BGP Extended Message MUST be handled, over this BGP session, using the Treat-as-withdraw approach as defined in [RFC7606]. The BGP speaker MAY, beforehand, remove some BGP attributes which are eligible to the Attribute discard approach [RFC7606]."



[Sue]:  This text deals with section 6.3 in RFC4271, and to my understanding draft-ietf-idr-bgp-extended-messges-28.txt only deals with section 6.1 of RFC4271.

[Bruno3] I disagree that the text deals with sections 6.3 or 6.1 of RFC 4271. Those sections refers to error handling or _received_ BGP update, while draft-ietf-idr-bgp-extended-messages create error when _sending_ a BGP update.

    In addition, there is no concept of propagation RFC7606 or RFC4271.  Each BGP peer receives BGP messages and updates, it then propagates or sends routes and attributes to its peers.    Could I restate your suggestion as:



6.9.2 Error handling

(added at the end of the current text



A BGP speaker which peers with some peers with extended message capability and other peers without extended message capability, MUST handle a BGP Route (attribute, NLRI pair) that is too large to be sent to a BGP peer without the extended message capability using the "treat-as-withdraw" approach defined in [RFC7606].  The BGP speaker, MAY remove some BGP attributes which are eligible to use the Attribute discard approach [RFC7606].

[Bruno3] point discussed at the top of you email.





3)      Once error handling is specified, the draft will be able to discuss

a.       the operational considerations for this issue (e.g. The one from RFC7606 could be referenced as-is, or used as inspiration)

b.      the security considerations (as a remote attacker would be able to craft a large BGP route that will be withdrawn (assuming "treat-as-withdraw") somewhere in some AS, possibly creating routing inconsistencies within the AS)

c.       the proposed mitigations (e.g., an operator should enable support for Extended messages on all IBGP sessions first, before enabling it on an EBGP session; If not possible, an operator could define a policy to filter BGP attributes from EBGP sessions, typically based on their type and size;....)

more inline [Bruno2]


From: Susan Hares [mailto:[e-mail]]
Sent: Thursday, February 14, 2019 6:20 PM
To: DECRAENE Bruno TGI/OLN
Cc: [e-mail]; 'Jakob Heitz (jheitz)'; 'John Scudder'; 'Alvaro Retana'
Subject: RE: [Idr] WG Last Call on Extened Message Support

Bruno:

Thank you for careful considerations on the use case.   I think we have translation issues between our "English" language again so I have tried to be precise in the detailed comments.  I've summarized my comments as well to help us take the next step.

Sue

Summary
----
Good catch on the 1000 large BGP communities blowing up the message size!  This is a case where a code path could get caught with program error.  The error handling (section 6.1 in RFC4271 per section 5 in the extended specification) IMHO handles the case where the attribute is longer than the message.   Please let me know if I've missed something.

[Bruno2] I don't think that section 6.1 of RFC4271 covers this. The problem is not a Message Header error handling as a proper BGP implementation would not sent the message. (not to mention with inconsistent size).
[Sue2]: OK, but section 6.1 is the only places that this draft changes.
[Bruno3] points discussed above

As I understand it,  you are asking this specification to be expanded to add notes on policies on what implementation should do to correctly combine RFC4271 length sizes with extended length sizes.   The implementers and operations people commented earlier that this should not be in the protocol specification other than as a brief footnote.

[Bruno2]An error handling must exist even in the absence of SP policies. The argument related to previous discussions does not hold IMHO as I've raised a new point (this happens with existing BGP attributes, not in a hypothetical new attribute)
[Sue2]:  Thank you for sending your text.  I can your comments are on the UPDATE handling processes based on RFC7606.  We were discussing 2 different places in RFC4271.

I agree there is a need for such standardization as BCPs for particular use cases (large communities, BESS (EVPN or centralized controller), SPRING, BGP-LS information (see Daylight comments yesterday), SD-WANs (rtgwg), and SPRING.   I think the chairs of the WGs utilizing should consider if there is need for standardization for a minimal set of policy for message sizes for specific use cases.   I will be glad to send request to these WG or to host something in IDR if there is policy that can be used across all use cases.

[Bruno2] I don't think that Error handling is to be considered as optional or for future consideration.
[Sue2]:  Based on your proposed text, I can see the value of considering this text at this time.
[Bruno3] Thanks for considering the error handling for new error conditions introduced by draft-ietf-idr-bgp-extended-messages-
--Bruno

To provide a slight expansion to point people in this direction, how about this change to paragraph in section 4:

Old/
   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.
/
New/
   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 cannot be decomposed to 4096 octets or
   less in an Extended Message is a likely path to routing failure.
   One example of a valid attribute which cannot be precisely decomposed if it
   sent in Extended message is a large community attribute with 1000 communities.
   (12,000 bytes).
/
[PS - in American English "Can not" is normally concatenated "cannot".]

[Bruno2] Thanks for the proposition, but this does not address my concern.
[Sue]: Thank you for your text - I understand why now.

From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, February 14, 2019 3:29 AM
To: Susan Hares
Cc: [e-mail]; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

Sue,

Thanks for the reply. Please see inline [Bruno]

From: Susan Hares [mailto:[e-mail]]
Sent: Wednesday, February 13, 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: [e-mail]; 'Jakob Heitz (jheitz)'
Subject: RE: [Idr] WG Last Call on Extened Message Support

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 bruno.decraene@orange..com
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->implementations<https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-%3eimplementations> 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.

[Bruno] ok, solved
>----
>§ 1
>" As BGP is extended to support newer AFI/SAFIs and
>   newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol<https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#ref-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


>[I-D.ietf-sidr-bgpsec-protocol<https://tools.ietf..org/html/draft-ietf-idr-bgp-extended-messages-27#ref-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.
[Bruno] So too bad the draft does not solve the real problem ;-) (as message space is still limited)

[Sue]: The message is still finite (smile),  but I hope 65,635 (smile) is probably enough for 10 years.

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
[Bruno] Let's take the example of a BGP Route Reflector having a mixed of clients, some supporting Extend Message (EM) and some not.
>From an EM client, it receives a BGP update containing one (single) NLRI with an Total Path Attribute Length bigger than  4090 byte (e.g. having 1000 large communitiess)
Can you explain me how it behaves to send this NLRI to an IBGP peer not supporting EM?
[Sue]:  Gladly...
A BGP route reflector (RR-A) is peering with each of its BGP clients.   It agrees with each of its clients (BGP-C1, BGPC2, BGPC3) whether the BGP Extended messages is accepted or not (based on capability announcement).
Let us assume that BGP-C1 does not support extended messages, and  BGP-C2 and BGP-C3 do support extended messages.

If the policy in RR accepts a total path length of 1000 large communities with  a single NLRI, it may send the BGP attribute via extended communities to BGP-C2 and BGP-C2.
The policy in the RR must specify whether:

a)      the "too long" attribute path length must be dropped, or

b)      the BGP attribute path can be truncated.

This is a policy issue within the BGP peer and the network operation staff.  Each operator may choose to write this policy differently.
[Bruno2] So we agree that a new behavior is REQUIRED. The draft does not mention this. The ability to change the behavior by policy does not remove the need for specifying the error handling.

Rather than specify the numerous cases in the protocol specification,  the previous discussions (private and public) asked us to trim this information out of the protocol specification.
[Bruno2] Can't be have a general rule which is good enough to handle the issue? Previous discussions seemed based on the fact the error condition would happen for future attribute. This is not the case.

If you believe this is worthy of a use case draft for the sake of BESS, LSVR, SPRING, Grow and others, I will happily WG chair sponsor a draft that can be reviewed by all these WGs.
[Bruno2] I believe that this is worthy in this specification.


- 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.
[Bruno] OK.

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


[Bruno] I don't think that I agree with this. E.g. I don't see where RFCs 1997 or 8092 [(large)community] limits the size of their attribute. Hence I don't see why you could not have, today (with Extended Message support) , attributes larger than 4096 octets. Most probably same status for the BGPSec attribute since they wanted for more space.
[Sue]: You make a good point about the possibility of large communities not limiting the size.  It is worthy of a change to both the large communities and a footnote in Randy's specification.  How about the addition of a single sentence to point people in the right direction.

Old/
   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.
/
New/
   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 cannot be decomposed to 4096 octets or
   less in an Extended Message is a likely path to routing failure.
   One example of a valid attribute which cannot be precisely decomposed if it
   sent in Extended message is a large community attribute with 1000 communities.
   (12,000 bytes).
/



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.

[Bruno] I think that the sentence could be elaborated. Indicating the problem, how the specification partially address it, and how the specification does not address it.
In "Running immediately to Extended Message" I don't think they that the issue is with "immediately". Whenever you start the transition, your likely to run into problems.


[Sue]: IMHO specification specifies how to encode the bytes on the wire and the appropriate error handling of the messages.   If I have missed something in this case, please let me know.
[Bruno2] IMHO specifications need to handle error conditions that they create by design.

The specification does not specify the necessary policies implementation should have in order to decide what to do in the case of mixed network.   The clear indication was this type was not appropriate for the protocol specification.

Earlier discussion indicated that these is policy and mechanism specific.  It is worthy of "use case or application notes" written for specific applications (BESS, SPRING, GROW), but not in the specification.  Again, if it is significant enough concern for operators and implementers - it would be worthy to have combined use case document besides this point.    I'm happy to sponsor cross-area work on this use case.

---
  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.
[Bruno]
1) cf above, I believe that there are existing BGP Attributes which may not fit into a bytes 4096 BGP message
2)Even in the absence of such attribute, you have the issue of 2 smaller attributes whose cumulative size does not fit into a 4096 bytes message.

The problem is introduced by this specification, hence I believe this specification needs to specify how to handle this case.

[Sue]:  IHMO the message transmission and reception error handling issues are complete in the combination of RFC4271 and the extended message section 5.

What is not in this specification is the policy issues about what happens if you combine 2 smaller attributes.  For example, if you have a large community attribute of 400 communities (4800 bytes), you will likely run into problems when combining with some longer AS path lengths.  [4800--> 5096 bytes is a short jump]. People on the list and in-person argued this was policy and implementation specific details.
[Bruno2] It's not implementation specific. This is an issue created by the specification. Let's discuss it in public.

I agree with you that it is extremely useful to the operator community to have this type of policy details discussed to see if there is some desire to have common policies and error communities.   It is the type of thing that GROW and IDR should be deeply involved for large communities.   BESS, LSVR, SPRING and others should consider what policy should be adapted for their applications.

>----
>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).
[Bruno] no, cf above.
[Sue]:  Thank you for reminding me of the potential of large communities to blow up BGP.  I have a new worry to add to my BGP concerns list!
[Bruno2] IMHO, the problem is more with Extended Message than with large community. And we can work to consider and address this problem.
--Bruno

Thanks,
--Bruno


---
>§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]<mailto:[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-implementations

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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.