Tony,
On 04/03/2022 18:30, Tony Li wrote:
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.
the single Admin Group sub-TLV allows you to advertise almost 2k groups.
Let's be realistic, how much more do we need?
Obviously, the combination of multiple ones could as well.
the combination is the (a) problem and that will be fixed. We are
talking problem (b) only now.
The flags subsubTLV is only one octet of contents today, but is also unbounded.
same as with admin groups, we have more then enough flags in a single
sub-TLV.
And the SRLG subsubTLV is, as noted, unbounded.
yes, but it's a theoretical problem IMHO.
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.
I'm not trying under-specify how to deal with overflow - we need to
specify it, no disagreement there.
What I'm trying to see of we need to support the "merge" at FAD sub-TLV
level.
thanks,
Peter
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
