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

[Albert Cabellos <[e-mail]>]

Approve

Thanks!

Albert

> On 12 Sept 2022, at 22:38, dsaucez <[e-mail]> wrote:
> 
> 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
>> 
>> 
>