Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)

[John Scudder <[e-mail]>]

Hi Éric,

A few more replies in line.

> On Dec 3, 2020, at 3:02 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hello John,
> 
> It seems that we agree on everything except perhaps a couple of places where I added some text prefixed with EV>
> 
> Regards
> 
> -éric
> 
> PS: thank you for using Éric rather than Eric ;-)

You’re welcome. I try to get people’s names right when I can. I’m sure I often fail, but I do try.

> -----Original Message-----
> From: John Scudder <[e-mail]>
> Date: Wednesday, 2 December 2020 at 21:11
> To: Eric Vyncke <[e-mail]>
> Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "idr@ietf. org" <[e-mail]>, Alvaro Retana <[e-mail]>, Hares Susan <[e-mail]>
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
> 
>    Hi Éric,
> 
>    Thanks for your review. My comments in line below.
> 
>> On Nov 30, 2020, at 11:15 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
>> 
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-idr-tunnel-encaps-20: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!ViCzn0BhxT8HlczCnDBqvHT7je-ahPfaepKEQClZ2sThFTwDBjpY825mI4QQyg$
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!ViCzn0BhxT8HlczCnDBqvHT7je-ahPfaepKEQClZ2sThFTwDBjpY827N1viI6A$
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thank you for the work put into this document.
>> 
>> Please find below some non-blocking COMMENT points, and one generic nit.
>> 
>> I hope that this helps to improve the document,
>> 
>> Regards,
>> 
>> -éric
>> 
>> == COMMENTS ==
>> 
>> -- Abstract --
>> A very generic comment about the abstract that is mainly about RFC 5512. I find
>> it a little surprising as it describes the protocol that this document
>> obsoletes... I would have preferred an abstract describing what this document
>> does w/o citing RFC 5512 (except of course at the end of the abstract).
> 
>    Agreed, thanks for bringing this up. How’s this for a rewrite?
> 
>       This document defines a BGP Path Attribute known as the "Tunnel
>       Encapsulation Attribute", which can be used with BGP UPDATEs of
>       various SAFIs to provide information needed to create tunnels and
>       their corresponding encapsulation headers.  It provides encodings for
>       a number of Tunnel Types along with procedures for choosing between
>       alternate tunnels and routing packets into tunnels.
> 
>       This document obsoletes RFC 5512, which provided an earlier
>       definition of the Tunnel Encapsulation Attribute.  RFC 5512 was never
>       deployed in production.  Since RFC 5566 relies on RFC 5512, it is
>       likewise obsoleted.  This document updates RFC 5640 by indicating
>       that the Load-Balancing Block sub-TLV may be included in any Tunnel
>       Encapsulation Attribute where load balancing is desired.
> 
> EV> It sounds good to me

Adopted.

>> -- Section 1.4 --
>> 
>> It is a little unclear what "these deficiencies" are ? Perhaps add a reference
>> to previous section 1.2 ?
> 
>    This was caused by the insertion of the new Use Case section as 1.3. It was a toss-up whether to exchange positions of 1.3 and 1.4, or adopt your suggestion, but I ended up doing the latter (“… addresses the deficiencies identified in Section 1.2…”)
> 
>> -- Section 3 --
>> Would it be easier for the reader to either have a summary table of all sub-TLV
>> types or repeat the type code in all sub-section headings?
> 
>    You mean instead of having the type codes in the prose, as in “… whose type code is 6”? I’m not dead set against having a table in the front material of Section 3, but I think it’s probably better for an implementor to refer to the actual IANA Registry, which is also tabular, and is guaranteed to be up-to-date. An earlier reviewer (Alvaro) expressed a marked preference for having the code named in line with the relevant section, and that makes sense, so on the whole I think it’s better to stick with the current structure. I think your alternate suggestion is to identify the code in the relevant heading, as in "The Tunnel Egress Endpoint Sub-TLV (type code 6)”? I’m OK with that but it would make the headings (and ToC) busier, and I’m not sure it really helps the document’s readability. I’m open to further input but at the moment I’m leaving it as written.
> 
> EV> Still have a preference for having the code in the heading but it is really a matter of taste. Up to the authors

Adopted — so now the type codes are in the headings and removed from the prose, it seems unnecessary to have them both places, except in the case of the Encapsulation sub-TLV where it seemed helpful for clarity to mention the type code in the prose as well.

>> -- Section 3.2.1 and 3.2.2 --
>> While the assumption of a 48-bit MAC address is correct in 2020 (barring
>> FireWire, IEEE 802.5.14), it also limits the usability of this document to a
>> set of data-link layers.
> 
>    Since 3.2.1 and 3.2.2 are specific to VXLAN and NVGRE, and since VXLAN and NVGRE are restricted to 48-bit MAC addresses, this seems appropriate. I guess if some child-of-VXLAN spec were to be written that used 64-bit addresses, or variable-length addresses, or whatever, then a new sub-TLV would have to be introduced that properly expressed that. So yeah, the document per se is limited to a set of data-link layers, but it’s extensible for new data-links.
> 
>> Should the length of the "Reserved" field be specified ?
> 
>    You’re right, it should. I updated the figure. That made me notice a similar deficiency in a bunch of the other figures, I fixed those too. There are just a couple that don’t now have explicit lengths, and those are given either in the adjacent text (DS Value), or in the reference which is the authoritative source (MPLS Label Stack).
> 
>> -- Section 3.3 --
>> Should the value of IPv6 Flow Label or any IPv6 extension header (e.g., hop by
>> hop or destination headers) be specified ?
> 
>    I think if someone would find these useful, they can and should publish a draft to extend this spec. It wasn’t our intention to cover every possible application. (Something about “boiling the ocean”…)
> 
>> -- Section 3.6 --
>> If not mistaken, RFC 8669 is only about SR-MPLS. So, I wonder whether the
>> authors also think to add a similar feature for SRv6 ?
> 
>    Similar response.
> 
> EV> So now, all fish are cooked ;-)

Great, now I’m hungry. :-)

—John