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

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Feb 2019 10:02:52 -0500

JIe, Bruno and Oliver: 

Thank you for your input.   You are correct that the error handling behavior was unclear based on the questions in the chart.   The purpose of the chart is to provide other BGP WGs (Bess, SPRING, LSVR) a clear indication of changes to the base BGP specification. 

I’ve reformatted sections 4 and 5 of the chart.  

To section 4 I’ve added: 

4c            Does send Extended Message  - with a yes from all implementations (based on their email) 

Section 5, I’ve alter to be: 

5              Error handing                     

5a           Accepts Extended message without receiving 

             BGP Extended Message Capability [Section 5 paragraph 1 MAY]

5b           If receives Extended Message without BGP extended message support,

             follows RFC4271 handling and sends Bad message length Notification 

            [section 5 paragraph 2 MUST] 

Oliver – if you would read the current text and let me know the updated message.  I believe the answer for all 3 implementations is “yes” due to 4b.   Please let me know and I will update the information in the chart. 

To follow-up on Jie’s comments, the text did not accurately represent the error handling.   Section 5, paragraph 1 has a “SHOULD NOT” modified by a “MAY”, which results in simply a “MAY”.   For readability, I think the “SHOULD NOT” provides useful information  to the implementer,  but it cannot be tested accurately when combined with the “MAY”.    

Let me give you an example of that:

If the peer did not send a BGP Extended Message capability, and it accepts the extended message (with a length of 10,000 bytes), it could have a liberal policy of MAY as a default in the implementation.   The “on-wire” observations cannot tell – only the implementation’s policy (default + configured).    

I also broke out the management information away from the specification information.  

Sue Hares  

From: Dongjie (Jimmy) [mailto:[email-masked]] 
Sent: Wednesday, January 30, 2019 8:53 PM
To: Borchert, Oliver (Fed); Susan Hares; [email-masked]; Borchert, Oliver (Fed)
Cc: [email-masked]
Subject: RE: [Idr] WG Last Call on Extened Message Support

Hi Oliver, Bruno and Sue,

To my understanding, bullet 5/5a/5b in the implementation report is corresponding to the second paragraph in section 5 “Error Handling”:

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 [RFC4271] if

   it receives an Extended Message.  Similarly, any speaker that treats

   an improper Extended Message as a fatal error, MUST treat it

   similarly.

Thus it is to describe the error handling behavior of an implementation version which does not support extended message. 

While I agree this could be misleading for a report of implementation which supports extended message capability, maybe it could be used to verify the behavior of an old version which does not support this capability?

Best regards,

Jie

From: Idr [mailto:[email-masked]] On Behalf Of Borchert, Oliver (Fed)
Sent: Wednesday, January 30, 2019 4:35 AM
To: Susan Hares <[email-masked]>; [email-masked]; Borchert, Oliver (Fed) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

Bruno and Susan,

I cannot speak for the ExaBGP Implementation but for BGPSEC-IO and QuaggaSRx.

I believe when I compiled the report, I mis-read 5a and overlooked the “not” and read instead: “Does send Extended Message Capability”.

Therefore the implementation report for section 5a must be corrected from “Yes” into “No” for both BGPSEC-IO and QuaggaSRx

BGPSEC-IO and QuaggaSRx, both do send the extended message capability if so configured.

I just checked the code and run it again. I copy/pasted the relevant output generated by BGPSEC-IO,

Oliver

-----  output of BGPSEC-IO  -------

./bgpsecio -f bgpsecio.test.cfg.qsrx 

Starting bgpsecio 0.2.0.25...

Send:  (Open message send from BGPSEC-IO to QuaggaSRx) 

OPEN Message

  +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

…

     +--Optional Parameter: Capability

     |  +--Type: Capability (2)

     |  +--Length: 2

     |  +--Capability: Extended message support capability

     |     +--Type: Extended message support capability (6)

     |     +--Length: 0

…

Received: (Open message send from QuaggaSRx and received by BGPSEC-IO)

OPEN Message

  +--marker: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

…

     +--Optional Parameter: Capability

        +--Type: Capability (2)

        +--Length: 2

        +--Capability: Extended message support capability

           +--Type: Extended message support capability (6)

           +--Length: 0

BGP-receiver thread created!

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Tuesday, January 29, 2019 at 11:43 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Bruno:

Thank you for your comments on this topic – as I think 

I did receive reports privately that we have 1 full implementations of draft-ietf-idr-bgp-extended-messages off list which is not listed in this report.   I hope those implementers will volunteer this information on the list.   If not, I will share this information with Alvaro and the IESG.   

