Re: [auth48] [C381] AUTH48: RFC-to-be 9300 <draft-ietf-lisp-rfc6830bis-38> for your review

[Dino Farinacci <[e-mail]>]

> Authors,

Thanks for the updates. See my comments inline.

> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] *AD:  Quite a few updates were made in Section 13.2 of
> the most recent version (-38) of this document.  Please review, and
> let us know if you approve. 

I have reviewed the changes in section 13.2 and they all look good. The working group decided to use the shortened version of the section. So we are in sync with the RFC editor.

> You can easily view the diff here:  
> https://www.ietf.org//rfcdiff?url1=draft-ietf-lisp-rfc6830bis-36&url2=draft-ietf-lisp-rfc6830bis-38
> -->
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in 
> the title) for use on <https://www.rfc-editor.org/search>. -->

How about "LISP data plane".

> 3) <!-- [rfced] Section 1:  This sentence reads oddly, especially as
> compared to "separates control from data" in the Abstract.  Will
> "separates control from the data plane" (as edited) be clear to
> readers?
> 
> Original:
> LISP is an overlay protocol that separates control from Data-Plane,
> this document specifies the Data-Plane as well as how LISP-capable
> routers (Tunnel Routers) exchange packets by encapsulating them to
> the appropriate location.
> 
> Currently:
> LISP is an overlay protocol that separates control from the data
> plane; this document specifies the data plane as well as how LISP-
> capable routers (Tunnel Routers) exchange packets by encapsulating
> them to the appropriate location.
> 
> Possibly:
> LISP is an overlay protocol that separates control from data; this
> document specifies the data plane as well as how LISP-capable
> routers (Tunnel Routers) exchange packets by encapsulating them to
> the appropriate location. -->

Your "Possibly" text is much better. Thanks.

> 4) <!-- [rfced] Section 1.1:  "LISP uses have been found and are being
> used" reads oddly.  May we update as suggested?
> 
> Original ("as been" has been fixed):
> While there are a number of approaches of
> interest for that problem, as LISP as been developed and refined, a
> large number of other LISP uses have been found and are being used.
> 
> Suggested:
> While there are a number of approaches of
> interest for that problem, as LISP has been developed and refined, a
> large number of other ways to use LISP have been found and are being
> implemented. -->

Suggested text looks good.

> 5) <!-- [rfced] Section 3:  Please let us know how the following text
> should be updated.
> 
> a) "An address family that pertains to addresses found in Data-Plane
> headers" is a fragment.  Please provide corrected text.

An address family is an address format found in data plane packet headers,
for example, an IPv4 address or an IPv6 address.

> b) RFC 3232 ("Assigned Numbers: RFC 1700 is Replaced by an On-line
> Database") does not directly mention "Address Family Identifier",
> "AFI", or "address"; it seems unlikely that readers would consult the
> obsoleted RFC 1700 to find the relevant information, unless they are
> directed to it.  Is there a current AFI-related RFC that would be
> more helpful?
> 
> Original:
> An address family that pertains to
> addresses found in Data-Plane headers.  See [AFN] and [RFC3232]
> for details. -->

Its an IANA registry found here:

https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

And references these:




> 6) <!-- [rfced] Section 3:  Please clarify the following:
> 
> a) As this sentence is written in the present tense, "the same way it
> obtains a destination address today" is confusing.  Are some words
> missing?
> 
> Original:
> The host obtains a destination
> EID the same way it obtains a destination address today, for
> example, through a Domain Name System (DNS) [RFC1034] lookup or
> Session Initiation Protocol (SIP) [RFC3261] exchange.
> 
> Possibly:
> At the time of this writing, the host obtains a destination
> EID the same way that many implementations obtain destination
> addresses - for example, through a Domain Name System (DNS) lookup
> [RFC1034] or Session Initiation Protocol (SIP) exchange [RFC3261].

Its not about the timeframe of the writing. It means the way a host obtains a destination address does not have to change when using LISP. The same behavior is used. Lets change the text to this:

