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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
> Sent: Wednesday, September 21, 2022 7:44 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: t petch <[e-mail]>; Eric Vyncke (evyncke)
> <[e-mail]>; The IESG <[e-mail]>; draft-ietf-lsr-isis-
> [e-mail]; [e-mail]; lsr <[e-mail]>;
> [e-mail]; [e-mail]
> 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)
> <[e-mail]> wrote:
> >
> >
> > Tom -
> >
> > > -----Original Message-----
> > > From: t petch <[e-mail]>
> > > Sent: Wednesday, September 21, 2022 3:45 AM
> > > To: Les Ginsberg (ginsberg) <[e-mail]>; John Scudder
> > > <[e-mail]>
> > > Cc: Eric Vyncke (evyncke) <[e-mail]>; The IESG
> <[e-mail]>;
> > > [e-mail]; [e-mail]; lsr
> <[e-mail]>;
> > > [e-mail]; [e-mail]
> > > 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 <[e-mail]> On Behalf Of t petch
> > > >> Sent: Friday, September 16, 2022 9:37 AM
> > > >> To: John Scudder <[e-mail]>
> > > >> Cc: Eric Vyncke (evyncke) <[e-mail]>; The IESG
> > > <[e-mail]>;
> > > >> [e-mail]; [e-mail]; lsr
> > > <[e-mail]>;
> > > >> [e-mail]; [e-mail]
> > > >> 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 <[e-mail]>
> 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
> > > >> <[e-mail]> 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
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/lsr