Locator/ID Separation Protocol (LISP) Map-Versioning
draft-ietf-lisp-6834bis-14

[Ballot comment]
Thanks for the detailed discussion and the updates. I've cleared my DISCUSS. I'm not going to reply to the various individual messages because the net of the whole thing is "LGTM".

A few small nits on -14:

1. §A.1:

  The ETR checks only the Dest Map-Version number, ignoring the Source
  Map-Version number as specified in the final sentence of Section 7.2,
  ignoring the Source Map-Version number.

The source map-version number is getting double ignored, it must feel sad. :-) Probably should be:

  The ETR checks only the Dest Map-Version number, ignoring the Source
  Map-Version number as specified in the final sentence of Section 7.2.

2. §A.2:

  Map-Versioning is compatible with the LISP interworking between LISP
  and non-LISP sites as defined in [RFC6832].  LISP interworking
  defines three techniques to allow communication LISP sites and non-

Insert "between" between "communication" and "LISP sites", so:

  Map-Versioning is compatible with the LISP interworking between LISP
  and non-LISP sites as defined in [RFC6832].  LISP interworking
  defines three techniques to allow communication between LISP sites and non-

--

Original DISCUSS:

This spec makes liberal use of the approach of dropping any packet received with an unloved Map-Version number, for example (but not limited to)

  2.  The packet arrives with a Dest Map-Version number newer (as
      defined in Section 6) than the one stored in the EID-to-RLOC
      Database.  Since the ETR is authoritative on the mapping, meaning
      that the Map-Version number of its mapping is the correct one,
      this implies that someone is not behaving correctly with respect
      to the specifications.  In this case, the packet carries a
      version number that is not valid and packet MUST be silently
      dropped.

Isn’t it the case that by definition the packet has arrived at a valid ETR for the mapping (since as the text says, “the ETR is authoritative”)? Isn’t the map-version more in the nature of a hint than a critical-for-correctness field? What bad behavior is being protected against by silently dropping this traffic, that has arrived at a correct endpoint albeit with an incorrect hint?

At various points in the document there's a kind of vague assertion that incorrect map-versions could be an attack. While I don't deny that, the assertion isn't supported or elaborated on anywhere that I saw, which is worrying and also makes it less convincing. Shouldn't the Security Considerations talk about this? I did also go have a look at the Security Considerations in draft-ietf-lisp-rfc6833bis-31, which also didn't help me. RFC 7835 §3.3 does touch on this, suggesting that maybe an attacker could use a spoofed Map-Version to trigger a DoS attack. But this, too, is an unsatisfying rationale, since as you take pains to point out, rate limiting of Map-Requests and such is required. Furthermore, if triggering Map-Requests is the concern, couldn't the packet still be delivered, without triggering a Map-Request?

When this was an Experimental protocol this kind of thing was probably less crucial to justify and explain, but I would have expected the experiment to produce results that could be fed into this document. At the moment, the "drop any packet that doesn't comply with expectations" design feels arbitrary and potentially brittle. I would appreciate some discussion of this design choice, thanks in advance.

