[lisp] AD Review of draft-ietf-lisp-6834bis-09

[Luigi Iannone <[e-mail]>]

Hi Alvaro,

A new revision of the 6834bis has been just submitted.
This time considering all of your review!
It hopefully addresses all of your concerns.
Inline you can find detailed answers to the pints you raised.

Ciao

L.

> On 13 Apr 2022, at 20:54, Alvaro Retana <[e-mail]> wrote:
> 
> Dear authors/WG:
> 
> While I appreciate the small number of changes from rfc6834 and the
> original intent (from 2018) of processing this document quickly, but
> it requires a non-trivial amount of work.  It is now going for
> Proposed Standard, so we need to be more rigorous.
> 
> I put detailed comments inline (below).  There are two main themes
> that I want to highlight here:
> 
> (1) Duplication and overlap
> 
> Several parts of this document describe the same or related behaviors.
> This issue has resulted in duplicate descriptions and specifications, not
> all of them saying the same thing. :-(  The problem extends beyond this
> document into both rfc6830bis and rfc6833bis.  I pointed and cross-
> referenced the sections as best as I could below.
> 
> In general, please specify the behavior only once.  Doing so in multiple
> places can be confusing and, as in this case, result in the specifications
> not being in sync.
> 
> Note that to address this point we may need to update rfc6830bis and
> rfc6833bis.  I would prefer to see as much of the specification related to
> Map-Versioning as possible (all?) in this document.  Removing pieces and
> referencing this document shouldn't require removing them from the RFC
> Editor's queue -- and they both Normatively depend on this document anyway.
> 
> One specific action is to remove the text from §13.2/rfc6830bis.  Some of
> it is already covered in this document -- the remaining pieces, which I
> believe are only the last couple of paragraphs, can find a better home.

[LI] Having a look to 6830bis:
Yes, Section 13.2 can be dropped altogether. 6830bis references Section 13.2 in Section 10 and Section 5.3. Both references can be replaced to a reference to 6834bis.
As for the last two paragraphs: The very last  is the text to be put in section 5.3.
The second last is actually already present in the security section of 6834bis. This should be enough, right?
I would just add the sentence “Further security considerations on Map-Versioning can be found in [6834bis]” in the paragraph mentioning Map-Versioning in Section 16 “Security Considerations” in 6833bis.

For 6833bis:
In Section 5.4 replacing:

Map-Version Number:  When this 12-bit value is non-zero, the Map-
  Reply sender is informing the ITR what the version number is for
  the EID record contained in the Map-Reply.  The ETR can allocate
  this number internally but MUST coordinate this value with other
  ETRs for the site.  When this value is 0, there is no versioning
  information conveyed.  The Map-Version Number can be included in
  Map-Request and Map-Register messages.  See Map-Versioning
  [I-D.ietf-lisp-6834bis] for more details.

With:

Map-Version Number:  12-bit version number assigned to the EID
  record contained in the Map-Reply.  See Map-Versioning
  [I-D.ietf-lisp-6834bis] for more details.

The above should completely eliminate any duplication.





> 
> 
> (2) Document Structure
> 
> As I started reading this document, I found myself going back to rfc6830bis
> to look for packet formats -- and I wasn't even past the Introduction!  I
> then realized that some of the information was in this document but an
> unexpected order.  Some actionable comments:
> 
> (1) Simplify the Introduction; there's too much detail.  For example, it
> mentions the location of the Map-Version in excruciating detail ("the 24
> low-order bits of the first longword of the LISP header"), but the
> description is wrong (see more inline).  There are explanations about the
> topics later on but no forward references.  Instead, paint a high-level
> picture and tell the reader where to find the details.
> 
> (2) Beyond the Introduction, the document is ordered in a cumbersome way:
> The location and format of the Map-Version are presented in §6, but both
> §4/§5 describe how the versions are handled.  It would be much better for
> the reader if §6 were moved forward.  This is my suggested ordering:
> 
> 6.  LISP Header and Map-Version Numbers
> 7.  Map Record and Map-Version (this could be a subsection)
> 4.  EID-to-RLOC Map-Version Number
> 5.  Dealing with Map-Version Numbers
> 
> Also, I suggest moving §8 to an Appendix.

[LI] Re-organized as suggested (thanks).


> 
> As we have a constrained timeline for this document, I would like to
> start the IETF Last-Call by the end of this month.  I have a lot of
> comments, but I don't think they will be hard to address.
> 
> Please reply inline to this message to expedite my review of any
> updates.  Also, if you think talking would clear things up faster,
> feel free to find time on my calendar:
> https://doodle.com/mm/alvaroretana/book-a-time
> 
> 
> Padma:  As Shepherd, I'll need you to please update the writeup when
> the final version is ready.
> 
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> [Line numbers from idnits.]
> 
> ...
> 13	Abstract
> 
> 15	   This document describes the LISP (Locator/ID Separation Protocol)
> 16	   Map-Versioning mechanism, which provides in-packet information about
> 17	   Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to
> 18	   encapsulate LISP data packets.  The proposed approach is based on
> 19	   associating a version number to EID-to-RLOC mappings and the
> 20	   transport of such a version number in the LISP-specific header of
> 21	   LISP-encapsulated packets.  LISP Map-Versioning is particularly
> 22	   useful to inform communicating Ingress Tunnel Routers (ITRs) and
> 23	   Egress Tunnel Routers (ETRs) about modifications of the mappings used
> 24	   to encapsulate packets.  The mechanism is optional and transparent to
> 25	   implementations not supporting this feature, since in the LISP-
> 26	   specific header and in the Map Records, bits used for Map-Versioning
> 27	   can be safely ignored by ITRs and ETRs that do not support or do not
> 28	   want to use the mechanism.
> 
> [minor] s/proposed//g
> This mechanism is now on the standards track, so it is not "proposed"
> any more. :-)

[LI] Fixed!

> 
> 
> ...
> 93	1.  Introduction
> 
> [] As I mentioned above, please simplify this section.  I left
> comments below, but I think that most of the text can be changed for a
> high-level description.
> 
> 
> ...
> 113	   When Map-Versioning is used, LISP-encapsulated data packets contain
> 114	   the version number of the two mappings used to select the RLOCs in
> 115	   the outer header (i.e., both source and destination RLOCs).  These
> 116	   version numbers are encoded in the 24 low-order bits of the first
> 117	   longword of the LISP header and indicated by a specific bit in the
> 118	   flags (first 8 high-order bits of the first longword of the LISP
> 119	   header).  Note that not all packets need to carry version numbers.
> 
> [major] "version numbers are encoded in the 24 low-order bits of the
> first longword of the LISP header"


[LI] Text dropped as part of the simplification of the Introduction (was actually a relic of early LISP documents…).


> 
> Wow!  That's not an easy reference to follow!
> 
> I went to find the "LISP Header" and found this definition in rfc6830bis:
> 
> LISP Header:   LISP header is a term used in this document to refer
>   to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
>   specific 8-octet header that follow the UDP header and that an ITR
>   prepends or an ETR strips.
> 
> If the LISP Header includes the "outer IPv4 or IPv6 header, a UDP
> header, and a LISP-specific 8-octet header" then the "24 low-order
> bits of the first longword" maps to something different. :-(
> 
> Instead, it would be easier for everyone to simple show the header
> with the V-bit set (from rfc6830bis):
> 
>  0 x 0 1 x x x x
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                 Instance ID/Locator-Status-Bits               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> [major] "indicated by a specific bit in the flags (first 8 high-order
> bits of the first longword of the LISP header)."

