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

[John Scudder <[e-mail]>]

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.

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

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

> -- Sections 5 & 12 --
> Unsure whether this paragraph is really useful, isn't it implicit ? (I am of
> course fine in either case)

Both of these were added because other reviewers thought it wasn’t clear enough, so I guess some people don’t think it’s implicit. So, I guess we’ll let them stand.

> == NITS ==
> 
> I find the choice of "encapsulation sub-TLV" a poor choice as it can easily be
> confused with "encapsulation TLV" (section 2) but I guess the train has left
> the station ;-)

Yes, it has. :-) I do see your point, though. Sorry.

—John