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 <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
