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

[Acee Lindem (acee)]

Hi Chris, 

The registries we are adding for FAD sub-TLVs do, in fact, refer to protocol 
encodings. Conversely, the IGP Algorithm type refers to a specific type of IGP 
algorithm independent of the protocol. So they are not completely analogous. 
Are you suggesting that we define a registry for the FAD information type 
abstraction and then say the OSPF/IS-IS sub-tlv types correspond to the FAD 
information type registry? I think having separate registries, as we do for 
other TLV and sub-TLV types, is much cleaner. 

Thanks,
Acee 

On 5/21/18, 11:54 AM, "Christian Hopps"  wrote:

We aren't talking generically about TLV space here. When I raised the 
question I certainly intended it to be limited to times, as is the case here, 
where we are literally duplicating registries b/c they both refer to the same 
thing. I didn't realize that we'd already done this with SR IGP Algorithm 
registry.

I did also include talking about what (if anything) to do with the 
duplicated containing TLV, but it seems no one wants to go there, which is 
fine, and I happen to agree probably is going too far.

Thanks,
Chris.

> On May 21, 2018, at 11:11 AM, Acee Lindem (acee)  wrote:
> 
> Hi Peter, Chris,
> 
> In this particular case, it may be ok as long as we just limit the code 
point space to the 1 octet type (i.e., 0-255 with reserved values). However, 
for all the reasons Peter and Les have already articulated, there will be cases 
where the TLV or Sub-TLV registries cannot be common. So, I have to ask myself 
just what are we gaining by here? The encodings are not going to be identical 
(for all the previously mentioned reasons) and this leaves the door open for 
time wasted on revisiting this issue...
> 
> Thanks,
> Acee
> 
> On 5/20/18, 9:21 AM, "Peter Psenak (ppsenak)"  wrote:
> 
>Chris,
> 
>On 20/05/18 01:47 , Christian Hopps wrote:
>> How about an option 2c
>> 
>>   2c: Leave the encodings the way they are, and use a common registry to 
define the type/value semantics.
> 
>having a combined registry that defines FAD Sub-TLVs types is fine 
with me.
> 
>thanks,
>Peter
> 
> 
> 



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Chris –

To be “absolutely clear”, I object to the sharing of the “protocol type” field 
at any level.
We are not talking about “content”.

   Les


From: Christian Hopps <cho...@chopps.org>
Sent: Monday, May 21, 2018 10:08 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

Ok, so your position is that b/c the defined content takes the form of 
type-len-value the registry for it cannot be shared, but if, like IGP 
Algorithm, it had "just" been a collection of values sharing would be fine.

Peter was OK with sharing the registry. I am as well.

Let's let others chime in.

Thanks,
Chris.


On May 21, 2018, at 12:46 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:

Chris –

I think you are making this thread far more confusing than necessary.
Protocol code points include:

Top level TLV types
Sub-TLV types
Sub-sub-TLV types
Etc.

Obviously a sub-TLV is “contained” in a TLV
And a “sub-sub-TLV” is contained within a sub-TLV

This does not alter the fact that all of these type identifiers are protocol 
specific and are managed in protocol specific registries. There are many 
existing examples of this.

The values managed in the “IGP Algorithm” registry are not used as a “type” 
identifier at any level in the protocol. They are the values advertised within 
the “container” – whether that container is a TLV or a sub-TLV or…

If we cannot agree on this then we will never agree on anything.

“types” at any level are protocol specific and should be managed on protocol 
specific registries.

   Les



From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>
Sent: Monday, May 21, 2018 9:15 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs


On May 21, 2018, at 11:46 AM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:

I fail to see any difference from the IGP algorithm case, which you agreed with.


  SR Algorithm container:
- distributed as a TLV inside Router Information Opaque LSA
- distributed as a sub-TLV inside Router Capability TLV

  IGP Algorithm: The container content which is defined using a common registry.

