[Idr] Martin Vigoureux's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)

[Martin Vigoureux via Datatracker <[e-mail]>]

Martin Vigoureux 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://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-tunnel-encaps/



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

Hi

thank you for the work you put in this document.
I only have minor comments/questions (though a couple of ones might be a bit
more important than the rest).

   Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.
   This is further discussed in Appendix A.
But neither the abstract nor the metadata mention this, and in fact Appendix A
is not clear about whether RFC 8365 is effectively obsoleted.

Not critical but IANA registration of the Tunnel Encapsulation Attribute is
with a upper-case 'A', while through out the document lower-case 'a' is used.

   A Tunnel Encapsulation TLV, also known as Tunnel TLV
but in the document you most often omit using Tunnel, thus reducing it to TLV.

   The Reserved subfield SHOULD be originated as zero.  It MUST be
   disregarded on receipt, and it MUST be propagated unchanged.
In the rest of the document, for unused bits or reserved fields you require
MUST be zero. Any reason for different levels of requirements?

   The Address Family subfield contains a value from IANA's "Address
   Family Numbers" registry.  This document assumes that the Address
   Family is either IPv4 or IPv6; use of other address families is
   outside the scope of this document.

   If the Address Family subfield has any value other than IPv4 or IPv6,
   the Tunnel Egress Endpoint sub-TLV is considered "unrecognized"
Not critical but I have the impression that these two paragraphs slightly
contradict each other. First one allows for other AFIs to be used in the future
in the Address Family subfield, while the second kind of rules that out. Maybe
simply add at the beginning of the second paragraph: "In the context of this
specification,".

   Note that in order to send an IP packet or an MPLS packet through a
   VXLAN tunnel, the packet must first be encapsulated in an Ethernet
   header, which becomes the "inner Ethernet header" described in
   [RFC7348].  The VXLAN Encapsulation sub-TLV may contain information
   (e.g.,the MAC address) that is used to form this Ethernet header.
This seems redundant with the last paragraph of the second bullet above (in the
document)

   sub-TLVs must be used
MUST?

      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |     0 or 1                |
     +-+-+-+-+-+-+-+-+
Should the values be 1 or 2 instead? At least the text says the only two
allowed values are 1 and 2.

   If a Label-Index is present in the Prefix-SID sub-TLV, then when a
   packet is sent through the tunnel identified by the TLV, if that
   tunnel is from a labeled address family
do you mean from "a BGP UPDATE of a labeled address family" ?

   document specifying such joint use should provide details
SHOULD?

    +--------------+--------------------------------+-----------------+
    |      0       | V (Virtual Network Identifier) | (this document) |

           +--------------+-----------------+-----------------+
           |      0       | V (VN-ID)       | (this document) |

Purely cosmetic, but may be choose VN-ID or Virtual Network Identifier as the
same name for the two allocations.

Nits
"Value Field" in the Fig1 and Fig2 legends seems superfluous.
s/In this case, the length field/In this case, the Length field/
s/address subfield/Address subfield/ (6 occurrences)
s/depicted in the Address Field/depicted in the Address subfield/ (3
occurrences, including Section 3.1.1 title) s/Tunnel Type itself/tunnel type
itself/? s/value field/Value field/ (17 occurrences + 6 occurrences with line
break between the two words) s/Reserved (two fields)/Reserved (two octets)/
(twice) s/The flags field of the VXLAN header/The flags field of the NVGRE
header/ (in the NVGRE section) s/Inner Destination MAC address/Inner
Destination MAC Address/ s/of the cookie/of the Cookie/ s/procedures of Section
9/procedures of Section 9)/ s/VNI (Virtual Network Identifier)/VNI (VXLAN
Network Identifier)/