Robert, sigh, the specs, especially on ISIS cannot be written to the lowest common denominator implementation out there.
And otherwise I can only TonyL last email +1 and refer to 1925 #4 while outlining mildy the reality of things. the whole "disable per mp-tlv" is valid and yang/vendor knob territory though frankly speaking I doubt it's of as much value as folks here think. Running out of TLV space and just getting an "alarm" that 255 got blown and flooding of further info is suppressed may lead to good amount of topology going of a sudden to hell in a handbasket in the middle of a night (and we are already dancing on this edge in practical deployments with limits 255 * 255 sometimes more often than I would like frankly ) so I assume to avoid that risk the deployments will basically "switch mp-tlv on" and let warn on 255 blowout when mp-tlvs are generated and flooded. And yes, the folks deploying it will come down hard on those evil, evil vendors to pack decently so it's not non-chalanty done for fun and this is BTW already the case today due to other reasons and that's another good reason for the SHOULD. -- tony On Mon, Sep 9, 2024 at 11:04 PM Robert Raszuk <[email protected]> wrote: > Hi Tony, > >> The section 5 says: >> >> Although MP-TLVs SHOULD NOT be sent unless the >> capacity of a single TLV (255 octets) is exceeded, receivers MUST NOT >> reject MP-TLVs if senders do not strictly adhere to this constraint. >> See Section 7.3 for guidance when sending MP-TLVs. >> >> If you replace "SHOULD NOT" above with "MUST NOT" perhaps the request for >> MUST to be able to disable MP-TLV (on a per TLV basis) would make a bit of >> a weaker case. >> >> >> Do you agree that receivers MUST NOT reject MP-TLVs if the senders do not >> strictly adhere to maximum packing? If you do agree, then why does it >> matter? There may be good reasons for not doing maximum packing, such as >> optimal LSP packing. A little lattitude here would be a good thing. >> >> Again, Postel’s law. >> > > Indeed - receivers should accept and process chunks of data from multiple > TLVs. No question. > > But the case I am worried about is introduction of a new vendor to the > network (may be to the cluster) where there is no support for some new > MP-TLVs. If I know I never need to flood more then 250 octets I may be safe > to peer it with Junos or Cisco TORs or Spines. > > But if those two can inject something into MP-TLVs just because it is > convenient for them and I have no knob to stop them to do that I am locked > to two vendors :) > > Cool for the vendors ... less cool for the operator. > > Cheers, > R. > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
