Hi, RtgWG,

Please find below some review comments on draft-rtg-dt-encap-02.

https://datatracker.ietf.org/doc/draft-rtg-dt-encap/

While this is not a comprehensive fine-tooth-comb review, I hope these (somewhat high-level) comments are useful.

General comments:

Scanning through the document, I have two high-level concerns.
	• First, there is really no evident or apparent definition of what “Encapsulation” is. This is not a pedantic comment, but I think it is a root cause of the point that follows.
	• Many of the considerations on this document are not applicable to the scoped “encapsulation” per se. Instead, they relate to a specific layer underneath the encapsulation, to a layer that further encapsulates the encapsulation.

For example, the document sets of explaining the need for understanding common requirements and considerations among groups of encaps. In addition to encaps in NOV3, these are also the BIER Header and NSH. Both these can be carried by multiple underlays each with different characteristics. However, the document conflates requirements and characteristics from the encap itself, and intertwines them with characteristics and requirements on the underlay.

I think this document would greatly benefit from a cleaner separation of what happens at the encap, versus what is expected, required, or considered from the underlay (transport, network, tunnel, etc). This is particularly exacerbated in the ECMP and MTU sections, but present in others as well.

Take for example ECMP — the BIER header has an Entropy field. Different encaps can provide Entropy fields to be used as a source for entropy, either at the encap (e.g., service) layer or by an underlay. One example is L2TPv3 session id and GRE Key (as per RFC 5640). However, the ECMP sections focus on IP and IP/UDP methods, which frankly are applicable generally and not only to these “Encapsulations”.

And I believe some of these potential disconnects go back to the high-level concern #1, lack of definition/scope of what is an encap (and what is not).

Just to be clear, I am all for inter-layer cooperation and requirement realization. However, if the goal is to understand encapsulation common requirements, then a more clean separation of the encapsulation headers versus a specific transport of said encapsulations will make it easier to understand if those requirements belong in an encap or in an underlay.

A smaller one: this document is titled "Encapsulation Considerations” (without any qualifiers), but the abstract narrowscopes it to a specific encaps.


Some more specific comments, prefaced with “CMP":

2.  Overview
…
   o  SFC carries service meta-data which might be modified or
      unmodified as the packets follow the service path.  SFC talks of
      some loop avoidance mechanism which is likely to result in
      modifications for for each hop in the service chain even if the
      meta-data is unmodified.

CMP: This is not complete (incorrect by omission). The SFC Encap is responsible first for Serfice Function Path Identification, and second, for Metadata. See Section 1.3 and 4.1 of https://tools.ietf.org/html/draft-ietf-sfc-architecture-09.

   o  SFC is all about carrying service meta-data along a path, and
      different services might need different types and amount of meta-
      data.

CMP: It is true that metadata requires extensibility. However the SFC Encap is all about path identification *and* carrying metadata.
CMP: Also, SFC’s extensibility has to do with OAM and graphs as well.

CMP: By the way, encaps need to strike a balance between flexibility and performance. This point could be made more explicitly.

   Most of the issues discussed in this document are not new.  The IETF
   and industry as specified and deployed many different encapsulation
   or tunneling protocols over time, ranging from simple IP-in-IP and
   GRE encapsulation, IPsec, pseudo-wires, session-based approached like
   L2TP, and the use of MPLS control and data planes.  IEEE 802 has also
   defined layered encapsulation for Provider Backbone Bridges (PBB) and
   IEEE 802.1Qbp (ECMP).  This document tries to leverage what we
   collectively have learned from that experience and summarize what
   would be relevant for new encapsulations like NVO3, SFC, and BIER.

CMP: I think it would be much clearer here to specify terms around what is encap, transport, etc. L2TPv3 for example can run over IPv6 directly, over IP/UDP, etc. Those cases have key differences although the actual L2TPv3 header does not change.

3.  Common Issues
…
   o  How to provide entropy for Equal Cost MultiPath (ECMP) routing

CMP: And LAGs?

   o  OAM - what support is needed in an encapsulation format?

CMP: OAM in what context? fault management, performance management, all?

