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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 12 Apr 2021 07:57:13 -0700

Éric Vyncke 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 IESG 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:
----------------------------------------------------------------------

Thank you for the work put into this document. It sounds like it is really a
useful extension to BGP-4.

Having written that, I must admit that I failed to understand the mechanism at
first reading. It took me a while to cross reference this doc + IANA registry +
RFC 4271 (but, for sure, I am not a BGP SW engineer!).

I suggest to mention, in section 2, that the Code Capability IANA registry for
255 was reserved per RFC 8810 (so not causing interoperation) as well as using
the actual values 255 in figure 1 and finally add the figure 4.2 from RFC 4271
to be crystal clear for the reader.

Should the "new speaker" behavior be specified when an "old speaker" close the
connection ? I.e., retry if possible without using this specification ?

I hope that this helps to improve the document,

Regards,

-éric

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 22:11:44 +0000

Hi Éric,

Thanks for your comments.

> On Apr 12, 2021, at 10:57 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
...
> 255 was reserved per RFC 8810 (so not causing interoperation)

Not quite! The code reserved in 8810 is a Capability Code. The code we’re reserving in this document is an Optional Parameter type. Capabilities nest inside Optional Parameters. (The reason it’s this way may qualify as ancient history by now.)

> as well as using

So, show two OPEN format diagrams: the non-extended, and the extended? I see your point, it could make some of the other text less painful as well; on the other hand, it’s a bigger rewrite than the other changes so I’m a little hesitant to tackle it at this late stage since the existing text has been pretty heavily reviewed by now. I’ll think on it, I’m not going to push it out with the other changes I’ll be posting today, though.

> connection ? I.e., retry if possible without using this specification ?

I don’t think so, because by definition (since we’ve mandated that the implementation MUST use the old format when possible) if the speaker sent the OPEN with the new format, it must need the new format in order to properly follow its configuration. I don’t want the router second-guessing the operator as to which capabilities are expendable; if this really has to be done the operator should intervene and make that decision.

Regards,

—John

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Apr 2021 07:58:25 +0000

Thank you John for the explanations.

Got it about the IANA registry :)

And the goal of changing the figures is to ease the understanding indeed. But, I understand that this is slightly more complex than fixing a typo, OTOH, it is an editorial change and not a protocol change. Really up to you and your co-authors

-éric

-----Original Message-----
From: John Scudder <[email-masked]>
Date: Thursday, 22 April 2021 at 00:11
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Hares Susan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-idr-ext-opt-param-11: (with COMMENT)

    Hi Éric,

    ...

    Regards,

    —John