Re: [auth48] [C336] [AD] RE: AUTH48: RFC-to-be 9299 <draft-ietf-lisp-introduction-15> for your review

[Albert Cabellos <[e-mail]>]

Hi all

Please see inline my responses:

On Wed, Sep 7, 2022 at 7:02 AM <[e-mail]> wrote:

> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] *AD, please approve the following changes:
>
> - updated and new text in Section 3.2
>
> - updates to the first paragraph of Section 3.3.1
>
> - removal of "using the native Internet core" in Section 3.4.3.1
>
> - update from "Internet global routing system" to "routing system
>  beyond the local LISP domain" in Section 3.5
>
> - removal of "Typical values of TTL defined by LISP are 24 hours" in
>  Section 4.1
>
> - new text and change from "IBGP" to "IGP" in Section 4.2
>
> - new paragraph at the end of Section 6
>
> - updates to the "To improve resiliency ..." paragraph in Section 8 -->
>
>
Approve

>
> 2) <!-- [rfced] Introduction:  We could not parse this sentence.  Does
> "nodes require to be identified" mean "nodes must be identified" or
> something else?
>
> Original:
>  However,
>  nodes and routing have fundamentally different requirements, routing
>  systems require that addresses are aggregatable and have topological
>  meaning, while nodes require to be identified independently of their
>  current location [RFC4984].
>
> Possibly:
>  However, nodes and
>  routing have fundamentally different requirements.  On one hand,
>  routing systems require that addresses be aggregatable and have
>  topological meaning; on the other hand, nodes must be identified
>  independently of their current location [RFC4984]. -->
>
>
"nodes must be identified", the "possibly" paragraph is correct.

>
> 3) <!-- [rfced] We note that "Traffic Engineering (TE)" is introduced,
> but this is the only place TE is used.  May we update instances of
> "traffic
> engineering" to "TE" after the initial introduction?  Note that we have
> moved
> "(TE)" to appaer where traffic engineering was initially used in the
> document.
>
> Original:
>    The initial motivation in the LISP effort is to be found in the
>    routing scalability problem [RFC4984], where, if LISP were to be
>    completely deployed, the Internet core is populated with RLOCs while
>    Traffic Engineering mechanisms are pushed to the Mapping System.
>
> Perhaps (with consistent use of TE thereafter):
>    The initial motivation in the LISP effort is to be found in the
>    routing scalability problem [RFC4984], where, if LISP were to be
>    completely deployed, the Internet core is populated with RLOCs while
>    Traffic Engineering (TE) mechanisms are pushed to the Mapping System.
> -->
>
>
Agreed.

>
> 4) <!-- [rfced] There are a couple of places that refer to "at the time of
> this writing".  Please review and let us know if any updates are desired,
> as
> this document was approved in 2015.
>
> Section 3.2 Original:
>    EIDs are IPv4 or IPv6
>    addresses that uniquely identify communication end-hosts and are
>    assigned and configured by the same mechanisms that exist at the time
>    of this writing.
>
> Section 4.3 Original:
>    At the time of this writing LISP does not specify a mechanism to
>    achieve ETR synchronization.
> -->
>
>
No updates are required.

>
> 5) <!-- [rfced] Section 3.3.1:  We changed "striped by ETRs" to
> "stripped by ETRs" here, per "stripped by ETRs" a few lines later and
> per "mechanisms to strip the LISP encapsulation" in Section 8.
> Please let us know if this is incorrect.
>
> Original:
>  The LISP header is
>  prepended by ITRs and striped by ETRs.
>
> Currently:
>  The LISP header is
>  prepended by ITRs and stripped by ETRs. -->
>
>
>
Agreed

> 6) <!-- [rfced] Section 3.3.1:  To what does "and that" refer in this
> sentence - the 'Instance ID' field, the traffic, the LISP site, or
> something else?
>
> Original:
>  The Instance ID field is used to distinguish traffic to/from
>  different tenant address spaces at the LISP site and that may use
>  overlapped but logically separated EID addressing. -->
>
>
>
Refers to the "this use of the instance ID"