[Les:] The SR Algorithm “container identifier” is NOT managed by the IGP 
Algorithm Registry. It is only the algorithm identifiers– which are advertised 
inside the protocol specific containers – which are managed by the shared 
registry.

Here, however, you are proposing to manage the identifier for the container 
(not its contents) in a shared registry. That I object to.

Unfortunately, you are incorrect here, I never made that proposal. I presented 
various options we might choose to share commonality, none of them had to do 
with sharing top-level code-points, all of them had to do strictly with the 
content of the FAD [sub-]TLV which is being entirely defined by the document in 
question.

 TLV/sub-TLV codepoints are a protocol property. That is why they are managed 
in protocol specific registries.
You are now proposing to take “some” protocol specific identifiers and manage 
them in a protocol independent registry. This is wrong.

I'm talking about the content of the FAD [sub-]TLV only, just like IGP 
Algorithm registry is defining the content for the SR Algorithm [sub-]TLV, they 
are completely analogous.




You think it makes sense to go to 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
to find all the IS-IS TLV/sub-TLV codepoints EXCEPT for a few which you want to 
put into a shared IS-IS/OSPF registry?

This is silly, perhaps not intended but it's very close to a straw man. I know 
I wrote in an early mail explicitly that my intent had nothing to do with back 
over anything, so no.

Thanks,
Chris.



I don’t.

   Les

Thanks,
Chris.

  Les

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

Ok, so your position is that b/c the defined content takes the form of 
type-len-value the registry for it cannot be shared, but if, like IGP 
Algorithm, it had "just" been a collection of values sharing would be fine.

Peter was OK with sharing the registry. I am as well.

Let's let others chime in.

Thanks,
Chris.

> On May 21, 2018, at 12:46 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> 
> wrote:
> 
> Chris –
> 
> I think you are making this thread far more confusing than necessary.
> Protocol code points include:
> 
> Top level TLV types
> Sub-TLV types
> Sub-sub-TLV types
> Etc.
> 
> Obviously a sub-TLV is “contained” in a TLV
> And a “sub-sub-TLV” is contained within a sub-TLV
> 
> This does not alter the fact that all of these type identifiers are protocol 
> specific and are managed in protocol specific registries. There are many 
> existing examples of this.
> 
> The values managed in the “IGP Algorithm” registry are not used as a “type” 
> identifier at any level in the protocol. They are the values advertised 
> within the “container” – whether that container is a TLV or a sub-TLV or…
> 
> If we cannot agree on this then we will never agree on anything.
> 
> “types” at any level are protocol specific and should be managed on protocol 
> specific registries.
> 
>Les
> 
> 
> 
> From: Christian Hopps <cho...@chopps.org>
> Sent: Monday, May 21, 2018 9:15 AM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
> Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
> 
> 
> On May 21, 2018, at 11:46 AM, Les Ginsberg (ginsberg) <ginsb...@cisco.com 
> <mailto:ginsb...@cisco.com>> wrote:
> 
> I fail to see any difference from the IGP algorithm case, which you agreed 
> with.
> 
> 
>   SR Algorithm container:
> - distributed as a TLV inside Router Information Opaque LSA
> - distributed as a sub-TLV inside Router Capability TLV
> 
>   IGP Algorithm: The container content which is defined using a common 
> registry.
> 
> [Les:] The SR Algorithm “container identifier” is NOT managed by the IGP 
> Algorithm Registry. It is only the algorithm identifiers– which are 
> advertised inside the protocol specific containers – which are managed by the 
> shared registry.
> 
> Here, however, you are proposing to manage the identifier for the container 
> (not its contents) in a shared registry. That I object to.
> 
> Unfortunately, you are incorrect here, I never made that proposal. I 
> presented various options we might choose to share commonality, none of them 
> had to do with sharing top-level code-points, all of them had to do strictly 
> with the content of the FAD [sub-]TLV which is being entirely defined by the 
> document in question.
> 
>  TLV/sub-TLV codepoints are a protocol property. That is why they are managed 
> in protocol specific registries.
> You are now proposing to take “some” protocol specific identifiers and manage 
> them in a protocol independent registry. This is wrong.
> 
> I'm talking about the content of the FAD [sub-]TLV only, just like IGP 
> Algorithm registry is defining the content for the SR Algorithm [sub-]TLV, 
> they are completely analogous.
> 
> 
> 
> You think it makes sense to go to 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
>  
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>
>  to find all the IS-IS TLV/sub-TLV codepoints EXCEPT for a few which you want 
> to put into a shared IS-IS/OSPF registry?
> 
> This is silly, perhaps not intended but it's very close to a straw man. I 
> know I wrote in an early mail explicitly that my intent had nothing to do 
> with back over anything, so no.
> 
> Thanks,
> Chris.
> 
> 
> I don’t.
> 
>Les
> 
> Thanks,
> Chris.
> 
>   Les



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Chris –

