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

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

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

> -----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