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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 Aug 2019 17:15:16 -0400

Sue,

On Tue, Jul 30, 2019 at 12:06:19PM -0400, Susan Hares 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.  

I support publication.  I'm fine with Bruno's comments.

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

Juniper supports this feature in the generally available 15.2 release and after.

We've done interop against Nokia.  I'll let them declare their supported
version.

-- Jeff

---

From: John Scudder <[email-masked]>
Date: Fri, 2 Aug 2019 01:27:18 +0000

Hi Bruno,

Thanks for your comments. I’ve just posted version -07 that I believe addresses them; more in-line below.

—John

On Jul 31, 2019, at 5:17 AM, [email-masked]<mailto:[email-masked]> wrote:

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.

Done.

---

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.

This comment led Enke and me to consider why it’s necessary to mandate any particular value for the length field; as you say the length could be 2, and for that matter it could indeed be any nonzero value. In the end we chose to leave it as 255 because there are implementations of -06 that do expect to see 255 as a magic value, but to make the spec more permissive as to what values may be received. We didn’t choose to mandate the TLV version you describe, first and most important for backward-compatibility reasons, but second because it’s actually not a TLV — it’s (candidly) a hack that (ab)uses the first two bytes of what would otherwise be a TLV, to indicate use of a different encoding. But whether you find the latter argument convincing or not, probably the former is sufficiently compelling.

I do want to draw your (and the WG’s) attention to the fact we made this change though, which is normative although entirely backward-compatible with -06.

---

   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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4271&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=ex0u_LhOZGOAxeHCrhS7eMnFmWvTlJhesBv2w33xhT0&s=rURYD2UMPN8kYVYuMNnoqQHElix3WSXZYAx23CLspb0&e=>] 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.

Done and done.

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

Yes, a pity but as you say 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]<mailto:[email-masked]>
Subject: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

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/<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=ex0u_LhOZGOAxeHCrhS7eMnFmWvTlJhesBv2w33xhT0&s=oZuwj43Z5yf5dr7GxgFV6J9yoJ5j79MwHWFOih-yW8E&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

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=ex0u_LhOZGOAxeHCrhS7eMnFmWvTlJhesBv2w33xhT0&s=bnkPRZKuenz2QlGT2wyzBWIeBi4Yk1u1u6qDrWbnHac&e=

---

From: Ondrej Zajicek <[email-masked]>
Date: Thu, 8 Aug 2019 21:13:46 +0200

On Tue, Jul 30, 2019 at 04:10:49PM +0000, John Scudder wrote:
> (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.

AFAIK we are not currently limited to 255 bytes of BGP capabilities.

According to RFC 5492, multiple instances of capability options are
allowed, well-defined, just discouraged:

   The Capabilities Optional Parameter (OPEN Optional Parameter Type 2)
   SHOULD only be included in the OPEN message once. ... However,
   for backward compatibility, a BGP speaker MUST be prepared to receive
   an OPEN message that contains multiple Capabilities Optional
   Parameters, each of which contains one or more capabilities TLVs.

If i want to announce 2k bytes of BGP capabilities, i can just split it
to multiple sub-256 blocks of capability options. Real limits are 255 bytes
for each capability and 4k bytes for whole OPEN message.

While the draft removes per-capability limit by allowing to put all
capabilities ot one large option, it does that by backward-incompatible way,
while splitting capabilities to multiple options is backward-compatible.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: [email-masked])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

---

From: John Scudder <[email-masked]>
Date: Fri, 9 Aug 2019 19:03:32 +0000

Wow. Color me embarrassed, and thank you for pointing this out. I think you are right, and furthermore I think it’s a better solution than what we describe in the draft.

Under the circumstances my suggestion to the WG is that we NOT advance the draft to Proposed Standard. The question would remain what to do with it, keeping in mind there are implementations in the wild. The options I can think of are to abandon it, or to publish it as Historic. So, options on the table for the WG are,

1. Abandon the draft.
2. Publish as Historic, because there are implementations out there.

I think in either of the above cases we would also move code 255 to “deprecated”.

3. Continue forward with the original plan of publishing as Proposed Standard, because ______ (fill in the blank if you support this option).

My preference is option 2, although I confess I might be biased by the sunk cost fallacy. :-/

Thanks again for your observation, Ondrej.

—John

> On Aug 8, 2019, at 3:13 PM, Ondrej Zajicek <[email-masked]> wrote:
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 9 Aug 2019 22:06:12 +0000

Huh???

https://tools.ietf.org/html/rfc4271#section-4.2

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+
       |    Version    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     My Autonomous System      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Hold Time           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         BGP Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opt Parm Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |             Optional Parameters (variable)                    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
      Optional Parameters Length:

         This 1-octet unsigned integer indicates the total length of the
         Optional Parameters field in octets.  If the value of this
         field is zero, no Optional Parameters are present.

      Optional Parameters:

         This field contains a list of optional parameters, in which
...

You may certainly include all capabilities in a single optional parameter
or each capability in its own optional parameter, but either way,
there is only one "Optional Parameters Length" field, so the total
length of all the optional parameters combined cannot exceed 255.

Can someone explain an alternative interpretation?

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of John Scudder
Sent: Friday, August 9, 2019 12:04 PM
To: Ondrej Zajicek <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

1. Abandon the draft.

—John

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 9 Aug 2019 22:17:34 +0000

BTW, I support the draft. It is an elegant way to increase the available space for capabilities.

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, August 9, 2019 3:06 PM
To: John Scudder <jgs=[email-masked]>; Ondrej Zajicek <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

Huh???

       0                   1                   2                   3

      Optional Parameters:

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of John Scudder
Sent: Friday, August 9, 2019 12:04 PM
To: Ondrej Zajicek <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

1. Abandon the draft.

—John

---

From: Ondrej Zajicek <[email-masked]>
Date: Sat, 10 Aug 2019 00:51:50 +0200

> Can someone explain an alternative interpretation?

You are right, sorry for confusion. I focused on the 1B optional
parameter length field in each option and forgot about the global
1B optional parameter length field.

---

From: John Scudder <[email-masked]>
Date: Fri, 9 Aug 2019 23:26:56 +0000

On Aug 9, 2019, at 6:06 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Huh???
...

Yes, Enke also pointed out that I was mistaken about being mistaken, so now I am embarrassed about having been embarrassed and I retract my retraction. Please disregard my previous email, and I hope this Friday is over soon. :-)

—John

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Fri, 9 Aug 2019 23:33:23 +0000

John:

It’s my mistake too. I was confused when we were discussing before.

Thanks.  -- Enke

From: Idr <[email-masked]> on behalf of John Scudder <jgs=[email-masked]>
Date: Friday, August 9, 2019 at 4:30 PM
To: "Jakob Heitz (jheitz)" <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

—John

---

From: <[email-masked]>
Date: Thu, 29 Aug 2019 12:38:02 +0000

Hi John,

Thank you. Comments fully addressed.

Sorry for my delay: extended PTO length.

--Bruno

From: John Scudder [mailto:[email-masked]]
Sent: Friday, August 2, 2019 3:27 AM
To: DECRAENE Bruno TGI/OLN
Cc: Hares Susan; [email-masked]
Subject: Re: [Idr] draft-ietf-idr-ext-opt-param-06.txt - 2 Week WG LC (7/30 to 8/13/2019)

Hi Bruno,

—John

Hi Sue,

Fully support.

1.  Introduction
[…]

Done.

---

   carry the actual length.

---

Done and done.

---

Thanks,
Regards,
--Bruno

For the WG, consider if:

Cheerily, Sue Hares

Thank you.