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

From: "Susan Hares" <[email-masked]>
Date: Tue, 29 Jan 2019 06:32:44 -0500

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

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

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

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

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

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

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

Sue Hares (WG Chair, Shepherd)

---

From: <[email-masked]>
Date: Tue, 29 Jan 2019 13:33:21 +0000

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

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

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

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

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

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

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

_________________________________________________________________________________________________________________________

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: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Jan 2019 13:45:58 -0000

The solution to:

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

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

Then everyone would be happy.

Adrian

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

level of implementation.  

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

----

§ 1

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

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

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

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

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

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

OLD: A BGP speaker

NEW:

A BGP speaker

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

----

“   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

----

 

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?

---

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:

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

 

 

____________________________________________________________________________
_____________________________________________
 
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: <[email-masked]>
Date: Tue, 29 Jan 2019 13:55:28 +0000

From: Adrian Farrel [mailto:[email-masked]]

The solution to:

  *   BGP-LS needs extended message support
  *   No one has implemented BGP extended message support
...would appear to be to have implementations of BGP-LS implement BGP extended message support.

+1
Also, if there are implementations of BGP-LS but no implementation of BGP extended message, the statement "*     BGP-LS needs extended message support" probably needs to be refined.
--Bruno

Adrian

Hi WG,

Yes

Yes

Yes

----
§ 1

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

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 29 Jan 2019 11:42:12 -0500

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,

level of implementation.  

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: Tue, 29 Jan 2019 11:44:30 -0500

Adrian: 

I hope those who have implementations will chime in.   I have received
reported of at least 1 full implementation and 1 private.   

By the way, IDR does send specification through WG LC and then hold for
implementations.     In this case, I hope this will encourage more
implementations. 

Cheerily, Sue 

From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2019 8:46 AM
To: [email-masked]; 'Susan Hares'
Cc: [email-masked]
Subject: RE: [Idr] WG Last Call on Extened Message Support

The solution to:

Adrian

Hi WG,

level of implementation.  

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: Tue, 29 Jan 2019 11:51:45 -0500

Bruno: 

On: 

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

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

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

Cheers, 

Sue 

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

The solution to:

+1

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

--Bruno

Adrian

Hi WG,

level of implementation.  

Yes 

Yes 

Yes 

----

§ 1

 

