Hi Tony, Well I did not mean to fit the spec to LCD implementation. Only help the implementers not to forget about those ...
To your pessimism on disabling per mp-tlv flooding - I think it is obvious that operator will not disable it unless he is perfectly sure that what needs to be advertised in say TLV 22 sub-TLV 8 & 10 will fit 255 octets. That is the only reason/scenario I believe such knob makes sense to be used under. Anyway I think we are all clear now on the mutual perspectives. Thx, R. On Mon, Sep 9, 2024 at 11:18 PM Tony Przygienda <[email protected]> wrote: > 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]