> 7) <!-- [rfced] Section 3.3.2:  Please review the following, and let us
> know how the text should be updated.
>
> a) The sentence that starts with "Meaning that" is a fragment.  If
> the suggested text is not correct, please clarify the intended
> meaning of this text.
>
> Original (the previous sentence is included for context):
>  In the LISP architecture, ITRs keep just enough information to route
>  traffic flowing through them.  Meaning that, ITRs retrieve from the
>  LISP Mapping System mappings between EID-prefixes (blocks of EIDs)
>  and RLOCs that are used to encapsulate packets.
>
> Suggested:
>  In other words, ITRs only need to retrieve from the
>  LISP mapping system mappings between EID-prefixes (blocks of EIDs)
>  and RLOCs that are used to encapsulate packets.
>
>
Correct.


> b) We had trouble parsing this sentence.  If the suggested text is
> not correct, please clarify "EID-prefixes, following a single
> request", "of mappings, covering the requested", and
> "more-specifics".
>
> Original:
>  Note that, in case of overlapping
>  EID-prefixes, following a single request, the ITR may receive a set
>  of mappings, covering the requested EID-prefix and all more-specifics
>  (cf., Section 6.1.5 [RFC6830]).
>
> Suggested:
>  Note that in the case of
>  overlapping EID-prefixes following a single request, the ITR may
>  receive a set of mappings covering the requested EID-prefix and all
>  more-specific EID-prefixes (cf., Section 5.5 of [RFC9301]). -->
>
> I suggest the following paragraph:


> Note that in the case of overlapping EID-prefixes, after a request the ITR
may

>  receive a set of mappings covering the requested EID-prefix and all
 more-specific EID-prefixes (cf., Section 5.5 of [RFC9301]).



> 8) <!-- [rfced] Section 3.4.1:  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,
> without guidance, readers would consult the obsoleted RFC 1700 to
> find the relevant information.  Is there a current AFI-related RFC that
> would be more helpful?
>
> Original:
>  IPv4 and IPv6 addresses are
>  encoded using the appropriate Address Family Identifier (AFI)
>  [RFC3232]. -->
>
>
Yes, RFC8060.


>
> 9) <!-- [rfced] Section 3.4.3.2:  We had trouble following this text.
> What matches the entire address space - the DDT root node or a
> particular instance of a DDT node?
>
> Original:
>  On top of the structure there is the DDT root node
>  [DDT-ROOT], which is a particular instance of a DDT node and that
>  matches the entire address space. -->
>
>
It means that the DDT root is just implemented as any DDT node, but since
it is the root it matches the entire address space.

>
> 10) <!-- [rfced] Figure 3:  We changed "DDT Note 2/8" to "DDT Node 2/8".
> Please let us know any concerns.
>
> Original (dashed lines broken to avoid interpretation as XML comment):
>  /- - - -\     /- - - -\    /- - - -\
>  |  DDT  |     |  DDT  |    |  DDT  |
>  | Node  |     | Node  |    | Note  |  ...
>  |  0/8  |     |  1/8  |    |  2/8  |
>  \- - - -/     \- - - -/    \- - - -/
>
> Currently:
>  /- - - -\     /- - - -\    /- - - -\
>  |  DDT  |     |  DDT  |    |  DDT  |
>  | Node  |     | Node  |    | Node  |  ...
>  |  0/8  |     |  1/8  |    |  2/8  |
>  \- - - -/     \- - - -/    \- - - -/ -->
>
>
>
Agreed.


> 11) <!-- [rfced] Section 3.4.3.2:  Please advise regarding the following:
>
> a) We could not parse this sentence.  Are some words missing?  If the
> suggested text is not correct, please provide clarifying text.
>
> Original:
>  The DDT structure does not actually index EID-prefixes but eXtended
>  EID-prefixes (XEID).
>
> Suggested:
>  The DDT structure does not actually index EID-prefixes; rather, it
>  indexes Extended EID-prefixes (XEID-prefixes).
>
>
This is correct.


