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

Re: [Lsr] Early Allocation Request for "IGP Flexible Algorithm"

[Acee Lindem (acee)]

Hi Alvaro,

From: Alvaro Retana 
Date: Friday, May 18, 2018 at 11:19 AM
To: Acee Lindem , IANA 
Cc: "lsr@ietf.org" 
Subject: Re: Early Allocation Request for "IGP Flexible Algorithm"

Hi!

This request is fine with me.

Acee:  yes, according to rfc7120, the AD has to approve early allocation 
requests for “IETF Review” registries.

Right – and the OSPF RI LSA TLV Registry “IETF Review” even if the IS-IS 
registries are not.

Thanks,
Acee


Alvaro.


On May 17, 2018 at 4:15:48 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
The authors of the subject document have requested early assignment for the 
subject draft - https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

The draft is now a working document and we believe the early allocations should 
be made to facilitate implementation.

Alvaro – do you need to approve the assignment in the OSPF RI LSA TLV registry 
since the assignment policy is “IETF Review”?

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

Re: [Lsr] Early Allocation Request for "IGP Flexible Algorithm"

[Alvaro Retana]

Hi!

This request is fine with me.

Acee:  yes, according to rfc7120, the AD has to approve early allocation
requests for “IETF Review” registries.

Alvaro.


On May 17, 2018 at 4:15:48 PM, Acee Lindem (acee) (a...@cisco.com) wrote:

The authors of the subject document have requested early assignment for the
subject draft - https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



The draft is now a working document and we believe the early allocations
should be made to facilitate implementation.



Alvaro – do you need to approve the assignment in the OSPF RI LSA TLV
registry since the assignment policy is “IETF Review”?



Thanks,

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

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

[Acee Lindem (acee)]

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