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]
