Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

(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 <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
> Sent: Friday, May 18, 2018 7:29 AM
> To: Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org
> 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 <chopps@chopps.org> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr