Hi Chris, Acee,
On 18/05/18 17:45 , Acee Lindem (acee) wrote:
On May 18, 2018, at 11:20 AM, Christian Hopps <cho...@chopps.org> 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) <a...@cisco.com> 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 <cho...@chopps.org> Thu, 17 May 2018 21:07 UTC
So in looking at the IANA requests inside the newly merged flex algorithm draft
I noticed that the document is creating 2 separate Flex Algorithm Definition
sub-tlvs Registries for IS-IS and OSPF with the initial content described in
sections:
6.1. ISIS Flexible Algorithm Exclude Admin Group Sub-TLV
6.2. ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV
6.3. ISIS Flexible Algorithm Include-All Admin Group Sub-TLV
7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV
7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV
7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV
They are basically the same thing (indeed the later OSPF sections refer back to
the IS-IS sections), except for one detail AFAICT, the size of the type and
length fields.
I think we may have some options here to make this a bit more elegant.
1. Share the same sub-TLV structure
a. using the OSPF sub-tlv structure (16 bit type and 16 bit len) for both
protocols
b. using the IS-IS sub-tlv structure (8 bit type and 8 bit len) for both
protocols
2. Use different structure with the same type field size of the
a. more constrained IS-IS 8 bit size
b. less constrained OSPF 16 bit size
3. Define and use some generic method to define shared TLVs like this where the
only actual difference is the size of the type and length fields.
1, Creates a clean and simple standard, 1 TLV definition and 1 sub-TLV registry.
1a, has the property that the length value in IS-IS can't normally exceed an 8
bit value; however, sub-TLV length values are already constrained beyond the
field size as sub-TLVs may appear anywhere in the TLV.
1b, restricts both protocols to 256 types, and perhaps more importantly
restricts the sub-TLV length to 257 octets. This is handled all the time in
IS-IS using repeated TLVs, but not so much (ever?) in OSPF.
2. Allows us to at least create a single IANA registry for the sub-tlv types so
we aren't duplicating them and their definitions for each protocol.
3. Is interesting but probably requires some work outside of this document.
This document is serving as our guinea pig for how to merge work so I think
it's worth spending some effort on these types of details.
Thanks,
Chris.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