The SIDR work did define draft-ietf-bgp-extended-messages as a requirement and only moved to not specifying it when we could not quickly pass this through WG LC. 

The real needs are a growing BGP-LS that may run out of BGP message space.  As my previous email to IDR indicates, I was hoping this handles an BGP message whose length is bigger than 4096 bytes.   Thank you for the correction of: 

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

As to your comment: 

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

This problem has been true for years, and thus as co-chairs had hoped to have the draft-ietf-bgp-extended-messages passed years ago.   As BGP-LS attributes grow use and in number, the potential of exceeding the BGP message limit increases.  It seems like a good direction to prevent issues. 

I hope the authors will comment on the changes you suggested to the text. 

Cheers, 

Susan Hares 

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2019 8:33 AM
To: Susan Hares
Cc: [email-masked]
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=hXBbOXqwvXqtCV%2B9PbP%2F7IE6WJjWUA2boM33Kds%2Bgh4%3D&reserved=0>  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%3D&reserved=0> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23section-1&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=YVWHAFbYRjG%2FlWPbpw2rW8uGQ6QXss3dufm%2FqHgRvDw%3D&reserved=0> 

[ <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%3D&reserved=0> 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:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, January 29, 2019 12:33 PM
To: [email-masked]
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-bgp-extended-messages%2F&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=okjTeLe6DcTaRV2USy2My6HXDRynupmXlB0i7gUwynA%3D&reserved=0> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=PoRyFofs04%2FC%2F%2FgbXL2zyED3SW6MrESpHiIE2e7p4cA%3D&reserved=0> 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.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 2 Feb 2019 06:45:07 +0000

Hi Sue,

Thanks for updating the implementation report.

My understanding was that bullet 4 was to cover the behavior of section 5 paragraph 1, bullet 5 was to cover the behavior of section 5 paragraph 2.

But after rereading section 5, I realize that both paragraph 1 and 2 are talking about the behavior of a BGP speaker which does not advertise the extended message capability to its peer, so perhaps bullets 4 and 5 in the implementation report could be merged as below:

4. When receives an extended message without advertising the BGP Extended Message Capability to this peer (Error Handling).
4a. Accepts the extended message if the BGP speaker is able to process extended message (but was configured not to advertise the capability)   [Section 5, paragraph 1 MAY]
4b. Does not accept the extended message, follows RFC4271 handling and sends Bad Message Length Notification [Section 5, paragraph 1 SHOULD NOT, and paragraph 2 MUST)

Hope this helps to reduce the confusion.

Best regards,
Jie

From: Susan Hares [mailto:[email-masked]]
Sent: Friday, February 01, 2019 11:03 PM
To: Dongjie (Jimmy) <[email-masked]>; 'Borchert, Oliver (Fed)' <oliver.borchert=[email-masked]>; [email-masked]; 'Borchert, Oliver (Fed)' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Idr] WG Last Call on Extened Message Support

JIe, Bruno and Oliver:

To section 4 I’ve added:

Sue Hares

From: Dongjie (Jimmy) [mailto:[email-masked]]
Sent: Wednesday, January 30, 2019 8:53 PM
To: Borchert, Oliver (Fed); Susan Hares; [email-masked]<mailto:[email-masked]>; Borchert, Oliver (Fed)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] WG Last Call on Extened Message Support

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of Borchert, Oliver (Fed)
Sent: Wednesday, January 30, 2019 4:35 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Borchert, Oliver (Fed) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Bruno and Susan,

Oliver

-----  output of BGPSEC-IO  -------

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 29, 2019 at 11:43 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Bruno:

As to your comment:

Cheers,
Susan Hares

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, January 29, 2019 8:33 AM
To: Susan Hares
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] WG Last Call on Extened Message Support

Hi WG,

> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=hXBbOXqwvXqtCV%2B9PbP%2F7IE6WJjWUA2boM33Kds%2Bgh4%3D&reserved=0> says : 5a

Yes

Yes

Yes

----
§ 1
“ As BGP is extended to support newer AFI/SAFIs and
   newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%3D&reserved=0>]), 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23section-1&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=YVWHAFbYRjG%2FlWPbpw2rW8uGQ6QXss3dufm%2FqHgRvDw%3D&reserved=0>

