Alvaro - Top posting...
RFC 5316 did not make explicit that the "router id" value advertised in the new TLVs/sub-TLVs MUST be the same as TLV134/TLV140. Perhaps this is what the original authors meant and perhaps they thought using the term "Router ID" was explicit enough. I will leave it to them to comment on that. In addition, they did not specify that TLV134/TLV140 MUST be advertised in order to support Inter-AS TE - something that is explicitly stated in RFC5305/6119 when TE is supported. The only stated explicit requirement was that the address be "globally unique". What this means is that it is possible that there are existing implementations that support RFC 5316 that do not use TLV134/140 values as the advertised router ID values in the Inter-AS TLVs. Why might this happen? Perhaps the configuration of a router ID is not required by a given implementation when configuring support for Inter-AS TE. Or perhaps an implementation chose to use an interface address as it was not prohibited. I am not defending or promoting these choices - just saying a strict reading of RFC 5316 allows them as valid. The fact that this possibility exists means that the bis version must not make changes which would render a working legacy implementation as invalid/non-conformant. Hence the need to allow values other than what is advertised in TLV 134/140. With that in mind, here is a proposed revised version of Section 3.1: <snip> 3.1. Choosing the TE Router ID Value Subsequent sections specify advertisement of a TE Router ID value for IPv4 and/or IPv6. This section defines how this value is chosen. A TE Router ID MUST be an address which is globally unique and stable i.e., it can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. When advertising an IPv4 address as a TE Router ID, if the Traffic Engineering Router ID TLV [RFC5305] is being advertised, then the address SHOULD be identical to the address in the Traffic Engineering Router ID TLV. The TE Router ID MAY be identical to an IP Interface Address [RFC1195] advertised by the originating IS so long as the address meets the requirements specified above. When advertising an IPv6 address as a TE Router ID, if the IPv6 TE Router ID TLV [RFC6119] is being advertised, then the address SHOULD be identical to the address in the IPv6 TE Router ID TLV. The TE Router ID MAY be identical to a non-link-local IPv6 Interface Address advertised by the originating IS in a Link State PDU using the IPv6 Intf. Addr TLV [RFC5308] so long as the address meets the requirements specified above. <end snip> Let me know if that works for you. Regarding issues you may have with RFC 5305 and/or RFC 6119, they are out of scope for this thread. Please do not pursue them here. If you think either of those documents need revision, you know what to do. 😊 Les > -----Original Message----- > From: Alvaro Retana <[email protected]> > Sent: Monday, September 26, 2022 12:31 PM > To: Les Ginsberg (ginsberg) <[email protected]>; The IESG <[email protected]> > Cc: Paul Wouters <[email protected]>; [email protected]; lsr- > [email protected]; [email protected]; Eric Vyncke > (evyncke) > <[email protected]>; [email protected]; Rob Wilton (rwilton) > <[email protected]>; Lars Eggert <[email protected]>; [email protected] > Subject: RE: Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: > (with > DISCUSS) > > On September 24, 2022 at 5:23:05 PM, Les Ginsberg wrote: > > > Les: > > Hi! > > > I have given your comments regarding clearer guidance on what value to > use > > for router id more thought and tried to address this in V5 of the document > > (recently posted). > > > > I introduced a new sub-section "Choosing the TE Router ID Value", > discussing > > how to choose the value for IPv4 and IPv6. > > Subsequent sections now refer to this section. > > > > Note that V5 also addresses comments from: > > > > Rob Wilton > > Eric Vyncke > > Lars Eggert > > Paul Wouters > > > > Let me know if you still have concerns. > > > I still have the same questions: > > > This is the new text from §3.1: > > 354 3.1. Choosing the TE Router ID Value > > 356 Subsequent sections specify advertisement of a TE Router ID value > for > 357 IPv4 and/or IPv6. This section defines how this value is chosen. > > 359 When advertising an IPv4 address as a TE Router ID, the address > 360 SHOULD be identical to the value advertised in the Traffic > 361 Engineering Router ID TLV [RFC5305]. In cases where the Traffic > 362 Engineering Router ID is not advertised, the TE Router ID MAY be > 363 identical to an IP Interface Address [RFC1195] advertised by the > 364 originating IS. > > [] If the Traffic Engineering Router ID TLV is advertised, when is it > ok for the Router ID to not be identical? Why is this behavior > recommended and not required? > > I had originally asked: > > > > > Should the receiver of these TLVs take any action if the values are not > > > > identical? > > > > > > [LES:] No. > > If the values are not required to be identical (which, without > qualification or guidance means that the Router ID can take any other > value), and no action is taken if they're not, then I'm at a loss as > to why the setting would even be normatively indicated. > > > The second part of the text makes it optional for the value to be > identical to something else. Again, if optional then there is an even > lower expectation that the value will be "identical to an IP Interface > Address". I realize that there aren't too many other options and that > there's a pretty good chance that an IP Interface Address will be > chosen, regardless of what this document says -- but chance is not a > way to guarantee interoperability nor something normative guidance > should be based on. > > > > I also asked: > > > > > (2) §3.1: The requirement for the Router ID to be unique within the > > > > flooding scope of the LSP has been removed. > > > > > > [LES:] We are not changing anything about TLV 134 (AKA TE Router ID ) . > But > > > given the multiple ways the field in the inter AS TLV can be filled in, it > > > no longer seemed appropriate to make this statement. > > Given the language above (not required, optional, etc.), I can buy > this statement. > > > > > The need for uniqueness of the TE Router ID still exists - but it is the > > > province of RFC 5305. > > This statement assumes that the Router ID in the Inter-AS Reachability > TLV will be set to the value in TLV 134, but the text above doesn't > require it. Also, rfc5305 doesn't mention anything about the TE > router ID being unique -- did I miss it? > > Given the language above (not required, optional, etc.), it doesn't > seem to matter whether the value is unique. > > > 366 When advertising an IPv6 address as a TE Router ID, the address > 367 SHOULD be identical to the value advertised in the IPv6 TE Router ID > 368 TLV [RFC6119]. In cases where the IPv6 TE Router ID is not > 369 advertised, the TE Router ID MAY be identical to a global IPv6 > 370 Interface Address advertised by the originating IS in a Link State > 371 PDU using the IPv6 Intf. Addr TLV [RFC5308]. > > [] The same comments apply. > > > Thanks! > > Alvaro. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
