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

[[e-mail]]

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


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


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


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


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


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


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.

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]). -->


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


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


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  |
 \- - - -/     \- - - -/    \- - - -/ -->


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

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


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


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


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


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


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?

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


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


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


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


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


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


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


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


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


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


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