[I-D.ietf-sidr-bgpsec-protocol<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%3D&reserved=0> 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

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

---

---

----

---
§4

Nits:

Thanks,
--Bruno

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

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-bgp-extended-messages%2F&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=okjTeLe6DcTaRV2USy2My6HXDRynupmXlB0i7gUwynA%3D&reserved=0>

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=PoRyFofs04%2FC%2F%2FgbXL2zyED3SW6MrESpHiIE2e7p4cA%3D&reserved=0>

Thank you.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 4 Feb 2019 20:13:55 +0000

BGPSec dropped the requirement for extended messages because the
signature was changed from RSA-2048 (256 byte sig) to ECDSA P-256 (64 byte sig).
https://mailarchive.ietf.org/arch/msg/sidr/LRHPuO5MF0u-vWuhNAVeVN_8fIU

There is no mention of extended messages in https://tools.ietf.org/html/rfc8205
All mention of it was struck out in:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Friday, February 1, 2019 10:45 PM
To: Susan Hares <[email-masked]>; 'Borchert, Oliver (Fed)' <oliver.borchert=[email-masked]>; [email-masked]; 'Borchert, Oliver (Fed)' <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi Sue,

Best regards,
Jie

To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; 'Borchert, Oliver (Fed)' <oliver.borchert=[email-masked]<mailto:oliver.borchert=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Borchert, Oliver (Fed)' <[email-masked]<mailto:[email-masked]>>

JIe, Bruno and Oliver:

To section 4 I’ve added:

Sue Hares

Best regards,
Jie

Bruno and Susan,

Oliver

-----  output of BGPSEC-IO  -------

Bruno:

As to your comment:

Cheers,
Susan Hares

Hi WG,

Yes

Yes

Yes

----
§ 1

----
§4

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

---

---

----

---
§4

Nits:

Thanks,
--Bruno

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 11 Feb 2019 10:17:04 -0500

Jakob:

Thanks for mentioning the correct information the BGPSec as far as the specifications.  Whether or not the RSA-2048 would have been useful to BGPSec, is left for the OPS group handling SIDR deployment.  

The focus of this discussion is to remove any future obstacles to the use of BGP-LS attributes/NLRI.  Two potential limits exist:  a) message size (greater than 4096) and b) error handling. 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Monday, February 4, 2019 3:14 PM
To: Dongjie (Jimmy); Susan Hares; 'Borchert, Oliver (Fed)'; [email-masked]; 'Borchert, Oliver (Fed)'
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

Regards,

Jakob.

Hi Sue, 

Best regards,

Jie

JIe, Bruno and Oliver: 

To section 4 I’ve added: 

5              Error handing                     

Sue Hares  

   similarly.

Best regards,

Jie

Bruno and Susan,

Oliver

-----  output of BGPSEC-IO  -------

OPEN Message

…

     |  +--Length: 2

     |     +--Length: 0

…

OPEN Message

…

        +--Type: Capability (2)

        +--Length: 2

           +--Length: 0

 

Bruno:

 

As to your comment: 

Cheers, 

Susan Hares 

Hi WG,

Yes 

Yes 

Yes 

----

§ 1

 

----

§4

OLD: A BGP speaker

NEW:

A BGP speaker

----

----

 

---

---

 

----

---

§4

Probably

----

§8

Nits:

Thanks,

--Bruno

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 11 Feb 2019 11:42:39 -0500

Oliver and Randy: 

We are waiting your comments/revisions to complete the WG LC on extended messages.  We will extend the WG LC 1 more week to receive your answers. 

Oliver – Please update the wiki with the correct information. 

Randy – Please respond to the questions send on the list. 

Thank you, Susan Hares 

From: Borchert, Oliver (Fed) [mailto:[email-masked]] 
Sent: Monday, February 4, 2019 10:55 AM
To: Susan Hares
Cc: Borchert, Oliver (Fed)
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi Susan,

I know it’s not much but I want to be thorough before I post to the list. I try today but definitely will get to this in the next days. Still cleaning up from the government shutdown,

Oliver

From: Susan Hares <[email-masked]>
Date: Friday, February 1, 2019 at 10:03 AM
To: "'Dongjie (Jimmy)'" <[email-masked]>, "'Borchert, Oliver (Fed)'" <oliver.borchert=[email-masked]>, "[email-masked]" <[email-masked]>, Oliver Borchert <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Idr] WG Last Call on Extened Message Support

JIe, Bruno and Oliver: 

To section 4 I’ve added: 

5              Error handing                     

Sue Hares  

   similarly.

Best regards,

Jie

Bruno and Susan,

Oliver

-----  output of BGPSEC-IO  -------

OPEN Message

…

     |  +--Length: 2

     |     +--Length: 0

…

OPEN Message

…

        +--Type: Capability (2)

        +--Length: 2

           +--Length: 0

 