[LI] text simplified and put explicit reference to the figure.

> 
> Please replace that with a specific mention to the V-bit.
> 
> 
> 121	   When an ITR (Ingress Tunnel Router) encapsulates a data packet, with
> 122	   a LISP header containing the Map-Version numbers, it puts in the
> 123	   LISP-specific header two version numbers:
> 
> 125	   1.  The version number assigned to the mapping used to select the
> 126	       source RLOC (contained in the EID-to-RLOC Database).
> 
> 128	   2.  The version number assigned to the mapping used to select the
> 129	       destination RLOC (contained in the EID-to-RLOC Map-Cache).
> 
> [major] Please use the names in the packet formats: indicate which is
> the "Source Map-Version" and which the "Dest Map-Version".
> 
> 

[LI] as part of the simplification of the Introduction this text has been dropped.

> ...
> 154	3.  Definitions of Terms
> 
> 156	   This document uses terms already defined in the main LISP
> 157	   specification ([I-D.ietf-lisp-rfc6830bis],
> 158	   [I-D.ietf-lisp-rfc6833bis]).  Here, we define the terms that are
> 159	   specific to the Map-Versioning mechanism.  Throughout the whole
> 160	   document, Big Endian bit ordering is used.
> 
> [major] Please avoid redefining terms that are already defined
> elsewhere.  Changes in either (even if editorial) may cause the
> documents to fall out of sync.  If you want to call attention to
> specific terms, please point at the original definition or a specific
> section.



> 
> For example:
> 
> Map-Version Number:  as defined in §7.
> 
> 
> 162	   Map-Version number:  An unsigned 12-bit integer is assigned to an
> 163	     EID-to-RLOC mapping, excluding the value 0 (0x000).
> 
> [major] Beyond being a 12-bit integer, this definition doesn't say
> what the Map-Version number is.  §7 contains a much better
> description.
> 

[LI] Modified to clarify what it is.

> 165	   Null Map-Version:  The 12-bit null value of 0 (0x000) is not used as
> 166	     a Map-Version number.  It is used to signal that no Map-Version
> 167	     number is assigned to the EID-to-RLOC mapping.
> 
> [] Suggestion>
> Null Map-Version:  A Map-Version number with a value of 0x000 (zero),
>   used to signal that no Map-Version number is assigned to the
>   EID-to-RLOC mapping (Section 4.1).

[LI] Thanks we used your text.

> 
> 169	   Source Map-Version number:  This Map-Version number of the EID-to-
> 170	     RLOC mapping is used to select the source address (RLOC) of the
> 171	     outer IP header of LISP-encapsulated packets.
> 
> [major] This definition describes what the Source Map-Version number
> is used for, but not what it is.  Also, the definition in §6 is
> different from the one here -- it is close, but not the same.  Please
> define terminology in only one place.  It seems to me that leaving
> this definition up to §6 would be best.
> 
> 
> 173	   Destination Map-Version number:  This Map-Version number of the EID-
> 174	     to-RLOC mapping is used to select the destination address (RLOC) of
> 175	     the outer IP header of LISP-encapsulated packets.
> 
> [major] The packet format in rfc6830bis uses "Dest Map-Version"
> instead of "Destination Map-Version".  Please use the same terminology
> in the packet format and throughout the document.
> 
> 

[LI] Fixed the definition of both source and dest map-version.
Also fixed the name to use “Dest Map-Version” throughout the document.


