Subject: [Idr] Martin Duke's No Objection on draft-ietf-idr-ext-opt-param-11: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 21 Apr 2021 10:39:30 -0700

Martin Duke has entered the following ballot position for
draft-ietf-idr-ext-opt-param-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Rob. Though not at all an expert on BGP, I think that if BGP nodes
MUST NOT use the new encoding for smaller parameter sets, that is going to make
it harder to test for the capability on the internet and reduce the incentives
to support this specification. I would suggest that instead they SHOULD use the
RFC4271 encoding, possibly discussing the reasons one might not.

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 21:57:30 +0000

Hi Martin,

> On Apr 21, 2021, at 1:39 PM, Martin Duke via Datatracker <[email-masked]> wrote:
...

As I mentioned in my reply to Rob, I actually can’t think of a good reason for them not to, which is why it’s a MUST; as I mentioned in my reply to Warren, the reason to consume the new format nonetheless (other than Postel’s Law) is to enable potential future deprecation of the old format (yes, I’m an optimist).

—John

---

From: Martin Duke <[email-masked]>
Date: Thu, 22 Apr 2021 07:08:58 -0700

Like I said, there are two reasons not to I can think of:
- To test support of this option on hosts across the internet
- To encourage hosts to handle it properly.

On Wed, Apr 21, 2021 at 2:57 PM John Scudder <[email-masked]> wrote:

> As I mentioned in my reply to Rob, I actually can’t think of a good reason
> for them not to, which is why it’s a MUST; as I mentioned in my reply to
> Warren, the reason to consume the new format nonetheless (other than
> Postel’s Law) is to enable potential future deprecation of the old format
> (yes, I’m an optimist).
>
> —John

---

From: John Scudder <[email-masked]>
Date: Thu, 22 Apr 2021 19:41:35 +0000

IDR WG:

Note the small normative change here: what used to be a MUST is now a SHOULD/MAY. I think this will be non-controversial, but wanted to point it out.

Hi Martin,

OK, you wore me down! :-)

Updated to read:

   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] MUST SHOULD be used without alteration.  (However,
   Configuration MAY override this to force the extended format to be
   used in all cases; this might be used, for example to test that a
   peer supports this specification.  (In any case, an implementation
   MUST accept an OPEN message that uses the encoding of this
   specification even if the length of Optional Parameters is 255 or
   less.)

Thanks,

—John

On Apr 22, 2021, at 10:08 AM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

On Wed, Apr 21, 2021 at 2:57 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

> On Apr 21, 2021, at 1:39 PM, Martin Duke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
...

—John