I think you are making this thread far more confusing than necessary.
Protocol code points include:

Top level TLV types
Sub-TLV types
Sub-sub-TLV types
Etc.

Obviously a sub-TLV is “contained” in a TLV
And a “sub-sub-TLV” is contained within a sub-TLV

This does not alter the fact that all of these type identifiers are protocol 
specific and are managed in protocol specific registries. There are many 
existing examples of this.

The values managed in the “IGP Algorithm” registry are not used as a “type” 
identifier at any level in the protocol. They are the values advertised within 
the “container” – whether that container is a TLV or a sub-TLV or…

If we cannot agree on this then we will never agree on anything.

“types” at any level are protocol specific and should be managed on protocol 
specific registries.

   Les



From: Christian Hopps <cho...@chopps.org>
Sent: Monday, May 21, 2018 9:15 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs


On May 21, 2018, at 11:46 AM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:

I fail to see any difference from the IGP algorithm case, which you agreed with.


  SR Algorithm container:
- distributed as a TLV inside Router Information Opaque LSA
- distributed as a sub-TLV inside Router Capability TLV

  IGP Algorithm: The container content which is defined using a common registry.

[Les:] The SR Algorithm “container identifier” is NOT managed by the IGP 
Algorithm Registry. It is only the algorithm identifiers– which are advertised 
inside the protocol specific containers – which are managed by the shared 
registry.

Here, however, you are proposing to manage the identifier for the container 
(not its contents) in a shared registry. That I object to.

Unfortunately, you are incorrect here, I never made that proposal. I presented 
various options we might choose to share commonality, none of them had to do 
with sharing top-level code-points, all of them had to do strictly with the 
content of the FAD [sub-]TLV which is being entirely defined by the document in 
question.

 TLV/sub-TLV codepoints are a protocol property. That is why they are managed 
in protocol specific registries.
You are now proposing to take “some” protocol specific identifiers and manage 
them in a protocol independent registry. This is wrong.

I'm talking about the content of the FAD [sub-]TLV only, just like IGP 
Algorithm registry is defining the content for the SR Algorithm [sub-]TLV, they 
are completely analogous.



You think it makes sense to go to 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
to find all the IS-IS TLV/sub-TLV codepoints EXCEPT for a few which you want to 
put into a shared IS-IS/OSPF registry?

This is silly, perhaps not intended but it's very close to a straw man. I know 
I wrote in an early mail explicitly that my intent had nothing to do with back 
over anything, so no.

Thanks,
Chris.


I don’t.

   Les

Thanks,
Chris.

  Les


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

We aren't talking generically about TLV space here. When I raised the question 
I certainly intended it to be limited to times, as is the case here, where we 
are literally duplicating registries b/c they both refer to the same thing. I 
didn't realize that we'd already done this with SR IGP Algorithm registry.

I did also include talking about what (if anything) to do with the duplicated 
containing TLV, but it seems no one wants to go there, which is fine, and I 
happen to agree probably is going too far.

Thanks,
Chris.

