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 
Sent: Monday, May 21, 2018 10:08 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; 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) 
> 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 >
Sent: Monday, May 21, 2018 9:15 AM
To: Les Ginsberg (ginsberg) >
Cc: Acee Lindem (acee) >; 
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) 
> 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)  
> 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 
> Sent: Monday, May 21, 2018 9:15 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Acee Lindem (acee) ; 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)  > 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



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 
Sent: Monday, May 21, 2018 9:15 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; 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) 
> 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] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

[Acee Lindem (acee)]

The WG last call for the subject document has completed. There have been 
comments from Ketan Talauikar, Chris Hopps, and Tal Mizrahi (Routing 
Directorate Review). These have been addressed in the -11 and -12 versions and 
publication will be requested from the -12 version.

Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Thursday, April 5, 2018 at 8:49 PM
To: "lsr@ietf.org" 
Subject: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using 
OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

This begins an LSR WG last call for the subject draft. Please send your
comments to this list prior to 12:00 AM GMT, April 20th, 2018.

Thanks,
Acee and Chris

___
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 
Sent: Monday, May 21, 2018 5:44 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; 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) 
> 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