Bruno:

 

As to your comment: 

Cheers, 

Susan Hares 

Hi WG,

> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C56e8cfced0214a38426208d68856623e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636846301939659496&sdata=IQ%2F4nC5x77nMiGgTxKHTxJja4afzEFZZt9HekJZ4y%2BU%3D&reserved=0>  says : 5a 

Yes 

Yes 

Yes 

----

§ 1

   newer capabilities (e.g., [ <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C56e8cfced0214a38426208d68856623e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636846301939669501&sdata=Ev7L503zU0SMj4FH2HaZpd12EhvAbi24k82GBRnVxHc%3D&reserved=0> I-D.ietf-sidr-bgpsec-protocol]), there is

https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#section-1 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23section-1&data=02%7C01%7Coliver.borchert%40nist.gov%7C56e8cfced0214a38426208d68856623e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636846301939679510&sdata=dBjVH3l81FQgHpjJiB%2F8jQnA%2BJUVpFVJrxKM1VCwmNU%3D&reserved=0> 

[ <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-bgp-extended-messages-27%23ref-I-D.ietf-sidr-bgpsec-protocol&data=02%7C01%7Coliver.borchert%40nist.gov%7C56e8cfced0214a38426208d68856623e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636846301939679510&sdata=d%2FUb6BIDKZHSUTNouVQzy%2BmMyvF1dAQX3QsoQaPpCP8%3D&reserved=0> 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.

----

§4

OLD: A BGP speaker

NEW:

A BGP speaker

----

----

 

---

---

 

----

---

§4

Probably

----

§8

Nits:

Thanks,

--Bruno

 

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-bgp-extended-messages%2F&data=02%7C01%7Coliver.borchert%40nist.gov%7C56e8cfced0214a38426208d68856623e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636846301939689519&sdata=LbFEBRGSPlVVUaVp4khNDjU6vKkqV%2BleZ1NAY%2F7bYfw%3D&reserved=0> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7C56e8cfced0214a38426208d68856623e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636846301939699524&sdata=hfSXkF3zek9Vmkr%2FUgr8j5G7HcVLBt76GKs1ofv5Ws0%3D&reserved=0> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 11 Feb 2019 23:16:53 +0000

Sue,

Sorry if I'm a bit behind, but could you elaborate the problem with BGP-LS please. Can you give some examples of a BGP-LS NLRI and associated path attribute that will not fit 4096 bytes?

Thanks,
Jakob.

On Feb 11, 2019, at 11:18 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Jakob:

Sue Hares

To: Dongjie (Jimmy); Susan Hares; 'Borchert, Oliver (Fed)'; [email-masked]<mailto:[email-masked]>; 'Borchert, Oliver (Fed)'

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: Friday, February 1, 2019 10:45 PM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Borchert, Oliver (Fed)' <oliver.borchert=[email-masked]<mailto:oliver.borchert=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Borchert, Oliver (Fed)' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi Sue,

Best regards,
Jie

JIe, Bruno and Oliver:

To section 4 I’ve added:

Sue Hares

Best regards,
Jie

Bruno and Susan,

Oliver

-----  output of BGPSEC-IO  -------

Bruno:

As to your comment:

Cheers,
Susan Hares

Hi WG,

Yes

Yes

Yes

----
§ 1

----
§4

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

---

---

----

---
§4

Nits:

Thanks,
--Bruno

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 13 Feb 2019 14:02:49 -0500

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 <[email-masked]> On Behalf Of [email-masked]
Sent: 29 January 2019 13:33
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi WG,

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

>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 

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.  

>   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

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

[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

NEW:

A BGP speaker

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

 

----

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

----

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

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

---

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

---

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

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

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

Thanks,

--Bruno

 

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.  

 

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Feb 2019 13:36:12 -0800

dear reviewer #2:

excuse, this has been in an edit buffer for weeks.

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

extended-messages authors had $dayjobs and did not have the stamina for
the level of dos in the sidr wg.  they were desperate to get bgpsec our
the door and idr was holding them hostage.  and it's not like bgpsec is
just around the corner.

> Can the introduction of draft-ietf-idr-bgp-extended-messages be

would you like it if we threw in bgp-ls?  no extra charge.

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

the intent was to allow simplexity, use of extended messages in one
direction only.  in retrospect, this may be too subtle/clever.  it could
be as you suggest if no one wants simplexity.

> "   Applications generating information which might be encapsulated
>    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

it was added to reaffirm what to you is obvious.  unless you really
object, i see no harm in leaving it.

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

a prefix announcement with 200 researcher-invents-massive-attribute? :)
[ nanog joke ]

> ---
> "   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 extension to BGP does not change BGP's underlying security issues »
> 

i took some edits, tyvm.

randy

---

From: Robert Varga <[email-masked]>
Date: Thu, 14 Feb 2019 00:41:45 +0100

Hello everyone,

On 29/01/2019 12:32, Susan Hares wrote:
> 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

I have updated the report with the behavior of OpenDaylight
implementation to the extent I could quickly ascertain. I suspect all 12
answers in the Management Information are either Yes, or N/A (in case of
CLI), but I currently do not have the cycles to make a definitive
answer, sorry :(

[snip]

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

As an implementer: we have implemented this extension many moons ago
based on a request from a real-life deployment. I believe the answer to
all three questions is yes.

Regards,
Robert

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 13 Feb 2019 19:00:28 -0500

Robert: 

The management section is option and standardization does not depend on that
portion of the implementation report.  It is extremely valuable information
that Opendaylight has yes or (n/a). 

Susan Hares 

-----Original Message-----
From: Robert Varga [mailto:[email-masked]] 
Sent: Wednesday, February 13, 2019 6:42 PM
To: Susan Hares; [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hello everyone,

On 29/01/2019 12:32, Susan Hares wrote:
> The authors should indicate whether they know of any IPR.   
> Implementers are encouraged to update the  implementation data at:
> 
>  
> 

I have updated the report with the behavior of OpenDaylight implementation
to the extent I could quickly ascertain. I suspect all 12 answers in the
Management Information are either Yes, or N/A (in case of CLI), but I
currently do not have the cycles to make a definitive answer, sorry :(

[snip]

> those deploying BGP-LS or SR, and c) if the specification is ready for 

As an implementer: we have implemented this extension many moons ago based
on a request from a real-life deployment. I believe the answer to all three
questions is yes.

Regards,
Robert

---

From: <[email-masked]>
Date: Thu, 14 Feb 2019 08:29:13 +0000

Sue,

Thanks for the reply. Please see inline [Bruno]

From: Susan Hares [mailto:[email-masked]]
Sent: Wednesday, February 13, 2019 8:03 PM
To: DECRAENE Bruno TGI/OLN
Cc: [email-masked]; '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)

Hi WG,

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

>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

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

[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)

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

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

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

OLD: A BGP speaker

NEW:
A BGP speaker

----

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

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

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.

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

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

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.

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

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

>Before evaluating this, I think this document should first specified how a BGP

Thanks,
--Bruno

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Feb 2019 09:47:10 +0000

Dear Randy,

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Wednesday, February 13, 2019 10:36 PM
> 
> dear reviewer #2:
> 

No problem. Thanks for the reply.
 
> would you like it if we threw in bgp-ls?  no extra charge.

-28 looks good to me.
 
> be as you suggest if no one wants simplexity.

Both options works for me. My comment was that §3 and §4 did not seemed aligned on this point.
-28 looks good to me.
 
> object, i see no harm in leaving it.

Whether this is obvious or not, this is true/applicable at least from RFC 4271. IOW, this draft does not change the point that the BGP message is limited in size.
Ok for leaving it.

> a prefix announcement with 200 researcher-invents-massive-attribute? :)

1) Taking the large community example, [RFC8092], this attribute could be bigger than 4096 octets. How would you handle this?
2) The problem is not limited to attribute bigger than 4096 octets. If you have one NLRI having an attribute of 2100 octets and an attribute of 2000 octets, how do you handle this?