> [major] Same comment as above: it describes what it's used for, not
> what it is.  There's a different definition in §6.
> 
> 
> 177	4.  EID-to-RLOC Map-Version Number
> 
> 179	   The EID-to-RLOC Map-Version number consists of an unsigned 12-bit
> 180	   integer.  The version number is assigned on a per-mapping basis,
> 181	   meaning that different mappings have a different version number,
> 182	   which is also updated independently.  An update in the version number
> 183	   (i.e., a newer version) consists of incrementing by one the older
> 184	   version number.
> 
> [major] "incrementing by one"
> 
> There's an exception in the case where V1+1 would result in 0, right?
> Please mention it.
> 

[LI] Added a reference to the end of Section 4.1.

> I later found that the last paragraph in §4.1 explains this exception.
> Please point to if from here, or move the paragraph to this section.
> Note that the text in §4.1 normatively requires (MUST) the increment,
> but the description here doesn't use normative language.  Please be
> consistent.
> 
> 

[LI] Isn’t the forwarding reference enough?

> ...
> 212	   Map-version numbers are assigned to mappings by configuration.  The
> 213	   initial Map-Version number of a new EID-to-RLOC mapping SHOULD be
> 214	   assigned randomly, but it MUST NOT be set to the Null Map-Version
> 215	   value (0x000), because the Null Map-Version number has a special
> 216	   meaning (see Section 4.1).
> 
> [major] "Map-version numbers are assigned to mappings by
> configuration.  The initial Map-Version number of a new EID-to-RLOC
> mapping SHOULD be assigned randomly..."
> 
> This sounds like a contradiction: configure, but make it random.  I
> assume that you mean that manual configuration may be the exception.
> 
> Suggestion>
> The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be
> assigned randomly; it MUST NOT be set to the Null Map-Version value
> (0x000) (see Section 4.1).  Optionally, the initial Map-Version number
> may be configured.

[LI] Thanks a lot. We included your suggestion.

> 
> ...
> 224	4.1.  The Null Map-Version
> 
> [] The comments below indicate that there are multiple places that
> overlap with this section.  The text from this section may be
> relocated (and clarifying actions taken) to make the document clearer.
> This section could then be eliminated.
> 
> Paragraph 1 could be moved to §6.
> 
> Paragraph 2 could be moved to §5/§5.1/§5.2.
> 
> Paragraph 3 could be moved to §7.
> 
> Paragraph 4 could be moved to §4.
> 

[LI] This is certainly a possible approach, but actually back to the writing of the original 6834, the section has been added in order to have one single place that specifies everything related to the null version number. If you really think that readability will have a huge improvement but spreading the content in other sections this can be done.



> 226	   The value 0x000 (zero) is not a valid Map-Version number indicating
> 227	   the version of the EID-to-RLOC mapping.  Such a value is used for
> 228	   special purposes and is named the Null Map-Version number.
> 
> 230	   The Null Map-Version MAY appear in the LISP-specific header as either
> 231	   a Source Map-Version number (cf.  Section 5.2) or a Destination Map-
> 232	   Version number (cf.  Section 5.1).  When the Source Map-Version
> 233	   number is set to the Null Map-Version value, it means that no map
> 234	   version information is conveyed for the source site.  This means that
> 235	   if a mapping exists for the source EID in the EID-to-RLOC Map-Cache,
> 236	   then the ETR MUST NOT compare the received Null Map-Version with the
> 237	   content of the EID-to-RLOC Map-Cache.  When the Destination Map-
> 238	   Version number is set to the Null Map-Version value, it means that no
> 239	   map version information is conveyed for the destination site.  This
> 240	   means that the ETR MUST NOT compare the value with the Map-Version
> 241	   number of the mapping for the destination EID present in the EID-to-
> 242	   RLOC Database.

[LI] Note the last two sentences have been delete because not consistent with other part of the document (as you pointed out later).

> 
> [major] "Null Map-Version MAY appear"
> 
> s/MAY/may
> 
> This is a statement of fact, not a Normative statement.
> 

[LI] Fixed.

> 
> [nit] s/cf.  //g
> 

[LI] Removed.


> 
> [minor] Please put a forward reference to §5.1/§5.2 where "MUST NOT
> compare" is used above.  §5.1/§5.2 don't use "compare" as part of
> their specification, but pointing to them should keep us from changing
> the language here.

[LI] OK. Added the references.

> 
> 244	   The other use of the Null Map-Version number is in the Map Records,
> 245	   which are part of the Map-Request, Map-Reply, and Map-Register
> 246	   messages (defined in [I-D.ietf-lisp-rfc6833bis]).  Map Records that
> 247	   have a Null Map-Version number indicate that there is no Map-Version
> 248	   number associated with the mapping.  This means that LISP-
> 249	   encapsulated packets destined to the EID-Prefix referred to by the
> 250	   Map Record MUST either not contain any Map-Version numbers (V bit set
> 251	   to 0) or, if they contain Map-Version numbers (V bit set to 1), then
> 252	   the destination Map-Version number MUST be set to the Null Map-
> 253	   Version number.  Any value different from zero means that Map-
> 254	   Versioning is supported and MAY be used.
> 
> [] See comments in §7 about the requirements in this paragraph.
> 
> [nit] s/(defined in [I-D.ietf-lisp-rfc6833bis])/[I-D.ietf-lisp-rfc6833bis]/g
> 
> 

[LI] The intention of reference about 6833bis was about the messages and the fact that map record are send through those message.
But the text is misleading. The reference is removed and the text simplified to focus only on Map Records, which is what is specified in this document.
We also moved the paragraph up, which look more logical.


> [major] "Any value different from zero means that Map-Versioning is
> supported and MAY be used."

[LI] Sentence deleted because covered by other parts of the document.

> 

