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

[dsaucez <[e-mail]>]

Dear all,

I  approve this RFC for publication

Thank you,

Damien Saucez 

> On 7 Sep 2022, at 07:01, [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 -->
> 
> 
> 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
> 
>