Peter,
> Once we get into FAD Sub-TLV overflow business, we would have to define, for
> each FAD sub-TLV, whether multiple of them can exist and how to resolve
> conflicts if only one is allowed. For all existing ones, I can only think of
> SRLG to be the candidate for multiple.
>
> I'm fine with adding extra complexity, but at least I would like to see some
> practical use case behind it.
We are defining a mechanism right now that we would like to have be functional
in perpetuity. We should not wait to redefine it when a P1 case comes in or
when we get a billion dollar RFP.
Right now, we have the following subsubTLVs in the FlexAlgo draft:
Exclude Admin Group Sub-TLV
Include-Any Admin Group Sub-TLV
Include-All Admin Group Sub-TLV
Flags Sub-TLV
Exclude SRLG Sub-TLV
We can and should expect more in the future. We cannot predict how many octets
the future subsubTLVs will hold.
Each of the Admin Group subsubTLVs can hold an extended admin group. There is
no hard bound to the number of bits
in the extended admin group and thus each subsubTLV could, theoretically, fill
the FAD subTLV. Obviously, the
combination of multiple ones could as well.
The flags subsubTLV is only one octet of contents today, but is also unbounded.
And the SRLG subsubTLV is, as noted, unbounded.
I submit that we are already in the overflow business, right now, and that not
specifying how to deal with overflow is an egregious
under-specification of the mechanism and a disservice to all of our
implementors.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