> 256	   The fact that the 0 value has a special meaning for the Map-Version
> 257	   number implies that, when updating a Map-Version number because of a
> 258	   change in the mapping, if the next value is 0, then the Map-Version
> 259	   number MUST be incremented by 2 (i.e., set to 1 (0x001), which is the
> 260	   next valid value).
> 
> [] See my comment in §4 about this exception.

[LI] We added a reference in Section 4.

> 
> 262	5.  Dealing with Map-Version Numbers
> ...
> 272	   To each mapping, a version number is associated and changes each time
> 273	   the mapping is changed.  Note that Map-Versioning does not introduce
> 274	   new problems concerning the coordination of different ETRs of a
> 275	   domain.  Indeed, ETRs belonging to the same LISP site must return for
> 276	   a specific EID-prefix the same mapping, including the same Map-
> 277	   Version number.  This is orthogonal to whether or not Map-Versioning
> 278	   is used.  The synchronization problem and its implications on the
> 279	   traffic are out of the scope of this document.
> 
> [] See my comment in §7 about leaving this out of scope and the
> requirement from rfc6833bis.
> 

[LI] This paragraph has been dropped to avoid duplication. 
The synchronization problem is mentioned only in the deployment consideration section, where the text has also be simplified for clarity.

> ...
> 304	   If one or both of the above conditions do not hold, the ETR can send
> 305	   a Map-Request either to make the ITR aware that a new mapping is
> 306	   available (see Section 5.1) or to update the mapping in the local
> 307	   EID-to-RLOC Map-Cache (see Section 5.2).
> 
> [major] Should this behavior be Normative (MUST/SHOULD)?  The text
> currently says that "the ETR can send"; if the text doesn't require
> (or at least recommend) an action then it looks like this document
> just talks about carrying extra numbers around that don't serve a
> specific purpose.  I believe that §10 makes a good case for an action
> to be specified.

[LI] Good point. Updated to a SHOULD.

> 
> 
> 309	5.1.  Handling Destination Map-Version Number
> 
> 311	   When an ETR receives a packet, the Destination Map-Version number
> 312	   relates to the mapping for the destination EID for which the ETR is
> 313	   an RLOC.  This mapping is part of the ETR EID-to-RLOC Database.
> 314	   Since the ETR is authoritative for the mapping, it has the correct
> 315	   and up-to-date Destination Map-Version number.  A check on this
> 316	   version number can be done, where the following cases can arise:
> 
> [major] "A check on this version number can be done..."  Same comment
> as above: Should this behavior be Normative (MUST/SHOULD)?

[LI] Another good point, SHOULD has been used.

> 
> 
> ...
> 323	   2.  The packet arrives with a Destination Map-Version number greater
> 324	       (i.e., newer) than the one stored in the EID-to-RLOC Database.
> 325	       Since the ETR is authoritative on the mapping, meaning that the
> 326	       Map-Version number of its mapping is the correct one, this
> 327	       implies that someone is not behaving correctly with respect to
> 328	       the specifications.  In this case, the packet carries a version
> 329	       number that is not valid; otherwise, the ETR would have the same
> 330	       number, and the packet SHOULD be silently dropped
> 
> [minor] The "otherwise" in this last sentence gives the impression
> that the packet is dropped "otherwise" (i.e. when the version is not
> greater).
> 
> Suggestion>
> In this case, the packet carries a version number that is not valid
> and the packet SHOULD be silently dropped.
> 
> 
> [major] When is it ok for the packet not to be dropped?  Why is this
> action recommended and not required?
> 

[LI] We simplified the sentence and changed for a MUST.


> 
> 332	   3.  The packets arrive with a Destination Map-Version number smaller
> 333	       (i.e., older) than the one stored in the EID-to-RLOC Database.
> 334	       This means that the ITR sending the packet has an old mapping in
> 335	       its EID-to-RLOC Map-Cache containing stale information.  The ETR
> 336	       MAY choose to normally process the encapsulated datagram
> 337	       according to [I-D.ietf-lisp-rfc6830bis]; however, the ITR sending
> 338	       the packet has to be informed that a newer mapping is available.
> 339	       This is done with a Map-Request message sent back to the ITR.
> 340	       The Map-Request will either trigger a Map-Request back using the
> 341	       Solicit-Map-Request (SMR) bit or it will piggyback the newer
> 342	       mapping.  These are not new mechanisms; how to use the SMR bit or
> 343	       how to piggyback mappings in Map-Request messages is already
> 344	       described in [I-D.ietf-lisp-rfc6833bis].  One feature introduced
> 345	       by Map-Version numbers is the possibility of blocking traffic not
> 346	       using the latest mapping.  Indeed, after a certain number of
> 347	       retries, if the Destination Map-Version number in the packets is
> 348	       not updated, the ETR MAY drop packets with a stale Map-Version
> 349	       number while limiting the rate of Map-Request messages.  This is
> 350	       because either the ITR is refusing to use the mapping for which
> 351	       the ETR is authoritative, or (worse) it might be some form of
> 352	       attack.
> 
> [major] (Related to the last comment in §5.) "the ITR sending the
> packet has to be informed that a newer mapping is available"
> 
> "has to be informed" sounds like a requirement.  Should this action be
> Normative?

[LI] Excellent catch. Yes, SHOULD is the most appropriate action (you can avoid sending anything if already tried according to retry policy below)

> 
> 
> [minor] If you're going to point at rfc6833bis anyway, don't go into
> unnecessary detail.
> 
> OLD>
>    This is done with a Map-Request message sent back to the ITR.
>    The Map-Request will either trigger a Map-Request back using the
>    Solicit-Map-Request (SMR) bit or it will piggyback the newer
>    mapping.  These are not new mechanisms; how to use the SMR bit or
>    how to piggyback mappings in Map-Request messages is already
>    described in [I-D.ietf-lisp-rfc6833bis].
> 
> NEW>
> This is done with a Map-Request message sent back to the ITR, as
> specified in [I-D.ietf-lisp-rfc6833bis].