> b) Should "less significant bit" be "least significant bit" or
> perhaps "less significant bits" as used in draft-ietf-lisp-sec?
>
> Original:
>  An XEID-prefix is just the concatenation of the
>  following fields (from most significant bit to less significant bit):
>  Database-ID, Instance ID, Address Family Identifier and the actual
>  EID-prefix. -->
>
> "less significant bits" is correct.
>


> 12) <!-- [rfced] Section 3.4.3.2:  Please clarify the meaning of
> "mapping retrieving latency".
>
> Original:
>  This is used
>  to reduce the mapping retrieving latency[Jakab].
>
> Possibly:
>  This is used
>  to reduce the time required to retrieve mappings [Jakab]. -->
>
> This is perfect.
>


> 13) <!-- [rfced] Section 4.2:  This sentence does not parse.  If the
> suggested text is not correct, please clarify the meaning of
> "waiting in return a Map-Reply".
>
> Original:
>  In particular this is done by sending a Map-Request
>  (with certain flags activated) on the data-plane (RLOC space) and
>  waiting in return a Map-Reply, also sent on the data-plane.
>
> Suggested:
>  In particular, this is done by sending a
>  Map-Request (with certain flags activated) on the data plane (RLOC
>  space) and then waiting for a Map-Reply (also sent on the data
>  plane). -->
>
>
Correct.

>
> 14) <!-- [rfced] Section 4.2:  It appears that some words are missing
> from this sentence.  Please clarify "cannot tell the difference
> between a failed bidirectional path or the return path is not used"
> (in other words, cannot tell the difference between a failed
> bidirectional path and what other entity?).
>
> Original:
>  Specifically if a nonce is not echoed, an ITR could RLOC-
>  probe to determine if the path is up when it cannot tell the
>  difference between a failed bidirectional path or the return path is
>  not used (a unidirectional path). -->
>
>
>
Proposed text:

Specifically if a nonce is not echoed, an ITR cannot determine which path
direction has failed. In this scenario an ITR can use RLOC-probing.


15) <!-- [rfced] Section 5:  Please clarify the meaning of "changes of"
> in this sentence.
>
> Original:
>  Whenever the device changes of RLOC, the xTR updates the RLOC of its
>  local mapping and registers it to its Map-Server, typically with a
>  low TTL value (1min).
>
> Possibly:
>  Whenever a device changes its RLOC, the xTR updates the RLOC of its
>  local mapping and registers it to its Map-Server, typically with a
>  low TTL value (1 min). -->
>
>
Agreed.


> 16) <!-- [rfced] Section 6:  We had trouble following this sentence.
> Does "LISP routers unicast encapsulate" mean "LISP routers
> unicast-encapsulate" (i.e., "encapsulate as unicast packets") or
> something else?
>
>
LISP routers encapsulate as unicast packets.


> Original:
>  When signaling is used
>  to create multicast state at the sites, LISP routers unicast
>  encapsulate PIM Join/Prune messages from receiver to source sites. -->
>
>
> 17) <!-- [rfced] Section 6:  "receiving ETRs that decapsulates the
> packets and sends" did not parse.  Because we see elsewhere in
> this document that ETRs decapsulate packets, we updated the text
> accordingly.  Please review, and let us know any objections.
>
> Original:
>  Then the
>  multicast packet is transmitted through the core towards the
>  receiving ETRs that decapsulates the packets and sends them using
>  the receiver's site multicast state.
>
> Currently:
>  Then, the
>  multicast packets are transmitted through the core towards the
>  receiving ETRs, which decapsulate the packets and forward them
>  using the receiver site's multicast state. -->
>
>
Correct.

