To clarify, I think the win here is with clear and concise specifications, and avoiding double definitions of what is supposed to be the same thing -- not shared TLV parsing code. :)
There's actually nothing sub-optimal encoding-wise with option 2a or 2b. The drawback with option 2 is we have 2 different TLV structures, the registry can be shared though. Thanks, Chris. > On May 18, 2018, at 10:29 AM, Acee Lindem (acee) <[email protected]> wrote: > > Hi Chris, > > Somehow, I lost the mail below and was only able to retrieve it from the > archive. Pardon my top posting. > > While I believe that sharing code points for values, e.g., IGP Algorithm > Type, is a good idea, I don’t necessarily think it is a good idea to merge > the TLV type registries. It seems to me it would be a poor trade-off to > impact optimal protocol encoding including implementation just so we can have > a combined IANA registry. It is extremely unlikely that OSPF and IS-IS > implementations will ever share a common TLV parsing library. > > Note that we did discuss this once before in the context of the OSPF and > IS-IS Tunnel Encapsulation drafts. I'd appreciate hearing what other WG > members feel with respect to this issue. > > Thanks, > Acee > > > > > > > Christian Hopps <[email protected]> Thu, 17 May 2018 21:07 UTC > > So in looking at the IANA requests inside the newly merged flex algorithm > draft I noticed that the document is creating 2 separate Flex Algorithm > Definition sub-tlvs Registries for IS-IS and OSPF with the initial content > described in sections: > > 6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV > 6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV > 6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV > > 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV > 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV > 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV > > They are basically the same thing (indeed the later OSPF sections refer back > to the IS-IS sections), except for one detail AFAICT, the size of the type > and length fields. > > I think we may have some options here to make this a bit more elegant. > > 1. Share the same sub-TLV structure > a. using the OSPF sub-tlv structure (16 bit type and 16 bit len) for both > protocols > b. using the IS-IS sub-tlv structure (8 bit type and 8 bit len) for both > protocols > > 2. Use different structure with the same type field size of the > a. more constrained IS-IS 8 bit size > b. less constrained OSPF 16 bit size > > 3. Define and use some generic method to define shared TLVs like this where > the only actual difference is the size of the type and length fields. > > > 1, Creates a clean and simple standard, 1 TLV definition and 1 sub-TLV > registry. > > 1a, has the property that the length value in IS-IS can't normally exceed an > 8 bit value; however, sub-TLV length values are already constrained beyond > the field size as sub-TLVs may appear anywhere in the TLV. > > 1b, restricts both protocols to 256 types, and perhaps more importantly > restricts the sub-TLV length to 257 octets. This is handled all the time in > IS-IS using repeated TLVs, but not so much (ever?) in OSPF. > > > 2. Allows us to at least create a single IANA registry for the sub-tlv types > so we aren't duplicating them and their definitions for each protocol. > > > 3. Is interesting but probably requires some work outside of this document. > > > This document is serving as our guinea pig for how to merge work so I think > it's worth spending some effort on these types of details. > > Thanks, > Chris. >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