[LI] Yes. Text has been cut.

> 
> 
> [major] "after a certain number of retries...the ETR MAY drop packets"
> 
> If this is a Normative action, then the number of retries should be
> indicated or at least suggested.  §5.3/rfc6833bis mentions this:
> 
> Map-Requests MUST be rate-limited to 1 per second per EID-prefix.
> After 10 retransmits without receiving the corresponding Map-Reply
> the sender MUST wait 30 seconds.
> 
> Would 10 reties be appropriate in this case?
> 

[LI] Thanks we refer to that policy and state that when Map-Request are sent every 30 seconds packets with stale version number 

> 
> [major] "ETR MAY drop packets"
> 
> Why is this an optional action and not required?  What should the ETR
> take into account when deciding if the packets are to be dropped or
> not?

[LI] The GW discussed this point. The outcome was to give the operator the choice whether it prefers to drop the traffic for safety or take a risk  and avoid dropping traffic (quid to drop the inner packet at the final destination). 
However,  SHOULD is more correct as assertion. The text has been updated .

> 
> 
> 354	   The rule in the third case MAY be more restrictive.  If the mapping
> 355	   has been the same for a period of time as long as the Time To Live
> 356	   (TTL) (defined in [I-D.ietf-lisp-rfc6833bis]) of the previous version
> 357	   of the mapping, all packets arriving with an old Map-Version SHOULD
> 358	   be silently dropped right away without issuing any Map-Request.  Such
> 359	   action is permitted because if the new mapping with the updated
> 360	   version number has been unchanged for at least the same time as the
> 361	   TTL of the older mapping, all the entries in the EID-to-RLOC Map-
> 362	   Caches of ITRs must have expired.  Hence, all ITRs sending traffic
> 363	   should have refreshed the mapping according to
> 364	   [I-D.ietf-lisp-rfc6833bis].  If packets with old Map-Version numbers
> 365	   are still received, then either someone has not respected the TTL or
> 366	   it is a form of spoof/attack.  In both cases, this is not valid
> 367	   behavior with respect to the specifications and the packet SHOULD be
> 368	   silently dropped.
> 
> [major] s/MAY be more restrictive/may be more restrictive
> This is just a statement of fact, not a normative one.

[LI] fixed.

> 
> 
> [minor] "the Time To Live (TTL) (defined in
> [I-D.ietf-lisp-rfc6833bis]) of the previous version"
> 
> I wasn't sure if you meant that the TTL was defined in rfc6833bis or
> if a specific value was defined there.  But after looking at
> rfc6833bis I am guessing that you mean something like this:
> 
> OLD>
> If the mapping has been the same for a period of time as long as
> the Time To Live (TTL) (defined in [I-D.ietf-lisp-rfc6833bis])
> of the previous version of the mapping, ...
> 
> NEW>
> If the Record TTL of the previous mapping has already expired, ...

[LI] Short and to the point. Thanks.

> 
> 
> [major] "all packets...SHOULD be silently dropped"
> 
> Why is this action recommended and not required?  When is it ok for
> the the packets to not be dropped?

[LI] like for a previous point, if the traffic is considered safe it can avoid drop.
Text has been updated.

> 
> 
> [minor] s/In both cases, this is not valid behavior with respect to
> the specifications and the packet SHOULD be silently dropped./In both
> cases, this is not valid behavior.
> 
> Please don't repeat the specification.

[LI] Fixed.

> 
> 
> 370	   LISP-encapsulated packets with the V-bit set, when the original
> 371	   mapping in the EID-to-RLOC Database has the version number set to the
> 372	   Null Map-Version value, MAY be silently dropped.  As explained in
> 373	   Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it
> 374	   means that ITRs, using the mapping for encapsulation, MUST NOT use a
> 375	   Map-Version number in the LISP-specific header.
> 
> [major] "MAY be silently dropped" -- "As explained in Section 4.1..."
> 
> Please look at the related comments in §4.1/§7 about the required
> behavior.  BTW, the reference should be to §7.

[LI] Because of previous changes the reference remains the one toward the null map-version number (where everything is about that mapping is concentrated).

> 
> If there is a required (MUST) behavior in §4.1/§7, why is the behavior
> specified here only optional (MAY)?  What should the ETR take into
> account when making the decision?

[LI] Fixed just using the reference.

> 
> Also, please just refer to other sections and don't repeat normative
> language here.

[LI] Done.

> 
> 
> 377	   For LISP-encapsulated packets with the V-bit set, when the original
> 378	   mapping in the EID-to-RLOC Database has the version number set to a
> 379	   value different from the Null Map-Version value, a Destination Map-
> 380	   Version number equal to the Null Map-Version value means that the
> 381	   Destination Map-Version number MUST be ignored.
> 
> [] I find this sentence (and the first one in the previous paragraph)
> hard to read.
> 
> Suggestion>
> If the mapping in the EID-to-RLOC Database has a non-zero version
> number, LISP-encapsulated packets with the V-bit set and a Null
> Map-Version in the Dest Map-Version field MUST be ignored.
> 
> 
> [minor] "MUST be ignored"
> 
> I'm assuming that ignoring a packet is the same as dropping it, right?
> The other instances talked about dropping, please be consistent.
> 

[LI] Actually all of the above is deleted. This can be an attack vector and is against the actual purpose of map versioning. 


