Re: [Teas] Alvaro Retana's Discuss on draft-ietf-lsr-isis-rfc5316bis-04: (with DISCUSS)

["Acee Lindem (acee)" <[e-mail]>]

Hi Les, 

On 9/24/22, 5:59 PM, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:

    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.

There seems to be inconsistency in the registry with respect to abbreviating "Interface" with "Intf." and "Address" with "Addr." I'd avoid the abbreviations in future documents. 

    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.
Sure.

Thanks,
Acee

       Les


    > -----Original Message-----
    > From: Acee Lindem (acee) <[e-mail]>
    > Sent: Saturday, September 24, 2022 2:36 PM
    > To: Les Ginsberg (ginsberg) <[e-mail]>; Alvaro Retana
    > <[e-mail]>; The IESG <[e-mail]>
    > Cc: [e-mail]; [e-mail]; [e-mail];
    > [e-mail]; [e-mail]; Rob Wilton (rwilton)
    > <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>; Lars
    > Eggert <[e-mail]>; Paul Wouters <[e-mail]>
    > 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)" <[e-mail]>
    > 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) <[e-mail]>
    >     > Sent: Tuesday, September 20, 2022 9:30 PM
    >     > To: Alvaro Retana <[e-mail]>; The IESG <[e-mail]>
    >     > Cc: [e-mail]; [e-mail]; [e-mail];
    >     > [e-mail]; [e-mail]
    >     > 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 <[e-mail]>
    >     > > Sent: Thursday, September 15, 2022 6:06 AM
    >     > > To: The IESG <[e-mail]>
    >     > > Cc: [e-mail]; [e-mail];
    > [e-mail];
    >     > > [e-mail]; [e-mail]
    >     > > 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.
    >     > >
    >     > >
    >     > >
    >     > >
    >