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

[t petch <[e-mail]>]

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











>
> $0.02. The authors might have additional comments of course.
>
>> ### Section 7
>>
>> While Les was not an author of RFC 5316, he is an author of this I-D, so no
>> more need to acknowledge him ;-)
>
> I did make this point during my review and the authors chose to clarify that the supplied acknowledgments are a verbatim copy of what was in RFC 5316. So although this is a little unusual, it was a deliberate choice.
>
> FYI, FWIW,
>
> —John
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>