>
> 18) <!-- [rfced] Section 7.1:  We see in version -15 of this document
> (https://datatracker.ietf.org/doc/html/draft-ietf-lisp-introduction-15)
> that "must enter" was changed to "must enters".  Which is intended -
> "must enter" (per previous versions) or "enters"?
>
> Original:
>  A LISP site can strictly impose via which ETRs the traffic must
>  enters the LISP site network even though the path followed to reach
>  the ETR is not under the control of the LISP site. -->
>
>
"must enter" is correct


>
> 19) <!-- [rfced] Section 7.1:  We had trouble following this sentence.
> If the suggested text is not correct, please clarify "with even the
> possibility for a site to support".
>
> Original:
>  As mappings are directly issued by the authoritative ETR of the EID
>  and are not altered while transmitted to the remote site, it offers
>  highly flexible incoming inter-domain traffic engineering with even
>  the possibility for a site to support a different mapping policy for
>  each remote site.
>
> Suggested:
>  As mappings are directly issued by the authoritative ETR of the EID
>  and are not altered when transmitted to the remote site, it offers
>  highly flexible incoming inter-domain traffic engineering and even
>  makes it possible for a site to support a different mapping policy
>  for each remote site. -->
>
>
Correct.

>
> 20) <!-- [rfced] Section 7.3:  This sentence does not parse.  If the
> suggested text is not correct, please clarify.
>
> Original:
>  In such virtual private networks, it is
>  essential to distinguish which virtual network a packet belongs and
>  tags or labels are used for that purpose.
>
> Suggested:
>  In such virtual private networks, determining to which virtual
>  network a packet belongs is essential; tags or labels are used for
>  that purpose. -->
>
>
>
Correct.

> 21) <!-- [rfced] Note that we added "(VM)" to introduce the abbreviation
> that was used earlier in the document.  It would have been awkward to use
> "Virtual Machine (VM)" earlier, so we are adding it where "virtual
> machine"
> next appears.  Please let us know if you have any concerns.
>
> Section 5 original (we did not expand VM here):
>    In the mobility case the EID-prefix can
>    be as small as a full /32 or /128 (IPv4 or IPv6 respectively)
>    depending on the specific use-case (e.g., subnet mobility vs single
>    VM/Mobile node mobility).
>
>
> Section 7.4 original ("(VM)" was added to this sentence):
>    A way to enable seamless virtual machine mobility in data center is
>    to conceive the datacenter backbone as the RLOC space and the subnet
>    where servers are hosted as forming the EID space.
> -->
>
>
Agreed.

>
> 22) <!-- [rfced] Section 8:  This sentence was difficult to follow.
> We updated the text.  Please let us know if this is incorrect.
>
> Original:
>  While in a push mapping system, the state necessary to forward
>  packets is learned independently of the traffic itself, with a pull
>  architecture, the system becomes reactive and data-plane events
>  (e.g., the arrival of a packet for an unknown destination) may
>  trigger control-plane events.
>
> Currently:
>  In a push mapping system, the state necessary to forward packets is
>  learned independently of the traffic itself.  However, with a pull
>  architecture, the system becomes reactive, and data plane events
>  (e.g., the arrival of a packet with an unknown destination address)
>  may trigger control plane events. -->
>
>
>
Correct.


> 23) <!-- [rfced] Section 8:  As it appears that the control plane is
> notified of data plane events, we updated this text accordingly.
> Please let us know if anything is incorrect.
>
> Original:
>  As a consequence,
>  the way data-plane events are notified to the control-plane must be
>  thought carefully so to not overload the slow path and rate limiting
>  should be used as specified in [RFC6830].
>
> Currently:
>  As a consequence, the
>  way to notify the control plane of data plane events must be
>  considered carefully so as not to overload the slow path, and rate
>  limiting should be used as specified in [RFC9300] and [RFC9301]. -->
>
>
>
Correct.

> 24) <!-- [rfced] Section 8:  We had trouble parsing this sentence.  If
> the suggested text is not correct, please clarify "LISP offers the
> possibility to leak information".
>
> Original ("reachabilty" has been corrected):
>  To improve resiliency and reduce the overall number of messages
>  exchanged, LISP offers the possibility to leak information, such as
>  reachabilty of locators, directly into data plane packets.
>
> Suggested:
>  To improve resiliency and reduce the overall number of messages
>  exchanged, LISP makes it possible to leak certain information, such
>  as the reachability of locators, directly into data plane packets. -->
>
>
Correct.