(I do acknowledge that security matters can be subtle, and I'm not a SEC AD after all... but all the more reason for the document to be explicit about what the security concerns are instead of just gesturing toward them and leaving the reader to guess.)

Original COMMENT:

I support Roman Danyliw's DISCUSS position.

I have a number of further questions and comments --

1. In §6.1:

          If an ETR receives LISP-encapsulated packets with the V-bit
  set, when the original mapping in the EID-to-RLOC Database has the
  version number set to the Null Map-Version value, then those packets
  MUST be silently dropped.

What does “original” mean in this context? Couldn’t the mapping in the db once have had a value but in a later revision, had its value changed to the null value? Presumably in such a situation packets would be lost until the ITR decided to issue a new map-request.


2. In §7.1 (3):

                                                    According to rate
      limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
      Request messages, after 10 retries Map-Requests are sent every 30
      seconds, if in the meantime the Dest Map-Version number in the
      packets is not updated, the ETR SHOULD drop packets with a stale
      Map-Version number.

What exactly is “the meantime”? Does that mean “after 10 retries”? After 30 seconds? Basically, what precisely is the grace period extended to the ITR have to come into compliance before being blocked? This seems important to be clear about -- even if the clarity is in the form of "it's implementation-dependent".


3. In §7.1, final paragraph:

  LISP-encapsulated packets cannot transport a Dest Map-Version number
  equal to the Null Map-Version number, because in this case the ETR is
  signaling that Map-Version numbers are not used for the mapping of
  the destination EID (see Section 6.1).

Considering that the Null Map-Version number is just the distinguished value 0, the first clause is prima facie wrong -- it's possible to encode 0 in that field. I think what you mean is something more along the lines of

  It is a protocol violation for LISP-encapsulated packets to contain a
  Dest Map-Version number equal to the Null Map-Version number, see
  Section 6.1.
 
Please don't try to explain it again in-line as you've done, it just confuses the reader (well, it confused me!). Instead, refer them back to the place where you specified the rule.

It does seem unfortunate that in this case, it's not possible to include a Source Map-Version number, even if that would be helpful to do, since the V bit is required to be set to 0 and covers both Source and Dest.


4. §7.1 (3), nit: s/The packets arrive/The packet arrives/


5. In §7.1 and §7.2:

                            A check on this version number SHOULD be
  done, where the following cases can arise:
 
and

                            If the ETR has an entry in its EID-to-RLOC
  Map-Cache for the source EID, then a check SHOULD be performed and
  the following cases can arise:

What are the cases under which the check can be omitted? Please consider adding discussion about those cases. Alternately, consider making the SHOULD a MUST if there are no such cases.


6. In §7.2:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Such a case is not valid with respect to the
      specifications.

The final sentence ("not valid") seems like it must be wrong: consider for example the case of out-of-order packets. Other scenarios also exist, such as transient non-synchronization between ETRs during convergence. I notice that §9 talks about the lack of synchronization mechanisms in LISP, other than diligent consistency of configuration. So, I guess there's a good chance that "convergence" means "someone updating mapping configurations by hand" and so version skew could exist for human-scale periods of time. Of greatest concern is if "human-scale periods of time" means "hours or days" in the case where a mistake with operational procedures leaves the hand-configured databases on two ETRs out of sync with one another.

I guess a minimum fix would be to simply cut the wrong sentence and slightly re-word, e.g.:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Note that if the mapping is already present in the
      EID-to-RLOC Map-Cache, this means that an explicit Map-Request
      has been sent and a Map-Reply has been received from an
      authoritative source.  In this situation, the packet SHOULD be
      silently dropped.  Operators can configure exceptions to this
      recommendation, which are outside the scope of this document.


7. In §7.2:

  If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
  the source EID, then the Source Map-Version number MUST be ignored.

I think it would be nice to have an xref to §A.1, where the reason for this is explained. Otherwise it seems rather arbitrary.


8. In §8:

I see that in -12 you cut the text that in -11 used to say

  Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.

I note that the requirement continues to exist however, since normative reference draft-ietf-lisp-rfc6830bis-38 §4.1 says

  Several of the mechanisms in this document are intended for
  deployment in controlled, trusted environments, and are insecure for
  use over the public Internet.  In particular, on the public internet
  xTRs:
...
  *  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

Thus it still seems to me that the questions others raised about this requirement may be relevant.

So, I question whether cutting the text is the right way to fix the concerns. It makes sense in an Experimental document, but perhaps not in a Standards Track one.


9. In §9:

  LISP requires ETRs to provide the same mapping for the same EID-
  Prefix to a requester.

What does this mean? Same as what? I guess maybe what you mean here is "LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix"? If so, please say that (or something else clearer than what's there now). If not, please help?


10. In §A.1:

  The ETR checks only the Dest Map-Version number as described in
  Section 7, ignoring the Source Map-Version number.

I would rewrite as

  The ETR checks only the Dest Map-Version number,
  ignoring the Source Map-Version number as specified in
  the final sentence of Section 7,.


11. In §A.2:

                                                LISP interworking
  defines three techniques to make LISP sites and non-LISP sites,
  namely Proxy-ITR, LISP-NAT, and Proxy-ETR.

This isn't a complete sentence. I guess what you mean is something like "LISP interworking defines three techniques to allow communication between LISP and non-LISP sites"?


12. In §A.2.1:

  With this setup, LISP Domain A is able to check whether the PITR is
  using the latest mapping.

First, how does Domain A check this? Second, the latest mapping for what? I suppose you might mean something like "Domain A is able to check whether the PITR is using the latest mapping for the destination EID, by inspecting the Destination Map-Version as detailed in Section 7.1"?


13. In §A.2.3:

  With this setup, the Proxy-ETR, by looking at the Source Map-Version
  Number, is able to check whether the mapping has changed.

Again, what mapping, and how? I guess it must be the source EID. (The version 12 text, which I've quoted here, makes that clearer, although it would still be even clearer to write "... check whether the Source EID-to-RLOC mapping has changed.") Why does the ETR care about that? I guess there's the assumption it might be an ITR/ETR passing traffic bidirectionally, in which case the source EID might be useful, but if that's the reason then some words to that effect would help.

[Ballot comment]
DISCUSS resolved by version 13/14. Old DISCUSS copied below:



Changed my comments to a DISCUSS, as Donald Eastlake also pointed these out in his secdir review, and I am now convinced we need better text to address this.

#1  map-version rollover is defined (to skip the 0 version) but I also see:

The packet arrives with a Dest Map-Version number greater (i.e.,
      newer) than the one stored in the EID-to-RLOC Database.  Since
      the ETR is authoritative on the mapping, meaning that the Map-
      Version number of its mapping is the correct one

This would imply rollover to a smaller number is not expected to occur ?

#2 MUST NOT or SHOULD ?

Map-Versioning MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments.

This sentence seems to contradict itself. I would turn the SHOULD into a MUST

[Ballot comment]
I support the discuss positions from Roman, Paul and John which I think cover the issues that I see in this document as well.

[Ballot comment]
The shepherd writeup says:

> It is the proper type of RFC since it provides updates to RFC 6834 Locator/ID
> Separation Protocol (LISP) Map-Versioning, which was an experimental document.

I don't follow.  Only a Proposed Standard can update an Experimental?

The SHOULD at the top of sections 7.1 and 7.2 are curious.  Does the protocol interoperate properly if both of those Map-Version checks are skipped, which the SHOULD allows in each case?  I would suggest including some guidance around when an implementation might legitimately choose not to do them.  Or should these be MUSTs or MAYs instead?

[Ballot discuss]
This spec makes liberal use of the approach of dropping any packet received with an unloved Map-Version number, for example (but not limited to)

  2.  The packet arrives with a Dest Map-Version number newer (as
      defined in Section 6) than the one stored in the EID-to-RLOC
      Database.  Since the ETR is authoritative on the mapping, meaning
      that the Map-Version number of its mapping is the correct one,
      this implies that someone is not behaving correctly with respect
      to the specifications.  In this case, the packet carries a
      version number that is not valid and packet MUST be silently
      dropped.

Isn’t it the case that by definition the packet has arrived at a valid ETR for the mapping (since as the text says, “the ETR is authoritative”)? Isn’t the map-version more in the nature of a hint than a critical-for-correctness field? What bad behavior is being protected against by silently dropping this traffic, that has arrived at a correct endpoint albeit with an incorrect hint?

At various points in the document there's a kind of vague assertion that incorrect map-versions could be an attack. While I don't deny that, the assertion isn't supported or elaborated on anywhere that I saw, which is worrying and also makes it less convincing. Shouldn't the Security Considerations talk about this? I did also go have a look at the Security Considerations in draft-ietf-lisp-rfc6833bis-31, which also didn't help me. RFC 7835 §3.3 does touch on this, suggesting that maybe an attacker could use a spoofed Map-Version to trigger a DoS attack. But this, too, is an unsatisfying rationale, since as you take pains to point out, rate limiting of Map-Requests and such is required. Furthermore, if triggering Map-Requests is the concern, couldn't the packet still be delivered, without triggering a Map-Request?

When this was an Experimental protocol this kind of thing was probably less crucial to justify and explain, but I would have expected the experiment to produce results that could be fed into this document. At the moment, the "drop any packet that doesn't comply with expectations" design feels arbitrary and potentially brittle. I would appreciate some discussion of this design choice, thanks in advance.

(I do acknowledge that security matters can be subtle, and I'm not a SEC AD after all... but all the more reason for the document to be explicit about what the security concerns are instead of just gesturing toward them and leaving the reader to guess.)

[Ballot discuss]
This spec makes liberal use of the approach of dropping any packet received with an unloved Map-Version number, for example (but not limited to)

  2.  The packet arrives with a Dest Map-Version number newer (as
      defined in Section 6) than the one stored in the EID-to-RLOC
      Database.  Since the ETR is authoritative on the mapping, meaning
      that the Map-Version number of its mapping is the correct one,
      this implies that someone is not behaving correctly with respect
      to the specifications.  In this case, the packet carries a
      version number that is not valid and packet MUST be silently
      dropped.

Isn’t it the case that by definition the packet has arrived at a valid ETR for the mapping (since as the text says, “the ETR is authoritative”)? Isn’t the map-version more in the nature of a hint than a critical-for-correctness field? What bad behavior is being protected against by silently dropping this traffic, that has arrived at a correct endpoint albeit with an incorrect hint?

At various points in the document there's a kind of vague assertion that incorrect map-versions could be an attack. While I don't deny that, the assertion isn't supported or elaborated on anywhere that I saw, which is worrying and also makes it less convincing. Shouldn't the Security Considerations talk about this? I did also go have a look at the Security Considerations in draft-ietf-lisp-rfc6833bis-31, which also didn't help me. RFC 7835 §3.3 does touch on this, suggesting that maybe an attacker could use a spoofed Map-Version to trigger a DoS attack. But this, too, is an unsatisfying rationale, since as you take pains to point out, rate limiting of Map-Requests and such is required. Furthermore, if triggering Map-Requests is the concern, couldn't the packet still be delivered, without triggering a Map-Request?

When this was an Experimental protocol this kind of thing was probably less crucial to justify and explain, but I would have expected the experiment to produce results that could be fed into this document. At the moment, the "drop any packet that doesn't comply with expectations" design feels arbitrary and potentially brittle. I would appreciate some discussion of this design choice.

(I do acknowledge that security matters can be subtle, and I'm not a SEC AD after all... but all the more reason for the document to be explicit about what the security concerns are instead of just gesturing toward them and leaving the reader to guess.)

[Ballot discuss]
This spec makes liberal use of the approach of dropping any packet received with an unloved Map-Version number, for example (but not limited to)

  2.  The packet arrives with a Dest Map-Version number newer (as
      defined in Section 6) than the one stored in the EID-to-RLOC
      Database.  Since the ETR is authoritative on the mapping, meaning
      that the Map-Version number of its mapping is the correct one,
      this implies that someone is not behaving correctly with respect
      to the specifications.  In this case, the packet carries a
      version number that is not valid and packet MUST be silently
      dropped.

Isn’t it the case that by definition the packet has arrived at a valid ETR for the mapping (since as the text says, “the ETR is authoritative”)? Isn’t the map-version more in the nature of a hint than a critical-for-correctness field? What bad behavior is being protected against by silently dropping this traffic, that has arrived at a correct endpoint albeit with an incorrect hint?

At various points in the document there's a kind of vague assertion that incorrect map-versions could be an attack. While I don't deny that, the assertion isn't supported or elaborated on anywhere that I saw, which is worrying and also makes it less convincing. Shouldn't the Security Considerations talk about this? I did also go have a look at the Security Considerations in draft-ietf-lisp-rfc6833bis-31, which also didn't help me. RFC 7835 §3.3 does touch on this, suggesting that maybe an attacker could use a spoofed Map-Version to trigger a DoS attack. But this, too, is an unsatisfying rationale, since as you take pains to point out, rate limiting of Map-Requests and such is required. Furthermore, if triggering Map-Requests is the concern, couldn't the packet still be delivered, without triggering a Map-Request?

When this was an Experimental protocol this kind of thing was probably less crucial to justify and explain, but I would have expected the experiment to produce results that could be fed into this document. At the moment, the "drop any packet that doesn't comply with expectations" design feels arbitrary and potentially brittle. I would appreciate some discussion of this design choice.

(I do acknowledge that security matters can be subtle, and I'm not a SEC AD after all... but all the more reason for the document to be explicit about what the security concerns are instead of just vaguely gesturing toward them and leaving the reader to guess.)

[Ballot comment]
I support Roman Danyliw's DISCUSS position.

I have a number of further questions and comments --

1. In §6.1:

          If an ETR receives LISP-encapsulated packets with the V-bit
  set, when the original mapping in the EID-to-RLOC Database has the
  version number set to the Null Map-Version value, then those packets
  MUST be silently dropped.

What does “original” mean in this context? Couldn’t the mapping in the db once have had a value but in a later revision, had its value changed to the null value? Presumably in such a situation packets would be lost until the ITR decided to issue a new map-request.


2. In §7.1 (3):

                                                    According to rate
      limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
      Request messages, after 10 retries Map-Requests are sent every 30
      seconds, if in the meantime the Dest Map-Version number in the
      packets is not updated, the ETR SHOULD drop packets with a stale
      Map-Version number.

What exactly is “the meantime”? Does that mean “after 10 retries”? After 30 seconds? Basically, what precisely is the grace period extended to the ITR have to come into compliance before being blocked? This seems important to be clear about -- even if the clarity is in the form of "it's implementation-dependent".


3. In §7.1, final paragraph:

  LISP-encapsulated packets cannot transport a Dest Map-Version number
  equal to the Null Map-Version number, because in this case the ETR is
  signaling that Map-Version numbers are not used for the mapping of
  the destination EID (see Section 6.1).

Considering that the Null Map-Version number is just the distinguished value 0, the first clause is prima facie wrong -- it's possible to encode 0 in that field. I think what you mean is something more along the lines of

  It is a protocol violation for LISP-encapsulated packets to contain a
  Dest Map-Version number equal to the Null Map-Version number, see
  Section 6.1.
 
Please don't try to explain it again in-line as you've done, it just confuses the reader (well, it confused me!). Instead, refer them back to the place where you specified the rule.

It does seem unfortunate that in this case, it's not possible to include a Source Map-Version number, even if that would be helpful to do, since the V bit is required to be set to 0 and covers both Source and Dest.


4. §7.1 (3), nit: s/The packets arrive/The packet arrives/


5. In §7.1 and §7.2:

                            A check on this version number SHOULD be
  done, where the following cases can arise:
 
and

                            If the ETR has an entry in its EID-to-RLOC
  Map-Cache for the source EID, then a check SHOULD be performed and
  the following cases can arise:

What are the cases under which the check can be omitted? Please consider adding discussion about those cases. Alternately, consider making the SHOULD a MUST if there are no such cases.


6. In §7.2:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Such a case is not valid with respect to the
      specifications.

The final sentence ("not valid") seems like it must be wrong: consider for example the case of out-of-order packets. Other scenarios also exist, such as transient non-synchronization between ETRs during convergence. I notice that §9 talks about the lack of synchronization mechanisms in LISP, other than diligent consistency of configuration. So, I guess there's a good chance that "convergence" means "someone updating mapping configurations by hand" and so version skew could exist for human-scale periods of time. Of greatest concern is if "human-scale periods of time" means "hours or days" in the case where a mistake with operational procedures leaves the hand-configured databases on two ETRs out of sync with one another.

I guess a minimum fix would be to simply cut the wrong sentence and slightly re-word, e.g.:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Note that if the mapping is already present in the
      EID-to-RLOC Map-Cache, this means that an explicit Map-Request
      has been sent and a Map-Reply has been received from an
      authoritative source.  In this situation, the packet SHOULD be
      silently dropped.  Operators can configure exceptions to this
      recommendation, which are outside the scope of this document.


7. In §7.2:

  If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
  the source EID, then the Source Map-Version number MUST be ignored.

I think it would be nice to have an xref to §A.1, where the reason for this is explained. Otherwise it seems rather arbitrary.


8. In §8:

I see that in -12 you cut the text that in -11 used to say

  Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.

I note that the requirement continues to exist however, since normative reference draft-ietf-lisp-rfc6830bis-38 §4.1 says

  Several of the mechanisms in this document are intended for
  deployment in controlled, trusted environments, and are insecure for
  use over the public Internet.  In particular, on the public internet
  xTRs:
...
  *  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

Thus it still seems to me that the questions others raised about this requirement may be relevant.

So, I question whether cutting the text is the right way to fix the concerns. It makes sense in an Experimental document, but perhaps not in a Standards Track one.


9. In §9:

  LISP requires ETRs to provide the same mapping for the same EID-
  Prefix to a requester.

What does this mean? Same as what? I guess maybe what you mean here is "LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix"? If so, please say that (or something else clearer than what's there now). If not, please help?


10. In §A.1:

  The ETR checks only the Dest Map-Version number as described in
  Section 7, ignoring the Source Map-Version number.

I would rewrite as

  The ETR checks only the Dest Map-Version number,
  ignoring the Source Map-Version number as specified in
  the final sentence of Section 7,.


11. In §A.2:

                                                LISP interworking
  defines three techniques to make LISP sites and non-LISP sites,
  namely Proxy-ITR, LISP-NAT, and Proxy-ETR.

This isn't a complete sentence. I guess what you mean is something like "LISP interworking defines three techniques to allow communication between LISP and non-LISP sites"?


12. In §A.2.1:

  With this setup, LISP Domain A is able to check whether the PITR is
  using the latest mapping.

First, how does Domain A check this? Second, the latest mapping for what? I suppose you might mean something like "Domain A is able to check whether the PITR is using the latest mapping for the destination EID, by inspecting the Destination Map-Version as detailed in Section 7.1"?


13. In §A.2.3:

  With this setup, the Proxy-ETR, by looking at the Source Map-Version
  Number, is able to check whether the mapping has changed.

Again, what mapping, and how? I guess it must be the source EID. (The version 12 text, which I've quoted here, makes that clearer, although it would still be even clearer to write "... check whether the Source EID-to-RLOC mapping has changed.") Why does the ETR care about that? I guess there's the assumption it might be an ITR/ETR passing traffic bidirectionally, in which case the source EID might be useful, but if that's the reason then some words to that effect would help.

[Ballot comment]
I support Roman Danyliw's DISCUSS position.

I have a number of further questions and comments --

1. In §6.1:

          If an ETR receives LISP-encapsulated packets with the V-bit
  set, when the original mapping in the EID-to-RLOC Database has the
  version number set to the Null Map-Version value, then those packets
  MUST be silently dropped.

What does “original” mean in this context? Couldn’t the mapping in the db once have had a value but in a later revision, had its value changed to the null value? Presumably in such a situation packets would be lost until the ITR decided to issue a new map-request.


2. In §7.1 (3):

                                                    According to rate
      limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
      Request messages, after 10 retries Map-Requests are sent every 30
      seconds, if in the meantime the Dest Map-Version number in the
      packets is not updated, the ETR SHOULD drop packets with a stale
      Map-Version number.

What exactly is “the meantime”? Does that mean “after 10 retries”? After 30 seconds? Basically, what precisely is the grace period extended to the ITR have to come into compliance before being blocked? This seems important to be clear about -- even if the clarity is in the form of "it's implementation-dependent".


3. In §7.1, final paragraph:

  LISP-encapsulated packets cannot transport a Dest Map-Version number
  equal to the Null Map-Version number, because in this case the ETR is
  signaling that Map-Version numbers are not used for the mapping of
  the destination EID (see Section 6.1).

Considering that the Null Map-Version number is just the distinguished value 0, the first clause is prima facie wrong -- it's possible to encode 0 in that field. I think what you mean is something more along the lines of

  It is a protocol violation for LISP-encapsulated packets to contain a
  Dest Map-Version number equal to the Null Map-Version number, see
  Section 6.1.
 
Please don't try to explain it again in-line as you've done, it just confuses the reader (well, it confused me!). Instead, refer them back to the place where you specified the rule.

It does seem unfortunate that in this case, it's not possible to include a Source Map-Version number, even if that would be helpful to do, since the V bit is required to be set to 0 and covers both Source and Dest.


4. §7.1 (3), nit: s/The packets arrive/The packet arrives/


5. In §7.1 and §7.2:

                            A check on this version number SHOULD be
  done, where the following cases can arise:
 
and

                            If the ETR has an entry in its EID-to-RLOC
  Map-Cache for the source EID, then a check SHOULD be performed and
  the following cases can arise:

What are the cases under which the check can be omitted? Please consider adding discussion about those cases. Alternately, consider making the SHOULD a MUST if there are no such cases.


6. In §7.2:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Such a case is not valid with respect to the
      specifications.

The final sentence ("not valid") seems like it must be wrong: consider for example the case of out-of-order packets. Other scenarios also exist, such as transient non-synchronization between ETRs during convergence. (I notice that §9 talks about the lack of synchronization mechanisms in LISP, other than diligent consistency of configuration. So, I guess there's a good chance that "convergence" means "someone updating mapping configurations by hand" and so version skew could exist for human-scale periods of time.)

I'll grant you that the probability seems pretty low that this situation would legitimately arise, but it's a big Internet and there are some surprisingly high-latency paths that exist. To see how it could happen, consider:

time    event
----    -----
t1      ITR sends packet p1 towards ETR with Src M-V = N. p1
                flows along a high-latency path.
t2      Mapping db on ITR is updated such that Src M-V is now N+1
t3      ITR sends packet p2 towards ETR with Src M-V = N+1. p2
                flows along a low-latency path, as do all subsequent
                packets.
t4      ETR receives p2, notices the change in Src M-V, sends a
                Map-Request.
t5      ITR receives Map-Request, sends Map-Reply.
t6      ETR receives Map-Reply, updates Map-Cache.
t7      p1 arrives.

It seems plausible for the interval [t2,t6] to be quite short, say a few hundred milliseconds. It's completely plausible for p1 to follow a path that takes more time than that, e.g. RTT to geosynchronous orbit is > 240 ms.

Given this is a corner case it seems OK to me that you'll throw the packet away... but the "not valid" thing is wrong. You could fix it by simply cutting that sentence and slightly re-wording, e.g.:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Note that if the mapping is already present in the
      EID-to-RLOC Map-Cache, this means that an explicit Map-Request
      has been sent and a Map-Reply has been received from an
      authoritative source.  In this situation, the packet SHOULD be
      silently dropped.  Operators can configure exceptions to this
      recommendation, which are outside the scope of this document.


7. In §7.2:

  If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
  the source EID, then the Source Map-Version number MUST be ignored.

I think it would be nice to have an xref to §A.1, where the reason for this is explained. Otherwise it seems rather arbitrary.


8. In §8:

I see that in -12 you cut the text that in -11 used to say

  Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.

I note that the requirement continues to exist however, since normative reference draft-ietf-lisp-rfc6830bis-38 §4.1 says

  Several of the mechanisms in this document are intended for
  deployment in controlled, trusted environments, and are insecure for
  use over the public Internet.  In particular, on the public internet
  xTRs:
...
  *  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

Thus it still seems to me that the questions others raised about this requirement may be relevant.

So, I question whether cutting the text is the right way to fix the concerns. It makes sense in an Experimental document, but perhaps not in a Standards Track one.


9. In §9:

  LISP requires ETRs to provide the same mapping for the same EID-
  Prefix to a requester.

What does this mean? Same as what? I guess maybe what you mean here is "LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix"? If so, please say that (or something else clearer than what's there now). If not, please help?


10. In §A.1:

  The ETR checks only the Dest Map-Version number as described in
  Section 7, ignoring the Source Map-Version number.

I would rewrite as

  The ETR checks only the Dest Map-Version number,
  ignoring the Source Map-Version number as specified in
  the final sentence of Section 7,.


11. In §A.2:

                                                LISP interworking
  defines three techniques to make LISP sites and non-LISP sites,
  namely Proxy-ITR, LISP-NAT, and Proxy-ETR.

This isn't a complete sentence. I guess what you mean is something like "LISP interworking defines three techniques to allow communication between LISP and non-LISP sites"?


12. In §A.2.1:

  With this setup, LISP Domain A is able to check whether the PITR is
  using the latest mapping.

First, how does Domain A check this? Second, the latest mapping for what? I suppose you might mean something like "Domain A is able to check whether the PITR is using the latest mapping for the destination EID, by inspecting the Destination Map-Version as detailed in Section 7.1"?


13. In §A.2.3:

  With this setup, the Proxy-ETR, by looking at the Source Map-Version
  Number, is able to check whether the mapping has changed.

Again, what mapping, and how? I guess it must be the source EID. (The version 12 text, which I've quoted here, makes that clearer, although it would still be even clearer to write "... check whether the Source EID-to-RLOC mapping has changed.") Why does the ETR care about that? I guess there's the assumption it might be an ITR/ETR passing traffic bidirectionally, in which case the source EID might be useful, but if that's the reason then some words to that effect would help.

[Ballot comment]
I support Roman Danyliw's DISCUSS position.

I have a number of further questions and comments --

1. In §6.1:

          If an ETR receives LISP-encapsulated packets with the V-bit
  set, when the original mapping in the EID-to-RLOC Database has the
  version number set to the Null Map-Version value, then those packets
  MUST be silently dropped.

What does “original” mean in this context? Couldn’t the mapping in the db once have had a value but in a later revision, had its value changed to the null value? Presumably in such a situation packets would be lost until the ITR decided to issue a new map-request.


2. In §7.1 (3):

                                                    According to rate
      limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
      Request messages, after 10 retries Map-Requests are sent every 30
      seconds, if in the meantime the Dest Map-Version number in the
      packets is not updated, the ETR SHOULD drop packets with a stale
      Map-Version number.

What exactly is “the meantime”? Does that mean “after 10 retries”? After 30 seconds? Basically, what precisely is the grace period extended to the ITR have to come into compliance before being blocked? This seems important to be clear about -- even if the clarity is in the form of "it's implementation-dependent".


3. In §7.1, final paragraph:

  LISP-encapsulated packets cannot transport a Dest Map-Version number
  equal to the Null Map-Version number, because in this case the ETR is
  signaling that Map-Version numbers are not used for the mapping of
  the destination EID (see Section 6.1).

Considering that the Null Map-Version number is just the distinguished value 0, the first clause is prima facie wrong -- it's possible to encode 0 in that field. I think what you mean is something more along the lines of

  It is a protocol violation for LISP-encapsulated packets to contain a
  Dest Map-Version number equal to the Null Map-Version number, see
  Section 6.1.
 
Please don't try to explain it again in-line as you've done, it just confuses the reader (well, it confused me!). Instead, refer them back to the place where you specified the rule.

It does seem unfortunate that in this case, it's not possible to include a Source Map-Version number, even if that would be helpful to do, since the V bit is required to be set to 0 and covers both Source and Dest.


4. §7.1 (3), nit: s/The packets arrive/The packet arrives/


5. In §7.1 and §7.2:

                            A check on this version number SHOULD be
  done, where the following cases can arise:
 
and

                            If the ETR has an entry in its EID-to-RLOC
  Map-Cache for the source EID, then a check SHOULD be performed and
  the following cases can arise:

What are the cases under which the check can be omitted? Please consider adding discussion about those cases. Alternately, consider making the SHOULD a MUST if there are no such cases.


6. In §7.2:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Such a case is not valid with respect to the
      specifications.

The final sentence ("not valid") seems like it must be wrong: consider for example the case of out-of-order packets. Other scenarios also exist, such as transient non-synchronization between ETRs during convergence. (I notice that §9 talks about the lack of synchronization mechanisms in LISP, other than diligent consistency of configuration. So, I guess there's a good chance that "convergence" means "someone updating mapping configurations by hand" and so version skew could exist for human-scale periods of time.)

I'll grant you that the probability seems pretty low that this situation would legitimately arise, but it's a big Internet and there are some surprisingly high-latency paths that exist. To see how it could happen, consider:

time    event
----    -----
t1      ITR sends packet p1 towards ETR with Src M-V = N. p1 flows along a
        high-latency path.
t2      Mapping db on ITR is updated such that Src M-V is now N+1
t3      ITR sends packet p2 towards ETR with Src M-V = N+1. p2 flows along
        a low-latency path, as do all subsequent packets.
t4      ETR receives p2, notices the change in Src M-V, sends a Map-Request.
t5      ITR receives Map-Request, sends Map-Reply.
t6      ETR receives Map-Reply, updates Map-Cache.
t7      p1 arrives.

It seems plausible for the interval [t2,t6] to be quite short, say a few hundred milliseconds. It's completely plausible for p1 to follow a path that takes more time than that, e.g. RTT to geosynchronous orbit is > 240 ms.

Given this is a corner case it seems OK to me that you'll throw the packet away... but the "not valid" thing is wrong. You could fix it by simply cutting that sentence and slightly re-wording, e.g.:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Note that if the mapping is already present in the
      EID-to-RLOC Map-Cache, this means that an explicit Map-Request
      has been sent and a Map-Reply has been received from an
      authoritative source.  In this situation, the packet SHOULD be
      silently dropped.  Operators can configure exceptions to this
      recommendation, which are outside the scope of this document.


7. In §7.2:

  If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
  the source EID, then the Source Map-Version number MUST be ignored.

I think it would be nice to have an xref to §A.1, where the reason for this is explained. Otherwise it seems rather arbitrary.


8. In §8:

I see that in -12 you cut the text that in -11 used to say

  Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.

I note that the requirement continues to exist however, since normative reference draft-ietf-lisp-rfc6830bis-38 §4.1 says

  Several of the mechanisms in this document are intended for
  deployment in controlled, trusted environments, and are insecure for
  use over the public Internet.  In particular, on the public internet
  xTRs:
...
  *  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

Thus it still seems to me that the questions others raised about this requirement may be relevant.

So, I question whether cutting the text is the right way to fix the concerns. It makes sense in an Experimental document, but perhaps not in a Standards Track one.


9. In §9:

  LISP requires ETRs to provide the same mapping for the same EID-
  Prefix to a requester.

What does this mean? Same as what? I guess maybe what you mean here is "LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix"? If so, please say that (or something else clearer than what's there now). If not, please help?


10. In §A.1:

  The ETR checks only the Dest Map-Version number as described in
  Section 7, ignoring the Source Map-Version number.

I would rewrite as

  The ETR checks only the Dest Map-Version number,
  ignoring the Source Map-Version number as specified in
  the final sentence of Section 7,.


11. In §A.2:

                                                LISP interworking
  defines three techniques to make LISP sites and non-LISP sites,
  namely Proxy-ITR, LISP-NAT, and Proxy-ETR.

This isn't a complete sentence. I guess what you mean is something like "LISP interworking defines three techniques to allow communication between LISP and non-LISP sites"?


12. In §A.2.1:

  With this setup, LISP Domain A is able to check whether the PITR is
  using the latest mapping.

First, how does Domain A check this? Second, the latest mapping for what? I suppose you might mean something like "Domain A is able to check whether the PITR is using the latest mapping for the destination EID, by inspecting the Destination Map-Version as detailed in Section 7.1"?


13. In §A.2.3:

  With this setup, the Proxy-ETR, by looking at the Source Map-Version
  Number, is able to check whether the mapping has changed.

Again, what mapping, and how? I guess it must be the source EID. (The version 12 text, which I've quoted here, makes that clearer, although it would still be even clearer to write "... check whether the Source EID-to-RLOC mapping has changed.") Why does the ETR care about that? I guess there's the assumption it might be an ITR/ETR passing traffic bidirectionally, in which case the source EID might be useful, but if that's the reason then some words to that effect would help.

[Ballot comment]
I support Roman Danyliw's DISCUSS position.

I have a number of further questions and comments --

1. In §6.1:

          If an ETR receives LISP-encapsulated packets with the V-bit
  set, when the original mapping in the EID-to-RLOC Database has the
  version number set to the Null Map-Version value, then those packets
  MUST be silently dropped.

What does “original” mean in this context? Couldn’t the mapping in the db once have had a value but in a later revision, had its value changed to the null value? Presumably in such a situation packets would be lost until the ITR decided to issue a new map-request.


2. In §7.1 (3):

                                                    According to rate
      limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
      Request messages, after 10 retries Map-Requests are sent every 30
      seconds, if in the meantime the Dest Map-Version number in the
      packets is not updated, the ETR SHOULD drop packets with a stale
      Map-Version number.

What exactly is “the meantime”? Does that mean “after 10 retries”? After 30 seconds? Basically, what precisely is the grace period extended to the ITR have to come into compliance before being blocked? This seems important to be clear about -- even if the clarity is in the form of "it's implementation-dependent".


3. In §7.1, final paragraph:

  LISP-encapsulated packets cannot transport a Dest Map-Version number
  equal to the Null Map-Version number, because in this case the ETR is
  signaling that Map-Version numbers are not used for the mapping of
  the destination EID (see Section 6.1).

Considering that the Null Map-Version number is just the distinguished value 0, the first clause is prima facie wrong -- it's possible to encode 0 in that field. I think what you mean is something more along the lines of

  It is a protocol violation for LISP-encapsulated packets to contain a
  Dest Map-Version number equal to the Null Map-Version number, see
  Section 6.1.
 
Please don't try to explain it again in-line as you've done, it just confuses the reader (well, it confused me!). Instead, refer them back to the place where you specified the rule.

It does seem unfortunate that in this case, it's not possible to include a Source Map-Version number, even if that would be helpful to do, since the V bit is required to be set to 0 and covers both Source and Dest.


4. §7.1 (3), nit: s/The packets arrive/The packet arrives/


5. In §7.2:

                            If the ETR has an entry in its EID-to-RLOC
  Map-Cache for the source EID, then a check SHOULD be performed and
  the following cases can arise:

What are the cases under which the check can be omitted? Please consider adding discussion about those cases. Alternately, consider making the SHOULD a MUST if there are no such cases.


6. In §7.2:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Such a case is not valid with respect to the
      specifications.

The final sentence ("not valid") seems like it must be wrong: consider for example the case of out-of-order packets. Other scenarios also exist, such as transient non-synchronization between ETRs during convergence. (I notice that §9 talks about the lack of synchronization mechanisms in LISP, other than diligent consistency of configuration. So, I guess there's a good chance that "convergence" means "someone updating mapping configurations by hand" and so version skew could exist for human-scale periods of time.)

I'll grant you that the probability seems pretty low that this situation would legitimately arise, but it's a big Internet and there are some surprisingly high-latency paths that exist. To see how it could happen, consider:

time    event
----    -----
t1      ITR sends packet p1 towards ETR with Src M-V = N. p1 flows along a
        high-latency path.
t2      Mapping db on ITR is updated such that Src M-V is now N+1
t3      ITR sends packet p2 towards ETR with Src M-V = N+1. p2 flows along
        a low-latency path, as do all subsequent packets.
t4      ETR receives p2, notices the change in Src M-V, sends a Map-Request.
t5      ITR receives Map-Request, sends Map-Reply.
t6      ETR receives Map-Reply, updates Map-Cache.
t7      p1 arrives.

It seems plausible for the interval [t2,t6] to be quite short, say a few hundred milliseconds. It's completely plausible for p1 to follow a path that takes more time than that, e.g. RTT to geosynchronous orbit is > 240 ms.

Given this is a corner case it seems OK to me that you'll throw the packet away... but the "not valid" thing is wrong. You could fix it by simply cutting that sentence and slightly re-wording, e.g.:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Note that if the mapping is already present in the
      EID-to-RLOC Map-Cache, this means that an explicit Map-Request
      has been sent and a Map-Reply has been received from an
      authoritative source.  In this situation, the packet SHOULD be
      silently dropped.  Operators can configure exceptions to this
      recommendation, which are outside the scope of this document.


7. In §7.2:

  If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
  the source EID, then the Source Map-Version number MUST be ignored.

I think it would be nice to have an xref to §A.1, where the reason for this is explained. Otherwise it seems rather arbitrary.


8. In §8:

I see that in -12 you cut the text that in -11 used to say

  Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.

I note that the requirement continues to exist however, since normative reference draft-ietf-lisp-rfc6830bis-38 §4.1 says

  Several of the mechanisms in this document are intended for
  deployment in controlled, trusted environments, and are insecure for
  use over the public Internet.  In particular, on the public internet
  xTRs:
...
  *  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

Thus it still seems to me that the questions others raised about this requirement may be relevant.

So, I question whether cutting the text is the right way to fix the concerns. It makes sense in an Experimental document, but perhaps not in a Standards Track one.


9. In §9:

  LISP requires ETRs to provide the same mapping for the same EID-
  Prefix to a requester.

What does this mean? Same as what? I guess maybe what you mean here is "LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix"? If so, please say that (or something else clearer than what's there now). If not, please help?


10. In §A.1:

  The ETR checks only the Dest Map-Version number as described in
  Section 7, ignoring the Source Map-Version number.

I would rewrite as

  The ETR checks only the Dest Map-Version number,
  ignoring the Source Map-Version number as specified in
  the final sentence of Section 7,.


11. In §A.2:

                                                LISP interworking
  defines three techniques to make LISP sites and non-LISP sites,
  namely Proxy-ITR, LISP-NAT, and Proxy-ETR.

This isn't a complete sentence. I guess what you mean is something like "LISP interworking defines three techniques to allow communication between LISP and non-LISP sites"?


12. In §A.2.1:

  With this setup, LISP Domain A is able to check whether the PITR is
  using the latest mapping.

First, how does Domain A check this? Second, the latest mapping for what? I suppose you might mean something like "Domain A is able to check whether the PITR is using the latest mapping for the destination EID, by inspecting the Destination Map-Version as detailed in Section 7.1"?


13. In §A.2.3:

  With this setup, the Proxy-ETR, by looking at the Source Map-Version
  Number, is able to check whether the mapping has changed.

Again, what mapping, and how? I guess it must be the source EID. (The version 12 text, which I've quoted here, makes that clearer, although it would still be even clearer to write "... check whether the Source EID-to-RLOC mapping has changed.") Why does the ETR care about that? I guess there's the assumption it might be an ITR/ETR passing traffic bidirectionally, in which case the source EID might be useful, but if that's the reason then some words to that effect would help.

[Ballot discuss]
This spec makes liberal use of the approach of dropping any packet received with an unloved Map-Version number, for example (but not limited to)

  2.  The packet arrives with a Dest Map-Version number newer (as
      defined in Section 6) than the one stored in the EID-to-RLOC
      Database.  Since the ETR is authoritative on the mapping, meaning
      that the Map-Version number of its mapping is the correct one,
      this implies that someone is not behaving correctly with respect
      to the specifications.  In this case, the packet carries a
      version number that is not valid and packet MUST be silently
      dropped.

Isn’t it the case that by definition the packet has arrived at a valid ETR for the mapping (since as the text says, “the ETR is authoritative”)? Isn’t the map-version more in the nature of a hint than a critical-for-correctness field? What bad behavior is being protected against by silently dropping this traffic, that has arrived at a correct endpoint albeit with an incorrect hint?

At various points in the document there's a kind of vague assertion that incorrect map-versions could be an attack. While I don't deny that, the assertion isn't supported or elaborated on anywhere that I saw, which is worrying and also makes it less convincing. Shouldn't the Security Considerations talk about this? I did also go have a look at the Security Considerations in draft-ietf-lisp-rfc6833bis-31, which also didn't help me. RFC 7835 §3.3 does touch on this, suggesting that maybe an attacker could use a spoofed Map-Version to trigger a DoS attack. But this, too, is an unsatisfying rationale, since as you take pains to point out, rate limiting of Map-Requests and such is required.

When this was an Experimental protocol this kind of thing was probably less crucial to justify and explain, but I would have expected the experiment to produce results that could be fed into this document. At the moment, the "drop any packet that doesn't comply with expectations" design feels arbitrary and potentially brittle. I would appreciate some discussion of this design choice.

(I do acknowledge that security matters can be subtle, and I'm not a SEC AD after all... but all the more reason for the document to be explicit about what the security concerns are instead of just vaguely gesturing toward them and leaving the reader to guess.)

[Ballot comment]
I support Roman Danyliw's DISCUSS position.

I have a number of further questions and comments --

1. In §6.1:

          If an ETR receives LISP-encapsulated packets with the V-bit
  set, when the original mapping in the EID-to-RLOC Database has the
  version number set to the Null Map-Version value, then those packets
  MUST be silently dropped.

What does “original” mean in this context? Couldn’t the mapping in the db once have had a value but in a later revision, had its value changed to the null value? Presumably in such a situation packets would be lost until the ITR decided to issue a new map-request.


2. In §7.1 (3):

                                                    According to rate
      limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
      Request messages, after 10 retries Map-Requests are sent every 30
      seconds, if in the meantime the Dest Map-Version number in the
      packets is not updated, the ETR SHOULD drop packets with a stale
      Map-Version number.

What exactly is “the meantime”? Does that mean “after 10 retries”? After 30 seconds? Basically, what precisely is the grace period extended to the ITR have to come into compliance before being blocked? This seems important to be clear about -- even if the clarity is in the form of "it's implementation-dependent".


3. In §7.1, final paragraph:

  LISP-encapsulated packets cannot transport a Dest Map-Version number
  equal to the Null Map-Version number, because in this case the ETR is
  signaling that Map-Version numbers are not used for the mapping of
  the destination EID (see Section 6.1).

Considering that the Null Map-Version number is just the distinguished value 0, the first clause is prima facie wrong -- it's possible to encode 0 in that field. I think what you mean is something more along the lines of

  It is a protocol violation for LISP-encapsulated packets to contain a
  Dest Map-Version number equal to the Null Map-Version number, see
  Section 6.1.
 
Please don't try to explain it again in-line as you've done, it just confuses the reader (well, it confused me!). Instead, refer them back to the place where you specified the rule.

It does seem unfortunate that in this case, it's not possible to include a Source Map-Version number, even if that would be helpful to do, since the V bit is required to be set to 0 -- right?


4. §7.1 (3), nit: s/The packets arrive/The packet arrives/


5. In §7.2:

                            If the ETR has an entry in its EID-to-RLOC
  Map-Cache for the source EID, then a check SHOULD be performed and
  the following cases can arise:

What are the cases under which the check can be omitted? Please consider adding discussion about those cases. Alternately, consider making the SHOULD a MUST if there are no such cases.


6. In §7.2:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Such a case is not valid with respect to the
      specifications.

The final sentence ("not valid") seems like it must be wrong: consider for example the case of out-of-order packets. Other scenarios also exist, such as transient non-synchronization between ETRs during convergence. (I notice that §9 talks about the lack of synchronization mechanisms in LISP, other than diligent consistency of configuration. So, I guess there's a good chance that "convergence" means "someone updating mapping configurations by hand" and so version skew could exist for human-scale periods of time.)

I'll grant you that the probability seems pretty low that this situation would legitimately arise, but it's a big Internet and there are some surprisingly high-latency paths that exist. To see how it could happen, consider:

time    event
----    -----
t1      ITR sends packet p1 towards ETR with Src M-V = N. p1 flows along a
        high-latency path.
t2      Mapping db on ITR is updated such that Src M-V is now N+1
t3      ITR sends packet p2 towards ETR with Src M-V = N+1. p2 flows along
        a low-latency path, as do all subsequent packets.
t4      ETR receives p2, notices the change in Src M-V, sends a Map-Request.
t5      ITR receives Map-Request, sends Map-Reply.
t6      ETR receives Map-Reply, updates Map-Cache.
t7      p1 arrives.

It seems plausible for the interval [t2,t6] to be quite short, say a few hundred milliseconds. It's completely plausible for p1 to follow a path that takes more time than that, e.g. RTT to geosynchronous orbit is > 240 ms.

Given this is a corner case it seems OK to me that you'll throw the packet away... but the "not valid" thing is wrong. You could fix it by simply cutting that sentence and slightly re-wording, e.g.:

  3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Map-
      Cache.  Note that if the mapping is already present in the
      EID-to-RLOC Map-Cache, this means that an explicit Map-Request
      has been sent and a Map-Reply has been received from an
      authoritative source.  In this situation, the packet SHOULD be
      silently dropped.  Operators can configure exceptions to this
      recommendation, which are outside the scope of this document.


7. In §7.2:

  If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
  the source EID, then the Source Map-Version number MUST be ignored.

I think it would be nice to have an xref to §A.1, where the reason for this is explained. Otherwise it seems rather arbitrary.


8. In §8:

I see that in -12 you cut the text that in -11 used to say

  Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.

I note that the requirement continues to exist however, since normative reference draft-ietf-lisp-rfc6830bis-38 §4.1 says

  Several of the mechanisms in this document are intended for
  deployment in controlled, trusted environments, and are insecure for
  use over the public Internet.  In particular, on the public internet
  xTRs:
...
  *  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

Thus it still seems to me that the questions others raised about this requirement may be relevant.

So, I question whether cutting the text is the right way to fix the concerns. It makes sense in an Experimental document, but perhaps not in a Standards Track one.


9. In §9:

  LISP requires ETRs to provide the same mapping for the same EID-
  Prefix to a requester.

What does this mean? Same as what? I guess maybe what you mean here is "LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix"? If so, please say that (or something else clearer than what's there now). If not, please help?


10. In §A.1:

  The ETR checks only the Dest Map-Version number as described in
  Section 7, ignoring the Source Map-Version number.

I would rewrite as

  The ETR checks only the Dest Map-Version number,
  ignoring the Source Map-Version number as specified in
  the final sentence of Section 7,.


11. In §A.2:

                                                LISP interworking
  defines three techniques to make LISP sites and non-LISP sites,
  namely Proxy-ITR, LISP-NAT, and Proxy-ETR.

This isn't a complete sentence. I guess what you mean is something like "LISP interworking defines three techniques to allow communication between LISP and non-LISP sites"?


12. In §A.2.1:

  With this setup, LISP Domain A is able to check whether the PITR is
  using the latest mapping.

First, how does Domain A check this? Second, the latest mapping for what? I suppose you might mean something like "Domain A is able to check whether the PITR is using the latest mapping for the destination EID, by inspecting the Destination Map-Version as detailed in Section 7.1"?


13. In §A.2.3:

  With this setup, the Proxy-ETR, by looking at the Source Map-Version
  Number, is able to check whether the mapping has changed.

Again, what mapping, and how? I guess it must be the source EID. (The version 12 text, which I've quoted here, makes that clearer, although it would still be even clearer to write "... check whether the Source EID-to-RLOC mapping has changed.") Why does the ETR care about that? I guess there's the assumption it might be an ITR/ETR passing traffic bidirectionally, in which case the source EID might be useful, but if that's the reason then some words to that effect would help.

[Ballot discuss]
On the -11 document, I initial wrote the following: The SECDIR review by Donald Eastlake asked about handling roll-over/wrap-around of the Map Version Number.  Specifically, can a “Map Version Number advance[e] … so quickly that an old version number is encountered that appears to be newer than or equal to the current version number. Why can't this happen? Or if it can, why doesn't that hurt?”  It would appear that a number of the conclusions of the ITR or ETR on arriving packets in Section 7.1 and 7.2 wouldn’t be correct.

I then saw the -12 document published on June 1 which added the following text to Section 7:
  Map Version Number incrementing
  and mappings' TTL MUST be managed so that an old version number will
  not be confused as a new version number.

Thank you for adding this text.  Practically, this identifies the desired intent, but doesn’t seem describe the mechanics.  Can more be said about how this confusion will be mitigated at the ITR/ETRs?  I also don't follow how to use the TTLs here.

Consider the situation that Donald noted where the Map Version advanced so quickly that it wraps around so that:

(a) the new Map Version Number value equals the old Map Version Number.  If one followed the guidance in Section 7.1 of:
  1.  The packet arrives with the same Dest Map-Version number stored
      in the EID-to-RLOC Database.  This is the regular case.  The ITR
      sending the packet has in its EID-to-RLOC Map-Cache an up-to-date
      mapping.  No further actions are needed.

It would seem that the ITR wouldn’t do a Map-Request and would misroute the packet based on the old mapping.

(b) the new Map Version Number is now smaller (but in fact fresher/newer)  If one followed the guidance of Section 7.1. of:

3.  The packets arrive with a Dest Map-Version number smaller (i.e.,
      older) than the one stored in the EID-to-RLOC Database.  This
      means that the ITR sending the packet has an old mapping in its
      EID-to-RLOC Map-Cache containing stale information.

Per bullet #3, if there was wrap-around would the ITR in fact be sending stale mapping information?

[Ballot discuss]
Changed my comments to a DISCUSS, as Donald Eastlake also pointed these out in his secdir review, and I am now convinced we need better text to address this.

#1  map-version rollover is defined (to skip the 0 version) but I also see:

The packet arrives with a Dest Map-Version number greater (i.e.,
      newer) than the one stored in the EID-to-RLOC Database.  Since
      the ETR is authoritative on the mapping, meaning that the Map-
      Version number of its mapping is the correct one

This would imply rollover to a smaller number is not expected to occur ?

#2 MUST NOT or SHOULD ?

Map-Versioning MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments.

This sentence seems to contradict itself. I would turn the SHOULD into a MUST

[Ballot comment]
# Internet AD comments for {draft-ietf-lisp-6834bis-11}
CC @ekline

## Comments

### S6

* Consider adding a reference to RFC 1982, which goes into this at
  greater length.

[Ballot comment]
#1  map-version rollover is defined (to skip the 0 version) but I also see:

The packet arrives with a Dest Map-Version number greater (i.e.,
      newer) than the one stored in the EID-to-RLOC Database.  Since
      the ETR is authoritative on the mapping, meaning that the Map-
      Version number of its mapping is the correct one

This would imply rollover to a smaller number is not expected to occur ?

#2 MUST NOT or SHOULD ?

Map-Versioning MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments.

This sentence seems to contradict itself. I would turn the SHOULD into a MUST

[Ballot comment]
# Éric Vyncke, INT AD, review of draft-ietf-lisp-6834bis-11

Thank you for the work put into this document. Updated ballot as I failed to clean up the template, i.e., this one does not contain the empty DISCUSS section ;-) Sorry about that.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Padma Pillay-Esnault for the shepherd's write-up including the WG consensus and the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 6

Just wondering why having an algorithm defined for 'N' while the versions are always on 12 bits.

### Section 8

```
Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.
```

An explanation of why and how would be welcome. Feel free to ignore this comment though as this is the usual recommendation for any tunneling mechanism w/o authentication/confidentiality.

## NITS 

### Section 6

s/MUST consist in an increment by one the older/MUST consist in an increment by one of the older/ ? Moreover, 'increment' is usually understood as 'add 1' so no need to add 'by one' in the sentence

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# Éric Vyncke, INT AD, review of draft-ietf-lisp-6834bis-11

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Padma Pillay-Esnault for the shepherd's write-up including the WG consensus and the intended status.

I hope that this helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 2.2


## COMMENTS

### Section 6

Just wondering why having an algorithm defined for 'N' while the versions are always on 12 bits.

### Section 8

```
Map-Versioning MUST NOT be used over the public Internet and SHOULD
  only be used in trusted and closed deployments.
```

An explanation of why and how would be welcome. Feel free to ignore this comment though as this is the usual recommendation for any tunneling mechanism w/o authentication/confidentiality.

## NITS 

### Section 6

s/MUST consist in an increment by one the older/MUST consist in an increment by one of the older/ ? Moreover, 'increment' is usually understood as 'add 1' so no need to add 'by one' in the sentence

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-lisp-6834bis-10

CC @larseggert

## Comments

### Section 6, paragraph 8
```
    1.  V1 = V2 : The Map-Version numbers are the same.

    2.  V2 > V1 : if and only if

          V2 > V1 AND (V2 - V1) <= 2**(N-1)

          OR

          V1 > V2 AND (V1 - V2) > 2**(N-1)

    3.  V1 > V2 : otherwise.
```
Shouldn't this include cases for if either V1 or V2 is the Null Map-Version?

### Section 6.1, paragraph 0
```
  6.1.  The Null Map-Version
```
It might have been cleaner to actually define a one-bit "Null
Map-Version" flag and use an 11-bit number space, instead of
overloading the 0x0000 version. That would have eliminated the
need for a lot of special-casing in the arithmetic.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not
  binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`,
  `unacceptable`, `inapplicable`, `revoked`, `rescinded`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 6.1, paragraph 5
```
C Map-Cache for the source EID is up to date. If one or both of the above pre
                                  ^^^^^^^^^^
```
It appears that hyphens are missing in the adjective "up-to-date".

#### "A.1.", paragraph 2
```
LISP Domain A is able to check whether or not the PITR is using the latest m
                                ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### "A.2.1.", paragraph 2
```
the Proxy-ETR is able to check whether or not the mapping has changed. A.3.
                                ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lisp-6834bis-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

(END IANA COMMENTS)

The following Last Call announcement was sent out (ends 2022-05-19):

From: The IESG
To: IETF-Announce
CC: Padma Pillay-Esnault , aretana.ietf@gmail.com, draft-ietf-lisp-6834bis@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, padma.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Locator/ID Separation Protocol (LISP) Map-Versioning) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'Locator/ID Separation Protocol
(LISP) Map-Versioning'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the LISP (Locator/ID Separation Protocol)
  Map-Versioning mechanism, which provides in-packet information about
  Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to
  encapsulate LISP data packets.  This approach is based on associating
  a version number to EID-to-RLOC mappings and the transport of such a
  version number in the LISP-specific header of LISP-encapsulated
  packets.  LISP Map-Versioning is particularly useful to inform
  communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers
  (ETRs) about modifications of the mappings used to encapsulate
  packets.  The mechanism is optional and transparent to
  implementations not supporting this feature, since in the LISP-
  specific header and in the Map Records, bits used for Map-Versioning
  can be safely ignored by ITRs and ETRs that do not support or do not
  want to use the mechanism.

  This document obsoletes RFC 6834 "Locator/ID Separation Protocol
  (LISP) Map-Versioning", which is the initial experimental
  specifications of the mechanisms updated by this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-6834bis/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is targeting publication as a Standards track RFC.
It is the proper type of RFC since it provides updates to RFC 6834 Locator/ID Separation Protocol (LISP) Map-Versioning, which was an experimental document.
The RFC type is clearly marked in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The document proposes a map versioning mechanism for the LISP mapping system to track the EID-locator bindings. The mechanism is based on versioning the bindings and also carrying the version in LISP hear for LISP encapsulated packets. The proposal allows tunnel end point to inform the other of the version of mapping used and indirectly signaling changes in the mapping.

The proposed mechanism is optional and transparent for nodes not implementing the feature.
This document obsoletes the RFC6834.

Working Group Summary:

The document was initially written in May 2018 and has mostly the same text as RFC6834.
The changes do not impact the clarity of the document and are:
1. Clarification that the mechanism is optional
2. Updated  section 8.4 for clarification
3. Removal of redundant section 9 in RFC6834
4. Updated the security section inline with the main specs.
5. Updated section 11 in RFC6834 for deployment considerations .
6. Removal of Appendix A of RFC6834. The very small delay was discussed and there was no objection in the working group and support to go rapidly in wg last call.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document is a respin from the RFC6438 and does not have significant changes except for few parts that made it coherent with the main specs (namely 6830bis and 6833bis).

There are at least two known implementations of the proposed mechanism (RFC6438)


Personnel:

Who is the Document Shepherd?

Padma Pillay-Esnault


Who is the Responsible Area Director?

Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I checked the IDnits and the document had no warnings to be solved. 
The text is sufficiently clear and understandable.
I have checked the mailing list and meeting minutes and publication WG consensus has been reached appropriately.

I had a few suggestions on the draft for readability and nits.

Section 1
consider rephrasing this sentence. Suggestion below
Old:
A change in an EID-to-RLOC mapping
  can be a change in the RLOCs set, by adding or removing one or more
  RLOCs, but it can also be a change in the priority or weight of one
  or more RLOCs.

New:
A change in an EID-to-RLOC mapping can be a modification in the RLOCs set such as addition, removal, or change in priority or weight of one or more RLOCs.

Section 3
  Map-Version number:  An unsigned 12-bit integer is assigned to an
    EID-to-RLOC mapping, not including the value 0 (0x000).
Suggestion below
Old: not including
New : excluding

Section 5.2

  2.  The packet arrives with a Source Map-Version number greater
      (i.e., newer) than the one stored in the local EID-to-RLOC Map-
      Cache.  This means that the ETR has in its EID-to-RLOC Map-Cache
      a mapping that is stale and needs to be updated.  A Map-Request


Old: This means that the ETR has in its EID-to-RLOC Map-Cache
      a mapping that is stale and needs to be updated. 

New: This means that the ETR has in its EID-to-RLOC Map-Cache
      a stale mapping and needs to be updated. 

Section 8.4.
  In the current LISP specifications, the set of RLOCs must always be
  maintained ordered and consistent with the content of the Loc Status
  Bits ([I-D.ietf-lisp-rfc6830bis]).  .  When a new RLOC is added to a

Punctuation to be fixed


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

As the document shepherd I have no concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I do not think that an additional specific review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues to point out.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have been polled for IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been clear consensus behind this document, showing that the WG as a whole understands and agrees with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Nobody showed discontent nor threatened an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


The ID nits did not show any errors, flaws or warnings.

idnits 2.16.05


tmp/draft-ietf-lisp-6834bis-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (March 24, 2021) is 115 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). --------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review is required.

(13) Have all references within this document been identified as either normative or informative?

All references are clearly identified as Normative or Informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

             
  [I-D.ietf-lisp-rfc6830bis]
              Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos-Aparicio, "The Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress),
              November  2020.

  [I-D.ietf-lisp-rfc6833bis]
              Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              draft-ietf-lisp-rfc6833bis-30 (work in progress), November
              2020.

There is a normative reference to draft-ietf-lisp-rfc6830bis, one to draft-ietf-lisp-rfc6833bis, but these documents are sitting in the RFC Editor queue waiting for this document (among others)

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references once the docs in (14) are published with the standards track status.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document is going to obsolete RFC6834, as it is clearly stated in the head, abstract, and Introduction of the document (as requested by the IETF process).

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).


The document does not have IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No expert review is required.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not contain a Yang Module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is targeting publication as a Standards track RFC.
It is the proper type of RFC since it provides updates to RFC 6834 Locator/ID Separation Protocol (LISP) Map-Versioning, which was an experimental document.
The RFC type is clearly marked in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The document proposes a map versioning mechanism for the LISP mapping system to track the EID-locator bindings. The mechanism is based on versioning the bindings and also carrying the version in LISP hear for LISP encapsulated packets. The proposal allows tunnel end point to inform the other of the version of mapping used and indirectly signaling changes in the mapping.

The proposed mechanism is optional and transparent for nodes not implementing the feature.
This document obsoletes the RFC6834.

Working Group Summary:

The document was initially written in May 2018 and has mostly the same text as RFC6834.
The changes do not impact the clarity of the document and are:
1. Clarification that the mechanism is optional
2. Updated  section 8.4 for clarification
3. Removal of redundant section 9 in RFC6834
4. Updated the security section inline with the main specs.
5. Updated section 11 in RFC6834 for deployment considerations .
6. Removal of Appendix A of RFC6834. The very small delay was discussed and there was no objection in the working group and support to go rapidly in wg last call.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document is a respin from the RFC6438 and does not have significant changes except for few parts that made it coherent with the main specs (namely 6830bis and 6833bis).

There are at least two known implementations of the proposed mechanism (RFC6438)


Personnel:

Who is the Document Shepherd?

Padma Pillay-Esnault


Who is the Responsible Area Director?

Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I checked the IDnits and the document had no warnings to be solved. 
The text is sufficiently clear and understandable.
I have checked the mailing list and meeting minutes and publication WG consensus has been reached appropriately.

I had a few suggestions on the draft for readability and nits.

Section 1
consider rephrasing this sentence. Suggestion below
Old:
A change in an EID-to-RLOC mapping
  can be a change in the RLOCs set, by adding or removing one or more
  RLOCs, but it can also be a change in the priority or weight of one
  or more RLOCs.

New:
A change in an EID-to-RLOC mapping can be a modification in the RLOCs set such as addition, removal, or change in priority or weight of one or more RLOCs.

Section 3
  Map-Version number:  An unsigned 12-bit integer is assigned to an
    EID-to-RLOC mapping, not including the value 0 (0x000).
Suggestion below
Old: not including
New : excluding

Section 5.2

  2.  The packet arrives with a Source Map-Version number greater
      (i.e., newer) than the one stored in the local EID-to-RLOC Map-
      Cache.  This means that the ETR has in its EID-to-RLOC Map-Cache
      a mapping that is stale and needs to be updated.  A Map-Request


Old: This means that the ETR has in its EID-to-RLOC Map-Cache
      a mapping that is stale and needs to be updated. 

New: This means that the ETR has in its EID-to-RLOC Map-Cache
      a stale mapping and needs to be updated. 

Section 8.4.
  In the current LISP specifications, the set of RLOCs must always be
  maintained ordered and consistent with the content of the Loc Status
  Bits ([I-D.ietf-lisp-rfc6830bis]).  .  When a new RLOC is added to a

Punctuation to be fixed


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

As the document shepherd I have no concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I do not think that an additional specific review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues to point out.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have been polled for IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been clear consensus behind this document, showing that the WG as a whole understands and agrees with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Nobody did show discontent nor threatened an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


The ID nits did not show any errors, flaws or warnings.

idnits 2.16.05


tmp/draft-ietf-lisp-6834bis-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (March 24, 2021) is 115 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). --------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review is required.

(13) Have all references within this document been identified as either normative or informative?

All references are clearly identified as Normative or Informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

             
  [I-D.ietf-lisp-rfc6830bis]
              Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos-Aparicio, "The Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress),
              November  2020.

  [I-D.ietf-lisp-rfc6833bis]
              Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              draft-ietf-lisp-rfc6833bis-30 (work in progress), November
              2020.

There is a normative reference to draft-ietf-lisp-rfc6830bis, one to draft-ietf-lisp-rfc6833bis, but these documents are sitting in the RFC Editor queue waiting for this document (among others)

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references once the docs in (14) are published with the standards track status.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document is going to obsolete RFC6834, as it is clearly stated in the head, abstract, and Introduction of the document (as requested by the IETF process).

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).


The document does not have IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No expert review is required.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document does not contain anything written in a formal
language, hence, no validation and/or check has been
performed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not contain a Yang Module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is targeting publication as a Standards track RFC.
It is the proper type of RFC since it provides updates to RFC 6834 Locator/ID Separation Protocol (LISP) Map-Versioning, which was an experimental document.
The RFC type is clearly marked in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The document proposes a map versioning mechanism for the LISP mapping system to track the EID-locator bindings. The mechanism is based on versioning the bindings and also carrying the version in LISP hear for LISP encapsulated packets. The proposal allows tunnel end point to inform the other of the version of mapping used and indirectly signaling changes in the mapping.

The proposed mechanism is optional and transparent for nodes not implementing the feature.
This document obsoletes the RFC6834.

Working Group Summary:

The document was initially written in May 2018 and has mostly the same text as RFC6834.
The changes do not impact the clarity of the document and are:
1. Clarification that the mechanism is optional
2. Updated  section 8.4 for clarification
3. Removal of redundant section 9 in RFC6834
4. Updated the security section inline with the main specs.
5. Updated section 11 in RFC6834 for deployment considerations .
6. Removal of Appendix A of RFC6834. The very small delay was discussed and there was no objection in the working group and support to go rapidly in wg last call.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document is a respin from the RFC6438 and does not have significant changes except for few parts that made it coherent with the main specs (namely 6830bis and 6833bis).

There are at least two known implementations of the proposed mechanism (RFC6438)


Personnel:

Who is the Document Shepherd?

Padma Pillay-Esnault


Who is the Responsible Area Director?

Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I checked the IDnits and the document had no warnings to be solved. 
The text is sufficiently clear and understandable.
I have checked the mailing list and meeting minutes and publication WG consensus has been reached appropriately.

I had a few suggestions on the draft for readability and nits.

Section 1
consider rephrasing this sentence. Suggestion below
Old:
A change in an EID-to-RLOC mapping
  can be a change in the RLOCs set, by adding or removing one or more
  RLOCs, but it can also be a change in the priority or weight of one
  or more RLOCs.

New:
A change in an EID-to-RLOC mapping can be a modification in the RLOCs set such as addition, removal, or change in priority or weight of one or more RLOCs.

Section 3
  Map-Version number:  An unsigned 12-bit integer is assigned to an
    EID-to-RLOC mapping, not including the value 0 (0x000).
Suggestion below
Old: not including
New : excluding

Section 5.2

  2.  The packet arrives with a Source Map-Version number greater
      (i.e., newer) than the one stored in the local EID-to-RLOC Map-
      Cache.  This means that the ETR has in its EID-to-RLOC Map-Cache
      a mapping that is stale and needs to be updated.  A Map-Request


Old: This means that the ETR has in its EID-to-RLOC Map-Cache
      a mapping that is stale and needs to be updated. 

New: This means that the ETR has in its EID-to-RLOC Map-Cache
      a stale mapping and needs to be updated. 

Section 8.4.
  In the current LISP specifications, the set of RLOCs must always be
  maintained ordered and consistent with the content of the Loc Status
  Bits ([I-D.ietf-lisp-rfc6830bis]).  .  When a new RLOC is added to a

Punctuation to be fixed


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

As the document shepherd I have no concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

I do not think that an additional specific review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns or issues to point out.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have been polled for IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been clear consensus behind this document, showing that the WG as a whole understands and agrees with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Nobody did show discontent nor threatened an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


The ID nits did not show any errors, flaws or warnings.

idnits 2.16.05


tmp/draft-ietf-lisp-6834bis-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (March 24, 2021) is 115 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). --------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal review is required.

(13) Have all references within this document been identified as either normative or informative?

All references are clearly identified as Normative or Informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

             
  [I-D.ietf-lisp-rfc6830bis]
              Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos-Aparicio, "The Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress),
              November  2020.

  [I-D.ietf-lisp-rfc6833bis]
              Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              draft-ietf-lisp-rfc6833bis-30 (work in progress), November
              2020.

There is a normative reference to draft-ietf-lisp-rfc6830bis, one to draft-ietf-lisp-rfc6833bis, but these documents are sitting in the RFC Editor queue waiting for this document (among others)

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references once the docs in (14) are published with the standards track status.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document is going to obsolete RFC6834, as it is clearly stated in the head, abstract, and Introduction of the document (as requested by the IETF process).

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).


The document does not have IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No expert review is required.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document does not contain anything written in a formal
language, hence, no validation and/or check has been
performed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not contain a Yang Module.