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