CMP: Also, this section seems to lack an issue of “adaptation” of the payload.

4.  Scope

   o  Focus on the class of encapsulations that would run over IP/UDP.
      That was done to avoid being distracted by the data-plane and
      control-plane interaction, which is more significant for protocols
      that are designed to run over "transports" that maintain session
      or path state.

CMP: I am not sure if the relationship between running over “transports” (which transports?) and control-plane - data-plane complexity is clear — it is not clear to me at least.

7.  Entropy

   In many cases the encapsulation format needs to enable ECMP in
   unmodified routers.  Those routers might use different fields in TCP/
   UDP packets to do ECMP without a risk of reordering a flow.

CMP: Is this an encap-supported requirements, or a requirement of IP/UDP in general, whatever is transported?

   the ephemeral port range) plus the outer IP addresses which seems to
   be sufficient for entropy; using outer IPv6 headers would give the
   option for more entropy should it be needed in the future.

CMP: And the IPv6 Flow Label and RFC 6438?

   There is some interaction between entropy and OAM and extensibility
   mechanism.  It is desirable to be able to send OAM packets to follow
   the same path as network packets.  Hence OAM packets should use the

CMP: This is having the underlying assumption that “OAM” is “OAM packets” as opposed to also fields in data packets. If OAM is in the packet, it fate-shares by definition.

   Architecturally the entropy and the next header field are really part
   of enclosing delivery header.  UDP with entropy goes hand-in-hand
   with the outer IP header.  Thus the UDP entropy is present for the

CMP: This is a very important point, and this clarity in demarcation should be throughout, to understand at which layer different requirements are.

8.  Next-protocol indication

   Next-protocol indications appear in three different context for
   encapsulations.
…
   Secondly, the encapsulation needs to indicate the type of its
   payload, which is in scope for the design of the encapsulation.

CMP: I believe that this section should not start assuming an explicit protocol indication. A demux context can provide protocol identification, or it could be explicitly carrier (self-defining package). And perhaps that is the first consideration.

   We
   have existing protocols which use Ethernet types (such as GRE).  Here
   each encapsulation header can potentially makes its own choices
   between:
   o  Reuse Ethernet types - makes it easy to carry existing L2 and L3
      protocols including IPv6, IPv6, and Ethernet.

CMP: I do not believe that the options are Ethertype, IP protocol number, or own registry only.
CMP: Nit — repeat IPv6.

   In summary:
   o  Would it be useful for the IETF come up with a common scheme for
      encapsulation protocols?  If not each encapsulation can define its
      own scheme.

CMP: This seems to be a non-sequitur. Why would that be useful?

9.  MTU and Fragmentation

CMP: This is another key section that could use clarify between encap and transport.

   In summary:
   o  In some deployments an encapsulation can assume well-managed MTU
      hence no need for fragmentation and reassembly related to the
      encapsulation.
   o  Even so, it makes sense for ingress to track any ICMP packet too
      big addressed to ingress to be able to log any MTU
      misconfigurations.

CMP: This section seems to be conflating MTU with PMTUD. Cleary related, but those are different things. The area of pre-fragmentation vs. post-frag is also underspecified. See e.g., https://tools.ietf.org/html/rfc3931#section-4.1.4


10.  OAM

   In terms of what we have heard from the various working groups there
   seem to be needs to:
   o  Be able to send out-of-band OAM messages - that potentially should
      follow the same path through the network as some flow of data
      packets.

CMP: It is not clear what are “out-of-band messages” that follow the same path as data packets…

CMP: Also, this section seems to imply that “OAM” is “separate OAM packets”, where there is OAM Performance Management (PM) considerations for in-band in-data-packets measurement. Those ought to be considered in the encap layer.

   There can be several ways to prevent OAM packets from accidentally
   being forwarded to the end station using:
   o  A bit in the frame (as in TRILL) indicating OAM
   o  A next-protocol indication with a designated value for "none" or
      "oam”.

CMP: Or both! An OAM bit with an OAM proto allows for max flexibility.

Hope these help!

— Carlos.