Robert,
> If FlexAlgo is adopted, then we should expect that it will get stressed and
> that further conditions will be added to a FAD. The problem will only become
> worse the more success that FlexAlgo has. It sounds to me like you want
> FlexAlgo to fail, which seems strange.
>
> Well I
Hi Tony,
> If FlexAlgo is adopted, then we should expect that it will get stressed
> and that further conditions will be added to a FAD. The problem will only
> become worse the more success that FlexAlgo has. It sounds to me like you
> want FlexAlgo to fail, which seems strange.
Well I have a
Gunter -
In regards to:
> Anyway, my point was that draft-pkaneria-lsr-multi-tlv may benefit to call-
> out subTLVs that by normative reference can only exist one time, in one
> place, like for example the flex-algo FAD.
>
I believe this is out of scope for draft-pkaneria-lsr-multi-tlv.
As
Hi Peter,
>> I believe that your assumption is that the FAD for a single algorithm can
>> never grow bigger as a 256 octets.
>
> yes, that is indeed a limitation.
Perhaps we should address it somehow? Coders have to deal with overflow
conditions on day one, whether people are hitting them
Hi Gunter,
> Is draft-pkaneria-lsr-multi-tlv intending to look TLVs that are explicitly
> restricted to only a single entry?
Usually, if a TLV has been defined to only have a single entry, it’s for a good
reason. We are not intending to override an author’s explicit and sensible
Gunter,
On 02/03/2022 10:02, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
My point to Tony was that there may be subTLVs out there that normative
prescribe a restriction that only a single occurrence may exist. For flex-algo
that is exactly one FAD for each algorithm.
Coming back to
My point to Tony was that there may be subTLVs out there that normative
prescribe a restriction that only a single occurrence may exist. For flex-algo
that is exactly one FAD for each algorithm.
Coming back to flex-algo FAD. It is indeed easy to mix things up sometimes,
however this time maybe