The host obtains a destination
EID through a Domain Name System (DNS) [RFC1034] lookup or
Session Initiation Protocol (SIP) [RFC3261] exchange. This
behavior does not change when LISP is in use.

> b) The first sentence here indicates that discussions take place
> with other proposals.  If the suggested text is not correct, please
> clarify.
> 
> Original:
> When used in discussions with other Locator/ID
> separation proposals, a LISP EID will be called an "LEID".
> Throughout this document, any references to "EID" refer to an
> LEID.
> 
> Suggested*:
> When discussing other Locator/ID separation proposals, any
> references to an EID in this document will refer to a LISP EID.
> 
> * We also suggest removing "LEID", because it is only used twice
> in published RFCs to date:  one sentence each in RFCs 6830 and
> 8112.  Also, "LEID" is not used anywhere else in the group of
> RFCs-to-be related to this document (Cluster 381 /
> <https://www.rfc-editor.org/cluster_info.php?cid=C381>): -->

I agree. This is a good change. Use "LISP EID" where LEID was occurred.

> 7) <!-- [rfced] Section 3:  This sentence is difficult to follow.
> Should "LISP-specific 8-octet header that follow" be
> "LISP-specific 8-octet header that follows", or does "follow" refer
> to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific
> 8-octet header?  Please clarify what the LISP header is composed of
> and what an ITR prepends or an ETR strips.

The 8 octet header is the LISP header.

> Original:
> LISP Header:   LISP header is a term used in this document to refer
>    to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
>    specific 8-octet header that follow the UDP header and that an ITR
>    prepends or an ETR strips.
> 
> Possibly:
> LISP Header:  "LISP header" is a term used in this document to refer
>    to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
>    specific 8-octet header, all of which follow the UDP header.  An
>    ITR prepends LISP headers on packets, and an ETR strips them. -->

The suggestion works for me.

I have a comment on section 3 where you changed "Traffic Engineering" to "TE" in 3 places. Since TE was not defined, I think you should keep the long form Traffic Engineering in the Definition of Terms text.

> 8) <!-- [rfced] Section 4:  As this sentence is written in the present
> tense, "end-systems operate the same way they do today" is confusing.
> Are some words missing?
> 
> Original:
> One key concept of LISP is that end-systems operate the same way they
> do today.
> 
> Possibly:
> One key concept of LISP is that, at the time of this writing, LISP
> end-systems operate the same way as end-systems do in other current
> implementations. -->

Its the same comment as above. That is end-systems to not have to change behavior. They operate the same way when LISP is not in use as well as when LISP is in use.

> 9) <!-- [rfced] Sections 4 and subsequent:  Since "Routing Locator" was
> already defined as "RLOC" several times prior to this point, would
> you like to change "Routing Locator", when used in running text, to
> "RLOC" from this point onward?

Yes.

> Original:
> o  LISP routers mostly deal with Routing Locator addresses.
> ...
> Section 10 for Routing Locator Reachability
> ...
> Routing Locator reachability algorithms
> etc. -->

Change it to:

LISP routers mostly deal with RLOC addresses.

> 10) <!-- [rfced] Section 4:  This sentence reads oddly.  We updated as
> follows.  Please let us know any objections.
> 
> Original (the previous sentence is included for context):
> o  LISP routers mostly deal with Routing Locator addresses.  See
>    details in Section 4.2 to clarify what is meant by "mostly".
> 
> Currently:
> For
> details and clarifications regarding this topic, see Section 4.2. -->

Change to:

LISP routers prepend and strip outer headers with RLOC addresses. See Section 4.2 for details.