> > 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 suppo…

That is my main comment.

Thanks,
--Bruno

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 14 Feb 2019 12:20:18 -0500

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.   

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.  

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. 

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

Old/

/

New/

   putting an attribute which cannot be decomposed to 4096 octets or

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

 

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

Sue,

Bruno: 

Sue 

<shepherd hat on> 

 

(snip) 

Hi WG,

level of implementation.  

Yes 

Yes 

Yes 

have indicate

[Bruno] ok, solved

 

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

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. 

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. 

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. 

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

----

§4

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

OLD: A BGP speaker

NEW:

A BGP speaker

 

----

[Bruno] OK.

----

 

[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/

/

New/

   putting an attribute which cannot be decomposed to 4096 octets or

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

/

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

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. 

---

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

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. 

[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! 

Thanks,

--Bruno

---

for the >OPEN message. 

BGP 

Thanks,

--Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Feb 2019 18:34:20 +0100

Dear Sue & authors of this proposal,

> Therefore, putting an attribute which cannot be decomposed to

> 4096 octets or less in an Extended Message is a likely path to

> routing failure.

That's brilliant statement but not enough to proceed with this spec.

See the fundamental change that today such issue is in vast majority of
cases locally significant. That means that if I send NLRI to BGP it will
have a decent chance to be received by all intended parties.

With new spec we are saying that it may silently fail somewhere in the
middle and we do not do anything about it. That's to me showstopper.

At min if given NLRI can not be sent with XXL attributes to some peers (say
on the RR which Bruno mentioned) we must specify protocol extension in this
very spec on how to deal with it.

Such extension may be as simple as to define a short attribute
BGP_PIPE_TOO_THIN which will be inserted in the place where XXL attribute
just did not fit smaller message size peers to tell them then "Hey
something is broken with this NLRI" - pls check. Then it will be up to
local policy to install such NLRI or drop it.

Thx,
R.

On Thu, Feb 14, 2019 at 6:21 PM Susan Hares <[email-masked]> wrote:

> be precise in the detailed comments.  I’ve summarized my comments as well
> to help us take the next step.
>
>
>
> Sue
>
>
>
> Summary
>
> ----
>
> 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
> 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.
>
>
>
>    One example of a valid attribute which cannot be precisely decomposed
> if it
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, February 14, 2019 3:29 AM
> *To:* Susan Hares
> *Cc:* [email-masked]; 'Jakob Heitz (jheitz)'
> *Subject:* RE: [Idr] WG Last Call on Extened Message Support
>
>
>
> Sue,
>
>
>
> *From:* Susan Hares [mailto:[email-masked]]
> *Sent:* Wednesday, February 13, 2019 8:03 PM
> *To:* DECRAENE Bruno TGI/OLN
> *Cc:* [email-masked]; 'Jakob Heitz (jheitz)'
> *Subject:* RE: [Idr] WG Last Call on Extened Message Support
>
>
>
> Bruno:
>
>
>
> (public and private) the chairs and I as the shepherd received on this
> draft in our last WG LCs.
>
>
>
> 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.
>
>
>
> *(snip) *
> *From:* Idr <[email-masked]> *On Behalf Of *
> [email-masked]
> *Sent:* 29 January 2019 13:33
> *To:* Susan Hares <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] WG Last Call on Extened Message Support
>
>
>
> Hi WG,
>
>
>
> >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).
>
>
>
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended->implementations
> says : 5a
>
> >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.
>
>
>
> >full support.   I’m waiting for Olivier to update based on the last
> point, but my understanding is that
>
> *[Bruno] ok, solved*
> >   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
>
> >[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.
>
>
>
> *[Bruno] So too bad the draft does not solve the real problem ;-) (as
> message space is still limited)*
>
>
>
> 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.
>
>
>
> *[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
> 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. *
>
>
>
> *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. *
>
>
>
> *If you believe this is worthy of a use case draft for the sake of BESS,
> can be reviewed by all these WGs. *
>
>
>
>
>
> 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
>
> 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.*
>
>
>
> ----
>
> >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.
>
> 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
> *[Bruno] I don’t think that I agree with this. E.g. I don’t see where RFCs
> 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/
>
>    One example of a valid attribute which cannot be precisely decomposed
> if it
>
> 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
> *[Bruno] I think that the sentence could be elaborated. Indicating the
> specification does not address it.*
>
> *In “Running immediately to Extended Message” I don’t think they that the
> 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. *
>
>
>
> *The specification does not specify the necessary policies implementation
> 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. *
>
>
>
> ---
>
> >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
>
> 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.
>
>
>
> 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.*
>
>
>
> 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
> 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.
>
>
>
> 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.
>
>
>
> *[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! *
>
>
>
> *Thanks,*
>
> *--Bruno*
>
>
>
>
>
> ---
>
> >§4
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares
> *Sent:* Tuesday, January 29, 2019 12:33 PM
> *To:* [email-masked]
> *Subject:* [Idr] WG Last Call on Extened Message Support
>
>
>
>
>
> 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.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 14 Feb 2019 13:46:20 -0500

Robert: 

Thank you for your message and your concerns regarding BGP in the Internet.   See my comments below. 

Sue 

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Thursday, February 14, 2019 12:34 PM
To: Susan Hares
Cc: Bruno Decraene; idr@ietf. org
Subject: Re: [Idr] WG Last Call on Extened Message Support

>See the fundamental change that today such issue is in vast majority of cases locally significant. That means that if I send NLRI to BGP it will have a decent chance to be received by all intended parties. 

[Sue]: The reason you receive this NLRI is due to the peer-wise agreements of all the BGP peers in the cloud.  Each peer agrees to send routing based on its policies and capabilities.   Policy and implementation specific details are not in BGP specifications. 

>With new spec we are saying that it may silently fail somewhere in the middle and we do not do anything about it. That's to me showstopper. 

[Sue]: Where do you see the point it must silently fail or an operator will not do anything about it?  

The error message handling specified in the draft and in RFC4271.  If see errors in the error handling as specified please send that to the list.   These errors must be on the peer-to-peer protocol exchange. 

The peer-wise agreements specify the length of a BGP message.  BGP peers receiving a large packet and expecting to send it to a peer which has 4096 bytes as a message size, will need to repackage it.  If it cannot be repackaged, then the BGP implementation needs to warn the operator.   If the BGP peers cannot repackage BGP messages today, there should be error messages and “bells” ringing.  If the implementation does not have the appropriate warning systems, please see your vendor.

What show stopper deployed today are you talking about?  I do not perceive any show-stopper on the peer-to-peer communication. 

At min if given NLRI can not be sent with XXL attributes to some peers (say on the RR which Bruno mentioned) we must specify protocol extension in this very spec on how to deal with it. 

[Sue]:  We cannot send the 12K large community attribute now.  This protocol specification deals with what happens when you send and receive BGP packets.  The BGP peers negotiate the length of the BGP message that can be sent/received.  It has been tested and deployed (see comment about OpenDaylight) for some years.  

Your description indicates a “network-wide” requirement.  A network-wide requirement is based on the specific needs of an application + BGP.  For example, some Data center BGP applications are very different than EVPN BGP over MPLS.  

Such extension may be as simple as to define a short attribute BGP_PIPE_TOO_THIN which will be inserted in the place where XXL attribute just did not fit smaller message size peers to tell them then "Hey something is broken with this NLRI" - pls check. Then it will be up to local policy to install such NLRI or drop it. 

[sue]This idea is orthogonal to the basic BGP engine.  It is similar to ideas that have been kicked around in Grow and IDR for a while.  If this use case gives new focus to these ideas, please write a specification and suggest it to the IDR and Grow WG.   IDR can look at the passage of error messages.  Grow can look at how useful it is for the general BGP.  We’ve talk about the error message concept for 10+ years, but the tradeoff for the error message has not given enough benefits to operators.    Perhaps this is the “killer-application” application..  

Thx,
R.

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.   

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.  

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. 

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

Old/

/

New/

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

/

 

Sue,

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) 

Hi WG,

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

>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended- <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-%3eimplementations> >implementations says : 5a 

Yes 

Yes 

Yes 

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

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

[Bruno] ok, solved

>   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

 

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

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

[Bruno] Let’s take the example of a BGP Route Reflector having a mixed of clients, some supporting Extend Message (EM) and some not.

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

This is a policy issue within the BGP peer and the network operation staff.  Each operator may choose to write this policy differently. 

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. 

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. 

– 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

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

OLD: A BGP speaker

NEW:

A BGP speaker

 

----

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

----

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

/

New/

   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. 

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. 

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. 

---

[Bruno]

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

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. 

[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! 

Thanks,

--Bruno

---

Thanks,

--Bruno

 

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

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

---

From: <[email-masked]>
Date: Fri, 15 Feb 2019 10:25:10 +0000

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/

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.

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.

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

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:[email-masked]]
Sent: Thursday, February 14, 2019 6:20 PM
To: DECRAENE Bruno TGI/OLN
Cc: [email-masked]; '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)

[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)

[Bruno2] I don't think that Error handling is to be considered as optional or for future consideration.

Old/
[PS - in American English "Can not" is normally concatenated "cannot".]

[Bruno2] Thanks for the proposition, but this does not address my concern.

Sue,

Bruno:

Sue

<shepherd hat on>

(snip)

Hi WG,

Yes

Yes

Yes

[Bruno] ok, solved

[Sue]:  Gladly...

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

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.

----
§4

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

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

[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/

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

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.

---

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.

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

---

Thanks,
--Bruno

Thank you.

Thank you.

Thank you.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 16 Feb 2019 01:01:51 +0000

This is a show stopper for me too.

One way to solve it would be to restrict the extended messages to new address families only.
Any new address family would then need to specify that it must support extended messages,
such that all implementations of the new address family must support the extended messages.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, February 15, 2019 1:34 AM
To: Susan Hares <[email-masked]>
Cc: Bruno Decraene <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Thx,
R.

On Thu, Feb 14, 2019 at 6:21 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Bruno:

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.

Old/

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

Sue,

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

Bruno:

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.

(snip)
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 29 January 2019 13:33
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi WG,

Yes

Yes

Yes

[Bruno] ok, solved

----
§4

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

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

Old/

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

---

Thanks,
--Bruno

---

Thanks,
--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, January 29, 2019 12:33 PM
To: [email-masked]<mailto:idr@ietf..org>
Subject: [Idr] WG Last Call on Extened Message Support

Thank you.

Thank you.

Thank you.
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Feb 2019 10:24:22 -0500

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

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.  

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.  

/ 

Please let me know I understand your suggested changes. 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, February 15, 2019 5:25 AM
To: Susan Hares
Cc: [email-masked]; 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.

Old/

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

    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

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

   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.

   a speaker MUST follow the error handling procedures of 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.  

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

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]

Bruno: 

Sue 

Summary

----

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

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

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

Old/

/

New/

   (12,000 bytes).  

/

[Sue]: Thank you for your text – I understand why now. 

Sue,

Bruno: 

in our last WG LCs..   

Sue 

<shepherd hat on> 

 

(snip) 

From: Idr <[email-masked]> On Behalf Of bruno.decraene@orange..com
Sent: 29 January 2019 13:33
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

Hi WG,

level of implementation.  

Yes 

Yes 

Yes 

have indicate

[Bruno] ok, solved

 

<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

[Sue]:  Gladly… 

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

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

 

----

§4

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

OLD: A BGP speaker

NEW:

A BGP speaker

 

----

[Bruno] OK.

----

 

Old/

/

New/

   (12,000 bytes).  

/

 

[Bruno2] IMHO specifications need to handle error conditions that they
create by design.

---

   peers which can only accommodate 4096 octet messages..

[Bruno]

[Bruno2] It’s not implementation specific. This is an issue created by the
specification. Let’s discuss it in public.  

[Bruno] no, cf above.

[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

---

for the >OPEN message. 

BGP 

Thanks,

--Bruno

 

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Feb 2019 10:36:38 -0500

Jakob and Robert: 

Thanks to Bruno’s proposed code – I think I understand Bruno’s concerns.  Would you read my response and the proposed text changes.   Let me know if my proposed changes to section 5 and 9 of Randy’s draft address your concerns. 

If so, I will start a specific all on those additions to the draft. 

Thanks for your patience with me,

Susan Hares

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, February 15, 2019 8:02 PM
To: Robert Raszuk; Susan Hares
Cc: Bruno Decraene; idr@ietf. org
Subject: Re: [Idr] WG Last Call on Extened Message Support

Regards,

Jakob.

 

Thx,
R.

Bruno: 

Sue 

Summary

----

Old/

/

New/

   (12,000 bytes).  

/

 

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

Sue,

Bruno: 

Sue 

<shepherd hat on> 

 

(snip) 

Hi WG,

Yes 

Yes 

Yes 

[Bruno] ok, solved

 

[Sue]:  Gladly… 

 

----

§4

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

OLD: A BGP speaker

NEW:

A BGP speaker

 

----

[Bruno] OK.

----

 

Old/

/

New/

   (12,000 bytes).  

/

 

---

[Bruno]

[Bruno] no, cf above.

Thanks,

--Bruno

---

Thanks,

--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, January 29, 2019 12:33 PM
To: [email-masked] <mailto:idr@ietf..org> 
Subject: [Idr] WG Last Call on Extened Message Support

---

From: <[email-masked]>
Date: Fri, 22 Feb 2019 16:46:10 +0000

Sue,

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

From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, February 21, 2019 4:24 PM
To: DECRAENE Bruno TGI/OLN
Cc: [email-masked]; '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 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:

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:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 15, 2019 5:25 AM
To: Susan Hares
Cc: [email-masked]; Robert Raszuk
Subject: Re: [Idr] WG Last Call on Extened Message Support

Susan,

Old/

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

   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:

   peer using BGP Capabilities Advertisement [RFC5492<https://tools.ietf.org/html/rfc5492>].  A BGP speaker

[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

[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)

[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

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

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

[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"

[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

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.

more inline [Bruno2]

Bruno:

Sue

Summary
----

[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

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

[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

Old/

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

Sue,

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

Sue

<shepherd hat on>

(snip)

Hi WG,

Yes

Yes

Yes

[Bruno] ok, solved

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

----
§4

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

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

Old/

---

Thanks,
--Bruno

---

Thanks,
--Bruno

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

Thank you.

Thank you.

Thank you.

Thank you.