(I never saw Chris's original email either - perhaps it was sent during the period when delivery to the alias when compromised.)
I am in full agreement w Acee - it is a VERY BAD idea to try to combine protocol TLV registries. There are many reasons for this - here are a few. 1)In IS-IS the scope of TLV type identifiers is the protocol - in OSPF it is the LSA type 2)There are (obviously) many legacy code points which will make consistency at best confusing 3)Imposing an 8 bit type on OSPF or a 16 bit type on IS-IS is simply a non-starter. RFC 7356 defines a non-backwards compatible way of doing this for IS-IS - but does so in a way that preserves the legacy codepoints - which seems obviously necessary. And introducing a 16 bit length into IS-IS isn't sensible unless we also address the current 256 LSP number limitation (which RFC 7356 also does). Suggesting this can be usefully done in a backwards compatible way does not make sense to me. I cannot imagine why OSPF would be motivated to move to a more restricted 8 bit type/length model. I cannot support this suggestion. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee) > Sent: Friday, May 18, 2018 7:29 AM > To: Christian Hopps <[email protected]> > Cc: [email protected] > Subject: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs > > 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. > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