> 11) <!-- [rfced] Sections 4, 4.2, 5, and 7.1:  We note that this document
> includes "RECOMMENDS" and "OPTIONALLY"; these are not considered
> official key words as listed in RFCs 2119 and 8174.  May these
> instances be rephrased to use "RECOMMENDED" and "OPTIONAL"?
> 
> Original:
> In order to avoid excessive packet overhead as well as possible
> encapsulation loops, this document RECOMMENDS that a maximum of two
> LISP headers can be prepended to a packet.
> ...
> 8.  In order to defer the need for a mapping lookup in the reverse
>     direction, an ETR can OPTIONALLY create a cache entry that maps
>     the source EID (inner-header source IP address) to the source
>     RLOC (outer-header source IP address) in a received LISP packet.
> ...
> In the case when fragmentation is needed, this specification
> RECOMMENDS that implementations provide support for one of the
> proposed fragmentation and reassembly schemes.
> ...
> This specification RECOMMENDS that L be defined as 1500.
> 
> Possibly:
> In order to avoid excessive packet overhead as well as possible
> encapsulation loops, it is RECOMMENDED that a maximum of two
> LISP headers can be prepended to a packet.
> ...
> 8.  In order to defer the need for a mapping lookup in the reverse
>     direction, it is OPTIONAL for an ETR to create a cache entry
>     that maps the source EID (inner-header source IP address) to the
>     source RLOC (outer-header source IP address) in a received LISP
>     packet.
> ...
> In the case when fragmentation is needed, it is RECOMMENDED that
> implementations provide support for one of the proposed
> fragmentation and reassembly schemes.
> ...
> It is RECOMMENDED that L be defined as 1500. -->

Yes, use the standard language.

> 12) <!-- [rfced] Section 4.1:  Should "Instead relying solely on" in this
> bullet item be "Instead, they MUST rely solely on", per the bullet
> item just before this one?
> 
> Original:
> o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
>    as described in Section 13 to update the EID-to-RLOC Mappings.
>    Instead relying solely on control-plane methods. -->

Yes, make your suggested change.

> 13) <!-- [rfced] Section 5.3:  The punctuation in these sentences made
> the text difficult to follow.  We updated per the first bullet item
> under "When doing ITR/PITR encapsulation:" (i.e., using parenthetical
> phrases).  Please let us know any objections.
> 
> Original:
> When doing ITR/PITR encapsulation:
> 
> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
>    the case of IPv6) SHOULD be copied from the inner-header 'Time to
>    Live' field.
> 
> o  The outer-header IPv4 'Differentiated Services Code Point' (DSCP)
>    field or the 'Traffic Class' field, in the case of IPv6, SHOULD be
>    copied from the inner-header IPv4 DSCP field or 'Traffic Class'
>    field in the case of IPv6, to the outer-header.  Guidelines for
>    this can be found at [RFC2983].
> ...
> When doing ETR/PETR decapsulation:
> 
> o  The inner-header IPv4 'Time to Live' field or 'Hop Limit' field in
>    the case of IPv6, MUST be copied from the outer-header 'Time to
>    Live'/'Hop Limit' field, when the 'Time to Live'/'Hop Limit' value
>    of the outer header is less than the 'Time to Live'/'Hop Limit'
>    value of the inner header.  Failing to perform this check can
>    cause the 'Time to Live'/'Hop Limit' of the inner header to
>    increment across encapsulation/decapsulation cycles.  This check
>    is also performed when doing initial encapsulation, when a packet
>    comes to an ITR or PITR destined for a LISP site.
> 
> o  The outer-header IPv4 'Differentiated Services Code Point' (DSCP)
>    field or the 'Traffic Class' field in the case of IPv6, SHOULD be
>    copied from the outer-header IPv4 DSCP field or 'Traffic Class'
>    field in the case of IPv6, to the inner-header.  Guidelines for
>    this can be found at [RFC2983].
> 
> Currently:
> When doing ITR/PITR encapsulation:
> 
> *  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
>    the case of IPv6) SHOULD be copied from the inner-header 'Time to
>    Live' field.
> 
> *  The outer-header IPv4 'Differentiated Services Code Point (DSCP)'
>    field (or 'Traffic Class' field, in the case of IPv6) SHOULD be
>    copied from the inner-header IPv4 'DSCP' field (or 'Traffic Class'
>    field, in the case of IPv6) to the outer header.  Guidelines for
>    this can be found in [RFC2983].
> ...
> When doing ETR/PETR decapsulation:
> 
> *  The inner-header IPv4 'Time to Live' field (or 'Hop Limit' field,
>    in the case of IPv6) MUST be copied from the outer-header 'Time to
>    Live'/'Hop Limit' field when the Time to Live / Hop Limit value of
>    the outer header is less than the Time to Live / Hop Limit value
>    of the inner header.  Failing to perform this check can cause the
>    Time to Live / Hop Limit of the inner header to increment across
>    encapsulation/decapsulation cycles.  This check is also performed
>    when doing initial encapsulation, when a packet comes to an ITR or
>    PITR destined for a LISP site.
> 
> *  The outer-header IPv4 'Differentiated Services Code Point (DSCP)'
>    field (or 'Traffic Class' field, in the case of IPv6) SHOULD be
>    copied from the outer-header 'IPv4 DSCP' field (or 'Traffic Class'
>    field, in the case of IPv6) to the inner header.  Guidelines for
>    this can be found in [RFC2983]. -->

