Hello Erik, > I guess we still need to have some idea how many bits would be required up > front (24, 32, more?) and whether we think this field needs to be > extensible.
I would go with a VNI of 24 or 32bit as this seems reasonable. I still have to understand why the data plane processing would need to have the concept of VNI hierarchy, I would have thought that's an abstraction for the control plane (?). At the end some bit limit must exist or we face problems with (hardware-) implementations. We can solve the open question later with an extension header - but you mention below this didn't work so well for other protocols - or define a next-version NVO3 header when there is need. For my comment about IPSEC/AH: > One question is whether the higher assurance is just for the VNI or for the > whole encapsulated frame. Using something like ESP/AH takes us down the > path of protecting the whole frame, which might be overkill. agree. My (naive?) idea was to let AH in the NVO3 case only cover the underlay IP header, the NVO3 header and maybe the tenant frame header (IPv4/v6 or the Ethernet header). Honestly, have to re-read the specs if there is a way to chieve this. It would protect all the information needed when decapsulating the NVO3 overlay. The tenant frame protection I would leave to a separate AH/ESP step before the overlay encap and after decap. If my idea is bad or impractical then we need to introduce NVO3's own hashing procedure. > As I tried to clarify in my response to Tom the meta-data discussion in the > IETF was mostly about vendor-specific service meta-data, but perhaps this > term is being used for more general extensibility? that's how I was thinking about it. This may work as long as the encap/decap entity - which can be a NIC, switch/router etc. - does not need to understand what the meta-data means and can just add/remove it as opaque data. > I think there should be ways to add better assurance (checksum, keyed > hashes) for the NVO3 header. But perhaps that can be in fixed fields in a > fixed length header. You mean the usual fields of "auth type", "key id" and such, typically part of an authentication TLV, should be part of the NVO3 header from the beginning? Nothing optional but build-in from the start? > In terms of the overall architecture there is a desire to carry some > service meta-data with frames. The sfc WG is thinking about doing that > using a separate NSH header. Even if we only cover IPv4, IPv6 and Ethernet as payload we need some protocol or next-header field, IMHO. This could cover e.g. NSH as well. Saying this, one could then also define a next-header value for OAM instead of having a OAM (aka RA) flag - and let the hardware trigger on the value instead of a flag. Nevertheless, I think a reserved field for flags is a good idea if we have the room in the NVO3 header. Regards, Marc > It would be good for the NVO3 WG to have a clear understanding of what data > needs to be carried with each encapsulated frame. That helps determine how > flexible and extensible the packet format needs to be. > The experience with extensibility for protocols that are in the dataplane > (be it IPv4 options, IPv6 extension headers, TRILL options, etc) is that > they don't tend to get implemented in hardware. And the dataplane protocols > tend to have a mixture of hardware and software implementations - which is > different than TCP which is mostly software. > One observation is that we (the IETF + industry) seems to be able to > redefine fixed-fields (e.g., IPv4 TOS->DSCP+ECN, MPLS labels with new > semantics like the entropy label) a lot easier than implementing new > options or extension headers. > >> Anyway, it sounds TLV-like and having a variable overhead length may be a >> problem for the overlay MTU. Assuming that this Meta-Data is orthogonal to >> the VNI, would another "MD-ID" field help? The control-/config plane could >> then map this MD-ID to the Meta-Data and program the data plane >> accordingly. > > One would have to require that the underlay MTU exceeds the overlay MTU by > the maximum encapsulation overhead. Thus a large max size of > options/extensions has some cost. >> >> >> I think another point, which was mentioned on the list, is the >> fragmentation/reassembly or MTU problem. For simplicity I would prefer the >> NVO3 header has no support for this. If your tenant frame is IPv4/v6 then >> fragmentation/reassembly should happen on this level. For Ethernet tenant >> frames - no idea but I assume Ethernet networks solve the MTU problem by >> "correct configuration"? So the NVO3 "link" would just be another interface >> with an unusual MTU (?). > > That seems to be how the hardware encapsulations handle things. > If it was all software on the endpoints then there would be more options, > but for efficiency we typically want to avoid fragmentation. > >> The document also mentions the "learning bridge" behaviour. I would have >> seen >> the details of MAC learning as "control plane" (albeit not necessarily the >> "centralized authority" of the charter). For the data plane it is a >> requirement to punt packets to the control plane. Well, actually forward >> the >> packet and punt a copy to control plane. I wonder if we have other >> requirement to trigger such a copy/punt? (e.g. an OAM/alert flag, as >> discussed in VXLAN-gpe) >> > While the option of "learning bridge" behavior might be useful, it doesn't > have anything to do with the dataplane encapsulation format. > > Your question about OAM/alert flags is a good one. I think it makes sense > to define some flags. > Perhaps we also want a "drop packet if you don't know about this flags" > flag; in many cases the control plane can be used to determine the > capabilities hence one can avoid sending dataplane packets with some new > OAM or other feature to endpoints that don't know about it. In such a case > it is sufficient to have flags that have the "ignore if you don't know > about it" semantics. > > Erik > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
