John - Thanx for the thoughtful suggestions. I like your last suggestion i.e., simply removing the phrase
"which contains the IPv4 Router ID of the router who generates the inter-AS reachability TLV" Hope that works for everyone. Les > -----Original Message----- > From: John Scudder <[email protected]> > Sent: Wednesday, September 21, 2022 7:44 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: t petch <[email protected]>; Eric Vyncke (evyncke) > <[email protected]>; The IESG <[email protected]>; draft-ietf-lsr-isis- > [email protected]; [email protected]; lsr <[email protected]>; > [email protected]; [email protected] > Subject: Re: [Lsr] [Teas] Éric Vyncke's No Objection on draft-ietf-lsr-isis- > rfc5316bis-04: (with COMMENT) > > Les, > > If I read Tom’s last comment correctly, the entire substance of the change > he’s suggesting is: > > OLD > which contains the IPv4 Router ID of the router which > NEW > which identifies the router which > > That seems reasonable to me considering that as Tom explains, the “IPv4 > Router ID” is *not a thing that exists*. The “TE Router ID” exists, and you > make the case that it should probably have been named the “IPv4 TE Router > ID", but that isn’t what the text in question is referring to. Why would you > *not* want to make this change, which seems to be both accurate and > harmless? > > Based only on the text shown in the OLD/NEW one might also suppose you > could correct it to “NEW: which contains the Traffic Engineering Router ID of > the router which”. But taken in context of the overall paragraph, that doesn’t > work: > > The Router ID field of the inter-AS reachability TLV is 4 octets in > length, which contains the IPv4 Router ID of the router who generates > the inter-AS reachability TLV. The Router ID SHOULD be identical to > the value advertised in the Traffic Engineering Router ID TLV > [RFC5305]. If no Traffic Engineering Router ID is assigned, the > > The sentence after the one in question says it SHOULD be identical to the… > TE Router ID. Which is the exception that proves the rule (that your text > “IPv4 Router ID” must not be referring directly to the TE Router ID). > > Another fix could be to simply remove the clause in question, as in > > The Router ID field of the inter-AS reachability TLV is 4 octets in > length. The Router ID SHOULD be identical to > the value advertised in the Traffic Engineering Router ID TLV > [RFC5305]. If no Traffic Engineering Router ID is assigned, the > > Thanks, > > —John > > > On Sep 21, 2022, at 9:49 AM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > > > > Tom - > > > > > -----Original Message----- > > > From: t petch <[email protected]> > > > Sent: Wednesday, September 21, 2022 3:45 AM > > > To: Les Ginsberg (ginsberg) <[email protected]>; John Scudder > > > <[email protected]> > > > Cc: Eric Vyncke (evyncke) <[email protected]>; The IESG > <[email protected]>; > > > [email protected]; [email protected]; lsr > <[email protected]>; > > > [email protected]; [email protected] > > > Subject: Re: [Lsr] [Teas] Éric Vyncke's No Objection on > > > draft-ietf-lsr-isis- > > > rfc5316bis-04: (with COMMENT) > > > > > > On 21/09/2022 05:16, Les Ginsberg (ginsberg) wrote: > > > > Top posting here - and my response applies to the discussion between > Eric, > > > John, and Tom regarding Section 3.1 (and also to Alvaro - though I will > reply > > > directly to Alvaro's email as he has some specific questions not covered > > > in > the > > > discussion below...) > > > > > > > > The text in Section 3.1 is currently: > > > > > > > > " The Router ID field of the inter-AS reachability TLV is 4 octets in > > > > length, > > > which contains the IPv4 Router ID of the router who generates the inter- > AS > > > reachability TLV. The Router ID SHOULD be identical to the value > advertised > > > in the Traffic Engineering Router ID TLV [RFC5305]. If no Traffic > Engineering > > > Router ID is assigned, the Router ID SHOULD be identical to an IP > Interface > > > Address [RFC1195] advertised by the originating IS. If the originating > > > node > > > does not support IPv4, then the reserved value 0.0.0.0 MUST be used in > the > > > Router ID field and the IPv6 Router ID sub-TLV MUST be present in the > inter- > > > AS reachability TLV. The Router ID could be used to indicate the source of > the > > > inter-AS reachability TLV." > > > > > > > > > > > > Tom suggests this should be modified to state: > > > > > > > > "> If a Traffic Engineering Router ID TLV > > > >> [RFC5305] is available for the router which generates > > > >> the inter-AS reachability TLV, then that value MUST be used. > > > > > > > > I am reluctant to do this. The use of MUST suggests that receivers > should > > > do a check to see if the router referred to in the Router ID field > > > actually > > > advertised a TE Router ID (TLV 134) and if it did and the value in the > > > inter- > AS > > > reachability TLV is non-zero and does not match the value advertised in > TLV > > > 134 then the receiver is obligated to reject the inter-AS Reachability TLV > as > > > "invalid". This is unnecessarily strict and onerous. > > > > > > > > If a node advertises TLV 134 then that value SHOULD be used in the > inter- > > > AS reachability TLV. But if an implementation were to choose to use a > value > > > advertised in an IPv4 Address TLV by the same node no harm would be > done. > > > So I believe the existing text is more appropriate. > > > > Note that I am not suggesting that the router ID be ignored (the use of > > > SHOULD is a strong statement against doing that) but forbidding the use > of > > > an IPv4 address advertisement goes beyond what is needed here IMO. > > > > > > > > Therefore, I prefer to leave this text unchanged. > > > > Is this acceptable? > > > > > > Les > > > > > > I think not. You focus on 'MUST' v 'SHOULD' (with hindsight that change > > > was a mistake) and prefer the latter and I am ok with that. > > > > > > The original IESG comments were about 'IPv4 Router ID' and I think that > > > that still needs addressing, which my formulation did. I see no such > > > concept as 'IPv4 Router ID' anywhere in the IETF AFACT and think that > > > the use of the term in an LSR document will reinforce a common > > > misconception, that the 32 bit router ID, as used e.g. in OSPFv3, is > > > something to do with IPv4, which it is not. It is 32 bits, that is all. > > > > > > Another way of putting it is > > > OLD > > > which contains the IPv4 Router ID of the router which > > > NEW > > > which identifies the router which > > > > > [LES:] I did not comment on the different meaning of Router ID in OSPF vs > IS-IS because I thought that had been sorted out in the email thread already. > > This is an IS-IS document. We need not be concerned with what router id > means in OSPF. > > > > If you look at https://www.iana.org/assignments/isis-tlv-codepoints/isis- > tlv-codepoints.xhtml#tlv-codepoints you will see: > > > > 134 Traffic Engineering router ID > > ... > > 140 IPv6 TE Router ID > > > > It could be argued that a better name for TLV 134 would have been "IPv4 > Traffic Engineering Router ID" - but that isn’t within the purview of RFC > 5316. > > > > The current text says (emphasis added): > > > > “The Router ID field of the inter-AS reachability TLV is 4 octets in length, > which contains the IPv4 Router ID of the router who generates the inter-AS > reachability TLV. The Router ID SHOULD be identical to the value advertised > in the Traffic Engineering Router ID TLV [RFC5305].” > > > > I really do not see what is unclear about this. > > You seem to be objecting to the use of the term “IPv4 Router ID” – but > given that RFC 5316bis necessarily has to talk about both an IPv4 Router ID > and an IPv6 Router ID I think this usage is necessary to avoid ambiguity. > > ?? > > > > Les > > > > > I think that the following three sentences about where the value comes > > > from - TLV, IPv4 address or 0.0.0.0 - still make perfect sense with that > > > change. > > > > > > Tom Petch > > > > > > > > > > > > > > > > > Les > > > > > > > >> -----Original Message----- > > > >> From: Lsr <[email protected]> On Behalf Of t petch > > > >> Sent: Friday, September 16, 2022 9:37 AM > > > >> To: John Scudder <[email protected]> > > > >> Cc: Eric Vyncke (evyncke) <[email protected]>; The IESG > > > <[email protected]>; > > > >> [email protected]; [email protected]; lsr > > > <[email protected]>; > > > >> [email protected]; [email protected] > > > >> Subject: Re: [Lsr] [Teas] Éric Vyncke's No Objection on draft-ietf-lsr- > isis- > > > >> rfc5316bis-04: (with COMMENT) > > > >> > > > >> On 16/09/2022 17:24, John Scudder wrote: > > > >>> Hi Tom, > > > >>> > > > >>> Thanks for your comments! > > > >>> > > > >>>> On Sep 16, 2022, at 11:56 AM, t petch <[email protected]> > wrote: > > > >>>> > > > >>>> On 16/09/2022 14:13, John Scudder wrote: > > > >>>>> Hi Éric, > > > >>>>> > > > >>>>> A few comments below. > > > >>>>> > > > >>>>>> On Sep 16, 2022, at 4:27 AM, Éric Vyncke via Datatracker > > > >> <[email protected]> wrote: > > > >>>>>> > > > >>>>>> ## COMMENTS > > > >>>>>> > > > >>>>>> ### Section 3.1 > > > >>>>>> > > > >>>>>> ``` > > > >>>>>> The Router ID field of the inter-AS reachability TLV is 4 > > > >>>>>> octets in > > > >>>>>> length, which contains the IPv4 Router ID of the router who > > > >> generates > > > >>>>>> the inter-AS reachability TLV. The Router ID SHOULD be > identical > > > to > > > >>>>>> the value advertised in the Traffic Engineering Router ID TLV > > > >>>>>> [RFC5305]. If no Traffic Engineering Router ID is assigned, > > > >>>>>> the > > > >>>>>> Router ID SHOULD be identical to an IP Interface Address > > > [RFC1195] > > > >>>>>> advertised by the originating IS. > > > >>>>>> ``` > > > >>>>>> > > > >>>>>> AFAIK, the router ID is 'just' a 32-bit value that it is protocol > version > > > >>>>>> agnostic. So, s/IPv4 Router ID/Router ID/ ? > > > >>>>>> > > > >>>>>> Suggest: s/IP Interface Address [RFC1195]/IPv4 Interface > Address > > > >> [RFC1195]/ ? > > > >>>>> > > > >>>>> I wondered about this too when I was reviewing the document, > and > > > >> indeed RFC 5305 just calls the TE Router ID a 4-octet value. But then > RFC > > > 6119 > > > >> says, > > > >>>>> > > > >>>>> The TE Router ID TLV contains a stable IPv4 address that is > routable, > > > >>>>> regardless of the state of each interface. > > > >>>>> > > > >>>>> Similarly, for IPv6, it is useful to have a stable IPv6 address > > > >>>>> identifying a TE node. The IPv6 TE Router ID TLV is defined in > > > >>>>> Section 4.1. > > > >>>>> > > > >>>>> So even though it was after the fact, I suppose calling the former > the > > > >> “IPv4 Router ID” makes sense and just codifies what is apparently > already > > > the > > > >> practice. The existence of the IPv6 TE Router ID, so named, is “the > > > exception > > > >> that proves the rule”. > > > >>>> > > > >>>> Well, not really. > > > >>>> > > > >>>> The router id is 32 bits with no semantics, often displayed as dotted > > > >>>> quad. It is used in a number of protocols, in both IPv4 and IPv6, as > in > > > >>>> OSPFv3. A YANG type for it is defined in routing-types (RFC8294) > and > > > >>>> you will find it in such as draft-ietf-opsawg-l2nm. It has nothing > > > >>>> to > > > >>>> do with IP of any version and so cannot be relied on for the transfer > of > > > >>>> packets. (I see it used to add semantics about a router, such as > OSPF > > > >>>> Area, although others conflate it with an IPv4 loopback address). > > > >>>> > > > >>>> TE needed a routable address and so created Traffic Engineering > > > >>>> Router-ID, one for IPv4 and a different one for IPv6. Try > > > >>>> draft-ietf-ospf-yang s.2.4 for usage and references. The > terminology is > > > >>>> not that of the original TE RFC (RFC3630) but I find the ospf-yang > > > >>>> terminology clear and used elsewhere. This I-D under review is a > > > >>>> product of the LSR WG and I would have hoped that a draft-ietf-lsr > > > would > > > >>>> get this distinction between the router-id, with no semantics, and > the > > > >>>> TE router ID, IPv4 or IPv6, right:-( > > > >>>> > > > >>>> Tom Petch > > > >>> > > > >>> Actually now that you have sent me back to look again, I’m second- > > > >> guessing myself. The text in question is from Section 3.1, which is > about > > > the > > > >> Inter-AS Reachability TLV, and NOT the TE Router ID. So, the analysis I > > > >> provided above doesn’t seem to be applicable. Looking at what RFC > 5316 > > > >> said, it’s > > > >>> > > > >>> The Router ID field of the inter-AS reachability TLV is 4 octets > > > >>> in > > > >>> length, which contains the Router ID of the router who generates > the > > > >>> inter-AS reachability TLV. > > > >>> > > > >>> The term “Router ID” is used as though it were an agreed term of art > in > > > IS- > > > >> IS, but it’s not, to my knowledge. This is probably the root of the > problem: > > > IS- > > > >> IS has a System Identifier or System-ID, which is notionally 1-8 bytes > > > variable > > > >> but AFAIK is generally (always?) 6 bytes. So it seems as though RFC > 5316 > > > >> could have been clearer in that regard, but quite probably did mean > what > > > >> you say above. > > > >>> > > > >>> So, I take it back, I think you and Éric are right, strictly speaking. > > > >> Unfortunately it doesn’t look like simply removing the adjective “IPv4” > will > > > be > > > >> sufficient, though. Let’s look at the whole paragraph in RFC 5316: > > > >>> > > > >>> The Router ID field of the inter-AS reachability TLV is 4 octets > > > >>> in > > > >>> length, which contains the Router ID of the router who generates > the > > > >>> inter-AS reachability TLV. The Router ID MUST be unique within > the > > > >>> ISIS area. If the router generates inter-AS reachability TLV > > > >>> with > > > >>> entire ISIS routing domain flooding scope, then the Router ID > MUST > > > >>> also be unique within the entire ISIS routing domain. The Router > ID > > > >>> could be used to indicate the source of the inter-AS reachability > > > >>> TLV. > > > >>> > > > >>> Now let’s look at the replacement paragraph: > > > >>> > > > >>> The Router ID field of the inter-AS reachability TLV is 4 octets > > > >>> in > > > >>> length, which contains the IPv4 Router ID of the router who > generates > > > >>> the inter-AS reachability TLV. The Router ID SHOULD be identical > to > > > >>> the value advertised in the Traffic Engineering Router ID TLV > > > >>> [RFC5305]. If no Traffic Engineering Router ID is assigned, the > > > >>> Router ID SHOULD be identical to an IP Interface Address > [RFC1195] > > > >>> advertised by the originating IS. If the originating node does > > > >>> not > > > >>> support IPv4, then the reserved value 0.0.0.0 MUST be used in the > > > >>> Router ID field and the IPv6 Router ID sub-TLV MUST be present in > the > > > >>> inter-AS reachability TLV. The Router ID could be used to > > > >>> indicate > > > >>> the source of the inter-AS reachability TLV. > > > >>> > > > >>> Even if you took “IPv4” out as a qualifier of "Router ID”, the > remainder of > > > >> the paragraph goes into some detail about harvesting bits to put in > that > > > field > > > >> from an IPv4 interface. It generally seems like sensible advice, but > > > >> it’s > > > >> blatantly IPv4-specific. If we don’t like “IPv4” qualifying “Router > > > >> ID”, is > > > there > > > >> some further consideration needed for the rest of the paragraph? By > the > > > >> way, the global uniqueness requirement is still satisfied in the “but > what if > > > >> there are no IPv4 interfaces” case by requiring that the IPv6 Router ID > > > sub- > > > >> TLV be present in that case, or so I read it. > > > >>> > > > >>> Anyway, I think this puts the ball back in the authors’ (and WG’s) > court to > > > >> decide what to do with the technically-inaccurate term “IPv4 Router > ID”. > > > >> (And in any case I do agree with Éric’s s/Interface Address/IPv4 > Interface > > > >> Address/.) > > > >> > > > >> Indeed. Perhaps something like > > > >> > > > >> The Router ID field of the inter-AS reachability TLV is 4 octets in > > > >> length. > > > >> > > > >> If a Traffic Engineering Router ID TLV > > > >> [RFC5305] is available for the router which generates > > > >> the inter-AS reachability TLV, then that value MUST be used. > > > >> If no Traffic Engineering Router ID is assigned, the > > > >> Router ID SHOULD be identical to an IP Interface Address [RFC1195] > > > >> advertised by the originating IS. > > > >> If the originating node does not > > > >> support IPv4, then the reserved value 0.0.0.0 MUST be used in the > > > >> Router ID field and the IPv6 Router ID sub-TLV MUST be present in the > > > >> inter-AS reachability TLV. The Router ID could be used to indicate > > > >> the source of the inter-AS reachability TLV. > > > >> > > > >> It is now later Friday and next Monday and Tuesday are spoken for so I > > > >> may not see any response until Wednesday. > > > >> > > > >> Tom Petch > > > >> > > > >> > > > >>> Thanks, > > > >>> > > > >>> —John > > > >>> > > > >> > > > >> _______________________________________________ > > > >> Lsr mailing list > > > >> [email protected] > > > >> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
