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 yet or not. 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. >> What if the FAD use SRLGs? Each of these SRLGs are big (4 octets) in size >> and will consume significant subTLV space resources and many of those may >> overrun the size of the FAD. So if we have a theoretical network with a >> theoretical use-case that wants to exclude, lets say 64, SRLGs, then how >> would that fit into a single FAD for a single algorithm? > > you would not be able to do that. Realistically, it looks like an academical > problem to me. Actually, what’s academic is your objection. Implementations are going to handle overflows and they will do it by generating multiple sub-TLVs. The problem is not going to go away just because you deny that it exists. >> 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 don't believe draft-pkaneria-lsr-multi-tlv should go into business of > specifying the restriction of any particular Sub-TLVs. These restrictions are > specific to Sub-TLV itself and should be covered by the specification that > defines the Sub-TLV. Except that many things didn’t define how they can and should be extended. Admittedly, that’s a bug in those specifications that we’re attempting to address. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
