Re: [Teas] [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

Tom -

> -----Original Message-----

> From: t petch <ietfa@btconnect.com>

> Sent: Wednesday, September 21, 2022 3:45 AM

> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; John Scudder

> <jgs@juniper.net>

> Cc: Eric Vyncke (evyncke) <evyncke@cisco.com>; The IESG <iesg@ietf.org>;

> draft-ietf-lsr-isis-rfc5316bis@ietf.org; lsr-chairs@ietf.org; lsr <lsr@ietf.org>;

> chopps@chopps.org; teas@ietf.org

> 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 <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of t petch

> >> Sent: Friday, September 16, 2022 9:37 AM

> >> To: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>

> >> Cc: Eric Vyncke (evyncke) <evyncke@cisco.com<mailto:evyncke@cisco.com>>; The IESG

> <iesg@ietf.org<mailto:iesg@ietf.org>>;

> >> draft-ietf-lsr-isis-rfc5316bis@ietf.org<mailto:draft-ietf-lsr-isis-rfc5316bis@ietf.org>; lsr-chairs@ietf.org<mailto:lsr-chairs@ietf.org>; lsr

> <lsr@ietf.org<mailto:lsr@ietf.org>>;

> >> chopps@chopps.org<mailto:chopps@chopps.org>; teas@ietf.org<mailto:teas@ietf.org>

> >> 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 <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> 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

> >> <noreply@ietf.org<mailto:noreply@ietf.org>> 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

> >> Lsr@ietf.org<mailto:Lsr@ietf.org>

> >> https://www.ietf.org/mailman/listinfo/lsr