[

----

§4

OLD: A BGP speaker

NEW:

A BGP speaker

----

----

 

---

---

----

---

§4

Probably

----

§8

Nits:

Thanks,

--Bruno

---

From: <[email-masked]>
Date: Tue, 29 Jan 2019 17:08:51 +0000

Sue,

Thanks for the clarification on this.
Regarding the choice of word, I'm definitely not the reference for fine understanding of English nuances. That being said,  Merriam-Webster seems to define "need" as "require".  I feel like the use of "would benefit from" may be clearer for everyone.
transitive verb<https://www.merriam-webster.com/dictionary/transitive>
: to be in need of : require<https://www.merriam-webster.com/dictionary/require>

https://www.merriam-webster.com/dictionary/need

Regarding the reality of the need, if BGP-LS implementations need Extended Message support, they are free to implement it today, yesterday or a few years ago. I'll take the risk of using an English idiom "the proof of the pudding is in the eating". I don't see IETF/IDR as blocking the implementations.

Cheers,
--Bruno

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, January 29, 2019 5:52 PM
To: DECRAENE Bruno TGI/OLN; [email-masked]
Cc: [email-masked]
Subject: RE: [Idr] WG Last Call on Extened Message Support

Bruno:

On:
"BGP-LS needs extended message support" probably needs to be refined" - I can live with.

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

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

Cheers,

Sue

The solution to:

+1

Adrian

Hi WG,

Yes

Yes

Yes

----
§ 1

----
§4

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

---

---

---
§4

Nits:

Thanks,
--Bruno

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 29 Jan 2019 17:26:15 +0000

Sue,

Please see 1 comment inline [Bruno]

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, January 29, 2019 5:42 PM
To: DECRAENE Bruno TGI/OLN
Cc: [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.
[Bruno] I understand the BGP-LS issue and more generally I support removing such limitation even before we hit it. But IMHO a bigger issue is the potential impact in networks supporting many services and users such as the Internet and VPN ones. The document is applicable to all AFI/SAFI so I'd like the document to define how such routes would be handled when received with a set of attributes larger than the current 4271 limit and having to be sent to speakers not supporting Extend Message. One possible option may be to treat as withdraw, possibly on RR/over IBGP (i.e., within the AS) which would translates in routing inconsistencies within the AS. Another option would be to drop some attributes or some attribute content (which ones). There are probably other reasons. As of today the behavior is undefined and the document does not even refer to this problem. I'm sorry to say that is not good enough for me. Again is not even about error handling, but regular behavior of this specification.

Thanks
Cheers,
--Bruno

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: "Randy Bush" <[email-masked]>
Date: Tue, 29 Jan 2019 09:27:53 -0800

colloquially, in pacific northwest american english, ‘need’ is not
as strong as ‘require.’  maybe 82.3% give or take a few tenths of
a percent. :)

i am working on your long review message.  thanks for putting the
time into it.

randy

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 29 Jan 2019 12:53:25 -0500

Bruno: 

Good catch on this point. 

“I’d like the document to define how such routes would be handled when
received with a set of attributes larger than the current 4271 limit”. 

While we discussed this earlier, the current version of the draft does not
have anything regarding it.  Randy indicated he would be replying regarding
your long message. 

Susan Hares 

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

Sue,

Bruno:

 

As to your comment: 

[Bruno] I understand the BGP-LS issue and more generally I support removing
such limitation even before we hit it. But IMHO a bigger issue is the
potential impact in networks supporting many services and users such as the
Internet and VPN ones. The document is applicable to all AFI/SAFI so I’d
like the document to define how such routes would be handled when received
with a set of attributes larger than the current 4271 limit and having to be
sent to speakers not supporting Extend Message.. One possible option may be
to treat as withdraw, possibly on RR/over IBGP (i.e., within the AS) which
would translates in routing inconsistencies within the AS. Another option
would be to drop some attributes or some attribute content (which ones).
There are probably other reasons. As of today the behavior is undefined and
the document does not even refer to this problem. I’m sorry to say that is
not good enough for me. Again is not even about error handling, but regular
behavior of this specification.

Thanks

Cheers,

--Bruno

Cheers, 

Susan Hares 

Hi WG,

level of implementation.  

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: Tue, 29 Jan 2019 12:56:43 -0500

Bruno: 

I’m fine with “would benefit from” replacement for need.   I’m glad the
specification of a BGP message longer than 4096 bytes is not blocking BGP-LS
implementations/deployments today.   Since deployments of some features like
a longer BGP message may take 3-5 years, BGP-LS would benefit from a longer
message being define now (smile).  

Sue 

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

Sue,

Regarding the choice of word, I’m definitely not the reference for fine
understanding of English nuances. That being said,  Merriam-Webster seems to
define “need” as “require”.  I feel like the use of “would benefit from” may
be clearer for everyone.

 <https://www.merriam-webster.com/dictionary/transitive> transitive verb

: to be in need of :  <https://www.merriam-webster.com/dictionary/require>
require 

Regarding the reality of the need, if BGP-LS implementations need Extended
Message support, they are free to implement it today, yesterday or a few
years ago. I’ll take the risk of using an English idiom “the proof of the
pudding is in the eating”. I don’t see IETF/IDR as blocking the
implementations.

Cheers,

--Bruno

Bruno: 

On: 

Cheers, 

Sue 

 

The solution to:

+1

--Bruno

Adrian

Hi WG,

level of implementation.  

Yes 

Yes 

Yes 

----

§ 1

 

[

----

§4

OLD: A BGP speaker

NEW:

A BGP speaker

----

----

 

---

---

----

---

§4

Probably

----

§8

Nits:

Thanks,

--Bruno

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 29 Jan 2019 20:34:40 +0000

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:

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

Cheers,
Susan Hares

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

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

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

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

----

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”

---

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?

---

----

---
§4

Nits:

Thanks,
--Bruno

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: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 29 Jan 2019 20:42:19 +0000

In hindsight it might be better to update the complete new statement in 5a from

No

No

Yes

Into
Does send Extended Message capability

Yes

Yes

No

It is easier to understand and is directly to the point without the double negation issue.

ExaBGP should be re-confirmed because I could imagine the same mistake happened there as well.

Oliver

From: Oliver Borchert <[email-masked]>
Date: Tuesday, January 29, 2019 at 3:34 PM
To: Susan Hares <[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

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, 30 Jan 2019 09:36:20 -0500

Oliver: 

Would you look at the rest of the web page and let me know if there is anything else I should adjust. 

 

Please send me a contact for the ExaBGP BGP implementation?  I will try to get an updated form. 

Sue Hares 

From: Borchert, Oliver (Fed) [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2019 3:42 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

No 

No 

Yes 

Into 

Yes 

Yes 

No 

Oliver

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%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=hXBbOXqwvXqtCV%2B9PbP%2F7IE6WJjWUA2boM33Kds%2Bgh4%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%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859165043&sdata=uZS%2BbN9v5cir2o5L3U3jP2xFPbY4Tz%2FNnBPfdH7iDf0%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%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.

----

§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%7C40bb8a943e614b1637f308d68608d6cd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636843769859321289&sdata=okjTeLe6DcTaRV2USy2My6HXDRynupmXlB0i7gUwynA%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%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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 31 Jan 2019 01:52:51 +0000

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,

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,

Yes

Yes

Yes

----
§ 1

----
§4

OLD: A BGP speaker

NEW:
A BGP speaker

----

----

---

---

----

---
§4

Nits:

Thanks,
--Bruno

Thank you.

---

From: <[email-masked]>
Date: Thu, 31 Jan 2019 10:58:24 +0000

Definitely +1

--Bruno

From: Borchert, Oliver (Fed) [mailto:[email-masked]]
Sent: Tuesday, January 29, 2019 9:42 PM
To: Susan Hares; DECRAENE Bruno TGI/OLN
Cc: [email-masked]
Subject: Re: [Idr] WG Last Call on Extened Message Support

No

No

Yes

Into

Yes

Yes

No

Oliver

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.