Acee - Thanx for the quick review/suggestions.
Note that I used the name of the TLV as shown in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints - which differs from what is in the text of RFC 5308. Happy to replace "global IPv6 Interface Address" with "non-link-local IPv6 address" - but let's wait for Alvaro's response in case he wants further changes. Les > -----Original Message----- > From: Acee Lindem (acee) <[email protected]> > Sent: Saturday, September 24, 2022 2:36 PM > To: Les Ginsberg (ginsberg) <[email protected]>; Alvaro Retana > <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected]; Rob Wilton (rwilton) > <[email protected]>; Eric Vyncke (evyncke) <[email protected]>; Lars > Eggert <[email protected]>; Paul Wouters <[email protected]> > Subject: Re: Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: > (with > DISCUSS) > > Hi Les, > > Looks good. See one suggestion. > > On 9/24/22, 5:23 PM, "Les Ginsberg (ginsberg)" <[email protected]> > wrote: > > Alvaro - > > 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. > > Consistent with the terminology in RFC 5308, I'd use " IPv6 Interface Address > TLV" and " non-link-local IPv6 address" in the second paragraph. > > Thanks, > Acee > > 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. > > Les > > > -----Original Message----- > > From: Les Ginsberg (ginsberg) <[email protected]> > > Sent: Tuesday, September 20, 2022 9:30 PM > > To: Alvaro Retana <[email protected]>; The IESG <[email protected]> > > Cc: [email protected]; [email protected]; > [email protected]; > > [email protected]; [email protected] > > Subject: RE: Alvaro Retana's Discuss on > draft-ietf-lsr-isis-rfc5316bis-04: > (with > > DISCUSS) > > > > 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
