Alvaro - Please see inline.
> -----Original Message----- > From: Alvaro Retana via Datatracker <[email protected]> > Sent: Thursday, September 15, 2022 6:06 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: (with > DISCUSS) > > Alvaro Retana has entered the following ballot position for > draft-ietf-lsr-isis-rfc5316bis-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > positions/ > for more information about how to handle DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am balloting DISCUSS because I believe the specification is not clear > enough. > > (1) The document recommends (5 separate times) that an ID "SHOULD be > identical > to the value advertised" in an existing TLV. > > If the other TLV is advertised, when is it ok for the values not to be the > same? Why is this action recommended and not required? > [LES:] The new text in Section 3.1 introduces a couple of new (as compared to the original RFC 5316 text) possibilities: 1)The non-zero value could be identical to what is advertised in TLV 134 or it could be identical to what is advertised in TLV 132 (IP Interface Address). This allows for cases where a Router ID is not configured but a stable unique IPv4 address is still advertised for the node. 2)The Router ID is 0.0.0.0 because we are dealing with an IPv6 only deployment. Now, I suppose we could say the Router ID field SHOULD/MUST be identical to TLV 134 except when TLV 134 isn't advertised (which is perfectly legal BTW) - but I find such text awkward at best - and (as per my reply to Tom et al) a MUST here is overly restrictive. Does this help address your concern? > Should the receiver of these TLVs take any action if the values are not > identical? [LES:] No. > > (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. The need for uniqueness of the TE Router ID still exists - but it is the province of RFC 5305. Les > > Please help me understand why this change is ok. If the Router ID can be > used > to identify "the router who generates the inter-AS reachability TLV", not > requiring unique values seems to go counter to that idea. > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
