Naiming - I think what Tom is referring to is this text from RFC 5029:
" This sub-TLV is OPTIONAL and MUST appear at most once for a single IS neighbor. If a received Link State Packet (LSP) contains more than one Link-Attribute Sub-TLV, an implementation SHOULD decide to consider only the first encountered instance." In the case of the Reverse Metric TLV, since it is only allowed in hellos, it would be easy to specify a similar behavior. The other alternative is to say when multiple such TLVs are received they are all ignored. I don't have a strong opinion either way - but I am inclined to the "ignore" strategy since if multiple TLVs are sent it seems clear that the receiver cannot tell what the sender intends. Given this is being used to modify the running config on the receiver, it seems more prudent NOT to do anything unless the instructions are unambiguous. Les > -----Original Message----- > From: Isis-wg [mailto:[email protected]] On Behalf Of Naiming Shen > (naiming) > Sent: Saturday, January 06, 2018 9:22 PM > To: t.petch <[email protected]> > Cc: Christian Hopps <[email protected]>; [email protected]; isis- > [email protected] > Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07 > > > Tom, > > Actually RFC 5029 does not mention anything about handling multiple same > link-attribute sub-TLV, it just says if a router does not support this > sub-TLV, it > will silently ignore the sub-TLV, and this is true for any IS-IS TLV or > sub-TLV. If > one does not understand, it has to ignore it. Spiting out an error or debug > message or not is up to the implementation. > > thanks. > - Naiming > > > On Jan 6, 2018, at 11:39 AM, Naiming Shen (naiming) <[email protected]> > wrote: > > > > > > Tom, > > > > Sure. We can add similar wording on that. > > > > thanks. > > - Naiming > > > >> On Jan 6, 2018, at 4:12 AM, t.petch <[email protected]> wrote: > >> > >> Naiming > >> > >> One follow-up comment inline > >> > >> Tom Petch > >> > >> ---- Original Message ----- > >> From: "Naiming Shen (naiming)" <[email protected]> > >> Sent: Saturday, January 06, 2018 12:31 AM > >> > >>> Hi Tom, > >>> > >>> Thanks for the review, some replies inline, > >>> > >>> On Dec 29, 2017, at 2:53 AM, t.petch > >> <[email protected]<mailto:[email protected]>> wrote: > >>> > >>> A couple of IANA thoughts on this I-D; > >>> > >>> "This document requests that IANA allocate from the IS-IS TLV > >>> Codepoints Registry a new TLV, " > >>> > >>> - Is there a particular range that this value should come from? > >>> > >>> NS> will add the range. > >>> > >>> > >>> - A note in s.2 asking that TBD be replaced by the value that IANA > >>> allocates might be useful for the RFC Editor. > >>> > >>> NS> will do. > >>> > >>> > >>> - Are the flag bits of this new TLV going to form a new registry? > >>> > >>> NS> it is not. > >>> > >>> > >>> - And a non-IANA thought - what does a receiver do if it receives > >>> more than one such TLV? > >>> > >>> NS> In section 2, it mentions "A sender MUST only transmit a single > >>> Reverse Metric TLV in a IS-IS Hello PDU.” > >> > >> I know it does, but I also know that we cannot rely on all > >> implementations being perfect:-) > >> > >> Look at some other RFC (e.g. RFC5029) and you will find an action > >> defined such as subsequent ones will be ignored, or perhaps that this > >> should be treated as a fatal error or .. I suggest something similar > >> here although have no strong views what the action should be. > >> > >> Tom Petch > >> > >>> "This document also request that IANA allocate from the > >>> link-attribute bit value for sub-TLV 19 of TLV 22." > >>> I struggled to parse this initially. > >>> > >>> Perhaps > >>> "This document also requests that IANA allocate a bit from the > >>> 'link-attribute bit values for sub-TLV 19 of TLV 22' registry. > >>> > >>> > >>> NS> OK. > >>> > >>> (That registry title is a bit of a mouthful compounded by the lack > >>> of Capitals in the title:-( > >>> > >>> The coupling between the request to IANA to allocate the bit and the > >>> actual definition in the body of the I-D is ... well, non-existent. > >> You > >>> should have a something about the octet with a TBD2 (not a second > >>> TBD) in section 3.6, a TBD2 in the IANA actions and a request that > >>> this be replaced by RFC Editor by the value that IANA allocates. > >>> > >>> > >>> NS> will do. > >>> > >>> thanks. > >>> - Naiming > >>> > >>> Yes, a reader can deduce all this but the lack of precision is how > >>> mistakes are made IMO. RFC5209 has the sort of detail that I would > >>> expect. > >>> > >>> Tom Petch > >>> > >>> ----- Original Message ----- > >>> From: "Naiming Shen (naiming)" > >> <[email protected]<mailto:[email protected]>> > >>> > >>> > >>> > >> > > > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