> On May 21, 2018, at 11:11 AM, Acee Lindem (acee)  wrote:
> 
> Hi Peter, Chris,
> 
> In this particular case, it may be ok as long as we just limit the code point 
> space to the 1 octet type (i.e., 0-255 with reserved values). However, for 
> all the reasons Peter and Les have already articulated, there will be cases 
> where the TLV or Sub-TLV registries cannot be common. So, I have to ask 
> myself just what are we gaining by here? The encodings are not going to be 
> identical (for all the previously mentioned reasons) and this leaves the door 
> open for time wasted on revisiting this issue...
> 
> Thanks,
> Acee
> 
> On 5/20/18, 9:21 AM, "Peter Psenak (ppsenak)"  wrote:
> 
>Chris,
> 
>On 20/05/18 01:47 , Christian Hopps wrote:
>> How about an option 2c
>> 
>>   2c: Leave the encodings the way they are, and use a common registry to 
>> define the type/value semantics.
> 
>having a combined registry that defines FAD Sub-TLVs types is fine with me.
> 
>thanks,
>Peter
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Chris -

From: Christian Hopps <cho...@chopps.org>
Sent: Monday, May 21, 2018 5:44 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

On May 20, 2018, at 12:33 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:

Chris-

I am happy to see that the scope of this discussion is narrowing. I think the 
scope of what your proposing is much more appropriate for discussion - but we 
are in still not in agreement.

This has never changed for me, so I'm glad that we are understanding each other 
better. :)


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.
[Les:] There is a qualitative difference between having a common registry to 
identify a protocol independent attribute and having a common registry to 
define a protocol scoped type value.

I appreciate that in this case we are defining a new container (FAD) which will 
have sub-containers that are applicable to both protocols. And I agree that it 
seems very hard to imagine any future sub-container which would not be 
applicable to both protocols. And I also agree that assigning the same type 
value to each sub-TLV for both protocols (now and in the future) is practical - 
and perhaps even desirable.

Great. BTW, nice renaming to "container" here.


Nevertheless, the "type" which identifies the sub-container is a protocol 
scoped attribute.  The fact that we could use a common number in this case does 
not mean it is conceptually correct to consider the value as protocol 
independent.

Let's please keep the definitions in registries which have the correct scope - 
which in the case of TLV/sub-TLV types is per/protocol.

I fail to see any difference from the IGP algorithm case, which you agreed with.


  SR Algorithm container:
- distributed as a TLV inside Router Information Opaque LSA
- distributed as a sub-TLV inside Router Capability TLV

  IGP Algorithm: The container content which is defined using a common registry.

[Les:] The SR Algorithm "container identifier" is NOT managed by the IGP 
Algorithm Registry. It is only the algorithm identifiers- which are advertised 
inside the protocol specific containers - which are managed by the shared 
registry.

Here, however, you are proposing to manage the identifier for the container 
(not its contents) in a shared registry. That I object to.

TLV/sub-TLV codepoints are a protocol property. That is why they are managed in 
protocol specific registries.
You are now proposing to take "some" protocol specific identifiers and manage 
them in a protocol independent registry. This is wrong.

You think it makes sense to go to 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
to find all the IS-IS TLV/sub-TLV codepoints EXCEPT for a few which you want to 
put into a shared IS-IS/OSPF registry?
I don't.

   Les

Thanks,
Chris.

  Les

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Peter, Chris, 

In this particular case, it may be ok as long as we just limit the code point 
space to the 1 octet type (i.e., 0-255 with reserved values). However, for all 
the reasons Peter and Les have already articulated, there will be cases where 
the TLV or Sub-TLV registries cannot be common. So, I have to ask myself just 
what are we gaining by here? The encodings are not going to be identical (for 
all the previously mentioned reasons) and this leaves the door open for time 
wasted on revisiting this issue... 

Thanks,
Acee

On 5/20/18, 9:21 AM, "Peter Psenak (ppsenak)"  wrote:

Chris,

On 20/05/18 01:47 , Christian Hopps wrote:
> How about an option 2c
>
>2c: Leave the encodings the way they are, and use a common registry to 
define the type/value semantics.