>
> 25) <!-- [rfced] Appendix A.1:  "is used ... by using this" is difficult
> to follow.  If the suggested text is not correct, please clarify.
>
> Original (the bad spacing has been fixed):
>  LISP 1:  EIDs all appear in the normal routing and forwarding tables
>     of the network (i.e. they are 'routable');this property is used to
>     'bootstrap' operation, by using this to load EID->RLOC mappings.
>
> Suggested:
>  This property is used
>  to load EID-to-RLOC mappings via bootstrapping operations. -->
>
>
>
correct.

> 26) <!-- [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 "natively" or "native" should be updated.
> -->
>
>
>
I have reviewed the document and I have not identified any instance where a
change is required.

Thanks for the outstanding review, I am really impressed how the
readability and correctness of the document has improved.

Albert

Thank you.
>
> RFC Editor
>
> On Sep 6, 2022, at 9:56 PM, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2022/09/06
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>    Please review and resolve any questions raised by the RFC Editor
>    that have been included in the XML file as comments marked as
>    follows:
>
>    <!-- [rfced] ... -->
>
>    These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>    Please ensure that you review any changes submitted by your
>    coauthors.  We assume that if you do not speak up that you
>    agree to changes submitted by your coauthors.
>
> *  Content
>
>    Please review the full content of the document, as this cannot
>    change once the RFC is published.  Please pay particular attention to:
>    - IANA considerations updates (if applicable)
>    - contact information
>    - references
>
> *  Copyright notices and legends
>
>    Please review the copyright notice and legends as defined in
>    RFC 5378 and the Trust Legal Provisions
>    (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>    Please review the markup in the XML file to ensure that elements of
>    content are correctly tagged.  For example, ensure that <sourcecode>
>    and <artwork> are set correctly.  See details at
>    <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>    Please review the PDF, HTML, and TXT files to ensure that the
>    formatted output, as generated from the markup in the XML file, is
>    reasonable.  Please note that the TXT will have formatting
>    limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>    *  your coauthors
>
>    *  [e-mail] (the RPC team)
>
>    *  other document participants, depending on the stream (e.g.,
>       IETF Stream participants are your working group chairs, the
>       responsible ADs, and the document shepherd).
>
>    *  [e-mail], which is a new archival mailing list
>       to preserve AUTH48 conversations; it is not an active discussion
>       list:
>
>      *  More info:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>      *  The archive itself:
>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>      *  Note: If only absolutely necessary, you may temporarily opt out
>         of the archiving of messages (e.g., to discuss a sensitive matter).
>         If needed, please add a note at the top of the message that you
>         have dropped the address. When the discussion is concluded,
>         [e-mail] will be re-added to the CC list and
>         its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
>  — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>    https://www.rfc-editor.org/authors/rfc9299.xml
>    https://www.rfc-editor.org/authors/rfc9299.html
>    https://www.rfc-editor.org/authors/rfc9299.pdf
>    https://www.rfc-editor.org/authors/rfc9299.txt
>
> Diff file of the text:
>    https://www.rfc-editor.org/authors/rfc9299-diff.html
>    https://www.rfc-editor.org/authors/rfc9299-rfcdiff.html (side by side)
>
> Diff of the XML:
>    https://www.rfc-editor.org/authors/rfc9299-xmldiff1.html
>
> The following files are provided to facilitate creation of your own
> diff files of the XML.
>
> Initial XMLv3 created using XMLv2 as input:
>    https://www.rfc-editor.org/authors/rfc9299.original.v2v3.xml
>
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>    https://www.rfc-editor.org/authors/rfc9299.form.xml
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>    https://www.rfc-editor.org/auth48/rfc9299
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9299 (draft-ietf-lisp-introduction-15)
>
> Title            : An Architectural Introduction to the Locator/ID
> Separation Protocol (LISP)
> Author(s)        : A. Cabellos, D. Saucez, Ed.
> WG Chair(s)      : Joel M. Halpern, Luigi Iannone
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>
>
>