No objection, use your suggested text.

> 14) <!-- [rfced] Section 5.3:  We don't see "PxTR" or "PxTRs" used
> anywhere else in this document or in the group of RFCs-to-be related
> to this document (Cluster 381; see 
> <https://www.rfc-editor.org/cluster_info.php?cid=C381>).  Does "PxTRs"
> mean "PETRs and PITRs"?

Yes it does.

> Original (the subject-verb disagreement has been fixed):
> Some xTRs and PxTRs performs re-encapsulation operations and need to
> treat the 'Explicit Congestion Notification' (ECN) in a special way.
> 
> Suggested (since "PxTRs" isn't used anywhere else)*:
> Some xTRs, PETRs, and PITRs perform re-encapsulation operations and
> need to treat ECN functions in a special way.
> -->

That is fine.

> 15) <!-- [rfced] Section 7.2: RFC 1981 has been obsoleted by RFC 8201.
> Because the citation is general, we updated the RFC number here and
> in the Informative References section.
> 
> However, this sentence seems to say that the RFCs themselves can
> behave suboptimally.  If the suggested text is not correct, please
> clarify what can behave suboptimally.
> 
> Original:
> Please note that [RFC1191] and [RFC1981], which describe the use of
> ICMP packets for PMTU discovery, can behave suboptimally in the
> presence of ICMP black holes or off-path attackers that spoof ICMP.
> 
> Currently:
> Please note that [RFC1191] and [RFC8201], which describe the use of
> ICMP packets for PMTU discovery, can behave suboptimally in the
> presence of ICMP black holes or off-path attackers that spoof ICMP.
> 
> Suggested:
> Please note that using ICMP packets for PMTU discovery, as described
> in [RFC1191] and [RFC8201], can result in suboptimal behavior in the
> presence of ICMP black holes or off-path attackers that spoof ICMP. -->

Suggested change is fine.

> 16) <!-- [rfced] Section 9:  These sentences are difficult to parse.
> In the first sentence here, it appears that the client-side ITR
> gives itself responsibility for bidirectional RLOC reachability and
> preferability.  Is the server-side ETR the responsible entity?

Yes.

> In the second sentence, it appears that either (1) one or more words
> are missing after "alternate" or (2) a word other than "alternate"
> should be used.  If the suggested text is not correct, please
> clarify.
> 
> Original:
> For example, if the server-side ETR gleans RLOCs, then
> the client-side ITR gives the client-side ITR responsibility for
> bidirectional RLOC reachability and preferability.
> ...
> The client-side ITR controls how traffic is
> returned and can alternate using an outer-header source RLOC,
> which then can be added to the list the server-side ETR uses to
> return traffic.
> 
> Suggested:
> For example, if the server-side ETR gleans RLOCs, then
> the client-side ITR gives the server-side ETR responsibility for
> bidirectional RLOC reachability and preferability.
> ...
> The client-side ITR controls how traffic is
> returned and can, as an alternative, use an outer-header source
> RLOC, which then can be added to the list the server-side ETR uses
> to return traffic. -->

Suggested change is fine.

> 17) <!-- [rfced] Section 9:  Should "'TTL' field" here be "'Time to Live'
> field" as used elsewhere in this document?  If yes, may we remove
> the "TTL" in the "Copying the Time to Live (TTL)" sentence in
> Section 5.3, as "TTL" isn't used anywhere else?

