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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
