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

[Christian Hopps <[e-mail]>]

> On May 19, 2018, at 12:27 PM, Les Ginsberg (ginsberg) <[e-mail]> wrote:

First, please understand that my intent is to have a discussion on the subject of when (and when not) to use common definitions. Just because I enumerated a bunch of ways that that might be accomplished does not mean that I am advocating for all of them or any one in particular. I bet that we agree on many of the options not being the right way, but I wanted to list all the ways I could imagine doing this so that we as a group could consider them during the discussion.

> Chris -
...
> As we often say "this is software - we can do anything" but please tell me WHY this is a good thing?
> So far the only argument seems to be that you think this make the draft "easier to read" - which begs the question as to whether in this particular case the current form of the draft (protocol specific encoding sections) is hard to read. It isn’t for me.

I don't agree with the paraphrasing "easier to read". I'm saying that it's better to define a thing in one place rather than in define it repeatedly in multiple places. Again this is why we have a combined document, right?

Ah, I see where we may not be understanding each other. I am thinking much more about the duplicate IANA registries, not about using 2 sections vs. 1 section in the combined document. The registries we are talking about are literally copies and I'd like to not have 2 IANA registries to document the same thing. 

> I really think you are extending the "combine the WGs" idea beyond where it should reasonably go.
> It has never been a goal to combine the protocols - and once you start straying into trying to combine descriptions of protocol specific encoding I think that is exactly what you are trying to do - even if only in a modest way.

That seems like a reasonable way to think about how far we should or shouldn't go. So how strict would you say your view is on this "rule"? Is it never appropriate to make any compromise on encoding in order to be able to share, or is it just this case that you find "too much for too little"?

> We have already defined combined registries in those cases where we are defining an attribute value that is the same for both protocols e.g., IGP algorithm and MSD.
> But trying to extend that and combine the description of the protocol specific encoding isn’t appropriate or desirable.

I agree! IGP algorithm is a great example, and I'm glad you agree that it was a good idea. The content of the "Sub-TLVs of the FAD TLV" are in the same way shared by both protocols. The types and the values are defined exactly the same for both protocols. The *only* difference is the encoding of the type (and length) value, the semantics are the same.

So again, is there a more elegant way to define and document that shared semantic in one place?

How about an option 2c

  2c: Leave the encodings the way they are, and use a common registry to define the type/value semantics.

Thanks,
Chris.

>   Les
> 
> 
>> -----Original Message-----
>> From: Christian Hopps <[e-mail]>
>> Sent: Saturday, May 19, 2018 6:15 AM
>> To: Les Ginsberg (ginsberg) <[e-mail]>
>> Cc: Acee Lindem (acee) <[e-mail]>; [e-mail]
>> Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
>> 
>> Hi Les,
>> 
>> It feels like your response is perhaps reading more into my suggestion than
>> was intended. I was in no way suggesting we go back and start combining TLV
>> registries, or that future registries needed to be combined unnecessarily.
>> 
>> I'm looking at this particular case where we have 2 copies of the same [sub-
>> ]sub-TLV registry that we will be creating as the document is written. The
>> OSPF definitions for the sub-TLV types are exactly the same as the IS-IS sub-
>> sub-TLVs ones. In fact option 2 keeps the containing [sub-]TLV separate and
>> only the [sub-]sub-TLV space is combined.
>> 
>> Isn't it better to define something once and refer to that single definition?
>> This is the motivation that led us to combining the documents in the first
>> place, and so I'm simply wondering if we can benefit more from this same
>> treatment.
>> 
>> Thanks,
>> Chris.
>> 
>> P.S WRT type field length of [sub-]sub-TLVs. We are *defining* the value
>> content, so of course we can do whatever we want and no documents about
>> other [sub-]TLV values, types or field lengths actually applies unless we wish
>> it to.
>> 
>> P.P.S. WRT scoping. The document defines an IS-IS sub-TLV which is scoped
>> to the IS-IS Router Capability TLV (242) and defines an OSPF TLV which is
>> scoped to the Router Information LSA. I think these are fairly analogous, or at
>> least can be treated as such for [sub-]sub-TLV definitions. In fact section 5.3
>> treats them as equal for defining their use. I don't put this above b/c it's not
>> something I want to distract from the general discussion and sharing the FAD
>> [sub-]TLV was only option 1 of a list.
>> 
>> 
>>> On May 18, 2018, at 11:41 AM, Les Ginsberg (ginsberg)
>> <[e-mail]> wrote:
>>> 
>>> (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 <[e-mail]> On Behalf Of Acee Lindem (acee)
>>>> Sent: Friday, May 18, 2018 7:29 AM
>>>> To: Christian Hopps <[e-mail]>
>>>> Cc: [e-mail]
>>>> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lsr
>