Les, Ok, will ‘ignore’:-) thanks.
- Naiming > On Jan 7, 2018, at 6:54 AM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > 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