> 
> 383	5.2.  Handling Source Map-Version Number
> ...
> 391	   1.  The packet arrives with the same Source Map-Version number as
> 392	       that stored in the EID-to-RLOC Map-Cache.  This is the correct
> 393	       regular case.  The ITR has in its EID-to-RLOC Map-Cache an up-to-
> 394	       date copy of the mapping.  No further actions are needed.
> 
> [minor] s/ITR/ETR

[LI] Fixed. 

> 
> 396	   2.  The packet arrives with a Source Map-Version number greater
> 397	       (i.e., newer) than the one stored in the local EID-to-RLOC Map-
> 398	       Cache.  This means that the ETR has in its EID-to-RLOC Map-Cache
> 399	       a stale mapping that needs to be updated.  A Map-Request SHOULD
> 400	       be sent to get the new mapping for the source EID.  This is a
> 401	       normal Map-Request message sent through the mapping system and
> 402	       MUST respect the specifications in [I-D.ietf-lisp-rfc6833bis],
> 403	       including rate-limitation policies.
> 
> [major] "Map-Request SHOULD be sent"
> 
> Why is this action recommended and not required?  When is it ok for
> the ETR to not send a Map-Request (in response to this event)?

[LI] It is now a MUST.
> 
> 
> [minor] The last sentence, specially the part requiring respect for
> rfc6833bis is not needed.  Please take it out.

[LI] While we can agree, the WG felt was important to be clear that no new signaling is proposed in this document.

We simplified the sentence as:

This is a normal Map-Request message sent through the LISP control plane 
according to [I-D.ietf-lisp-rfc6833bis], including rate-limitation policies.  

> 
> 
> 405	   3.  The packet arrives with a Source Map-Version number smaller
> 406	       (i.e., older) than the one stored in the local EID-to-RLOC Map-
> 407	       Cache.  Such a case is not valid with respect to the
> 408	       specifications.  Indeed, if the mapping is already present in the
> 409	       EID-to-RLOC Map-Cache, this means that an explicit Map-Request
> 410	       has been sent and a Map-Reply has been received from an
> 411	       authoritative source.  Assuming that the mapping system is not
> 412	       corrupted, the Map-Version in the EID-to-RLOC Map-Cache is the
> 413	       correct one, while the one carried by the packet is stale.  In
> 414	       this situation, the packet MAY be silently dropped.
> 
> [] "Assuming that the mapping system is not corrupted"
> 
> I don't think this text adds anything to the specification -- just
> opens up questions of mapping system consistency, etc.. which we don't
> want to address in this document.  Please take that part out.

[LI] Done.

> 
> 
> [major] "the packet MAY be silently dropped"
> 
> Why is this action optional and not required?  The rest of the
> paragraph talks about how this "case is not valid with respect to the
> specifications" -- I then don't understand why it would only be
> optional to drop the packet.

[LI] Correct, it is a SHOULD with explanation about exceptions.


> 
> 
> ...
> 419	   For LISP-encapsulated packets with the V-bit set, if the Source Map-
> 420	   Version number is the Null Map-Version value, it means that the
> 421	   Source Map-Version number MUST be ignored.
> 
> [] There is related text in §4.1.  Please specify actions only once.

[LI] Indeed, text dropped.

> 
> 
> 423	6.  LISP Header and Map-Version Numbers
> 
> 425	   In order for the versioning approach to work, the LISP-specific
> 426	   header has to carry both the Source Map-Version number and
> 427	   Destination Map-Version number.  This is done by setting the V-bit in
> 428	   the LISP-specific header as specified in [I-D.ietf-lisp-rfc6830bis].
> 429	   When the V-bit is set and the N bit is reset (0), the low-order 24
> 430	   bits of the first longword are used to transport both the source and
> 431	   destination Map-Version numbers.  In particular, the first 12 bits
> 432	   are used for the Source Map-Version number and the second 12 bits for
> 433	   the Destination Map-Version number.
> 
> [minor] "... as specified in [I-D.ietf-lisp-rfc6830bis].  When the
> V-bit is set and the N bit is reset (0), the low-order 24 bits of the
> first longword are used to transport both the source and destination
> Map-Version numbers.  In particular, the first 12 bits are used for
> the Source Map-Version number and the second 12 bits for the
> Destination Map-Version number."
> 
> rfc6830bis also shows (§5.3) that the E-bit is not set.  That makes
> this description incomplete.  Instead of trying to repeat what
> rfc6830bis already says, simply point at it.  Also, a picture is worth
> a thousand words -- in this case it can replace cumbersome
> descriptions:
> 
> Suggestion>
> ... as specified in [I-D.ietf-lisp-rfc6830bis].  The Source
> Map-Version and Dest Map-Version are included as shown in
> Figure x.

[LI] Text modified.

> 
> 
> 435	   Below is an example of a LISP header carrying version numbers.
> 
> [major] s/LISP header/LISP-specific header

[LI] Fixed.

> 
> Note the definition of "LISP header" in rfc6830bis:
> 
> LISP Header:   LISP header is a term used in this document to refer
>   to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
>   specific 8-octet header that follow the UDP header and that an ITR
>   prepends or an ETR strips.
> 
> 
> 437	        0                   1                   2                   3
> 438	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 439	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 440	     / |N|L|E|V|I|R|K|K|  Source Map-Version   |Destination Map-Version|
> 441	   LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 442	     \ |                 Instance ID/Locator Status Bits               |
> 443	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> [minor] Please add a figure number/title to this and all the figures.
> 

[LI] Done
> 
> [minor] s/Locator Status Bits/Locator-Status-Bits/g

[LI] Fixed.

