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]<mailto:[email protected]>> On Behalf Of > >> t petch > >> Sent: Friday, September 16, 2022 9:37 AM > >> To: John Scudder <[email protected]<mailto:[email protected]>> > >> Cc: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; > >> The IESG > <[email protected]<mailto:[email protected]>>; > >> [email protected]<mailto:[email protected]>; > >> [email protected]<mailto:[email protected]>; lsr > <[email protected]<mailto:[email protected]>>; > >> [email protected]<mailto:[email protected]>; > >> [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