> 
> Original:
> A reply to this "verifying Map-Request" is
> used to fully populate the Map-Cache entry for the "gleaned" EID
> and is stored and used for the time indicated from the 'TTL' field
> of a received Map-Reply. -->

Yes, it is "Time to Live". You can change to that.

> 18) <!-- [rfced] Section 10:  Because "PE" is used only once in this
> document, for ease of the reader we changed it to "Provider Edge" as
> used in draft-ietf-lisp-introduction.  Please let us know if any corrections are needed. 
> 
> Original:
> o  If an ITR fails or if the upstream link to its PE fails, its
>    default route will either time out or be withdrawn.
> 
> Currently:
> *  If an ITR fails or if the upstream link to its Provider Edge
>    fails, its default route will either time out or be withdrawn. -->

This change is fine. Thanks.

> 19) <!-- [rfced] Section 10.1:  We updated this run-on sentence as
> follows.  If this is incorrect, please provide clarifying text
> (e.g., does the packet include the nonce, and not the ETR?).
> 
> Original:
> When the ETR is an xTR (co-located as an ITR),
> it then sends a data packet to the ITR (when it is an xTR co-located
> as an ETR), it includes the nonce received earlier with the N-bit set
> and E-bit cleared.
> 
> Currently:
> When the ETR is an xTR (co-located as an ITR),
> it then sends a data packet to the ITR (when it is an xTR co-located
> as an ETR) and includes the nonce received earlier with the N-bit set
> and E-bit cleared. -->

Your suggested text is fine.

> 20) <!-- [rfced] Section 10.1:  Should "echo nonce requests" be
> "echo-nonce-request packets" as used in the next sentence?

Yes.

> Original (the next sentence is included for context):
> The number of packets sent or the time during which echo
> nonce requests are sent is an implementation-specific setting.  In
> this case, an xTR receiving the echo-nonce-request packets will
> suspend the echo-nonce-request state and setup a 'echo-nonce-request-
> state' timer. -->

Your suggested text is fine.

> 21) <!-- [rfced] Section 12:  Should "then" be "and" in this sentence?
> If not, please clarify the text.
> 
> Original:
> When the inner header is IPv6 then the flow label is not
> zero, it MAY be used to compute the hash. -->

Yes "and".

> 22) <!-- [rfced] Section 13:  As it appears that "which ITRs requested
> its mappings" means "which ITRs requested their mappings" and
> "but need to provide" means "but implementors need to provide",
> we updated these sentences accordingly.  If these changes are
> incorrect, please provide clarifying text.
> 
> Original:
> However, the ITRs do not
> know when the mappings change, and the ETRs do not keep track of
> which ITRs requested its mappings.  For scalability reasons, it is
> desirable to maintain this approach but need to provide a way for
> ETRs to change their mappings and inform the sites that are currently
> communicating with the ETR site using such mappings.
> 
> Currently:
> However, the ITRs do not
> know when the mappings change, and the ETRs do not keep track of
> which ITRs requested their mappings.  For scalability reasons, it is
> desirable to maintain this approach, but implementors need to provide
> a way for ETRs to change their mappings and inform the sites that are
> currently communicating with the ETR site using such mappings. -->

Your suggested text is fine.

> 23) <!-- [rfced] Section 13.1:  Please confirm that "setting" and not
> "sending" is correct here.  We ask because of the word "receiving"
> in the same sentence.
> 
> Original:
> In this section the term "source xTR" is used
> to refer to the xTR setting the LSB and "destination xTR" is used to
> refer to the xTR receiving the LSB. -->

Yes, "setting" is correct.

> 24) <!-- [rfced] Section 13.1:  Does "use LSB (L-bit = 0)" mean "use the
> LSB if the L-bit is set to 0", or something else?  Please clarify.

The LSB is used when the L-bit is 1.

> Original ("will setup" has been fixed):
> At this point the source xTR MUST NOT use LSB
> (L-bit = 0) since the destination xTR site has outdated information.
> The source xTR will setup a 'use-LSB' timer. -->

