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

[John Scudder <[e-mail]>]

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/.)

Thanks,

—John