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

[Alanna Paloma <[e-mail]>]

Hi Damien and Albert, 

Thank you for your replies. Please note that there are 25 queries that remain unanswered (see below). We will wait until these have been addressed before moving forward with the publication process. 

Best regards,
RFC Editor/ap

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

> On Sep 13, 2022, at 5:11 AM, Albert Cabellos <[e-mail]> wrote:
> 
> 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
>>> 
>>> 
>> 
>