Subject: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jul 2019 12:06:19 -0400

This begins a 2 week working group last call on
draft-ietf-idr-ext-opt-param-06.txt from 7/30 to 8/13/2019.  

You can access the draft at: 

https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/

John and Enke - I am counting on you gather information on the 2
implementations and post this on the IDR Wiki during these 2 weeks. 

For the WG, consider if:

1)      The technology is ready for publication or if there are flaws that
prevent its publication, 

2)      Is this technology useful to BGP deployments? 

3)      Are there any minor editorial errors the authors should address
before publication. 

Cheerily, Sue Hares

---

From: John Scudder <[email-masked]>
Date: Tue, 30 Jul 2019 16:10:49 +0000

(As a co-author of course.)

Since it seemed helpful last time, here's the elevator pitch for ext-opt-param: We are currently limited to 255 bytes of BGP capabilities. Since many/most BGP extensions want to use a capability, it’s not hard to imagine overrunning the 255 bytes. It would be in everyone’s interest to fix the limitation before we ever bump into it. This draft is a spec for a fix.

Thanks,

—John

On Jul 30, 2019, at 12:06 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

This begins a 2 week working group last call on draft-ietf-idr-ext-opt-param-06.txt from 7/30 to 8/13/2019.

https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dext-2Dopt-2Dparam_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=7yslJny2ZMcwH_kCk9UyVzGfQaVlMu7BoMyOtSDbMnk&s=p2572N3TH8pEFI-9eitSzTedYkto_TMR805OddPtQHU&e=>

John and Enke – I am counting on you gather information on the 2 implementations and post this on the IDR Wiki during these 2 weeks.

For the WG, consider if:

1)      The technology is ready for publication or if there are flaws that prevent its publication,
2)      Is this technology useful to BGP deployments?
3)      Are there any minor editorial errors the authors should address before publication.

Cheerily, Sue Hares

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2019 15:00:44 -0700

read
makes sense

---

From: <[email-masked]>
Date: Wed, 31 Jul 2019 09:17:37 +0000

Hi Sue,

Fully support.
I'm also fine with the _current_ version of the document.

Nevertheless, I'll try some comments, possibly useless but at minimum to show to the shepherd/AD that I've read and reviewed the doc.

1.  Introduction
[...]
The Parameter Length field of individual Optional Parameters is similarly extended.

I would rather remove 'similarly' or change it to 'also'. As although the technical specification is crystal clear, I fear that the sentence could be interpreted as the length field for individual optional parameters been extended the same way (length 255, followed by extended length) while this is not the case.

---

The (non-extended) length field is set to

   255, as is the subsequent octet that in the non-extended format would

   be the first Optional Parameter Type.  The subsequent two octets

   carry the actual length.

This works so let it be so.
One could have argued that this encoding is borderline as per RFC 4271. May be an encoding  more in line with 4271 could have been Type: 255, Length: 2, Value: actual/extended length. (i.e. adding/keeping the 'length' field of the Optional Parameter type 255). That would also have been more friendly for protocol parser (e.g. wireshark) especially since there is a chance that network operator get surprised the first time that the BGP session get rejected and may want to have a look at the open message).
Note that I understand that my comment is way too late ... and also a matter of opinion.
---

   In the event that the length of Optional Parameters in the BGP OPEN

   message does not exceed 255, the encodings of the base BGP

   specification [RFC4271<https://tools.ietf.org/html/rfc4271>] MUST be used without alteration.

Could the document define the error handling if this MUST is not followed? I believe any option (notification or silently ignore) works, but in general I have a preference for error handling to be covered by the spec.

That may also be the opportunity to remove the following sentence "If the value of this field is zero, no Optional Parameters are present (this would never be expected to happen with the extended encoding, however). > which is both not general enough (does not cover length 1-254) and appears in the general specification/behavior while it's about error handling.
---
As of 2019, I feel that this extension may have been an opportunity to also enable the use of BGP extended message length for the BGP OPEN message. (if the "BGP Extended Message" capability was also exchanged.). Alternatively, the burden of defining this could also been in draft-ietf-idr-bgp-extended-messages. But probably too late for both documents so let's move forward.

Thanks,
Regards,
--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, July 30, 2019 6:06 PM
To: [email-masked]
Subject: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

John and Enke - I am counting on you gather information on the 2 implementations and post this on the IDR Wiki during these 2 weeks.

For the WG, consider if:

Cheerily, Sue Hares

_________________________________________________________________________________________________________________________

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: "Susan Hares" <[email-masked]>
Date: Wed, 31 Jul 2019 13:14:58 -0400

Bruno:

Thank you for your normal detailed review.    I will let John and Enke
respond to you first before I comment. 

Sue 

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 31, 2019 5:18 AM
To: Susan Hares; [email-masked]
Subject: RE: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30
to 8/13/2019)

Hi Sue,

Fully support.

Nevertheless, I'll try some comments, possibly useless but at minimum to
show to the shepherd/AD that I've read and reviewed the doc. 

1.  Introduction

[.]

The Parameter Length field of individual Optional Parameters is similarly
extended.

I would rather remove 'similarly' or change it to 'also'. As although the
technical specification is crystal clear, I fear that the sentence could be
interpreted as the length field for individual optional parameters been
extended the same way (length 255, followed by extended length) while this
is not the case.

---

One could have argued that this encoding is borderline as per RFC 4271. May
be an encoding  more in line with 4271 could have been Type: 255, Length: 2,
Value: actual/extended length. (i.e. adding/keeping the 'length' field of
the Optional Parameter type 255). That would also have been more friendly
for protocol parser (e.g. wireshark) especially since there is a chance that
network operator get surprised the first time that the BGP session get
rejected and may want to have a look at the open message).

Note that I understand that my comment is way too late . and also a matter
of opinion.

---

   In the event that the length of Optional Parameters in the BGP OPEN
   message does not exceed 255, the encodings of the base BGP
   specification [ <https://tools.ietf.org/html/rfc4271> RFC4271] MUST be
used without alteration.

Could the document define the error handling if this MUST is not followed? I
believe any option (notification or silently ignore) works, but in general I
have a preference for error handling to be covered by the spec.

That may also be the opportunity to remove the following sentence "If the
value of this field is zero, no Optional Parameters are present (this would
never be expected to happen with the extended encoding, however). > which is
both not general enough (does not cover length 1-254) and appears in the
general specification/behavior while it's about error handling.

---

As of 2019, I feel that this extension may have been an opportunity to also
enable the use of BGP extended message length for the BGP OPEN message. (if
the "BGP Extended Message" capability was also exchanged.). Alternatively,
the burden of defining this could also been in
draft-ietf-idr-bgp-extended-messages. But probably too late for both
documents so let's move forward.

Thanks,

Regards,

--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, July 30, 2019 6:06 PM
To: [email-masked]
Subject: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to
8/13/2019)

For the WG, consider if:

 

Cheerily, Sue Hares 

____________________________________________________________________________
_____________________________________________
 
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: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 31 Jul 2019 18:39:33 +0000

I have read the document and support publication with the improvements discussed on this list.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Tuesday, July 30, 2019 at 12:07 PM
To: IDR List <[email-masked]>
Subject: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

For the WG, consider if:

Cheerily, Sue Hares