having a combined registry that defines FAD Sub-TLVs types is fine with me.

thanks,
Peter



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Chris-

I am happy to see that the scope of this discussion is narrowing. I think the 
scope of what your proposing is much more appropriate for discussion - but we 
are in still not in agreement.
Please see inline.

> -Original Message-
> From: Christian Hopps <cho...@chopps.org>
> Sent: Saturday, May 19, 2018 4:48 PM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
> Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
> 
> 
> 
> > On May 19, 2018, at 12:27 PM, Les Ginsberg (ginsberg)
> <ginsb...@cisco.com> 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.
> 
[Les:] There is a qualitative difference between having a common registry to 
identify a protocol independent attribute and having a common registry to 
define a protocol scoped type value.

I appreciate that in this case we are defining a new container (FAD) which will 
have sub-containers that are applicable to both protocols. And I agree that it 
seems very hard to imagine any future sub-container which would not be 
applicable to both protocols. And I also agree that assigning the same type 
value to each sub-TLV for both protocols (now and in the future) is practical - 
and perhaps even desirable.

Nevertheless, the "type" which identifies the sub-container is a protocol 
scoped attribute.  The fact that we could use a common number in this case does 
not mean it is conceptually correct to consider the value as protocol 
independent.

Let's please keep the definitions in registries which have the correct scope - 
which in the case of TLV/sub-TLV types is per/protocol.

   Les



> 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,
&

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

[Christian Hopps]

> On May 19, 2018, at 12:27 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> 
> 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 <cho...@chopps.org>
>> Sent: Saturday, May 19, 2018 6:15 AM
>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
>> Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
>> 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

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

[Les Ginsberg (ginsberg)]

Chris -

Let's go back to the beginning of this thread - where you proposed:


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



1b/2a - I think there is absolutely no motivation for OSPF to use an 8 bit type 
- ever.
1a/2b - For IS-IS, this introduces a requirement to alter the parsing of a TLV 
(or sub-TLV) based on the type i.e., sometimes type will be 8 bits and 
sometimes it will be 16 bits.
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 would also point out that RFC 7356 - which does introduce 16 bit type/length 
TLVs for IS-IS - does so on a per PDU type basis i.e., in a given PDU ALL 
TLVs/sub-TLVs are either 8 bit type/length or 16 bit type/length. We did this 
precisely because we wanted to avoid logic which required altering the parsing 
on a per TLV type basis.

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.

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.

   Les


> -Original Message-
> From: Christian Hopps <cho...@chopps.org>
> Sent: Saturday, May 19, 2018 6:15 AM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Cc: Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
> 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)
> <ginsb...@cisco.com> 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-backwa

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

[Christian Hopps]

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)  
> 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  On Behalf Of Acee Lindem (acee)
>> Sent: Friday, May 18, 2018 7:29 AM
>> To: Christian Hopps 
>> 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  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 

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

[Peter Psenak]

Hi Chris, Acee,

On 18/05/18 17:45 , Acee Lindem (acee) wrote:




On May 18, 2018, at 11:20 AM, Christian Hopps  wrote:

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. :)


I think this can be accomplished without a single IANA registry. It is all a 
matter of how the draft is written.


I'm all for making it better, but we should not overdo it.

ISIS and OSPF TLVs are never really the same due to basic TLV header 
difference. OSPF TLVs are always padded to 4-octet alignment, while ISIS 
ones are not. Having a common definition for both given these 
differences would be messy IMHO.


thanks,
Peter






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.


I don’t think 2b is an option since it increases the IS-IS type/length size. 2a 
would be viable but by the time you documented all the constraints and what 
OSPF should do if they weren’t followed, you’d have negated any benefit.

If the WG really wants protocol convergence, everyone should move to OSPFv3 
since it has all the advantages of both protocols. ;^)

Thanks,
Acee




Thanks,
Chris.


On May 18, 2018, at 10:29 AM, Acee Lindem (acee)  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  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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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