Les,
> On Oct 6, 2022, at 7:22 PM, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > Chris - > > Not trying to convince you of anything - just want to step back and summarize > where we are. > > MP-TLV support has been explicitly allowed in multiple cases - and in these > cases no additional signaling has been specified i.e., all TLVs in the "set" > are encoded the same way they would be if the there were only 1 TLV in the > set and there is no signaling of MP-TLV support required in order to send > MP-TLVs. > > Due to new features/increased scale, we now have a need to send MP-TLVs for > some additional TLVs (notably Prefix Reachability and Neighbor TLVs). The > RFCs defining these TLVs did not explicitly specify the use of MP-TLVs - but > they also did not specify any prohibition against doing so. > > Some implementations have chosen to apply the same MP-TLV model used for the > "explicit-MP-TLV allowed" cases to these new cases. > > Two possible protocol changes for these new cases have been suggested in this > thread: > > 1)Require some additional encoding in the MP-TLVs to identify the TLV as a > member of an MP-TLV set > > This would mean that the encoding of MP-TLVs would be different depending on > the TLV type. > I see no justification for this. > > 2)Prohibit the sending of MP-TLVs unless all nodes advertise support > > Even though the encoding used by these early implementations is correct, they > would then be penalized and declared illegal because they did not come to the > WG and "ask for permission". > I find this approach at best very petty. > > I share the concern about how a network might behave when not all nodes > support MP-TLVs for a given TLV, but this is best handled by having an > implementation knob to disable the sending of MP-TLVs - thus giving the > operator control. > Your summarization is incorrect. The proposal is to advertise a advisory message that indicates that a node is ready to receive MP-TLVs. It prohibits nothing. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
