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.
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) <ginsb...@cisco.com>
> Sent: Tuesday, September 20, 2022 9:30 PM
> To: Alvaro Retana <aretana.i...@gmail.com>; The IESG <i...@ietf.org>
> Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;
> cho...@chopps.org; t...@ietf.org
> 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 <nore...@ietf.org>
> > Sent: Thursday, September 15, 2022 6:06 AM
> > To: The IESG <i...@ietf.org>
> > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> > lsr@ietf.org;
> > cho...@chopps.org; t...@ietf.org
> > 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to