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