The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-22

[ section 3.3.1 ]

https://www.rfc-editor.org/rfc/rfc2474.html#section-3 says this about the term "DS field":

   Six bits of the DS field are used as a codepoint (DSCP) to select the
   PHB a packet experiences at each node.  A two-bit currently unused
   (CU) field is reserved and its definition and interpretation are
   outside the scope of this document.  The value of the CU bits are
   ignored by differentiated services-compliant nodes when determining
   the per-hop behavior to apply to a received packet.

   The DS field structure is presented below:


        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |         DSCP          |  CU   |
      +---+---+---+---+---+---+---+---+

        DSCP: differentiated services codepoint
        CU:   currently unused

So, if this section 3.3.1 one byte DS field is meant to be the same (i.e. includes the 2 CU bits that are now ECN bits), then I'm good with this.

Thanks.

Throughout the document it seemed like a lot of care had been taken in the appropriate use of SHOULDs and MUSTs.  Nice work.

In addition to Barry's comments about the IANA Considerations section, please state in Section 14.1 which registry/registries are to be updated.

Thank you to Scott Kelly for performing the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT feedback.

Thanks to Jouni  for the Opsdir review, and authors for addressing them (https://mailarchive.ietf.org/arch/msg/idr/MkQPOktdsUZAkxgv9iqtJgdG4HE)

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

-- Section 1.4 --

It is a little unclear what "these deficiencies" are ? Perhaps add a reference to previous 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?

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

Should the length of the "Reserved" field be specified ?

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

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

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

== 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 ;-)

For the new registries defined in Sections 14.6 through 14.9, it would help both IANA and the reader if the definition specified the range of values: for the bit fields, how many bits are available?  For the numeric field in 14.8, what’s the valid numeric range?

Thank you for the discussion and clarifications relating to my discuss point,
as well as all the other updates to the document.

I support Erik's DISCUSS.

Thank you for Section 1.3; it was extremely helpful to understand what this spec is trying to accomplish.

In Sec 3.1 it says there MUST be exactly one Tunnel Egress Endpoint sub-TLV but describes an error if there are zero sub-TLVs. In Sec 13 this is correctly specified as anything other than 1 sub-TLV. Please update 3.1 to match.

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)/

Hi,

Thanks for this document.  I have no significant comments.

Like Martin, I'm also somewhat confused by this text "Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.", since it appears that RFC 8365 isn't really being formally obsoleted.

From a manageability perspective, are there any addition data nodes required to the BGP YANG data model, or augmentations to that model?  If so, are these being taken care of in another draft or subsumed into existing YANG modelling work?

Regards,
Rob