> 
> 
> ...
> 450	   Destination Map-Version number (12 bits):  Map-Version of the mapping
> 451	     used by the ITR to select the RLOC present in the "Destination
> 452	     Routing Locator" field.  Section 5.1 describes how to set this
> 453	     value on transmission and handle it on reception.
> 
> [minor] The description in §5.1 says that "the Destination Map-Version
> number relates to the mapping for the destination EID for which the
> ETR is an RLOC."  I know that this description is equivalent to "the
> mapping used by the ITR to select the RLOC present in the "Destination
> Routing Locator" field", but they are different.  It might be worth
> spending a paragraph or two in the Introduction summarizing how LISP
> works.  Or, even better, put an Informative reference to
> lisp-introduction.
> 
> Suggestion (for the Introduction)>
> [lisp-introduction] describes the architecture of the Locator/ID
> Separation Protocol.  It is expected that the reader is familiar
> with this introductory document.
> 

[LI] We might be wrong but with 6830bis and 6833bis normative being familiar with LISP is already there. It is the very essence of the difference between normative and informative documents. We added anyway the reference.


> 
> ...
> 460	7.  Map Record and Map-Version
> 
> 462	   To accommodate the proposed mechanism, the Map Records that are
> 463	   transported in Map-Request/Map-Reply/Map-Register messages need to
> 464	   carry the Map-Version number as well.  For this purpose, the 12 bits
> 465	   before the EID-AFI field in the Record that describes a mapping are
> 466	   used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example.
> 
> [minor] "For this purpose, the 12 bits before the EID-AFI field in the
> Record that describes a mapping are used (see
> [I-D.ietf-lisp-rfc6833bis] and reported here as an example."
> 
> The description is again cumbersome ("12 bits before") -- simply point
> at the figure.  Also, I'm not sure what the example part means.
> 
> Suggestion>
> For reference, the Map Register (specified in [I-D.ietf-lisp-rfc6833bis])
> is presented in Figure y.
> 

[LI] Done thanks.

> 
> 468	        0                   1                   2                   3
> 469	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 470	   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 471	   |   |                          Record TTL                           |
> 472	   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 473	   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
> 474	   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 475	   c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
> 476	   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 477	   r   |                          EID-Prefix                           |
> 478	   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 479	   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
> 480	   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 481	   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
> 482	   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 483	   |  \|                             Locator                           |
> 484	   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 486	   Map-Version Number:  Map-Version of the mapping contained in the
> 487	     Record.  As explained in Section 4.1, this field can be zero (0),
> 488	     meaning that no Map-Version is associated to the mapping; hence,
> 489	     packets that are LISP encapsulated using this mapping MUST NOT
> 490	     contain Map-Version numbers in the LISP-specific header, and the
> 491	     V-bit MUST be set to 0.
> 
> [major] This description is not the same as what is specified in §4.1
> or the definition in §5.4/rfc6833bis.  Please define this term only
> once!
> 

[LI] Description has been simplified to avoid inconsistencies.


> 
> (A) "Section 4.1...hence, packets that are LISP encapsulated using
> this mapping MUST NOT contain Map-Version numbers in the LISP-specific
> header, and the V-bit MUST be set to 0."
> 
> The required actions here are different from the actions required in §4.1:
> 
> This means that LISP-encapsulated packets destined to the EID-Prefix
> referred to by the Map Record MUST either not contain any Map-Version
> numbers (V bit set to 0) or, if they contain Map-Version numbers (V
> bit set to 1), then the destination Map-Version number MUST be set to
> the Null Map-Version number.  Any value different from zero means that
> Map-Versioning is supported and MAY be used.
> 
> Note that "MUST either" is not a valid construct because it doesn't
> reflect a requirement, it indicates an option.

[LI] The paragraph has been also changed because was not consistent with other parts of the document. 


> 
> 
> [B] §5.4/rfc6833bis contains a different definition of this field:
> 
> Map-Version Number:  When this 12-bit value is non-zero, the Map-
>   Reply sender is informing the ITR what the version number is for
>   the EID record contained in the Map-Reply.  The ETR can allocate
>   this number internally but MUST coordinate this value with other
>   ETRs for the site.  When this value is 0, there is no versioning
>   information conveyed.  The Map-Version Number can be included in
>   Map-Request and Map-Register messages.  See Map-Versioning
>   [I-D.ietf-lisp-6834bis] for more details.

[LI] See previous proposed fix to 6833bis.


> 
> The text in §5 is vague about the required coordination mentioned in
> rfc6883bis.  In fact, it mentions this: "The synchronization problem
> and its implications on the traffic are out of the scope of this
> document."   This is a significant problem!

[LI] Yes, it is  significant LISP problem, it is not specific to map versioning. That is the point of that sentence.


> 
> rfc6833bis requires (MUST) the coordination and points to this
> document for more details.  However, this document declares the
> problem out of scope.

[LI] That is just badly written specification about being in sync. 
With the proposed changes to 6833bis and the updated text in this document everything should be in line.

> 
> To make it worst, rfc6830bis both leaves synchronization out of scope
> *and* specifies a window for doing so: "synchronization protocol is
> out-of-the-scope of this document, but MUST keep ETRs synchronized
> within a 1 minute window."
> 
> How can the requirements in rfc6833bis/rfc6830bis be satisfied if the
> mechanism is out of scope?
> 
> 
> Personally, I am ok with the synchronization between ETRs to be out of
> scope. 

[LI] As previously stated this is a LISP problem, not a map versioning problem. 
Actually versioning can help since there is a direct way to check whether two LISP ETRs use the same mapping, as explained in the deployment considerations. As such the above sentence has been deleted because overlapping with discussion in the deployment consideration section.

> I need you to the come up with specific language that gets the
> specs in sync.  That will require eliminating the normative language
> and possibly updating rfc6830bis and rfc6833bis.

[LI] Do you consider the above-mentioned changes sufficient?

> 
> 
> 493	   This packet format works perfectly with xTRs that do not support Map-
> 494	   Versioning, since they can simply ignore those bits.
> 
> [nit] By "works perfectly" I assume you mean something less
> "marketing" like "is backwards compatible".

[LI] Yes, when changed the sentence.

> 
> 
> 496	8.  Benefits and Case Studies for Map-Versioning
> 
> [] I suggest this section be moved to an appendix.
> 
> 

[LI] Yes, it has been moved.

> ...
> 502	8.1.  Map-Versioning and Unidirectional Traffic
> ...
> 521	   In the case of the ITR, the ITR is able to put both the source and
> 522	   destination version number in the LISP header, since the Source Map-
> 523	   Version number is in the ITR's database, while the Destination Map-
> 524	   Version number is in the ITR's cache.
> 
> [nit] NEW>
> An ITR is able to put both the source and destination version
> numbers in the LISP header since the Source Map-Version number
> is in its database while the Destination Map-Version number is
> in its cache.

[LI] Changed, thanks.

> 
> 
> 526	   In the case of the ETR, the ETR simply checks only the Destination
> 527	   Map-Version number in the same way as that described in Section 5,
> 528	   ignoring the Source Map-Version number.
> 
> [nit] NEW>
> The ETR checks only the Dest Map-Version number as described
> in Section 5, ignoring the Source Map-Version number.
> 

[LI] Changed, thanks.

> 
> ...
> 612	8.4.  Map-Version Additional Use Cases
> 
> [] This use case, and specifically "a lightweight implementation of
> LISP" seems inline with the experimental version of this document, but
> not the current form.  Please remove it.
> 
> If there is a document describing that "lightweight implementation"
> then a reference can be added.
> 

[LI] Section has been dropped.

> 
> ...
> 628	9.  Security Considerations
> 
> 630	   Attackers can try to trigger a large number of Map-Requests by simply
> 631	   forging packets with random Map-Versions.  The Map-Requests are rate-
> 632	   limited as described in [I-D.ietf-lisp-rfc6833bis].  With Map-
> 633	   Versioning it is possible to filter invalid version numbers before
> 634	   triggering a Map-Request, thus helping to reduce the effects of DoS
> 635	   attacks.  However, it might not be enough to really protect from a
> 636	   DDoS attack.
> 
> [] Given what is specified here, are there other things that an
> attacker could do?  For example, just thinking out loud, not sure if
> these are possible:
> 
> - Can an attacker glean at headers and reuse the version numbers to
> generate additional traffic (to overload a node, for example) with a
> header that looks to be correct?

[LI] Not beyond the attack described above.

> 
> - If the network is configured to use Map-Versioning but a rogue node
> decides to not use the V-bit, are there significant consequences?  I
> don't think to, just asking.

[LI] Nice question. We don’t see any significant consequence.

> 
> - Is there any significant information (topology, cache content, for
> example) that could be gleaned from knowing the Map-Versions at
> different xTRs?  Besides the attack already mentioned, can an attacker
> do anything else with this knowledge?

[LI] Knowing the version number does not leak more information beyond the mapping itself.

> 
> 
> 638	   Robustness of the Map-Versioning mechanism leverages on a trusted
> 639	   Mapping Distribution System.  A thorough security analysis of LISP is
> 640	   documented in [RFC7835].
> 
> [major] We shouldn't get into aspects of what "trusted Mapping
> Distribution System" may be.  Instead of this paragraph, let's add a
> pointer to the base specs as the initial paragraph of this section.
> 
> Suggestion>
> This document builds on the specification and operation of the
> LISP control and data planes.  The Security Considerations of
> [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis] apply.

[LI] Changed, thanks.
> 
> 
> 642	   As specified in [I-D.ietf-lisp-rfc6830bis], Map-Versioning MUST NOT
> 643	   be used over the public Internet and SHOULD only be used in trusted
> 644	   and closed deployments.
> 
> [major] Please don't specify things in two places!  If specified in
> rfc6830bis and this section points there anyway there's no need to
> even mention it.

[LI] If Section 13.2 (in 6830bis) is dropped, then this document is the only place where it is stated.

> 
> 
> 646	10.  Deployment Considerations
> ...
> 692	   The same problem can, however, arise without Map-Versioning, for
> 693	   instance, if the two ITRs of Domain A send different Locator Status
> 694	   Bits.  In this case, either the traffic is disrupted if ETR B trusts
> 695	   the Locator Status Bits, or if ETR B does not trust the Locator
> 696	   Status Bits it will start sending Map-Requests to confirm each change
> 697	   in reachability.
> 
> [major] "ETR B trusts...ETR B does not trust"
> 
> Instead of talking about "trust", which may not convey the appropriate
> intent, please talk about "verification" (using the language in
> rfc6830bis) and how the ETR can verify and avoid disruptions.
> 

[LI] sentence has been reformulated.

> 
> 699	   So far, LISP does not provide any specific synchronization mechanism
> 700	   but assumes that synchronization is provided by configuring the
> 701	   different xTRs consistently.  The same applies for Map-Versioning.
> 702	   If in the future any synchronization mechanism is provided, Map-
> 703	   Versioning will take advantage of it automatically, since it is
> 704	   included in the Record format, as described in Section 7.
> 
> [minor] Both §5/§7 talk about synchronization.  Please consolidate
> this topic in one place.

[LI] Done. It is now only in deployment considerations.