Change text to:

At this point the source xTR MUST NOT use LSB, when the L-bit is 0,
since the destination xTR site has outdated information.
The source xTR will setup a 'use-LSB' timer.

> 25) <!-- [rfced] Section 15:  We expanded "MAC" as "Message
> Authentication Code" here.  If this is incorrect, please provide
> the correct definition.

That is fine.

> Original:
> o  On an ITR, prepending a new IP header consists of adding more
>    octets to a MAC rewrite string and prepending the string as part
>    of the outgoing encapsulation procedure.
> 
> Currently:
> *  On an ITR, prepending a new IP header consists of adding more
>    octets to a Message Authentication Code (MAC) rewrite string and
>    prepending the string as part of the outgoing encapsulation
>    procedure. -->

Your suggested text is fine.

> 26) <!-- [rfced] Section 16:  As we only see the concept of the
> gleaning mechanism discussed in the singular, we updated this
> sentence accordingly.  If this update is incorrect, please provide
> clarifying text.
> 
> Original:
> The optional mechanisms of gleaning is offered to directly obtain a
> mapping from the LISP encapsulated packets.
> 
> Currently:
> The optional gleaning mechanism is offered to directly obtain a
> mapping from the LISP-encapsulated packets. -->

Your suggested text is fine.

> 27) <!-- [rfced] Section 16:
> 
> a) This sentence was difficult to follow.  We updated it as listed
> below.  If this is incorrect, please provide clarifying text.
> 
> Original:
> Note the attacker must guess a
> valid nonce the ITR is requesting to be echoed within a small window
> of time.
> 
> Currently:
> Note that the attacker only
> has a small window of time within which to guess a valid nonce that
> the ITR is requesting to be echoed.

Your suggested text is fine.

> b) We did not see "uRPF", "RPF", "reverse path forwarding", or "path
> forwarding" in RFC 2827 - only "reverse tunnels" and "reverse
> tunneling".  Will this citation be clear to readers, or should a
> different RFC be cited here?
> 
> Original:
> This specific attack can be
> mitigated by preventing RLOC spoofing in the network by deploying
> uRPF BCP 38 [RFC2827]. -->

How about RFC 8704.

> 28) <!-- [rfced] Section 16:  Should "outer header fragments" be
> "outer-header fragments", per "outer-header source IP address",
> "outer-header 'Time to Live' field", "outer-header encapsulation",
> etc.?

No, I don't think so. What we quoted were fields in the IP header. But fragments are packets.

> Original:
> LISP implementations and deployments which permit outer header
> fragments of IPv6 LISP encapsulated packets as a means of dealing
> with MTU issues should also use implementation techniques in ETRs to
> prevent this from being a DoS attack vector. -->

Leave the text above.

> 29) <!-- [rfced] Should "help" be "helped" (past tense) here?  

Yes.

> Original: 
>   The current authors would like to give a sincere thank you to the
>   people who help put LISP on standards track in the IETF.
> -->

Please change to "helped".

> 30) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 
> and let us know if any changes are needed.  For example, please consider
> whether the following should be updated: black hole and native. 
> 
> In addition, consider whether "traditional" should be updated. It may be 
> ambiguous as it is subjective. 
> -->

Do whatever is standard. I don't understand what you want us to do exactly.

> 31) <!-- [rfced] Please let us know if any changes are needed for the
> following:
> 
> a) The following term was used inconsistently in this document.
> We chose to use the latter form.  Please let us know any objections.
> 
> Reserved and unassigned bit / reserved and unassigned bit
>   (per "documented as reserved and unassigned" in Section 18
>   and per draft-ietf-lisp-rfc6833bis)

Fine.

> b) The following terms appear to be used inconsistently in this
> document.  Please let us know which form is preferred.
> 
> a Nonce / a nonce (e.g., "a nonce", "a Nonce value")

Fine.

> ICMP Unreachable / ICMPv4 ICMP Unreachable / ICMPv4 Unreachable -->

This is fine.

> Thank you.
> 
> RFC Editor

Thank you for the edits and effort,
Dino