Skip to main content

The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-38

Revision differences

Document history

Date Rev. By Action
2022-09-14
38 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-09-08
38 (System) RFC Editor state changed to AUTH48
2022-08-10
38 (System) RFC Editor state changed to RFC-EDITOR from REF
2022-07-19
38 (System) RFC Editor state changed to REF from EDIT
2022-07-14
38 (System) RFC Editor state changed to EDIT from MISSREF
2022-05-07
38 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-38.txt
2022-05-07
38 Dino Farinacci New version accepted (logged-in submitter: Dino Farinacci)
2022-05-07
38 Dino Farinacci Uploaded new revision
2022-05-02
37 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-37.txt
2022-05-02
37 Dino Farinacci New version accepted (logged-in submitter: Dino Farinacci)
2022-05-02
37 Dino Farinacci Uploaded new revision
2021-03-10
36 Alvaro Retana Shepherding AD changed to Alvaro Retana
2021-03-10
36 Alvaro Retana Notification list changed to Luigi Iannone <ggx@gigix.net>, aretana.ietf@gmail.com from Luigi Iannone <ggx@gigix.net>
2021-02-17
36 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-02-17
36 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-02-17
36 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-02-17
36 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-02-11
36 (System) RFC Editor state changed to MISSREF
2021-02-11
36 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-02-11
36 (System) Announcement was received by RFC Editor
2021-02-11
36 (System) IANA Action state changed to In Progress
2021-02-11
36 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2021-02-11
36 Cindy Morgan IESG has approved the document
2021-02-11
36 Cindy Morgan Closed "Approve" ballot
2021-02-11
36 Cindy Morgan Ballot writeup was changed
2021-02-11
36 Deborah Brungard Ballot approval text was changed
2020-12-11
36 Deborah Brungard Pen holder doing a final check before AD approval.
2020-11-29
36 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 12 ]

* "When the inner header is IPv6 then the flow label is not zero,
  it …
[Ballot comment]
[[ nits ]]

[ section 12 ]

* "When the inner header is IPv6 then the flow label is not zero,
  it MAY be used to compute the hash."

  Perhaps:

* "When the inner header is IPv6 and the flow label is not zero,
  it MAY be used when computing the hash."
2020-11-29
36 Erik Kline [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss
2020-11-18
36 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2020-11-18
36 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-36.txt
2020-11-18
36 (System) New version approved
2020-11-18
36 (System) Request for posting confirmation emailed to previous authors: Dino Farinacci , Darrel Lewis , Albert Cabellos-Aparicio , Vince Fuller , David Meyer
2020-11-18
36 Albert Cabellos-Aparicio Uploaded new revision
2020-11-18
35 Luigi Iannone Added to session: IETF-109: lisp  Thu-1200
2020-09-18
35 Roman Danyliw
[Ballot discuss]
** Section 8.  Per “Participants within a LISP deployment must agree on the meaning of Instance ID values.  The source and destination EIDs …
[Ballot discuss]
** Section 8.  Per “Participants within a LISP deployment must agree on the meaning of Instance ID values.  The source and destination EIDs MUST belong to the same Instance ID.”  Could parties agree that the Instance ID is 802.1Q tags and send those across the internet?  Recommend stronger cautionary language on using Instance ID.
2020-09-18
35 Roman Danyliw
[Ballot comment]
Thank you for being responsive to the prior security feedback from the SECDIR (and thanks to Kyle Rose for performing it) and Security …
[Ballot comment]
Thank you for being responsive to the prior security feedback from the SECDIR (and thanks to Kyle Rose for performing it) and Security ADs in the return of this document to the telechat.

I support Martin Duke’s DISCUSS position and endorse the creation of a dedicated section covering which protocol features should not be used on the internet.

Thanks for addressing my other DISCUSS and COMMENTS points.  This ballot is now pruned down to the remaining issues under discussion.
2020-09-18
35 Roman Danyliw Ballot comment and discuss text updated for Roman Danyliw
2020-09-09
35 Martin Duke
[Ballot comment]
Thank you for addressing my DISCUSS.

Old Comment:

Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, …
[Ballot comment]
Thank you for addressing my DISCUSS.

Old Comment:

Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. It is not quite as simple as simply always copying DSCP to the outer packet.

Sec 9. I don't understand what this sentence means:

"The value of the 'Weight'  represents the relative weight of the total packets that match the maping entry." (s/maping/mapping, obviously)

What is the "relative weight" of packets? Is this the number of packets, the cumulative number of bytes, or something else?

Sec 16. "If  the attacker spoofs the source RLOC, it can mount a DoS attack by  redirecting traffic to the spoofed victim's RLOC, potentially  overloading it."

This not the only problem. The attacker could also DoS by directing traffic to an unreachable RLOC.
2020-09-09
35 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss
2020-09-09
35 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-35.txt
2020-09-09
35 (System) New version approved
2020-09-09
35 (System) Request for posting confirmation emailed to previous authors: Albert Cabellos-Aparicio , Vince Fuller , Dino Farinacci , David Meyer , Darrel Lewis
2020-09-09
35 Albert Cabellos-Aparicio Uploaded new revision
2020-09-09
34 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-34.txt
2020-09-09
34 (System) New version approved
2020-09-09
34 (System) Request for posting confirmation emailed to previous authors: Albert Cabellos-Aparicio , Darrel Lewis , David Meyer , Vince Fuller , Dino Farinacci
2020-09-09
34 Albert Cabellos-Aparicio Uploaded new revision
2020-08-12
33 Martin Duke
[Ballot discuss]
Thanks for the adding the “public internet” explanation and clarifying how multipath routing works. Remaking Discuss issues:

Sec 5.3 What is in the …
[Ballot discuss]
Thanks for the adding the “public internet” explanation and clarifying how multipath routing works. Remaking Discuss issues:

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4.  If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case:

- How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither?

- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?
2020-08-12
33 Martin Duke Ballot discuss text updated for Martin Duke
2020-07-29
33 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-29
33 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-07-29
33 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-33.txt
2020-07-29
33 (System) New version approved
2020-07-29
33 (System) Request for posting confirmation emailed to previous authors: David Meyer , Darrel Lewis , Albert Cabellos-Aparicio , Vince Fuller , Dino Farinacci
2020-07-29
33 Albert Cabellos-Aparicio Uploaded new revision
2020-07-27
32 Luigi Iannone Added to session: IETF-108: lisp  Wed-1300
2020-07-09
32 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-07-09
32 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-07-08
32 Murray Kucherawy
[Ballot comment]
I support Roman's DISCUSS specifically with respect to Section 16.  I also support Martin's and Roman's DISCUSSes with respect to being explicit about …
[Ballot comment]
I support Roman's DISCUSS specifically with respect to Section 16.  I also support Martin's and Roman's DISCUSSes with respect to being explicit about what's safe for use on the public Internet.
2020-07-08
32 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-07-08
32 Erik Kline
[Ballot discuss]
[ section 8 ]

* I think the currently architecture of IPv6 is such that at a minimum this
  doc should say …
[Ballot discuss]
[ section 8 ]

* I think the currently architecture of IPv6 is such that at a minimum this
  doc should say that instances SHOULD NOT be used when the inner traffic is
  IPv6 as overlapping IPv6 prefixes are best and fairly easily avoided and
  folks should be encouraged to avoid recreating some of the limitations that
  were unavoidable in IPv4.

[ section 12 ]

* When the outer header is IPv6, the flow label may also be set a la RFC 6438.

* When the inner header is IPv6, the flow label may also be a factor in the
  hashing (6348, if the flow label is non-zero a la 6437).

[ section 16 ]

* Is it worth adding an extra warning about gleaning mappings for EIDs that
  the ETR would otherwise have routed internally via the IGP?

* In addition to basic uRPF, can an ETR do LISP-specific uRPF, i.e. look up
  the source EID in the mapping system and check that the source RLOC is within
  the set returned?  If so, the document might mention it.  If not, it might
  be good state explicitly that LISP does not afford this kind of uRPF check.
2020-07-08
32 Erik Kline
[Ballot comment]
[ section 4.1 ]

* Source host "host1.abc.example.com" is sending a packet to
  "host2.xyz.example.com", exactly what host1 would …
[Ballot comment]
[ section 4.1 ]

* Source host "host1.abc.example.com" is sending a packet to
  "host2.xyz.example.com", exactly what host1 would do if the site
  was not using LISP.

  Suggest:

  Source host "host1.abc.example.com" is sending a packet to
  "host2.xyz.example.com", exactly as it would if the site was not
  was not using LISP.

* (6) "Subsequent packets"?  Can you say here what happens to the first
  packet that caused the mapping lookup to happen?  Ah, I see it's in
  section 6...  Up to you if you want drop a forward reference here to that.

[ section 7.x ]

* Still another options is for the tunnel to generate fragments at the outer
  header layer.  Even though may not be standard or recommended practice, a
  few words saying why this shouldn't be considered seems good; recommend
  pointing to https://tools.ietf.org/html/rfc4459#section-3.1 for a summary of
  the badness.

[ section 9 ]

* "multiple RLOC" -> "multiple RLOCs"
2020-07-08
32 Erik Kline [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline
2020-07-08
32 Benjamin Kaduk
[Ballot comment]
Thanks for addressing my previous Discuss points.  I have some notes
locally for an analysis of the security considerations at the boundaries of …
[Ballot comment]
Thanks for addressing my previous Discuss points.  I have some notes
locally for an analysis of the security considerations at the boundaries of
the various components in the ecosystem, and hope to have some text
soon.  That said, I'm balloting No Objection now anyway, to make my other
comments (from a fresh reread of the document) available now.

Section 1

  LISP is an overlay protocol that separates control from Data-Plane,
  this document specifies the Data-Plane as well as how LISP-capable
  routers (Tunnel Routers) exchange packets by encapsulating them to
  the appropriate location.  [...]

nit: comma splice

Section 3

  EID-Prefix:  An EID-Prefix is a power-of-two block of EIDs that are
      allocated to a site by an address allocation authority.  EID-
      Prefixes are associated with a set of RLOC addresses.  EID-Prefix
      allocations can be broken up into smaller blocks when an RLOC set
      is to be associated with the larger EID-Prefix block.

nit(?): this definition might be artifically narrow.  E.g., there might
be other cases when a prefix can be broken up, including when different
RLOC sets are to be assigned to sub-blocks of the larger EID-Prefix.

  End-System:  An end-system is an IPv4 or IPv6 device that originates
      packets with a single IPv4 or IPv6 header.  The end-system
      supplies an EID value for the destination address field of the IP
      header when communicating outside of its routing domain.  An end-

Just to check: when would an end-system supply a destination address
that is not an EID (i.e., what requires the "when communicating outside
of its routing domain" caveat)?  (This is in a mindset that assumes for
non-LISP systems the EID and RLOC collapse to the same value usable as
either EID or RLOC depending on context.)

  Routing Locator (RLOC):  An RLOC is an IPv4 [RFC0791] or IPv6
      [RFC8200] address of an Egress Tunnel Router (ETR).  An RLOC is
      the output of an EID-to-RLOC mapping lookup.  An EID maps to zero
      or more RLOCs.  Typically, RLOCs are numbered from blocks that are
      assigned to a site at each point to which it attaches to the
      underlay network; where the topology is defined by the
      connectivity of provider networks.  Multiple RLOCs can be assigned

nit: the bit after the semicolon is not a complete sentence; probably
just replacing it with a comma is best.

Section 4

  when re-routing of the path for a packet is desired.  A potential
  use-case for this would be an ISP router that needs to perform
  Traffic Engineering for packets flowing through its network.  In such
  a situation, termed "Recursive Tunneling", an ISP transit acts as an
  additional ITR, and the destination RLOC it uses for the new

nit: "Recursive Tunneling" is a defined term now, so we don't need quite
as much of an in-band definition.  Perhaps "in such a Recursive
Tunneling situation".

Section 4.1

      Request for that EID.  Both the ITR and the ETR MAY also
      influence the decision the other makes in selecting an RLOC.

It might be worth a bit more detail on how the one xTR influences the
decision of the other.

Section 5.3

  LISP Locator-Status-Bits (LSBs):  When the L-bit is also set, the
      'Locator-Status-Bits' field in the LISP header is set by an ITR to

nit: s/also// ?

Section 6

  The Map-Cache is a local cache of mappings, entries are expired based
  on the associated Time to live.  [...]

nit: comma splice

Section 7.1

  When the 'DF' field of the IP header is set to 1, or the packet is an
  IPv6 packet originated by the source host, the ITR will drop the

This seems to be the only indication that the mechanism described in
this subsection is an IPv4-only mechanism; it's probably worth being a
little more clear and up-front about that.

Section 9

  corresponding to the EID's topological location.  Each RLOC in the
  Locator-Set is associated with a 'Priority' and 'Weight', this
  information is used to select the RLOC to encapsulate.

nit: comma splice.

Section 10

  1.  An ETR MAY examine the Locator-Status-Bits in the LISP header of
      an encapsulated data packet received from an ITR.  If the ETR is
      also acting as an ITR and has traffic to return to the original
      ITR site, it can use this status information to help select an
      RLOC.

Since we said earlier that LSBs are "a hint to convey up/down router
status and not path reachability status", so I'd suggest rephrasing this
in terms of "use this status information to avoid selecting routers that
are down".

  When determining Locator up/down reachability by examining the
  Locator-Status-Bits from the LISP-encapsulated data packet, an ETR
  will receive up-to-date status from an encapsulating ITR about
  reachability for all ETRs at the site.  CE-based ITRs at the source
  site can determine reachability relative to each other using the site
  IGP as follows:

Similarly, we might clarify that this "reachability for all ETRs at the
site" reflects local reachability from the ITR in question, and may not
be indicative of reachability from the ETR receiving the LSBs.

  When ITRs at the site are not deployed in CE routers, the IGP can
  still be used to determine the reachability of Locators, provided
  they are injected into the IGP.  This is typically done when a /32
  address is configured on a loopback interface.

"/32 address" seems IPv4-specific.

  RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
  Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0
  to n-1 starting with the least significant bit.  For example, if an
  RLOC listed in the 3rd position of the Map-Reply goes down (ordinal
  value 2), then all ITRs at the site will clear the 3rd least
  significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for
  the packets they encapsulate.

It might be worth a forward-reference to § 13.2 to mention that, in line
with map versioning, the ITRs at the site already need to know the
Map-Reply contents and to also note that, per Section 5.5 of 6833bis,
the list of locators is sorted in a specific order.

Section 10.1

  When data flows bidirectionally between Locators from different
  sites, a Data-Plane mechanism called "nonce echoing" can be used to
  determine reachability between an ITR and ETR.  When an ITR wants to
  solicit a nonce echo, it sets the N- and E-bits and places a 24-bit
  nonce [RFC4086] in the LISP header of the next encapsulated data
  packet.

I do note the title of RFC 4086 and the resulting implication, but since
a generic "nonce" is just a "number used once" and can in such cases be
a simple counter, I think we really need to say "random nonce" (or
"selected from a uniform random distribution" or similar), since we do
rely on the unpredictability inherent in a random nonce.  For reference,
6833bis says "[t]he nonce MUST be generated by a properly seeded
pseudo-random source, see as an example [RFC4086]."

  The ITR will set the E-bit and N-bit for every packet it sends while
  in the echo-nonce-request state.  The time the ITR waits to process
  the echoed nonce before it determines the path is unreachable is
  variable and is a choice left for the implementation.

draft-ietf-tcpm-rto-consider, also on this week's telechat, might be an
interesting reference here.

  The echo-nonce algorithm is bilateral.  That is, if one side sets the
  E-bit and the other side is not enabled for echo-noncing, then the
  echoing of the nonce does not occur and the requesting side may
  erroneously consider the Locator unreachable.  An ITR SHOULD set the
  E-bit in an encapsulated data packet when it knows the ETR is enabled
  for echo-noncing.  This is conveyed by the E-bit in the Map-Reply
  message.

Do we want a corresponding "SHOULD NOT set the E-bit when [...]" here?

Also, this could be a good place to note that the Map-Reply E-bit is
spoofable in the absence of LISP-SEC.

  Many implementations default to not advertising they are echo-nonce
  capable in Map-Reply messages and so RLOC-probing tends to be used
  for RLOC reachability.

Do we want to hedge this with an "at the time of this writing" in case
it ages badly?

Section 13

  which ITRs requested its mappings.  For scalability reasons, it is
  desirable to maintain this approach but need to provide a way for
  ETRs to change their mappings and inform the sites that are currently
  communicating with the ETR site using such mappings.

nit: missing word (maybe s/need/there remains a need/?)

Section 13.1

  or down).  The specific value for the 'use-LSB' timer depends on the
  LISP deployment, the 'use-LSB' timer needs to be large enough for the
  destination xTR to retreive the updated EID-to-RLOC mappings.  A

nit: comma splice.

Section 16

  For example of such attacks, an off-path attacker can exploit the
  echo-nonce mechanism by sending data packets to an ITR with a random
  nonce from an ETR's spoofed RLOC.  Note the attacker must guess a
  valid nonce the ITR is requesting to be echoed within a small window
  of time.  [...]

I suggest noting that "the nonce echoing mechanism defined in this
document has only a 24-bit nonce, which is small enough that randomly
guessing a nonce will succeed with some regularity".
That would also give an opportunity to mention the idea, introduced in
lisp-gpe, that a dedicated shim header could be used to provide a longer
nonce that is strong enough to be reliable for route-returnability
checks (though I concede it's a bit far afield since it's a reference to
a reference to future work).

  Map-Versioning is a Data-Plane mechanism used to signal a peering xTR
  that a local EID-to-RLOC mapping has been updated, so that the
  peering xTR uses LISP Control-Plane signaling message to retrieve a
  fresh mapping.  This can be used by an attacker to forge the map-
  versioning field of a LISP encapsulated header and force an excessive
  amount of signaling between xTRs that may overload them.

I'd suggest adding at the end ", or prevent updates from being processed".

  LISP implementations and deployments which permit outer header
  fragments of IPv6 LISP encapsulated packets as a means of dealing
  with MTU issues should also use implementation techniques in ETRs to
  prevent this from being a DoS attack vector.  Limits on the number of
  fragments awaiting reassembly at an ETR, RTR, or PETR, and the rate
  of admitting such fragments may be used.

I note that draft-ietf-intarea-frag-fragile might be a relevant
reference (and is in the RFC Editor's queue).

Section 20.1

How can RFC 6830 be a normative reference when this document Obsoletes
it?

It's not really clear that RFCs 6831 or 8378 need to be normative; we
mostly just mention that they exist but don't require implementing or
using them.

Section 20.2

In addition to what idnits picked up, I note that RFC 1918 is only
referenced from the changelog entry saying that it's not referenced
anymore :)

I could see an argument that RFC 6936 should be normative, but defer to
my TSV-area colleagues.

I'm slightly surprised to see that Mirja did not insist upon RFC 8085
being a normative reference.
2020-07-08
32 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-07-08
32 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-07-08
32 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. This is really useful work and the document is easy to read. I also …
[Ballot comment]
Thank you for the work put into this document. This is really useful work and the document is easy to read. I also appreciate the way the document handles IPv6 and IPv4 at the same level. Selecting the UDP source port for ECMP based on the inner 5-tuple is smart .

Please find below a couple of non-blocking COMMENTs.

I also support Martin Duke's DISCUSS on ICMP.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
I find the use of "prepending a LISP header" unusual. Why not using the word "encapsulating" in a LISP packet? Or did I miss something? It may also slightly be confusing when parts of the text use "prepending" and others use "encapsulating".


-- Section 3 --
In "Egress Tunnel Router (ETR): ", is it required to be a 'server' to be able to do "A server host can be the endpoint of a LISP tunnel as well.". I would assume that any host can do it as well.
In "Ingress Tunnel Router (ITR):" per symmetry with ETR, can a server/client host also be the encapsulating endpoint of a LISP tunnel?

-- Section 4 --
I STRONGLY suggest to remove the "telnet" example and keep only "SSH".

Cosmetic: suggest to add reference to SSH, BGP, SNMP, ...

-- Section 5.3 --
For "outer header", there is specific text for the IPv4 DF-bit, DSCP, ... but what about specific IPv6 fields such as "flow label"?

Beside the convenience of making a bis document reflecting the original, defining the "R" bit as reserved when at the same IESG telechat there is the GPE document is really a missed opportunity IMHO.

Side comment (no need to reply), I am also puzzled why the outer DSCP is copied to the inner DSCP on decapsulation.

-- Section 10 --
Is it on purpose that IPv6 is ignored in "This is typically done when a /32 address is configured on a loopback interface." ?

-- Section 12 --
What is meant by "flow" in "The Source port SHOULD be the same for all packets belonging to the same flow." Probably worth defining it as packets with identical 5-tuple ?

I also suggest not to limit the load-balancing text to LAG but also to any topology where ECMP occurs.

Is there a reason why the hashing for LAG/load balancing is under the title of "Routing Locator Hashing"? The UDP source port selection is vaguely related but different than RLOC hashing.


-- Section 15 --
Unsure whether this performance section is still relevant in 2020, there are many similar overlay techniques.

== NITS ==


-- Section 1 --
There are some repetitions in this section such as "[I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. "

-- Section 3 --
When defining "anycast", I find that "An EID or RLOC can be an anycast address in each of their own address spaces." is more a property of EID/RLOC than adding anything to "anycast".
2020-07-08
32 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-07-08
32 Alissa Cooper [Ballot comment]
I support Roman's first two DISCUSS points.
2020-07-08
32 Alissa Cooper Ballot comment text updated for Alissa Cooper
2020-07-07
32 Roman Danyliw
[Ballot discuss]
** Section 1.1. The applicability statement of “large set of cooperating entities seeking to communicate over the public Internet or other large underlay …
[Ballot discuss]
** Section 1.1. The applicability statement of “large set of cooperating entities seeking to communicate over the public Internet or other large underlay IP infrastructures” seems inconsistent with many of the protocol mechanics described.  Specifically, most of the capabilities in the LISP header (Locator-Status-Bits, Echo-nonce mechanism, Map-Versioning, Instance ID) and the “Gleaning mechanism” are explicitly noted as not being suitable for Internet use.  This section needs to be explicit that only a subset of the protocol is suitable for the Internet.  Likewise, it should be clearer about what is assumed elements of the closed network are trusted for what particular behaviors.

** Section 16. Per “Locator-Status-Bits, echo-nonce and map-versioning SHOULD NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments” -- not disagreement.  However, under what circumstances would they be used on the internet to warrant a SHOULD NOT instead of a stronger MUST NOT?

** Section 8.  Per “Participants within a LISP deployment must agree on the meaning of Instance ID values.  The source and destination EIDs MUST belong to the same Instance ID.”  Could parties agree that the Instance ID is 802.1Q tags and send those across the internet?  Recommend stronger cautionary language on using Instance ID.
2020-07-07
32 Roman Danyliw
[Ballot comment]
Thank you for being responsive to the prior security feedback from the SECDIR (and thanks to Kyle Rose for performing it) and Security …
[Ballot comment]
Thank you for being responsive to the prior security feedback from the SECDIR (and thanks to Kyle Rose for performing it) and Security ADs in the return of this document to the telechat.

I support Martin Duke’s DISCUSS position and endorse the creation of a dedicated section covering which protocol features should not be used on the internet.

**  Section 4.0.  Per “… this document recommends that a maximum of two LISP headers …”, should a normative RECOMMENDED be used here instead?

** Section 5.3. Per “However, the same nonce can be used for a period of time when encapsulating to the same ETR.”, should this be bounded, even qualitatively?

** Section 9. 
      A
      "gleaned" Map-Cache entry is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner-header IP
      source address) of the received encapsulated packet. 

-- Is there any more precision that could be provided about the cache lifetime beyond “a few seconds”

-- Should normative language be provided that this cache should be aged and verification performed?

** Editorial Nit
-- Section 13.2. Typo s/synzhronization/ synchronization/
2020-07-07
32 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2020-07-03
32 Martin Duke
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely …
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely done over the public internet, and what can be only be done in trusted environments. I realize that this is probably because the no-internet provisions entered late in the game. If it were my document, I might reorganize it to make the distinction more clear (i.e. present the internet-safe dataplane spec and then have additional sections about insecure add-ons). That said, at this stage in the game I'd be happy to have a new section that clarified what is what. For example (assuming I'm reading it correctly, which is my point)

NEW:
"
Section 4 and a half. Deployment on the Public Internet

Many 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:

* SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;

* SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);

* SHOULD NOT use any data plane methods described in Section 10 for Routing Locator Reachability, instead relying solely on control plane methods;

* SHOULD NOT use any data plane methods described in Section 13 to update the EID-to-RLOC mapping, instead relying solely on control plane methods.

"

END

Perhaps my text is inaccurate, but something to that effect would be very helpful.

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4.  If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case:

- How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither?

- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?

Sec 9. I don't understand what this sentence means:
"The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic."

This would appear to be the inverse of the "Routing Locator Hashing" discussion in Section 12, which provides a technique for switching destination RLOC. Is this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e. each flow uses only one source RLOC)?

If not, would this involve potentially sending packets for one flow on different interfaces with different path characteristics, causing packet reordering. Or perhaps you mean each packet is sent from the same interface with a spoofed source RLOC, which creates interesting issues for ICMP returns and the like.
2020-07-03
32 Martin Duke
[Ballot comment]
Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. It …
[Ballot comment]
Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. It is not quite as simple as simply always copying DSCP to the outer packet.

Sec 9. I don't understand what this sentence means:

"The value of the 'Weight'  represents the relative weight of the total packets that match the maping entry." (s/maping/mapping, obviously)

What is the "relative weight" of packets? Is this the number of packets, the cumulative number of bytes, or something else?

Sec 16. "If  the attacker spoofs the source RLOC, it can mount a DoS attack by  redirecting traffic to the spoofed victim's RLOC, potentially  overloading it."

This not the only problem. The attacker could also DoS by directing traffic to an unreachable RLOC.
2020-07-03
32 Martin Duke Ballot comment and discuss text updated for Martin Duke
2020-07-03
32 Martin Duke
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely …
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely done over the public internet, and what can be only be done in trusted environments. I realize that this is probably because the no-internet provisions entered late in the game. If it were my document, I might reorganize it to make the distinction more clear (i.e. present the internet-safe dataplane spec and then have additional sections about insecure add-ons). That said, at this stage in the game I'd be happy to have a new section that clarified what is what. For example (assuming I'm reading it correctly, which is my point)

NEW:
"
Section 4 and a half. Deployment on the Public Internet

Many 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:

* SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;

* SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);

* SHOULD NOT use any data plane methods described in Section 10 for Routing Locator Reachability, instead relying solely on control plane methods;

* SHOULD NOT use any data plane methods described in Section 13 to update the EID-to-RLOC mapping, instead relying solely on control plane methods.

"

END

Perhaps my text is inaccurate, but something to that effect would be very helpful.

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4.  If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case:

- How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither?

- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?

Sec 9. I don't understand what this sentence means:
"The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic."
This would appear to be the inverse of the "Routing Locator Hashing" discussion in Section 12, which provides a technique for switching destination RLOC. Is this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e. each flow uses only one source RLOC)?

If not, would this involve potentially sending packets for one flow on different interfaces with different path characteristics, causing packet reordering. Or perhaps you mean each packet is sent from the same interface with a spoofed source RLOC, which creates interesting issues for ICMP returns and the like.
2020-07-03
32 Martin Duke Ballot discuss text updated for Martin Duke
2020-07-03
32 Martin Duke
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely …
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely done over the public internet, and what can be only be done in trusted environments. I realize that this is probably because the no-internet provisions entered late in the game. If it were my document, I might reorganize it to make the distinction more clear (i.e. present the internet-safe dataplane spec and then have additional sections about insecure add-ons). That said, at this stage in the game I'd be happy to have a new section that clarified what is what. For example (assuming I'm reading it correctly, which is my point)

NEW:
"
Section 4 and a half. Deployment on the Public Internet

Many 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:

* SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;

* SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);

* SHOULD NOT use any data plane methods described in Section 10 for Routing Locator Reachability, instead relying solely on control plane methods;

* SHOULD NOT use any data plane methods described in Section 13 to update the EID-to-RLOC mapping, instead relying solely on control plane methods.

"

END

Perhaps my text is inaccurate, but something to that effect would be very helpful.

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4.  If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case:
- How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither.
- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?

Sec 9. I don't understand what this sentence means:
"The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic."
This would appear to be the inverse of the "Routing Locator Hashing" discussion in Section 12, which provides a technique for switching destination RLOC. Is this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e. each flow uses only one source RLOC)?

If not, would this involve potentially sending packets for one flow on different interfaces with different path characteristics, causing packet reordering. Or perhaps you mean each packet is sent from the same interface with a spoofed source RLOC, which creates interesting issues for ICMP returns and the like.
2020-07-03
32 Martin Duke Ballot discuss text updated for Martin Duke
2020-07-03
32 Martin Duke
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely …
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely done over the public internet, and what can be only be done in trusted environments. I realize that this is probably because the no-internet provisions entered late in the game. If it were my document, I might reorganize it to make the distinction more clear (i.e. present the internet-safe dataplane spec and then have additional sections about insecure add-ons). That said, at this stage in the game I'd be happy to have a new section that clarified what is what. For example (assuming I'm reading it correctly, which is my point)

NEW:
"
Section 4 and a half. Deployment on the Public Internet

Many 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:

* SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;

* SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);

* SHOULD NOT use any data plane methods described in Section 10 for Routing Locator Reachability, instead relying solely on control plane methods;

* SHOULD NOT use any data plane methods described in Section 13 to update the EID-to-RLOC mapping, instead relying solely on control plane methods.

"

END

Perhaps my text is inaccurate, but something to that effect would be very helpful.

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4.  If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either.

While I fully support xTRs sending and processing ICMP packets, they don't always work in the public internet due to ICMP black holes and the like. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/, which is the RFC Editor queue, would be a more reliable way to determine the Path MTU. Regrettably, the LISP data plane doesn't have a method to pad or otherwise modify the size of its packets besides IP fragmentation, nor to acknowledge those packets beyond the insecure Nonce. It would be best if the ITRs and ETRs had some sort of reliable way to send and acknowledge packets to each other of variable size.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case:
- How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither.
- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?

Sec 9. I don't understand what this sentence means:
"The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic."
This would appear to be the inverse of the "Routing Locator Hashing" discussion in Section 12, which provides a technique for switching destination RLOC. Is this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e. each flow uses only one source RLOC)?

If not, would this involve potentially sending packets for one flow on different interfaces with different path characteristics, causing packet reordering. Or perhaps you mean each packet is sent from the same interface with a spoofed source RLOC, which creates interesting issues for ICMP returns and the like.
2020-07-03
32 Martin Duke Ballot discuss text updated for Martin Duke
2020-07-03
32 Martin Duke
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely …
[Ballot discuss]
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely done over the public internet, and what can be only be done in trusted environments. I realize that this is probably because the no-internet provisions entered late in the game. If it were my document, I might reorganize it to make the distinction more clear (i.e. present the internet-safe dataplane spec and then have additional sections about insecure add-ons). That said, at this stage in the game I'd be happy to have a new section that clarified what is what. For example (assuming I'm reading it correctly, which is my point)

NEW:
"
Section 4 and a half. Deployment on the Public Internet

Many 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:
* SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;
* SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);
* SHOULD NOT use any data plane methods described in Section 10 for Routing Locator Reachability, instead relying solely on control plane methods;
* SHOULD NOT use any data plane methods described in Section 13 to update the EID-to-RLOC mapping, instead relying solely on control plane methods.
"
END

Perhaps my text is inaccurate, but something to that effect would be very helpful.

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4.  If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either.

While I fully support xTRs sending and processing ICMP packets, they don't always work in the public internet due to ICMP black holes and the like. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/, which is the RFC Editor queue, would be a more reliable way to determine the Path MTU. Regrettably, the LISP data plane doesn't have a method to pad or otherwise modify the size of its packets besides IP fragmentation, nor to acknowledge those packets beyond the insecure Nonce. It would be best if the ITRs and ETRs had some sort of reliable way to send and acknowledge packets to each other of variable size.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case:
- How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither.
- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?

Sec 9. I don't understand what this sentence means:
"The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic."
This would appear to be the inverse of the "Routing Locator Hashing" discussion in Section 12, which provides a technique for switching destination RLOC. Is this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e. each flow uses only one source RLOC)?

If not, would this involve potentially sending packets for one flow on different interfaces with different path characteristics, causing packet reordering. Or perhaps you mean each packet is sent from the same interface with a spoofed source RLOC, which creates interesting issues for ICMP returns and the like.
2020-07-03
32 Martin Duke
[Ballot comment]
Comments:
Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. …
[Ballot comment]
Comments:
Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. It is not quite as simple as simply always copying DSCP to the outer packet.

Sec 9. I don't understand what this sentence means:
"The value of the 'Weight'  represents the relative weight of the total packets that match the maping entry." (s/maping/mapping, obviously)
What is the "relative weight" of packets? Is this the number of packets, the cumulative number of bytes, or something else?

Sec 16. "If  the attacker spoofs the source RLOC, it can mount a DoS attack by  redirecting traffic to the spoofed victim's RLOC, potentially  overloading it."
This not the only problem. The attacker could also DoS by directing traffic to an unreachable RLOC.
2020-07-03
32 Martin Duke [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke
2020-07-03
32 Robert Wilton
[Ballot comment]
Given that this document is an update to an existing RFC and has already been through one IESG ballot, I have not read …
[Ballot comment]
Given that this document is an update to an existing RFC and has already been through one IESG ballot, I have not read the entirety of this draft in detail.

A couple of minor comments:

8.  Using Virtualization and Segmentation with LISP

  For example, an 802.1Q VLAN tag or VPN identifier could be used as a
  24-bit Instance ID.  See [I-D.ietf-lisp-vpn] for LISP VPN use-case
  details.

Standard 802.1Q VLAN identifiers are only 12 bits (unless an I-SID is being used), so possibly you might want to slightly elaborate here.  E.g. do you potentially mean a pair of 802.1Q VLAN tags?

17.  Network Management Considerations

  Considerations for network management tools exist so the LISP
  protocol suite can be operationally managed.  These mechanisms can be
  found in [RFC7052] and [RFC6835].

Given that SNMP is on its way out, having an informative reference to the work-in-progress LISP YANG model may be helpful here.

Regards,
Rob
2020-07-03
32 Robert Wilton Ballot comment text updated for Robert Wilton
2020-07-03
32 Robert Wilton
[Ballot comment]
Given that this document is an update to an existing RFC and has already been through one IESG ballot, I have not read …
[Ballot comment]
Given that this document is an update to an existing RFC and has already been through one IESG ballot, I have not read the entirety of this draft in detail.

A couple of minor comments:

8.  Using Virtualization and Segmentation with LISP

  For example, an 802.1Q VLAN tag or VPN identifier could be used as a
  24-bit Instance ID.  See [I-D.ietf-lisp-vpn] for LISP VPN use-case
  details.

Standard 802.1Q VLAN identifiers are only 12 bits (unless an I-SID is being used), so possibly you might want to slightly elaborate here.  E.g. do you potentially mean a part of 802.1Q VLAN tags?

17.  Network Management Considerations

  Considerations for network management tools exist so the LISP
  protocol suite can be operationally managed.  These mechanisms can be
  found in [RFC7052] and [RFC6835].

Given that SNMP is gradually on its way out, having an informative reference to the work-in-progress LISP YANG model may be helpful here.

Regards,
Rob
2020-07-03
32 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-07-02
32 Luigi Iannone
draft-ietf-lisp-6830bis-32.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is …
draft-ietf-lisp-6830bis-32.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(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 draft is targeting Standard Track publication. It is the proper type of RFC, since is the evolution of RFC 6830, which is experimental and is one of items in the LISP WG charter. The RFC type is indicated in the 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 provides the specifications for the data-plane of LISP  (Locator/Id Separation Protocol).  LISP defines two namespaces, End-point  Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. In this way, LISP effectively separates control from data, and allows routers to create overlay networks.  LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.


Working Group Summary:

The current LISP WG charter has as main task porting the main LISP specifications on Standard Track. The WG has decided to focus on two main documents, one with the specifications of the data-plane and the other with the specifications of the control-plane. This document concerns the data-plane. The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related include some features/improvements not present in RFC 6830. On the organisation of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document there has been quite some discussion. The current version is the trade-off the WG  achieved and for which clear consensus has been reached. The version of the document that was approved during WG Last Call is -12. As a shepherd I required a few editorial changes to the document to fix some nits.

Post-Publication Request Summary:

  After requesting publication the document went through IESG review. The document raised several question from the Security and Transport Area ADs.
  In order to solve the issues raised the document went through 18 revisions (publication was requested for revision 14, now is 32).
  All revisions have been also presented in the LISP WG so to be sure that the group was aware of all changes and that there were no objections. No concerns were raised by the LISP WG. All issues seem to be addressed. That is why a new Internet reviews has been performed so to check whether there are concerns from the IETF community.


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, 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?

There are several independent implementations of the LISP data-plane.


Personnel:

Who is the Document Shepherd?

  Luigi Iannone


Who is the Responsible Area Director?

  Deborah Brungard .



(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 closely followed the document while in the WG and afterwards as a shepherd during IESG review.
  The document has improved a lot in quality thanks to the IESG and the authors working together. As previously stated, document changes have been always presented to the LISP WG to make sure that the updated do not raise any concern.  The output of the IDnits tool for the -32 version of the document is provided on point 11. There are three unused reference but these can be deleted while the document is in the RFC Editor queue.


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

  No broader review is required for this document. It has undergone a through review in the last year.



(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?

  All authors have made conforming IPR disclosure.



(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 concerning this specific document. However, there is an IPR disclosure filled by Huawei on RFC 6830, hence, because this document is largely based on that one, the same IPR disclosure may relate to this document.



(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 strong consensus behind this document, showing that the WG as a whole understand and agree with it and no objection have been raised during the document review.



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

idnits 2.16.04

/tmp/draft-ietf-lisp-rfc6830bis-32.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 5, 2020) is 119 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)

  == Unused Reference: 'RFC7833' is defined on line 1753, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7835' is defined on line 1760, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC8111' is defined on line 1778, but no explicit
    reference was found in the text


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

    Run idnits with the --verbose option for more detailed information about
    the items above.

--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review
criteria, such as the MIB 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?

  Yes.



(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?

There are no normative references in unclear state. For clarification, there is a normative reference to draft-ietf-lisp-rfc6833bis and one to draft-ietf-lisp-6834bis, but these documents passed as well WG Last Call. Worst case the RFC editor can hold this document in the queue until there is a RFC number for them.


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



(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 will obsolete RFC 6830, as mentioned in the header, abstract and introduction.



(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
5226
).

  IANA already allocated UDP port number 4341 for the LISP Data-Plane. This document just demands to update the description as follows:

      The IANA registry has allocated UDP port number 4341 for the LISP
      Data-Plane.  IANA has updated the description for UDP port 4341 as
      follows:

          lisp-data      4341 udp    LISP Data Packets


(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, etc.

  The document does not contain anything written in a formal
  language, hence, no validation and/or check has been
  performed.
2020-07-02
32 Luigi Iannone
draft-ietf-lisp-6830bis-32.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is …
draft-ietf-lisp-6830bis-32.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(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 draft is targeting Standard Track publication. It is the proper type of RFC, since is the evolution of RFC 6830, which is experimental and is one of items in the LISP WG charter. The RFC type is indicated in the 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 provides the specifications for the data-plane of LISP  (Locator/Id Separation Protocol).  LISP defines two namespaces, End-point  Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. In this way, LISP effectively separates control from data, and allows routers to create overlay networks.  LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.


Working Group Summary:

The current LISP WG charter has as main task porting the main LISP specifications on Standard Track. The WG has decided to focus on two main documents, one with the specifications of the data-plane and the other with the specifications of the control-plane. This document concerns the data-plane. The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related include some features/improvements not present in RFC 6830. On the organisation of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document there has been quite some discussion. The current version is the trade-off the WG  achieved and for which clear consensus has been reached. The version of the document that was approved during WG Last Call is -12. As a shepherd I required a few editorial changes to the document to fix some nits.

Post-Publication Request Summary:

  After requesting publication the document went through IESG review. The document raised several question from the Security and Transport Area ADs.
  In order to solve the issues raised the document went through 18 revisions (publication was requested for revision 14, now is 32).
  All revisions have been also presented in the LISP WG so to be sure that the group was aware of all changes and that there were no objections. No concerns were raised by the LISP WG. All issues seem to be addressed. That is why a new Internet reviews has been performed so to check whether there are concerns from the IETF community.


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, 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?

There are several independent implementations of the LISP data-plane.


Personnel:

Who is the Document Shepherd?

  Luigi Iannone


Who is the Responsible Area Director?

  Deborah Brungard .



(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 closely followed the document while in the WG and afterwards as a shepherd during IESG review.
  The document has improved a lot in quality thanks to the IESG and the auhtors working together. As previously stated, document changes have been always presented to the LISP WG to make sure that the updated do not raise any concern.  The output of the IDnits tool for the -32 version of the document is provided on point 11. There are three unsude reference but these can be deleted while the document is in the RFC Editor queue.


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

  No broader review is required for this document. It has undergone a through review in the last year.



(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?

  All authors have made conforming IPR disclosure.



(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 concerning this specific document. However, there is an IPR disclosure filled by Huawei on RFC 6830, hence, because this document is largely based on that one, the same IPR disclosure may relate to this document.



(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 strong consensus behind this document, showing that the WG as a whole understand and agree with it and no objection have been raised during the document review.



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

idnits 2.16.04

/tmp/draft-ietf-lisp-rfc6830bis-32.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 5, 2020) is 119 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)

  == Unused Reference: 'RFC7833' is defined on line 1753, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7835' is defined on line 1760, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC8111' is defined on line 1778, but no explicit
    reference was found in the text


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

    Run idnits with the --verbose option for more detailed information about
    the items above.

--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review
criteria, such as the MIB 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?

  Yes.



(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?

There are no normative references in unclear state. For clarification, there is a normative reference to draft-ietf-lisp-rfc6833bis and one to draft-ietf-lisp-6834bis, but these documents passed as well WG Last Call. Worst case the RFC editor can hold this document in the queue until there is a RFC number for them.


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



(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 will obsolete RFC 6830, as mentioned in the header, abstract and introduction.



(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
5226
).

  IANA already allocated UDP port number 4341 for the LISP Data-Plane. This document just demands to update the description as follows:

      The IANA registry has allocated UDP port number 4341 for the LISP
      Data-Plane.  IANA has updated the description for UDP port 4341 as
      follows:

          lisp-data      4341 udp    LISP Data Packets


(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, etc.

  The document does not contain anything written in a formal
  language, hence, no validation and/or check has been
  performed.
2020-06-22
32 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-06-22
32 Amy Vezza Telechat date has been changed to 2020-07-09 from 2019-02-07
2020-06-22
32 Deborah Brungard Ballot has been issued
2020-06-22
32 Deborah Brungard Ballot writeup was changed
2020-06-18
32 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-06-17
32 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-06-17
32 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-rfc6830bis-32. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-rfc6830bis-32. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

the existing registration for port number 4341 is as follows:

Service Name: lisp-data
Port number: 4341
Transport protocol: UDP
Description: LISP Data Packets
Assignee: IESG
Contact: IETF Chair
Reference: RFC6830

IANA Question --> the existing registration appears to alread meet the requirements of section 19.1 of the current draft. Should the reference now be changed to [ RFC-to-be ]?

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-06-04
32 Amy Vezza
The following Last Call announcement was sent out (ends 2020-06-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lisp-rfc6830bis@ietf.org, ggx@gigix.net, db3546@att.com, lisp@ietf.org, Luigi …
The following Last Call announcement was sent out (ends 2020-06-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lisp-rfc6830bis@ietf.org, ggx@gigix.net, db3546@att.com, lisp@ietf.org, Luigi Iannone , lisp-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Locator/ID Separation Protocol (LISP)) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'The Locator/ID Separation
Protocol (LISP)'
  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 2020-06-18. 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. Note, this is a 2nd IETF Last
Call due to technical changes during IESG review.

Abstract


  This document describes the Data-Plane protocol for the Locator/ID
  Separation Protocol (LISP).  LISP defines two namespaces, End-point
  Identifiers (EIDs) that identify end-hosts and Routing Locators
  (RLOCs) that identify network attachment points.  With this, LISP
  effectively separates control from data, and allows routers to create
  overlay networks.  LISP-capable routers exchange encapsulated packets
  according to EID-to-RLOC mappings stored in a local Map-Cache.

  LISP requires no change to either host protocol stacks or to underlay
  routers and offers Traffic Engineering, multihoming and mobility,
  among other features.

  This document obsoletes RFC 6830.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8378: Signal-Free Locator/ID Separation Protocol (LISP) Multicast (Experimental - IETF stream)
    rfc6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments (Experimental - IETF stream)
    rfc6830: The Locator/ID Separation Protocol (LISP) (Experimental - IETF stream)
    draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream)



2020-06-04
32 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-06-04
32 Deborah Brungard Last call was requested
2020-06-04
32 Deborah Brungard IESG state changed to Last Call Requested from IESG Evaluation - Defer::AD Followup
2020-06-04
32 Deborah Brungard Last call announcement was changed
2020-06-04
32 Deborah Brungard Last call announcement was generated
2020-03-05
32 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-32.txt
2020-03-05
32 (System) New version approved
2020-03-05
32 (System) Request for posting confirmation emailed to previous authors: Dino Farinacci , Albert Cabellos-Aparicio , David Meyer , Vince Fuller , Darrel Lewis
2020-03-05
32 Albert Cabellos-Aparicio Uploaded new revision
2020-03-05
31 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-31.txt
2020-03-05
31 (System) New version approved
2020-03-05
31 (System) Request for posting confirmation emailed to previous authors: David Meyer , Dino Farinacci , Albert Cabellos-Aparicio , Vince Fuller , Darrel Lewis
2020-03-05
31 Albert Cabellos-Aparicio Uploaded new revision
2020-01-13
30 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-30.txt
2020-01-13
30 (System) New version approved
2020-01-13
30 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2020-01-13
30 Albert Cabellos-Aparicio Uploaded new revision
2020-01-12
29 Benjamin Kaduk
[Ballot discuss]
[Someone (me?) still owe some analysis on the security considerations at the boundaries
of the various components in the ecosystem.  Deborah putting this …
[Ballot discuss]
[Someone (me?) still owe some analysis on the security considerations at the boundaries
of the various components in the ecosystem.  Deborah putting this back on an IESG
telechat as a returning item might be the most expedient way to get this to happen, sadly.]
2020-01-12
29 Benjamin Kaduk Ballot discuss text updated for Benjamin Kaduk
2020-01-08
29 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-29.txt
2020-01-08
29 (System) New version approved
2020-01-08
29 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2020-01-08
29 Albert Cabellos-Aparicio Uploaded new revision
2019-12-30
28 Benjamin Kaduk
[Ballot discuss]
Thank you for all the updates in the -28; we're making great progress!

My ballot on the -26 included:

% The usage of …
[Ballot discuss]
Thank you for all the updates in the -28; we're making great progress!

My ballot on the -26 included:

% The usage of the Instance ID does not seem to be adequately covered; from
% what I've been able to pick up so far it seems that both source and
% destination participants must agree on the meaning of an Instance ID, and
% the source and destination EIDs must be in the same Instance.  This does
% not seem like it is compatible with Internet scale, especially if there are
% only 24 usable bits of Instance ID.

The -28 now says that the whole LISP deployment has to agree on the
meaning of Instance ID values (thank you!), but I'm still not entirely sure
if the source and destination EIDs need to belong to the same Instance.
If they do need to be in the same Instance, I think we should note that
(but if not, then the current text should be fine as-is).
My apologies if this was already covered and I just forgot.

[Someone (me?) still owe some analysis on the security considerations at the boundaries
of the various components in the ecosystem.  Deborah putting this back on an IESG
telechat as a returning item might be the most expedient way to get this to happen, sadly.]
2019-12-30
28 Benjamin Kaduk
[Ballot comment]
Thank you for the discussion of Map-Version synchronization requirements!
I'm not in a position to assess whether the current 1-minute window is
adequate …
[Ballot comment]
Thank you for the discussion of Map-Version synchronization requirements!
I'm not in a position to assess whether the current 1-minute window is
adequate for the expected usage, and trust that you picked something reasonable.

We had a good exchange off-list about my comments on the -26/-27; I'm going
to keep a couple of the points from that but expand on them when the original was
unclear.

Section 10.1

Some side discussion: in some sense, the echo nonce functionality is the
most reliable method for determining reachability, and yet we say that it
MAY be overridden by other methods.
There's also some potential conflict between the "will set the E-bit and
N-bit for every packet it sends while in the echo-nonce-request state" and
the later text about echoing the peer's nonce when both ETR and ITR go into
the echo-nonce-request state at the same time, since if the E-bit and N-bit
are sent on literally every packet sent, then it's not possible to send packets
that echo the peer's nonce (which would just set the N-bit but not the E-bit,
if I understand correctly).

  erroneously consider the Locator unreachable.  An ITR SHOULD only set
  the E-bit in an encapsulated data packet when it knows the ETR is
  enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
  probe Map-Reply message.

Is this only in RLOC-probe Map-Reply messages (and not generic, including
mapping-driven, Map-Reply messages)?  Specifically, my understanding was that
any Map-Reply could set the E-bit to indicate support for echo noncing, and so
there's not much point in us specifically qualifying that the E-bit is set in an
*RLOC-probe* Map-Reply (as opposed to just "a Map-Reply"). If this behavior
is specific to the RLOC-probe replies, I think that 6833bis needs
some clarification in Section 5.4.
2019-12-30
28 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2019-11-17
28 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-28.txt
2019-11-17
28 (System) New version approved
2019-11-17
28 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2019-11-17
28 Albert Cabellos-Aparicio Uploaded new revision
2019-11-17
27 Luigi Iannone Added to session: IETF-106: lisp  Tue-1000
2019-08-02
27 Benjamin Kaduk
[Ballot discuss]
Updating for the -27 by removing points that are fully addressed but leaving
points that I still want to have further discussion on.  …
[Ballot discuss]
Updating for the -27 by removing points that are fully addressed but leaving
points that I still want to have further discussion on.  It may be most expedient to
continue discussion on my -26 ballot thread.

Please also note that the COMMENT section was entirely refreshed for the -26 and
had a few additions as I read the -27.

The various places where we mention "gleaming" or similar unauthenticated
(un-path-verified?) schemes for learning mapping information should all
mention at their description that they are susceptible to spoofing and link
to the security considerations.
[ed. I have noted offlist to the authors some specific locations]

Section 13

  When a Locator record is removed from a Locator-Set, ITRs that have
  the mapping cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, even if the Locator is in
  the list, it will not be used.  For new mapping requests, the xTRs
  can set the Locator AFI to 0 (indicating an unspecified address), as
  well as setting the corresponding Locator-Status-Bit to 0.  This

I do not remember there being an ordering (or even consistency) requirement
on the ITR-RLOC entries in the Map-Request, so it's unclear that just
replacing one entry with an AFI-0 entry would convey this information.  I
suppose that using only a single ITR-RLOC entry, with AFI 0, would provide
a usable signal to the ETR, but that does not seem to be what is being
described here.  (Also, on a rhetorical point, please clarify that the "as
well as" is for setting the LSB to 0 in data packets; Map-Requests do not
include any LSBs.)

  If many changes occur to a mapping over a long period of time, one
  will find empty record slots in the middle of the Locator-Set and new
  records appended to the Locator-Set. At some point, it would be
  useful to compact the Locator-Set so the Locator-Status-Bit settings
  can be efficiently packed.

This text, implying that compactification must wait for some unspecified
later event, seems to be assuming some requirement to preserve order of
Locator-Set entries that I cannot find a description of in either 6830bis
or 6833bis.
[ed. these previous two items are rather poorly described; another thread is ongoing
to try to clarify both my concerns and how they might be addressed]

I think Warren is correct that there is also an attack that lies in
convincing an ITR that an ETR is not reachable even when it is reachable.


The following items were present in my original DISCUSS position and still
have not been resolved.  Note that I copy below the previous ballot text
even for some issues that are described above already in different words.

There are some fairly subtle ordering requirements between the order of
entries in Map-Reply messages and the Locator-Status-Bits in data-plane
traffic (so that the semantic meaning of the status bits are meaningful),
which is only given a minimal treatment in the control-plane document.  The
need for synchronization in interpreting these bits should be mentioned
more prominently in the data-plane document as well.

The usage of the Instance ID does not seem to be adequately covered; from
what I've been able to pick up so far it seems that both source and
destination participants must agree on the meaning of an Instance ID, and
the source and destination EIDs must be in the same Instance.  This does
not seem like it is compatible with Internet scale, especially if there are
only 24 usable bits of Instance ID.

There seems to be a lot of intra-site synchronization requirements, notably
with respect to Map-Version consistency, the contents and ordering of
locator sets for EIDs in the site, etc.; the actual hard requirements for
synchronization within a site should be clearly called out, ideally in a
single location.

The security considerations attempt to defer substantially to the
threat-analysis in RFC 7835, which does not really seem like a complete
threat analysis and does not provide analysis as to what requirements are
placed on the boundaries between the different components of LISP (data
plane, control plane, mapping system, various extensions, etc.).  The
secdir reviewer had some good thoughts in this space.

[We're getting closer to something that's possible to properly analyze, but
I haven't done that analysis yet]
2019-08-02
27 Benjamin Kaduk
[Ballot comment]
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually …
[Ballot comment]
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually don't understand are
generally accompanied by text like "just to confirm" or provide some option
for possible interpretation.  Others are intended as rhetorical devices,
indicating that the text locally at this point in the document is unclear
and the question posed should be addressed in the document, in-line.

Section 1

                                                        LISP
  encapsulation uses a dynamic form of tunneling where no static
  provisioning is required or necessary.

Do I interpret this correctly as meaning that no static provisioning is
necessary on end-hosts?  It seems that ETRs and the mapping system
entities definitely need static configuration.  But do end sites need to
know what lisp site/administrative domain they are part of?

  LISP is an overlay protocol that separates control from Data-Plane,
  this document specifies the Data-Plane, how LISP-capable routers
  (Tunnel Routers) exchange packets by encapsulating them to the
  appropriate location.  [...]

nit: this is a comma splice

Section 3

  Anycast Address:  Anycast Address is a term used in this document to

How does this definition differ from the one in RFC 8499?

  Data-Probe:  A Data-Probe is a LISP-encapsulated data packet where
      the inner-header destination address equals the outer-header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  [...]

nit: is this better as two sentences?  ("...is a LISP-encapsulated data
packet where the inner-header destination address equals the outer-header
destination address.  It is used to trigger...")

I would also say something in this paragraph about how this behavior blurs
the distinction between EID and RLOC.

                    When using Data-Probes, by sending Map-Requests on
      the underlying routing system, EID-Prefixes must be advertised.

I don't understand why the one follows from the other (in fact, there seem
to be three not-particularly-related concepts in this sentence).

(I also note that "Data-Probe" is not mentioned anywhere in this document
other than its own definition, which would suggest that it could be moved
to 6833bis, which does mention them.)

  EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC

I thought we had agreed to remove this "global distributed database"
language.

      addresses that are routable on the underlay.  Note that there MAY
      be transient conditions when the EID-Prefix for the site and
      Locator-Set for each EID-Prefix may not be the same on all ETRs.

nit: we haven't indicated a definite site for "the site" to be meaningful.

  EID-to-RLOC Map-Cache:  The EID-to-RLOC Map-Cache is generally
      short-lived, on-demand table in an ITR that stores, tracks, and is
      responsible for timing out and otherwise validating EID-to-RLOC
      mappings.  This cache is distinct from the full "database" of EID-
      to-RLOC mappings; it is dynamic, local to the ITR(s), and
      relatively small, while the database is distributed, relatively
      static, and much more global in scope to LISP nodes.

"global" caught my eye again here; perhaps "global in scope to a LISP
deployment"?

  EID-Prefix:  An EID-Prefix is a power-of-two block of EIDs that are
      allocated to a site by an address allocation authority.  EID-
      Prefixes are associated with a set of RLOC addresses.  EID-Prefix
      allocations can be broken up into smaller blocks when an RLOC set
      is to be associated with the larger EID-Prefix block.

nit: I think the causality here is backwards -- the breaking up does not
occur at the moment that you associate an RLOC set to a larger EID-Prefix
block.

  Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's

Er, that the ISP ITR uses as source or as destination?

  Negative Mapping Entry:  A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty, one with an encoded Locator
      count of 0.  This type of entry could be used to describe a prefix
      from a non-LISP site, which is explicitly not in the mapping
      database.  There are a set of well-defined actions that are
      encoded in a Negative Map-Reply.

This bit about Negative Map-Replys comes out of the blue; is it really
needed in this paragraph?

  TE-ETR:  A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

nit: is it really the act of stripping the header that is done for TE
purposes?

Also in Section 3 (moved from Discuss, since probably editorial):
  Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

Section 4.1

  2.  The LISP ITR must be able to map the destination EID to an RLOC
      of one of the ETRs at the destination site.  The specific method
      used to do this is not described in this example.  See
      [I-D.ietf-lisp-rfc6833bis] for further information.

  3.  The ITR sends a LISP Map-Request as specified in
      [I-D.ietf-lisp-rfc6833bis].  Map-Requests SHOULD be rate-limited.

At risk of repeating myself, isn't (3) just doing what (2) says the ITR
must be able to do?  I don't see why both items are needed.

  5.  The ETR looks at the destination EID of the Map-Request and
      matches it against the prefixes in the ETR's configured EID-to-
      RLOC mapping database.  This is the list of EID-Prefixes the ETR
      is supporting for the site it resides in.  If there is no match,
      the Map-Request is dropped.  Otherwise, a LISP Map-Reply is

Isn't this (1) something that 6833bis should be authoritative on, and (2)
a recipe for random hangs if the mapping system ever misdirects a
map-request?

  7.  Subsequent packets from host1.abc.example.com to
      host2.xyz.example.com will have a LISP header prepended by the

The use of "subsequent" implies that he original IP packet does not receive
this treatment.  But we don't say anywhere that it gets dropped, leaving us
guessing as to what is supposed to happen to it.

  9.  In order to defer the need for a mapping lookup in the reverse
      direction, an ETR can OPTIONALLY create a cache entry that maps
      the source EID (inner-header source IP address) to the source
      RLOC (outer-header source IP address) in a received LISP packet.
      Such a cache entry is termed a "glean mapping" and only contains

This gleaming seems susceptible to spoofing.

Section 5.3

  L: The L-bit is the 'Locator-Status-Bits' field enabled bit.  When
      this bit is set to 1, the Locator-Status-Bits in the second
      32 bits of the LISP header are in use.

What happens to those bits when the L-bit is set to zero?

  E: The E-bit is the echo-nonce-request bit.  This bit MUST be ignored
      and has no meaning when the N-bit is set to 0.  When the N-bit is
      set to 1 and this bit is set to 1, an ITR is requesting that the

Do we need to say what to do when N is 1 and E is 0?

  LISP Locator-Status-Bits (LSBs):  When the L-bit is also set, the
      [...]
      'Locator-Status-Bits' field in the LISP header is set by an ITR to
      indicate to an ETR the up/down status of the Locators in the
      source site.  Each RLOC in a Map-Reply is assigned an ordinal
      value from 0 to n-1 (when there are n RLOCs in a mapping entry).
      The Locator-Status-Bits are numbered from 0 to n-1 from the least
      significant bit of the field.  The field is 32 bits when the I-bit
      is set to 0 and is 8 bits when the I-bit is set to 1.  When a

I guess maybe clarifying that LSB 0 is the last bit in the field is
worthwhile?
Ah, we have an example down in Section 10.

      the ETRs at the same site.  When a site has multiple EID-Prefixes
      that result in multiple mappings (where each could have a
      different Locator-Set), the Locator-Status-Bits setting in an
      encapsulated packet MUST reflect the mapping for the EID-Prefix
      that the inner-header source EID address matches.  If the LSB for

I don't think there is guaranteed to be a single unique EID-Prefix that
matches the inner source EID; we need to say longest-match here.

  When doing ETR/PETR decapsulation:

  o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in
      the case of IPv6) MUST be copied from the outer-header 'Time to
      Live' field, when the Time to Live value of the outer header is
      less than the Time to Live value of the inner header.  Failing to
      perform this check can cause the Time to Live of the inner header
      to increment across encapsulation/decapsulation cycles.  This
      check is also performed when doing initial encapsulation, when a
      packet comes to an ITR or PITR destined for a LISP site.

I'm not sure how to do this check when doing initial encapsulation; there's
no outer header then.

  o  The outer-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) to the inner-header.

IPv6 is a first-class IP protocol; it should not be relegated to a
parenthetical.  (This shows up in several places.)

  Note that if an ETR/PETR is also an ITR/PITR and chooses to re-
  encapsulate after decapsulating, the net effect of this is that the
  new outer header will carry the same Time to Live as the old outer
  header minus 1.

Where is the decrementing of the TTL documented?  I just see "copy" in the
above text.

Is the last paragraph adding anything that was not already said previously?
It seems pretty redundant on first read.

Section 6

  The Map-Cache is a local cache of mappings, entries are expired based
  on the associated Time to live.  In addition, entries can be updated

nit: comma splice.

            Finally, the Map-Cache also contains reachability
  information about EIDs and RLOCs, and uses LISP reachability
  information mechanisms to determine the reachability of RLOCs, see
  Section 10 for the specific mechanisms.

nit: The Map-Cache performs reachability discovery?  That seems incongruous with
a cache nature; perhaps it is better to say that it is updated with the
results of such procedures.

Section 7.1

                    Note that reassembly can happen at the ETR if the
  encapsulated packet was fragmented at or after the ITR.

Why would an ETR want to take on this additional state-keeping burden
instead of relegating it to the end host?

  When the 'DF' field of the IP header is set to 1, or the packet is an
  IPv6 packet originated by the source host, the ITR will drop the
  packet when the size is greater than L and send an ICMPv4 ICMP

Which size?

Section 8

  There are several cases where segregation is needed at the EID level.
  For instance, this is the case for deployments containing overlapping
  addresses, traffic isolation policies or multi-tenant virtualization.

(Note that earlier we state that EIDs must be unique...)

Section 9

  o  Either side (more likely the server-side ETR) decides not to send
      a Map-Request.  For example, if the server-side ETR does not send
      Map-Requests, it gleans RLOCs from the client-side ITR, giving the

[in the next paragraph we talk about sending Map-Requests to verify gleamed
mappings, which doesn't mesh very well with "does not send Map-Requests"
here]

      client-side ITR responsibility for bidirectional RLOC reachability
      and preferability.  Server-side ETR gleaning of the client-side
      ITR RLOC is done by caching the inner-header source EID and the
      outer-header source RLOC of received packets.  [...]

Isn't this susceptible to spoofing?

  Instead of using the Map-Cache or mapping system, RLOC information
  MAY be gleaned from received tunneled packets or Map-Request
  messages.  A "gleaned" Map-Cache entry, one learned from the source

To double-check, this is describing the same behavior described in the iast
bullet point?

  RLOC of a received encapsulated packet, is only stored and used for a
  few seconds, pending verification.  Verification is performed by
  sending a Map-Request to the source EID (the inner-header IP source
  address) of the received encapsulated packet.  A reply to this

As I commented on 6833bis, I'd appreciate mention that this
"verification" is akin to reverse-routability verification and does not
involve any cryptographic assurances.

                    This "gleaning" mechanism is OPTIONAL, refer to
  Section 16 for security issues regarding this mechanism.

nit: comma splice

Section 10

  1.  An ETR MAY examine the Locator-Status-Bits in the LISP header of
      an encapsulated data packet received from an ITR.  If the ETR is
      also acting as an ITR and has traffic to return to the original
      ITR site, it can use this status information to help select an
      RLOC.

Maybe note that this only conveys "up" information, which is necessary but
not sufficient for reachability.

  2.  When an ETR receives an encapsulated packet from an ITR, the
      source RLOC from the outer header of the packet is likely to be
      reachable.

Liktely to, but not guaranteed, since that's a spoofable field and we rely
on the ITR to fill it with something useful.

  When determining Locator up/down reachability by examining the
  Locator-Status-Bits from the LISP-encapsulated data packet, an ETR
  will receive up-to-date status from an encapsulating ITR about
  reachability for all ETRs at the site.  [...]

This ("up-to-date") wording concerns me, relating to the interaction
between map-versioning, addition/removal of locators from a mapping, and
propagation to values in the LSBs.  I do not think there is currently a
strong consistency guarantee in place that would justify the "up-to-date"
wording, and 6834bis has not received IETF (or IESG) review yet.  My
current understanding is that the status information provided via this
mechanism could be characterized as "best-effort" or "accurate in the
steady-state".

  The security considerations of Section 16 related with data-plane
  reachability applies to the data-plane RLOC reachability mechanisms

nit: I think this is "related to", not "related with".

Section 10.1

  When this packet is received by the ETR, the encapsulated packet is
  forwarded as normal.  When the ETR is an xTR (co-located as an ITR),
  it next sends a data packet to the ITR (when it is an xTR co-located

nit: I don't think this is grammatical; maybe "when it next sends"?

Some side discussion: in some sense, the echo nonce functionality is the
most reliable method for determining reachability, and yet we say that it
MAY be overridden by other methods.
There's also some potential conflict between the "will set the E-bit and
N-bit for every packet it sends while in the echo-nonce-request state" and
the later text about echoing the peer's nonce when both ETR and ITR go into
the echo-nonce-request state at the same time.

  erroneously consider the Locator unreachable.  An ITR SHOULD only set
  the E-bit in an encapsulated data packet when it knows the ETR is
  enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
  probe Map-Reply message.

Is this only in RLOC-probe Map-Reply messages (and not generic, including
mapping-driven, Map-Reply messages)?  If so, I think that 6833bis needs
some clarification in Section 5.4.  (If not, I think that "RLOC-probe"
should be removed from here.)

Section 13

  ignores them.  However, this can only happen for locator addresses
  that are lexicographically greater than the locator addresses in the
  existing Locator-Set.

(It might be apropos to explicitly remind the reader that the entries in the
locator-set are sorted by IP address.)

  When a Locator record is removed from a Locator-Set, ITRs that have
  the mapping cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, even if the Locator is in

Why will the xTRs set the Locator-Status-Bit to 0?  Won't they just use
the updated mapping and have a smaller number of LSBs in their data
packets?

  If many changes occur to a mapping over a long period of time, one
  will find empty record slots in the middle of the Locator-Set and new
  records appended to the Locator-Set. At some point, it would be

How can this happen when the Locator-Set is required to be sorted?  Or does
the sorting requirement not apply to the "Map-Reply Record" field of the
Map-Request?

Section 13.1

  A Map-Version Number can be included in Map-Register messages as
  well.  This is a good way for the Map-Server to assure that all ETRs
  for a site registering to it will be synchronized according to Map-
  Version Number.

This seems vastly underspecified not just to the detailed semantics (for
which the 6834bis reference is probably a suitable replacement) but also
the goals of the synchronization that is to be obtained.  It's unclear to
me that it's appropriate to mention Map-Register and versions at all in
this document; instead we might just note that 6834bs provides for version
synchronization for the ETRs within a site.  (If that's what it does; I
haven't yet read it in detail.)

Section 14

  Just like it would if the destination EID was a unicast address.

nit: this is a sentence fragment; I suggest joining to the previous
sentence with a comma.

Section 15

  o  When a tunnel-encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special Forwarding
      Information Base (FIB) entries for the EID-Prefixes of EIDs served
      by the ETR (those for which the router provides an RLOC

Isn't the outer destination address an RLOC?  How do EIDs come into play?

Section 20.2

Maybe throw us a bone and include the string
"draft-iannone-openlisp-implementation" in the [OPENLISP] entry?
2019-08-02
27 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2019-07-11
27 Luigi Iannone Added to session: IETF-105: lisp  Mon-1330
2019-06-17
27 Warren Kumari [Ballot comment]
Thank you for considering and addressing my DISCUSS concerns.
2019-06-17
27 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2019-06-16
27 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-06-16
27 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-06-16
27 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-27.txt
2019-06-16
27 (System) New version approved
2019-06-16
27 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2019-06-16
27 Albert Cabellos-Aparicio Uploaded new revision
2019-03-27
26 Luigi Iannone Added to session: IETF-104: lisp  Fri-0900
2019-02-14
26 Tero Kivinen Closed request for Telechat review by SECDIR with state 'Withdrawn'
2019-02-14
26 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kyle Rose
2019-02-14
26 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kyle Rose
2019-02-12
26 Kyle Rose Assignment of request for Telechat review by SECDIR to Kyle Rose was rejected
2019-02-07
26 Jean Mahoney Closed request for Telechat review by GENART with state 'Team Will not Review Version'
2019-02-07
26 Cindy Morgan IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer::AD Followup
2019-02-07
26 Benjamin Kaduk
[Ballot comment]
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually …
[Ballot comment]
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually don't understand are
generally accompanied by text like "just to confirm" or provide some option
for possible interpretation.  Others are intended as rhetorical devices,
indicating that the text locally at this point in the document is unclear
and the question posed should be addressed in the document, in-line.

Section 1

                                                        LISP
  encapsulation uses a dynamic form of tunneling where no static
  provisioning is required or necessary.

Do I interpret this correctly as meaning that no static provisioning is
necessary on end-hosts?  It seems that ETRs and the mapping system
entities definitely need static configuration.  But do end sites need to
know what lisp site/administrative domain they are part of?

  LISP is an overlay protocol that separates control from Data-Plane,
  this document specifies the Data-Plane, how LISP-capable routers
  (Tunnel Routers) exchange packets by encapsulating them to the
  appropriate location.  [...]

nit: this is a comma splice

Section 3

  Anycast Address:  Anycast Address is a term used in this document to

How does this definition differ from the one in RFC 8499?

  Data-Probe:  A Data-Probe is a LISP-encapsulated data packet where
      the inner-header destination address equals the outer-header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  [...]

nit: is this better as two sentences?  ("...is a LISP-encapsulated data
packet where the inner-header destination address equals the outer-header
destination address.  It is used to trigger...")

I would also say something in this paragraph about how this behavior blurs
the distinction between EID and RLOC.

                    When using Data-Probes, by sending Map-Requests on
      the underlying routing system, EID-Prefixes must be advertised.

I don't understand why the one follows from the other (in fact, there seem
to be three not-particularly-related concepts in this sentence).

(I also note that "Data-Probe" is not mentioned anywhere in this document
other than its own definition, which would suggest that it could be moved
to 6833bis, which does mention them.)

  EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC

I thought we had agreed to remove this "global distributed database"
language.

      addresses that are routable on the underlay.  Note that there MAY
      be transient conditions when the EID-Prefix for the site and
      Locator-Set for each EID-Prefix may not be the same on all ETRs.

nit: we haven't indicated a definite site for "the site" to be meaningful.

  EID-to-RLOC Map-Cache:  The EID-to-RLOC Map-Cache is generally
      short-lived, on-demand table in an ITR that stores, tracks, and is
      responsible for timing out and otherwise validating EID-to-RLOC
      mappings.  This cache is distinct from the full "database" of EID-
      to-RLOC mappings; it is dynamic, local to the ITR(s), and
      relatively small, while the database is distributed, relatively
      static, and much more global in scope to LISP nodes.

"global" caught my eye again here; perhaps "global in scope to a LISP
deployment"?

  EID-Prefix:  An EID-Prefix is a power-of-two block of EIDs that are
      allocated to a site by an address allocation authority.  EID-
      Prefixes are associated with a set of RLOC addresses.  EID-Prefix
      allocations can be broken up into smaller blocks when an RLOC set
      is to be associated with the larger EID-Prefix block.

nit: I think the causality here is backwards -- the breaking up does not
occur at the moment that you associate an RLOC set to a larger EID-Prefix
block.

  Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's

Er, that the ISP ITR uses as source or as destination?

  Negative Mapping Entry:  A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty, one with an encoded Locator
      count of 0.  This type of entry could be used to describe a prefix
      from a non-LISP site, which is explicitly not in the mapping
      database.  There are a set of well-defined actions that are
      encoded in a Negative Map-Reply.

This bit about Negative Map-Replys comes out of the blue; is it really
needed in this paragraph?

  TE-ETR:  A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

nit: is it really the act of stripping the header that is done for TE
purposes?

Section 4.1

  2.  The LISP ITR must be able to map the destination EID to an RLOC
      of one of the ETRs at the destination site.  The specific method
      used to do this is not described in this example.  See
      [I-D.ietf-lisp-rfc6833bis] for further information.

  3.  The ITR sends a LISP Map-Request as specified in
      [I-D.ietf-lisp-rfc6833bis].  Map-Requests SHOULD be rate-limited.

At risk of repeating myself, isn't (3) just doing what (2) says the ITR
must be able to do?  I don't see why both items are needed.

  5.  The ETR looks at the destination EID of the Map-Request and
      matches it against the prefixes in the ETR's configured EID-to-
      RLOC mapping database.  This is the list of EID-Prefixes the ETR
      is supporting for the site it resides in.  If there is no match,
      the Map-Request is dropped.  Otherwise, a LISP Map-Reply is

Isn't this (1) something that 6833bis should be authoritative on, and (2)
a recipe for random hangs if the mapping system ever misdirects a
map-request?

  7.  Subsequent packets from host1.abc.example.com to
      host2.xyz.example.com will have a LISP header prepended by the

The use of "subsequent" implies that he original IP packet does not receive
this treatment.  But we don't say anywhere that it gets dropped, leaving us
guessing as to what is supposed to happen to it.

  9.  In order to defer the need for a mapping lookup in the reverse
      direction, an ETR can OPTIONALLY create a cache entry that maps
      the source EID (inner-header source IP address) to the source
      RLOC (outer-header source IP address) in a received LISP packet.
      Such a cache entry is termed a "glean mapping" and only contains

This gleaming seems susceptible to spoofing.

Section 5.3

  L: The L-bit is the 'Locator-Status-Bits' field enabled bit.  When
      this bit is set to 1, the Locator-Status-Bits in the second
      32 bits of the LISP header are in use.

What happens to those bits when the L-bit is set to zero?

  E: The E-bit is the echo-nonce-request bit.  This bit MUST be ignored
      and has no meaning when the N-bit is set to 0.  When the N-bit is
      set to 1 and this bit is set to 1, an ITR is requesting that the

Do we need to say what to do when N is 1 and E is 0?

  LISP Locator-Status-Bits (LSBs):  When the L-bit is also set, the
      [...]
      the ETRs at the same site.  When a site has multiple EID-Prefixes
      that result in multiple mappings (where each could have a
      different Locator-Set), the Locator-Status-Bits setting in an
      encapsulated packet MUST reflect the mapping for the EID-Prefix
      that the inner-header source EID address matches.  If the LSB for

I don't think there is guaranteed to be a single unique EID-Prefix that
matches the inner source EID; we need to say longest-match here.

  o  The outer-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) to the inner-header.

IPv6 is a first-class IP protocol; it should not be relegated to a
parenthetical.

  Note that if an ETR/PETR is also an ITR/PITR and chooses to re-
  encapsulate after decapsulating, the net effect of this is that the
  new outer header will carry the same Time to Live as the old outer
  header minus 1.

Where is the decrementing of the TTL documented?  I just see "copy" in the
above text.

Is the last paragraph adding anything that was not already said previously?
It seems pretty redundant on first read.

Section 6

            Finally, the Map-Cache also contains reachability
  information about EIDs and RLOCs, and uses LISP reachability
  information mechanisms to determine the reachability of RLOCs, see
  Section 10 for the specific mechanisms.

nit: The Map-Cache performs reachability discovery?  That seems incongruous with
a cache nature; perhaps it is better to say that it is updated with the
results of such procedures.

Section 7.1

                    Note that reassembly can happen at the ETR if the
  encapsulated packet was fragmented at or after the ITR.

Why would an ETR want to take on this additional state-keeping burden
instead of relegating it to the end host?

  When the 'DF' field of the IP header is set to 1, or the packet is an
  IPv6 packet originated by the source host, the ITR will drop the
  packet when the size is greater than L and send an ICMPv4 ICMP

Which size?

Section 9

  o  Either side (more likely the server-side ETR) decides not to send
      a Map-Request.  For example, if the server-side ETR does not send
      Map-Requests, it gleans RLOCs from the client-side ITR, giving the

[in the next paragraph we talk about sending Map-Requests to verify gleamed
mappings, which doesn't mesh very well with "does not send Map-Requests"
here]

      client-side ITR responsibility for bidirectional RLOC reachability
      and preferability.  Server-side ETR gleaning of the client-side
      ITR RLOC is done by caching the inner-header source EID and the
      outer-header source RLOC of received packets.  [...]

Isn't this susceptible to spoofing?

  Instead of using the Map-Cache or mapping system, RLOC information
  MAY be gleaned from received tunneled packets or Map-Request
  messages.  A "gleaned" Map-Cache entry, one learned from the source

To double-check, this is describing the same behavior described in the iast
bullet point?

  RLOC of a received encapsulated packet, is only stored and used for a
  few seconds, pending verification.  Verification is performed by
  sending a Map-Request to the source EID (the inner-header IP source
  address) of the received encapsulated packet.  A reply to this

As I commented on 6833bis, I'd appreciate mention that this
"verification" is akin to reverse-routability verification and does not
involve any cryptographic assurances.

                    This "gleaning" mechanism is OPTIONAL, refer to
  Section 16 for security issues regarding this mechanism.

nit: comma splice

Section 10

  2.  When an ETR receives an encapsulated packet from an ITR, the
      source RLOC from the outer header of the packet is likely to be
      reachable.

Liktely to, but not guaranteed, since that's a spoofable field and we rely
on the ITR to fill it with something useful.

  When determining Locator up/down reachability by examining the
  Locator-Status-Bits from the LISP-encapsulated data packet, an ETR
  will receive up-to-date status from an encapsulating ITR about
  reachability for all ETRs at the site.  [...]

This ("up-to-date") wording concerns me, relating to the interaction
between map-versioning, addition/removal of locators from a mapping, and
propagation to values in the LSBs.  I do not think there is currently a
strong consistency guarantee in place that would justify the "up-to-date"
wording, and 6834bis has not received IETF (or IESG) review yet.  My
current understanding is that the status information provided via this
mechanism could be characterized as "best-effort" or "accurate in the
steady-state".

  The security considerations of Section 16 related with data-plane
  reachability applies to the data-plane RLOC reachability mechanisms

nit: I think this is "related to", not "related with".

Section 10.1

  When this packet is received by the ETR, the encapsulated packet is
  forwarded as normal.  When the ETR is an xTR (co-located as an ITR),
  it next sends a data packet to the ITR (when it is an xTR co-located

nit: I don't think this is grammatical; maybe "when it next sends"?

  erroneously consider the Locator unreachable.  An ITR SHOULD only set
  the E-bit in an encapsulated data packet when it knows the ETR is
  enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
  probe Map-Reply message.

Is this only in RLOC-probe Map-Reply messages (and not generic, including
mapping-driven, Map-Reply messages)?  If so, I think that 6833bis needs
some clarification in Section 5.4.  (If not, I think that "RLOC-probe"
should be removed from here.)

Section 13

  ignores them.  However, this can only happen for locator addresses
  that are lexicographically greater than the locator addresses in the
  existing Locator-Set.

(It might be apropos to explicitly remind the reader that the entries in the
locator-set are sorted by IP address.)

  When a Locator record is removed from a Locator-Set, ITRs that have
  the mapping cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, even if the Locator is in

Why will the xTRs set the Locator-Status-Bit to 0?  Won't they just use
the updated mapping and have a smaller number of LSBs in their data
packets?

  If many changes occur to a mapping over a long period of time, one
  will find empty record slots in the middle of the Locator-Set and new
  records appended to the Locator-Set. At some point, it would be

How can this happen when the Locator-Set is required to be sorted?  Or does
the sorting requirement not apply to the "Map-Reply Record" field of the
Map-Request?

Section 13.1

  A Map-Version Number can be included in Map-Register messages as
  well.  This is a good way for the Map-Server to assure that all ETRs
  for a site registering to it will be synchronized according to Map-
  Version Number.

This seems vastly underspecified not just to the detailed semantics (for
which the 6834bis reference is probably a suitable replacement) but also
the goals of the synchronization that is to be obtained.  It's unclear to
me that it's appropriate to mention Map-Register and versions at all in
this document; instead we might just note that 6834bs provides for version
synchronization for the ETRs within a site.  (If that's what it does; I
haven't yet read it in detail.)

Section 14

  Just like it would if the destination EID was a unicast address.

nit: this is a sentence fragment; I suggest joining to the previous
sentence with a comma.

Section 20.2

Maybe throw us a bone and include the string
"draft-iannone-openlisp-implementation" in the [OPENLISP] entry?
2019-02-07
26 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2019-02-07
26 Benjamin Kaduk
[Ballot discuss]
Section 3 still contains text:

  EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known …
[Ballot discuss]
Section 3 still contains text:

  EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC

that indicates that the mapping database is a single, global, distributed
database; we had previously agreed that the target scope was much more
narrow.  I could perhaps charitably assume that this instance was missed as an
editing error because the phrase "global distributed database" spans a line
break, but given that this specific instance was called out in my previous
discuss position, it is fairly hard to do so.

Also in Section 3:
  Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

The various places where we mention "gleaming" or similar unauthenticated
(un-path-verified?) schemes for learning mapping information should all
mention at their description that they are susceptible to spoofing and link
to the security considerations.

I'm still concerned about the synchronization requirements between
map-version changes and LSB usage; with the currently described technology
it seems almost inevitable for race conditions around RLOC changes to cause
ITRs to make incorrect routing decisions due to misinterpreted status bits.
It's unclear whether it's even worth trying to tackle this problem before
the map-versioning document is more advanced along in the process, though.
(Several comments throughout are relevant, especially those on Section
13.1.)

I agree with Warren that clarity on whether traffic is buffered or dropped
during the lookup process is needed (e.g., in Section 6).

Also in the vein of Warren's comments, in Section 7.1 I was expecting (from
our previous discussions) that some text would be added about the
determination of L being something that is "performed once by the
administrator of the LISP deployment and treated as a constant across the
deployment".

The discussion of Instance IDs remains incomplete, with no discussion of
within what scope their values must be unique (as truncated to 24 bits).

Similarly (also Section 8),
                                                              Multiple
  Data-Planes can use the same 32-bit space as long as the low-order 24
  bits don't overlap among xTRs.

That's a pretty lousy property to have in a PS specification.

Section 13

  When a Locator record is removed from a Locator-Set, ITRs that have
  the mapping cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, even if the Locator is in
  the list, it will not be used.  For new mapping requests, the xTRs
  can set the Locator AFI to 0 (indicating an unspecified address), as
  well as setting the corresponding Locator-Status-Bit to 0.  This

I do not remember there being an ordering (or even consistency) requirement
on the ITR-RLOC entries in the Map-Request, so it's unclear that just
replacing one entry with an AFI-0 entry would convey this information.  I
suppose that using only a single ITR-RLOC entry, with AFI 0, would provide
a usable signal to the ETR, but that does not seem to be what is being
described here.  (Also, on a rhetorical point, please clarify that the "as
well as" is for setting the LSB to 0 in data packets; Map-Requests do not
include any LSBs.)

  If many changes occur to a mapping over a long period of time, one
  will find empty record slots in the middle of the Locator-Set and new
  records appended to the Locator-Set. At some point, it would be
  useful to compact the Locator-Set so the Locator-Status-Bit settings
  can be efficiently packed.

This text, implying that compactification must wait for some unspecified
later event, seems to be assuming some requirement to preserve order of
Locator-Set entries that I cannot find a description of in either 6830bis
or 6833bis.

Do RFCs 6831 and 8378 need to be normative references for how to do
multicast as an optional protocol feature (recalling that
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
clarifies that references that are relevant only for optional features are
still classified as normative)?

In Section 16:

  A complete LISP threat analysis can be found in [RFC7835].  In what

RFC 7835 remains an incomplete analysis; please stop referring to it as
such.

  of time.  The goal is to convince the ITR that the ETR's RLOC is
  reachable even when it may not be reachable.  If the attack is

I think Warren is correct that there is also an attack that lies in
convincing an ITR that an ETR is not reachable even when it is reachable.


The following items were present in my original DISCUSS position and still
have not been resolved.  Note that I copy below the previous ballot text
even for some issues that are described above already in different words.

Section 4.1's Step (6) only mentions parsing "to check for format
validity".  I think it is appropriate to mention (and refer to) source
authentication checks as well, since bad Map-Reply data can allow all sorts
of attacks to occur.

There are some fairly subtle ordering requirements between the order of
entries in Map-Reply messages and the Locator-Status-Bits in data-plane
traffic (so that the semantic meaning of the status bits are meaningful),
which is only given a minimal treatment in the control-plane document.  The
need for synchronization in interpreting these bits should be mentioned
more prominently in the data-plane document as well.

The usage of the Instance ID does not seem to be adequately covered; from
what I've been able to pick up so far it seems that both source and
destination participants must agree on the meaning of an Instance ID, and
the source and destination EIDs must be in the same Instance.  This does
not seem like it is compatible with Internet scale, especially if there are
only 24 usable bits of Instance ID.

There seems to be a lot of intra-site synchronization requirements, notably
with respect to Map-Version consistency, the contents and ordering of
locator sets for EIDs in the site, etc.; the actual hard requirements for
synchronization within a site should be clearly called out, ideally in a
single location.

The security considerations attempt to defer substantially to the
threat-analysis in RFC 7835, which does not really seem like a complete
threat analysis and does not provide analysis as to what requirements are
placed on the boundaries between the different components of LISP (data
plane, control plane, mapping system, various extensions, etc.).  The
secdir reviewer had some good thoughts in this space.

I am not convinced that this protocol meets the current IETF requirements
for the security properties of Standards-Track Protocols without at least
LISP-SEC as a mandatory-to-implement component, and possibly additional or
stronger requirements.  (I did not do a full analysis of the system in the
presence of those security mechanisms, since that is not what is being
presented for review.)
[ed. even though LISP-SEC has been promoted to MTI, it remains difficult to
be confident in the results of a full system analysis due to the number of
other outstanding issues with the core documents.  Consider the risk Ekr
noted yesterday in email about tampering with the Map-Request causing
apparently-valid repsonses that convey incorrect results with respect to
the original query.]
2019-02-07
26 Benjamin Kaduk
[Ballot comment]
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually …
[Ballot comment]
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually don't understand are
generally accompanied by text like "just to confirm" or provide some option
for possible interpretation.  Others are intended as rhetorical devices,
indicating that the text locally at this point in the document is unclear
and the question posed should be addressed in the document, in-line.

Section 1

                                                        LISP
  encapsulation uses a dynamic form of tunneling where no static
  provisioning is required or necessary.

Do I interpret this correctly as meaning that no static provisioning is
necessary on end-hosts?  It seems that ETRs and the mapping system
entities definitely need static configuration.  But do end sites need to
know what lisp site/administrative domain they are part of?

  LISP is an overlay protocol that separates control from Data-Plane,
  this document specifies the Data-Plane, how LISP-capable routers
  (Tunnel Routers) exchange packets by encapsulating them to the
  appropriate location.  [...]

nit: this is a comma splice

Section 3

  Anycast Address:  Anycast Address is a term used in this document to

How does this definition differ from the one in RFC 8499?

  Data-Probe:  A Data-Probe is a LISP-encapsulated data packet where
      the inner-header destination address equals the outer-header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  [...]

nit: is this better as two sentences?  ("...is a LISP-encapsulated data
packet where the inner-header destination address equals the outer-header
destination address.  It is used to trigger...")

I would also say something in this paragraph about how this behavior blurs
the distinction between EID and RLOC.

                    When using Data-Probes, by sending Map-Requests on
      the underlying routing system, EID-Prefixes must be advertised.

I don't understand why the one follows from the other (in fact, there seem
to be three not-particularly-related concepts in this sentence).

(I also note that "Data-Probe" is not mentioned anywhere in this document
other than its own definition, which would suggest that it could be moved
to 6833bis, which does mention them.)

  EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC

I thought we had agreed to remove this "global distributed database"
language.

      addresses that are routable on the underlay.  Note that there MAY
      be transient conditions when the EID-Prefix for the site and
      Locator-Set for each EID-Prefix may not be the same on all ETRs.

nit: we haven't indicated a definite site for "the site" to be meaningful.

  EID-to-RLOC Map-Cache:  The EID-to-RLOC Map-Cache is generally
      short-lived, on-demand table in an ITR that stores, tracks, and is
      responsible for timing out and otherwise validating EID-to-RLOC
      mappings.  This cache is distinct from the full "database" of EID-
      to-RLOC mappings; it is dynamic, local to the ITR(s), and
      relatively small, while the database is distributed, relatively
      static, and much more global in scope to LISP nodes.

"global" caught my eye again here; perhaps "global in scope to a LISP
deployment"?

  EID-Prefix:  An EID-Prefix is a power-of-two block of EIDs that are
      allocated to a site by an address allocation authority.  EID-
      Prefixes are associated with a set of RLOC addresses.  EID-Prefix
      allocations can be broken up into smaller blocks when an RLOC set
      is to be associated with the larger EID-Prefix block.

nit: I think the causality here is backwards -- the breaking up does not
occur at the moment that you associate an RLOC set to a larger EID-Prefix
block.

  Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's

Er, that the ISP ITR uses as source or as destination?

  Negative Mapping Entry:  A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty, one with an encoded Locator
      count of 0.  This type of entry could be used to describe a prefix
      from a non-LISP site, which is explicitly not in the mapping
      database.  There are a set of well-defined actions that are
      encoded in a Negative Map-Reply.

This bit about Negative Map-Replys comes out of the blue; is it really
needed in this paragraph?

  TE-ETR:  A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

nit: is it really the act of stripping the header that is done for TE
purposes?

Section 4.1

  2.  The LISP ITR must be able to map the destination EID to an RLOC
      of one of the ETRs at the destination site.  The specific method
      used to do this is not described in this example.  See
      [I-D.ietf-lisp-rfc6833bis] for further information.

  3.  The ITR sends a LISP Map-Request as specified in
      [I-D.ietf-lisp-rfc6833bis].  Map-Requests SHOULD be rate-limited.

At risk of repeating myself, isn't (3) just doing what (2) says the ITR
must be able to do?  I don't see why both items are needed.

  5.  The ETR looks at the destination EID of the Map-Request and
      matches it against the prefixes in the ETR's configured EID-to-
      RLOC mapping database.  This is the list of EID-Prefixes the ETR
      is supporting for the site it resides in.  If there is no match,
      the Map-Request is dropped.  Otherwise, a LISP Map-Reply is

Isn't this (1) something that 6833bis should be authoritative on, and (2)
a recipe for random hangs if the mapping system ever misdirects a
map-request?

  7.  Subsequent packets from host1.abc.example.com to
      host2.xyz.example.com will have a LISP header prepended by the

The use of "subsequent" implies that he original IP packet does not receive
this treatment.  But we don't say anywhere that it gets dropped, leaving us
guessing as to what is supposed to happen to it.

  9.  In order to defer the need for a mapping lookup in the reverse
      direction, an ETR can OPTIONALLY create a cache entry that maps
      the source EID (inner-header source IP address) to the source
      RLOC (outer-header source IP address) in a received LISP packet.
      Such a cache entry is termed a "glean mapping" and only contains

This gleaming seems susceptible to spoofing.

Section 5.3

  L: The L-bit is the 'Locator-Status-Bits' field enabled bit.  When
      this bit is set to 1, the Locator-Status-Bits in the second
      32 bits of the LISP header are in use.

What happens to those bits when the L-bit is set to zero?

  E: The E-bit is the echo-nonce-request bit.  This bit MUST be ignored
      and has no meaning when the N-bit is set to 0.  When the N-bit is
      set to 1 and this bit is set to 1, an ITR is requesting that the

Do we need to say what to do when N is 1 and E is 0?

  LISP Locator-Status-Bits (LSBs):  When the L-bit is also set, the
      [...]
      the ETRs at the same site.  When a site has multiple EID-Prefixes
      that result in multiple mappings (where each could have a
      different Locator-Set), the Locator-Status-Bits setting in an
      encapsulated packet MUST reflect the mapping for the EID-Prefix
      that the inner-header source EID address matches.  If the LSB for

I don't think there is guaranteed to be a single unique EID-Prefix that
matches the inner source EID; we need to say longest-match here.

  o  The outer-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) to the inner-header.

IPv6 is a first-class IP protocol; it should not be relegated to a
parenthetical.

  Note that if an ETR/PETR is also an ITR/PITR and chooses to re-
  encapsulate after decapsulating, the net effect of this is that the
  new outer header will carry the same Time to Live as the old outer
  header minus 1.

Where is the decrementing of the TTL documented?  I just see "copy" in the
above text.

Is the last paragraph adding anything that was not already said previously?
It seems pretty redundant on first read.

Section 6

            Finally, the Map-Cache also contains reachability
  information about EIDs and RLOCs, and uses LISP reachability
  information mechanisms to determine the reachability of RLOCs, see
  Section 10 for the specific mechanisms.

nit: The Map-Cache performs reachability discovery?  That seems incongruous with
a cache nature; perhaps it is better to say that it is updated with the
results of such procedures.

Section 7.1

                    Note that reassembly can happen at the ETR if the
  encapsulated packet was fragmented at or after the ITR.

Why would an ETR want to take on this additional state-keeping burden
instead of relegating it to the end host?

  When the 'DF' field of the IP header is set to 1, or the packet is an
  IPv6 packet originated by the source host, the ITR will drop the
  packet when the size is greater than L and send an ICMPv4 ICMP

Which size?

Section 8

Section 9

  o  Either side (more likely the server-side ETR) decides not to send
      a Map-Request.  For example, if the server-side ETR does not send
      Map-Requests, it gleans RLOCs from the client-side ITR, giving the

[in the next paragraph we talk about sending Map-Requests to verify gleamed
mappings, which doesn't mesh very well with "does not send Map-Requests"
here]

      client-side ITR responsibility for bidirectional RLOC reachability
      and preferability.  Server-side ETR gleaning of the client-side
      ITR RLOC is done by caching the inner-header source EID and the
      outer-header source RLOC of received packets.  [...]

Isn't this susceptible to spoofing?

  Instead of using the Map-Cache or mapping system, RLOC information
  MAY be gleaned from received tunneled packets or Map-Request
  messages.  A "gleaned" Map-Cache entry, one learned from the source

To double-check, this is describing the same behavior described in the iast
bullet point?

  RLOC of a received encapsulated packet, is only stored and used for a
  few seconds, pending verification.  Verification is performed by
  sending a Map-Request to the source EID (the inner-header IP source
  address) of the received encapsulated packet.  A reply to this

As I commented on 6833bis, I'd appreciate mention that this
"verification" is akin to reverse-routability verification and does not
involve any cryptographic assurances.

                    This "gleaning" mechanism is OPTIONAL, refer to
  Section 16 for security issues regarding this mechanism.

nit: comma splice

Section 10

  2.  When an ETR receives an encapsulated packet from an ITR, the
      source RLOC from the outer header of the packet is likely to be
      reachable.

Liktely to, but not guaranteed, since that's a spoofable field and we rely
on the ITR to fill it with something useful.

  When determining Locator up/down reachability by examining the
  Locator-Status-Bits from the LISP-encapsulated data packet, an ETR
  will receive up-to-date status from an encapsulating ITR about
  reachability for all ETRs at the site.  [...]

This ("up-to-date") wording concerns me, relating to the interaction
between map-versioning, addition/removal of locators from a mapping, and
propagation to values in the LSBs.  I do not think there is currently a
strong consistency guarantee in place that would justify the "up-to-date"
wording, and 6834bis has not received IETF (or IESG) review yet.  My
current understanding is that the status information provided via this
mechanism could be characterized as "best-effort" or "accurate in the
steady-state".

  The security considerations of Section 16 related with data-plane
  reachability applies to the data-plane RLOC reachability mechanisms

nit: I think this is "related to", not "related with".

Section 10.1

  When this packet is received by the ETR, the encapsulated packet is
  forwarded as normal.  When the ETR is an xTR (co-located as an ITR),
  it next sends a data packet to the ITR (when it is an xTR co-located

nit: I don't think this is grammatical; maybe "when it next sends"?

  erroneously consider the Locator unreachable.  An ITR SHOULD only set
  the E-bit in an encapsulated data packet when it knows the ETR is
  enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
  probe Map-Reply message.

Is this only in RLOC-probe Map-Reply messages (and not generic, including
mapping-driven, Map-Reply messages)?  If so, I think that 6833bis needs
some clarification in Section 5.4.  (If not, I think that "RLOC-probe"
should be removed from here.)

Section 13

  ignores them.  However, this can only happen for locator addresses
  that are lexicographically greater than the locator addresses in the
  existing Locator-Set.

(It might be apropos to explicitly remind the reader that the entries in the
locator-set are sorted by IP address.)

  When a Locator record is removed from a Locator-Set, ITRs that have
  the mapping cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, even if the Locator is in

Why will the xTRs set the Locator-Status-Bit to 0?  Won't they just use
the updated mapping and have a smaller number of LSBs in their data
packets?

  If many changes occur to a mapping over a long period of time, one
  will find empty record slots in the middle of the Locator-Set and new
  records appended to the Locator-Set. At some point, it would be

How can this happen when the Locator-Set is required to be sorted?  Or does
the sorting requirement not apply to the "Map-Reply Record" field of the
Map-Request?

Section 13.1

  A Map-Version Number can be included in Map-Register messages as
  well.  This is a good way for the Map-Server to assure that all ETRs
  for a site registering to it will be synchronized according to Map-
  Version Number.

This seems vastly underspecified not just to the detailed semantics (for
which the 6834bis reference is probably a suitable replacement) but also
the goals of the synchronization that is to be obtained.  It's unclear to
me that it's appropriate to mention Map-Register and versions at all in
this document; instead we might just note that 6834bs provides for version
synchronization for the ETRs within a site.  (If that's what it does; I
haven't yet read it in detail.)

Section 14

  Just like it would if the destination EID was a unicast address.

nit: this is a sentence fragment; I suggest joining to the previous
sentence with a comma.

Section 20.2

Maybe throw us a bone and include the string
"draft-iannone-openlisp-implementation" in the [OPENLISP] entry?
2019-02-07
26 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2019-02-07
26 Ignas Bagdonas
[Ballot comment]
As a (mostly happy) user of the specified technology for a proof that it works I am inclined to ballot a YES. For …
[Ballot comment]
As a (mostly happy) user of the specified technology for a proof that it works I am inclined to ballot a YES. For practical purposes it is not expected that LISP will be deployed globally end to end, it is a localized mechanism for (mostly) controlled environments. This, however, does not mean that security concerns raised are to be ignored, therefore I do have sympathy for DISCUSSes raised by SEC ADs. The industry needs to continue experimenting with LISP, trying to build it ideal at the first try is not realistic. Therefore NO OBJECTION.
2019-02-07
26 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-02-06
26 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-02-06
26 Alissa Cooper [Ballot comment]
I find the SEC ADs' DISCUSS positions concerning and support the resolution of their security concerns.
2019-02-06
26 Alissa Cooper Ballot comment text updated for Alissa Cooper
2019-02-06
26 Alissa Cooper Ballot comment text updated for Alissa Cooper
2019-02-05
26 Warren Kumari
[Ballot discuss]
I read much of this on a plane while overtired, so it is entirely possible / probable that I've completely misunderstood something(s) obvious. …
[Ballot discuss]
I read much of this on a plane while overtired, so it is entirely possible / probable that I've completely misunderstood something(s) obvious.
Many of the below are probably simple to address, and either I simply need to be educated, or just there needs to be a bit more text / detail provided.

1: "3.  The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis].  Map-Requests SHOULD be rate-limited."
What does the ITR do with the packet while waiting for the Map-Request to complete? Must it buffer the packets or can it discard them? If the former, for how long must it buffer?
When you say "SHOULD be rate-limited", can you provide guidance on rates? 1 request per second? 1 million per second? Is this rate-limit per destination or per device?
Apologies if this is clearly stated in RFC6833(bis) - I only skimmed it, and didn't see an answer there.

2: "6. ... Note that the Map-Cache is an on-demand cache. An ITR will manage its Map-Cache in such a way that optimizes for its resource constraints."
Presumably I could cause this cache to thrash / overflow by looking at the RLOC database, and choosing EIDs to send traffic to which all require different cache entries, causing the cache to overflow (or, at least, causing maximum cache pressure). This seems like an ideal DoS vector. It seems that there should be more guidance provided on how to size the Map-Cache / the expected order of the cache size, even if it is ultimately an implementation issue (e.g: is a Map-Cache of 100 entries OK for an ITR? or should it be O(1000)? Or roughly size(database)/2? Having multiple devices with small caches, and a bot which does the above seems like a global risk).

I'm quite confused by much of the MTU / Fragmentation stuff -- I did read the documents on a plane after not getting much sleep, and so it is entirely possible / probable that I'm just being stupid, but there are bits which don't seem to make sense to me.
3: "2.  Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet."
How do I know what L is? The document "RECOMMENDS that L be defined as 1500" -- but 1500 isn't universally true (if it were, we would never have to do Path MTU). What happens when the *actual* MTU on the path is e.g 1476 because there is a tunnel on the path?
The text also mentions "which is less than the ITR’s estimate of the path MTU between the ITR and its correspondent ETR" - this implies that the ITR is tracking / estimating the MTU, which a: doesn't align with the rest of the text, or b: sounds like the stateful solution below.
I have reread this multiple times, but it still feels like it is avoiding the issue by defining it to not exist.

4: "Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR." - I think that there needs to be more text / description about resource constraints on routers performing reassembly of fragments - in most cases a router doesn't have to / isn't expected to have to reassemble transit packets from arbitrary sources on the Internet (things where routers may reassemble are aimed at the control plane which can be rate-limited, or are from expected source addresses). It seems that spoofing lots of initial fragments without the final one will be a tax on the router.

5: "Instead of using the Map-Cache or mapping system, RLOC information MAY be gleaned from received tunneled packets or Map-Request messages. A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification." - it seems that this is ripe for abuse (or I'm missing in the cache expiration). I want to hijack traffic from Site X to well known Service Y, so I look up Service Y and save the TTL from the Map-Reply. I then start spoof packets listing myself as the ETR - eventually Site X will glean from my spoofed packets, and start sending traffic to me - yes, this will only work for a few seconds -- but as soon as I stop getting packets from site X, I know site X has verified the entry and discovered it is wrong... and that the TTL is now being deprecated. I start a timer, and second or two less than the TTL later I start spoofing packets again, knowing that site X will soon expire the cache entry and will once again be willing to accept mine again. A: I get some Site X to Site Y traffic for a few seconds every TTL seconds, and B: the loss of this traffic is a signal that TTL seconds again it will need to be refreshed.

6: "10.1.  Echo Nonce Algorithm" -- If I spoof lots of packets with the N- and E-bits set, the receiving ETR will need to keep false state, and presumably I can overfill a cache. This will cause the ETR to not be able to include the received nonce on legitimate traffic, and so the ITR on the far side will think this ETR is down. This seems like a fairly easy DoS. I'm guessing that this can be worked around by not setting the E bit in the RLOC-probe Map-Reply message, but this feels like a dangerous foot gun, and should at least be noted. Note that this is different to the "Note the attacker must guess a valid nonce the ITR is requesting to be echoed within a small window of time.  The goal is to convince the ITR that the ETR’s RLOC is  reachable even when it may not be reachable."  attack listed in the document in that a: it doesn't require any guessing, and b: makes an ETR appear down, not up.

The document does mention "... attack can be mitigated by preventing RLOC spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while that may be true for many of the above, BCP38 is far from being universally deployed, and this feels similar to solving world hunger by saying everyone must have enough food. :-)

Again, apologies if I've completely misunderstood something, clue-bat gladly accepted...
2019-02-05
26 Warren Kumari
[Ballot comment]
Comments:
1: "LISP Locator-Status-Bits (LSBs):  ... The field is 32 bits when the I-bit is set to 0 and is 8 bits when …
[Ballot comment]
Comments:
1: "LISP Locator-Status-Bits (LSBs):  ... The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1." - I think I'm missing something fairly fundamental here (and in Section 10, 13.1, and others) - if I'm using the I bit, it sounds like I can only have 8 ETRs? And with this clear I can only have 32? I feel like I must have missed something....

2: "When the ’DF’ field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMPv4..."
I think this needs to say when the resulting (or encapsulated) packet is greater than L (otherwise it is unclear if you are referring to the original or resulting packet).

3: "The server-side sets a Weight of zero for the RLOC subset list. In this case, the client-side can choose how the traffic load is  spread across the subset list." -- please insert a reference to Section 12 here. I wrote up a long comment on what happens of the load sharing delivers packets to different ETRs, before finding this section later on in the document.

Nits:
1: " LISP does not require changes to either host protocol stack or to underlay routers. " -- I think either "to either the host protocol stack" or " to either host protocol stacks"

2: "As an exmple of such attacks an off-path attacker can" -- typo for example.

3: "it can protect itself from erroneious reachability attacks" -- typo for erroneous.
2019-02-05
26 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2019-02-05
26 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2019-02-04
26 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-01-24
26 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2019-01-24
26 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2019-01-24
26 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kyle Rose
2019-01-24
26 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kyle Rose
2019-01-24
26 Amy Vezza Telechat date has been changed to 2019-02-07 from 2018-09-27
2018-11-04
26 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-26.txt
2018-11-04
26 (System) New version approved
2018-11-04
26 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-11-04
26 Dino Farinacci Uploaded new revision
2018-11-03
25 Luigi Iannone Added to session: IETF-103: lisp  Mon-0900
2018-10-21
25 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-25.txt
2018-10-21
25 (System) New version approved
2018-10-21
25 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-10-21
25 Dino Farinacci Uploaded new revision
2018-10-12
24 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-24.txt
2018-10-12
24 (System) New version approved
2018-10-12
24 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-10-12
24 Dino Farinacci Uploaded new revision
2018-10-03
23 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-23.txt
2018-10-03
23 (System) New version approved
2018-10-03
23 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-10-03
23 Dino Farinacci Uploaded new revision
2018-10-01
22 Suresh Krishnan [Ballot comment]
Thanks for addressing my DISCUSS.
2018-10-01
22 Suresh Krishnan [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss
2018-10-01
22 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-22.txt
2018-10-01
22 (System) New version approved
2018-10-01
22 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-10-01
22 Dino Farinacci Uploaded new revision
2018-09-27
21 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-09-27
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-09-27
21 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-21.txt
2018-09-27
21 (System) New version approved
2018-09-27
21 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-09-27
21 Dino Farinacci Uploaded new revision
2018-09-27
20 Cindy Morgan IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer
2018-09-27
20 Ben Campbell
[Ballot comment]
I support the Security ADs DISCUSS positions.

(I was unfortunately not able to do more than a cursory review due to external time …
[Ballot comment]
I support the Security ADs DISCUSS positions.

(I was unfortunately not able to do more than a cursory review due to external time constraints.)
2018-09-27
20 Ben Campbell Ballot comment text updated for Ben Campbell
2018-09-27
20 Ben Campbell [Ballot comment]
I support the Security ADs DISCUSS positions.
2018-09-27
20 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-09-27
20 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-09-27
20 Alissa Cooper
[Ballot comment]
I unfortunately ran out of time to do more than a cursory review of the LISP documents on this week's telechat. My apologies. …
[Ballot comment]
I unfortunately ran out of time to do more than a cursory review of the LISP documents on this week's telechat. My apologies. I find the SEC ADs' DISCUSS positions concerning, though, and support the resolution of their security concerns.

Section 15 of RFC 6830 lists a number of open issues and areas for future work. It seems like at least some of these are not addressed in this round of document updates. I would have expected some more explicit discussion of how the bis document addresses those areas, or why it does not need to.

I'm curious why there are several authors listed with an affiliation (Cisco) who no longer have that affiliation AFAIK.
2018-09-27
20 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-09-27
20 Alexey Melnikov
[Ballot comment]
I share many of the security related concerns raised by Benjamin.

The document is otherwise readable. I have one specific question:

12.  Routing …
[Ballot comment]
I share many of the security related concerns raised by Benjamin.

The document is otherwise readable. I have one specific question:

12.  Routing Locator Hashing

  When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
  that is stored in the Map-Cache of a requesting ITR, the Locator-Set
  for the EID-Prefix MAY contain different Priority and Weight values
  for each locator address.  When more than one best Priority Locator
  exists, the ITR can decide how to load-share traffic against the
  corresponding Locators.

  The following hash algorithm MAY be used by an ITR to select a
  Locator for a packet destined to an EID for the EID-to-RLOC mapping:

  1.  Either a source and destination address hash or the traditional
      5-tuple hash can be used.  The traditional 5-tuple hash includes
      the source and destination addresses; source and destination TCP,
      UDP, or Stream Control Transmission Protocol (SCTP) port numbers;
      and the IP protocol number field or IPv6 next-protocol fields of
      a packet that a host originates from within a LISP site.  When a
      packet is not a TCP, UDP, or SCTP packet, the source and
      destination addresses only from the header are used to compute
      the hash.

Ok, maybe this is just me, but you don't actually define how to hash these things, you are only talking about what needs to be covered by the hash. I appreciate that picking a specific hashing algorithm is probably not relevant for interoperability, but I feel adding a specific algorithm (as an example or via a pointer) would improve the document.
2018-09-27
20 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-09-27
20 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3126

See my DISCUSS on 6833bis for overall issues. This is just detailed issues
on 6830bis as …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3126

See my DISCUSS on 6833bis for overall issues. This is just detailed issues
on 6830bis as I went through it.


DETAIL
S 4.1.
>          RLOC (outer-header source IP address) in a received LISP packet.
>          Such a cache entry is termed a "glean mapping" and only contains
>          a single RLOC for the EID in question.  More complete information
>          about additional RLOCs SHOULD be verified by sending a LISP Map-
>          Request for that EID.  Both the ITR and the ETR MAY also
>          influence the decision the other makes in selecting an RLOC.

This seems like it introduces an immediate overclaiming problem.


S 10.
>      When an ETR decapsulates a packet, it will check for any change in
>      the 'Locator-Status-Bits' field.  When a bit goes from 1 to 0, the
>      ETR, if acting also as an ITR, will refrain from encapsulating
>      packets to an RLOC that is indicated as down.  It will only resume
>      using that RLOC if the corresponding Locator-Status-Bit returns to a
>      value of 1.  Locator-Status-Bits are associated with a Locator-Set

This seems to enable a pretty obvious denial of service attack in
which you send  a message with all LSBs set to 0.


S 10.
>      list returned by the last Map-Reply will be set to zero for that
>      particular EID-Prefix.  Refer to Section 16 for security related
>      issues regarding Locator-Status-Bits.

>      When an ETR decapsulates a packet, it knows that it is reachable from
>      the encapsulating ITR because that is how the packet arrived.  In

It doesn't even know this. It just knows that that's been claimed by
someone who can generate traffic to it.


S 10.1.
>      NOT use the lack of return traffic as an indication that the ETR is
>      unreachable.  Instead, it MUST use an alternate mechanism to
>      determine reachability.

>  10.1.  Echo Nonce Algorithm


This mechanism seems sufficient to verify unreachability but is not a
secure test of reachability because the nonce is way too short.


S 16.
>      Map-Versioning is a Data-Plane mechanism used to signal a peering xTR
>      that a local EID-to-RLOC mapping has been updated, so that the
>      peering xTR uses LISP Control-Plane signaling message to retrieve a
>      fresh mapping.  This can be used by an attacker to forge the map-
>      versioning field of a LISP encapsulated header and force an excessive
>      amount of signaling between xTRs that may overload them.

Can't I also set a super-high version number, thus gagging updates?
2018-09-27
20 Eric Rescorla
[Ballot comment]
S 5.3.
>        header.

>      When doing ETR/PETR decapsulation:

>      o  The inner-header 'Time …
[Ballot comment]
S 5.3.
>        header.

>      When doing ETR/PETR decapsulation:

>      o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in
>        the case of IPv6) SHOULD be copied from the outer-header 'Time to

This should probably be a MUST because there are other protocols that
assume that TTLs get decremented.


S 7.1.
>      destination site.  The two fragments are reassembled at the
>      destination host into the single IP datagram that was originated by
>      the source host.  Note that reassembly can happen at the ETR if the
>      encapsulated packet was fragmented at or after the ITR.

>      This behavior MAY be performed by the ITR only when the source host

Nit: I think you want to say MUST be, assuming you mean that you can
perform it only if....


S 7.2.
>      2.  When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
>          with the DF bit set to 1, exceeds what the core network can
>          deliver, one of the intermediate routers on the path will send an
>          ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/
>          Fragmentation-Needed to the ITR, respectively.  The ITR will
>          parse the ICMP message to determine which Locator is affected by

What if you are in an environment where ICMP is blocked?


S 9.
>        outside of the subset list if it determines that the subset list
>        is unreachable (unless RLOCs are set to a Priority of 255).  Some
>        sharing of control exists: the server-side determines the
>        destination RLOC list and load distribution while the client-side
>        has the option of using alternatives to this list if RLOCs in the
>        list are unreachable.

How would you obtain alternative RLOCs?


S 10.
>          also acting as an ITR and has traffic to return to the original
>          ITR site, it can use this status information to help select an
>          RLOC.

>      2.  When an ETR receives an encapsulated packet from an ITR, the
>          source RLOC from the outer header of the packet is likely up.

What does "is likely up" mean?
2018-09-27
20 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2018-09-26
20 Suresh Krishnan
[Ballot discuss]
* Section 7.1.

This should be an easy fix but I would like to see it fixed before publication. When talking about IPv6 …
[Ballot discuss]
* Section 7.1.

This should be an easy fix but I would like to see it fixed before publication. When talking about IPv6 packets being larger than L, the correct behavior should be to send an ICMPv6 message with Type 2 (Packet Too Big) instead of the Destination Unreachable (Type 1) message as specified in the text. The text *is correct* for IPv4 messages with the DF bit set where the Destination Unreachable (Type 3) is the right kind of message to send.
2018-09-26
20 Suresh Krishnan [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan
2018-09-26
20 Benjamin Kaduk
[Ballot discuss]
I have grave concerns about the suitability of LISP as a whole, in its
present form, for advancement to the Standards-Track.  While some …
[Ballot discuss]
I have grave concerns about the suitability of LISP as a whole, in its
present form, for advancement to the Standards-Track.  While some of my
concerns are not specific to this document, as the core protocol
(data-plane) spec, it seems an appropriate place to attach them to.

I am told, out of band, that the intended deployment model is no longer to
cover the entire Internet (c.f. the MISSREF-state
draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the
core can be logically separated and interconnected by LISP-capable
routers", etc.), and that full Internet-scale operation is no longer a
goal.  However, since that does not seem to be reflected in the current
batch of documents up for IESG review, I am forced to ballot on them
"as-is", namely as targetting global Internet deployment.  The requirements
placed on the mapping system are so stringent so as to be arguably
unachievable at Internet-scale, though that arguably has more of an
interaction with the control-plane than the data-plane.  It's still in
scope here, though, as part of the overall description of the protocol
flow.

There are an almost innumerable number of downgrade attacks possible, and
the control-plane and data-plane security mechanisms are not normative
dependencies of the current corpus of documents, and as such are not up for
consideration as mitigating the security concerns with the core documents.

Section 3 defines the EID-to-RLOC Datbaase:

  EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC
      mappings.  Each potential ETR typically contains a small piece of
      the database: the EID-to-RLOC mappings for the EID-Prefixes
      "behind" the router.  These map to one of the router's own
      globally visible IP addresses.  Note that there MAY be transient
      conditions when the EID-Prefix for the site and Locator-Set for
      each EID-Prefix may not be the same on all ETRs.  This has no
      negative implications, since a partial set of Locators can be
      used.

No compelling architecture for a trustworthy global distributed database
has been presented that I've seen so far, and LISP relies heavily on the
mapping system's database for its functionality.  I am concerned that so
many requirements are placed on the mapping system so as to be in effect
unimplementable, in which case it would seem that the architecture as a
whole (that is, for a global Internet-scale system) is not fit for purpose.

Section 4.1's Step (6) only mentions parsing "to check for format
validity".  I think it is appropriate to mention (and refer to) source
authentication checks as well, since bad Map-Reply data can allow all sorts
of attacks to occur.

There are some fairly subtle ordering requirements between the order of
entries in Map-Reply messages and the Locator-Status-Bits in data-plane
traffic (so that the semantic meaning of the status bits are meaningful),
which is only given a minimal treatment in the control-plane document.  The
need for synchronization in interpreting these bits should be mentioned
more prominently in the data-plane document as well.

The usage of the Instance ID does not seem to be adequately covered; from
what I've been able to pick up so far it seems that both source and
destination participants must agree on the meaning of an Instance ID, and
the source and destination EIDs must be in the same Instance.  This does
not seem like it is compatible with Internet scale, especially if there are
only 24 usable bits of Instance ID.

There seems to be a lot of intra-site synchronization requirements, notably
with respect to Map-Version consistency, the contents and ordering of
locator sets for EIDs in the site, etc.; the actual hard requirements for
synchronization within a site should be clearly called out, ideally in a
single location.

The security considerations attempt to defer substantially to the
threat-analysis in RFC 7835, which does not really seem like a complete
threat analysis and does not provide analysis as to what requirements are
placed on the boundaries between the different components of LISP (data
plane, control plane, mapping system, various extensions, etc.).  The
secdir reviewer had some good thoughts in this space.

The security considerations throughout the LISP documents place a heavy
focus on the risk of over-claiming for routing EID-prefixes.  This is a
real concern, to be clear, but it should not overshadow the risk of an
attacker who is able to move traffic around at will, strip security
protections, cause denial of service, alter data-plane payloads, etc.
Similarly, this document's security considerations call out denial of
service as a risk from Map-Cache insertion/spoofing, but the risks from an
attacker being able to read and modify the traffic, perhaps even without
detection, seems a much greater threat to me.

I am not convinced that this protocol meets the current IETF requirements
for the security properties of Standards-Track Protocols without at least
LISP-SEC as a mandatory-to-implement component, and possibly additional or
stronger requirements.  (I did not do a full analysis of the system in the
presence of those security mechanisms, since that is not what is being
presented for review.)

Having an EID that is associated to user-correlatable devices has severe
privacy considerations, but I could not find this mentioned anywhere in all
of the LISP documents I've read so far.
2018-09-26
20 Benjamin Kaduk
[Ballot comment]
I apologize for the somewhat scattered nature of these comments; there are
a lot of them and I was focusing my time more …
[Ballot comment]
I apologize for the somewhat scattered nature of these comments; there are
a lot of them and I was focusing my time more on trying to understand the
broader system, and the intended security posture, so they did not get as
much clean-up as I would have liked.  (Most of my review was performed on the
-18, though I have tried to update to the -20 as relevant.)


The instance ID provides for organizational correlation, another privacy
exposure.

Is there anything different between an "EID-to-RLOC Map-Request" and just a
"Map-Request"?  (Same question for "Map-Reply", too.)

There's a lot of stuff that seems to work best if there is symmetric
bidirectional traffic, with inline signalling of map version and
reachability changes, though clearly everything is designed to also work
with asymmetric connectivity or unidirectional traffic.  It would be nice
to have a high-level summary in or near the introduction about what kinds
of behavior/performance differences are expected for bidirectional vs.
unidirectional traffic.

Section 2

That's not the 8174 boilerplate; it's more than just adding a cite to the
2119 boilerplate.

Section 3

nit: "An address family that pertains to the Data-Plane." is a sentence
fragment.

  Ingress Tunnel Router (ITR):  An ITR is a router that resides in a
      [...]
      mapping lookup in the destination address field.  Note that this
      destination RLOC MAY be an intermediate, proxy device that has
      better knowledge of the EID-to-RLOC mapping closer to the

This doesn't seem like a 2119 MAY is necessary, but rather a statement of
fact that may not be known to the encapsulating ITR.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's
      supplied EID).

I'm confused here, perhaps in multiple ways.  Are there now *two* LISP
headers on the packet?  Is the "outer RLOC the ISP ITR uses" the source
RLOC or the destination RLOC?

  Negative Mapping Entry:  A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty or has an encoded Locator count
      of 0.

Is "empty" a distinct representation from "locator count of zero"?

Perhaps something of an aside, but the check described for
Route-Returnability is a somewhat weak check, and in some cases could still
be spoofed.  (I don't expect this to surprise anyone, of course, but
perhaps some more qualifiers could be added to the text.)

Section 4

  An additional LISP header MAY be prepended to packets by a TE-ITR
  when re-routing of the path for a packet is desired.  A potential
  use-case for this would be an ISP router that needs to perform
  Traffic Engineering for packets flowing through its network.  In such
  a situation, termed "Recursive Tunneling", an ISP transit acts as an
  additional ITR, and the RLOC it uses for the new prepended header
  would be either a TE-ETR within the ISP (along an intra-ISP traffic
  engineered path) or a TE-ETR within another ISP (an inter-ISP traffic
  engineered path, where an agreement to build such a path exists).

"the RLOC it uses for the new prepnded header", again, this is as the
destination RLOC (vs. source RLOC)?

Section 4.1

  o  Map-Replies are sent on the underlying routing system topology
      using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol.

Just to check my understanding: is the "underlying routing system topology"
the same as the "underlay"?

Is step (3) just describing more of what step (2) says is "not described in
this example"?

Section 5.3

The word "nonce" is normally used for something used exactly once.
E.g., with some AEAD algorithms, if the same "nonce" input is used for
different encryptions, the entire security of the system is compromised.
It would be better to refer to this field with a different term, given
that "the same nonce can be used for a period of time when encapsulating to
the same ETR".  "Uniquifier" or "random value" might be reasonable choices.

Why is there no discussion of the Map-Version or Instance-ID fields
in this section?

When doing ETR/PETR decapsulation:

  o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in
      the case of IPv6) SHOULD be copied from the outer-header 'Time to
      Live' field, when the Time to Live value of the outer header is
      less than the Time to Live value of the inner header.  Failing to
      perform this check can cause the Time to Live of the inner header
      to increment across encapsulation/decapsulation cycles.  This
      check is also performed when doing initial encapsulation, when a
      packet comes to an ITR or PITR destined for a LISP site.

Er, what is "this check" that is also performed for initial encapsulation?
How are there multiple TTL values to compare?

  o  The inner-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) to the inner-header.

nit: the first "inner-header" seems like an editing remnant?

Section 7.1

How is this stateless if it invovles knowledge about the routers between
the ITR and all possible ETRs (i.e., a set that could change over time)?

Section 8

This 32-bit vs 24-bit thing is pretty hokey for a standards-track
specification (yes, I know that LISP-DDT is not standards track at the
moment).

Section 9

  Alternatively, RLOC information MAY be gleaned from received tunneled

What is this an alternative to?  The list of four options above?

  packets or EID-to-RLOC Map-Request messages.  A "gleaned" Map-Cache
  entry, one learned from the source RLOC of a received encapsulated
  packet, is only stored and used for a few seconds, pending
  verification.  Verification is performed by sending a Map-Request to
  the source EID (the inner-header IP source address) of the received
  encapsulated packet.

The source EID is some random end system, right?  So this relys on some
magic in the ETR to detect that there's a Map-Request and reply directly
instead of passing it on to the EID that won't know what to do with it?

Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and
might benefit from an explicit section reference to the other document.

Section 10

What is the "CE" of "CE-based ITRs"?  Presumably Customer Edge, but it
is not marked as well-known at
https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is
probably in order.

Again, when we are talking about the internal structure of the Map-Reply, a
detailed section refernce to 6833bis is useful.

Modifying LSBs seems like a fine DoS attack vector for an on-path attacker.

  value of 1.  Locator-Status-Bits are associated with a Locator-Set
  per EID-Prefix.  Therefore, when a Locator becomes unreachable, the
  Locator-Status-Bit that corresponds to that Locator's position in the
  list returned by the last Map-Reply will be set to zero for that
  particular EID-Prefix

Doesn't this imply a stateful relationship between the ordering of
Map-Replys and data-plane traffic?

Section 10.1

  Note that "ITR" and "ETR" are relative terms here.  Both devices MUST
  be implementing both ITR and ETR functionality for the echo nonce
  mechanism to operate.

Perhaps they could be given actual names so as to disambiguate which steps
are performed with ITR vs. ETR role?

  The echo-nonce algorithm is bilateral.  That is, if one side sets the
  E-bit and the other side is not enabled for echo-noncing, then the
  echoing of the nonce does not occur and the requesting side may
  erroneously consider the Locator unreachable.  An ITR SHOULD only set
  the E-bit in an encapsulated data packet when it knows the ETR is
  enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
  probe Map-Reply message.

Why is this even optional?  If it was mandatory to use, then there would
not be a question.  But at least clarify that the "this" that is conveyed
is whether the peer supports the echo-nonce algorithm.  (Also, subject to
downgrade.)

Section 13

  When a Locator record is removed from a Locator-Set, ITRs that have
  the mapping cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, even if the Locator is in
  the list, it will not be used.  For new mapping requests, the xTRs
  can set the Locator AFI to 0 (indicating an unspecified address), as
  well as setting the corresponding Locator-Status-Bit to 0.  This
  forces ITRs with old or new mappings to avoid using the removed
  Locator.

The behavior describe here seems like it would be better described as "when
a Locator is taken out of service" than "removed from a Locator-Set", since
if it is not in the set at all, it has no index, and no LSB or AFI to set.
Should actually depopulating it like this be forbidden?

I guess the Map Versioning is supposed to help with this, but we need to
nail down the semantics more and/or give a clearer reference to it.

Section 13.1

  An ITR, when it encapsulates packets to ETRs, can convey its own Map-
  Version Number.  This is known as the Source Map-Version Number.

Replacing "its own Map-Version Number" with something like "the Map-Version
numer for the LISP site of which it is a part".  Writing this causes me to
note that the semantics of the Map-Version are unclear, here -- what is it
scoped to?  An EID-Prefix?  An RLOC?  Oh, you say that in the next
paragraph (EID-Prefix).

  A Map-Version Number can be included in Map-Register messages as
  well.  This is a good way for the Map-Server to assure that all ETRs
  for a site registering to it will be synchronized according to Map-
  Version Number.

Huh?  I must be confused how this works.  (Also, wouldn't this be better in
the control plane document which covers Map-Register?)

Section 15

  o  When a tunnel-encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special Forwarding
      Information Base (FIB) entries for the EID-Prefixes of EIDs served
      by the ETR (those for which the router provides an RLOC
      translation).  These FIB entries are marked with a flag indicating
      that Control-Plane processing SHOULD be performed.

I assume this is just my lack of background showing, but I'm confused how
it makes sense to mark these for control-plane processing.  Isn't the
control plane much slower, and we're not putting all of the LISP data-plane
traffic onto the slow path?

Section 18

  o  Data-Plane gleaning for creating map-cache entries has been made
      optional.  If any ITR implementations depend or assume the remote
      ETR is gleaning should not do so.

nit: this is ungrammatical; "they should not" or "Any ITR implementations
that depend on or assume that" would fix it.

Section 19.1

Presumably IANA also updated the reference column to point to this
document?
2018-09-26
20 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-09-26
20 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-09-26
20 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-09-26
20 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-20.txt
2018-09-26
20 (System) New version approved
2018-09-26
20 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-09-26
20 Dino Farinacci Uploaded new revision
2018-09-25
19 Brian Trammell Request for Telechat review by TSVART Completed: Ready with Nits. Reviewer: Brian Trammell. Sent review to list.
2018-09-22
19 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-19.txt
2018-09-22
19 (System) New version approved
2018-09-22
19 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-09-22
19 Dino Farinacci Uploaded new revision
2018-09-20
18 Kyle Rose Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Kyle Rose. Sent review to list.
2018-09-20
18 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kyle Rose
2018-09-20
18 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kyle Rose
2018-09-17
18 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-18.txt
2018-09-17
18 (System) New version approved
2018-09-17
18 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-09-17
18 Dino Farinacci Uploaded new revision
2018-09-12
17 Francis Dupont Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Francis Dupont. Sent review to list.
2018-09-12
17 Magnus Westerlund Request for Telechat review by TSVART is assigned to Brian Trammell
2018-09-12
17 Magnus Westerlund Request for Telechat review by TSVART is assigned to Brian Trammell
2018-09-11
17 Eric Rescorla Telechat date has been changed to 2018-09-27 from 2018-09-13
2018-09-11
17 Eric Rescorla IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2018-09-11
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-09-11
17 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-17.txt
2018-09-11
17 (System) New version approved
2018-09-11
17 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-09-11
17 Dino Farinacci Uploaded new revision
2018-09-11
16 Mirja Kühlewind
[Ballot discuss]
I have a couple of smaller discuss points with should be straight-forward to address and one more high-level discussion point that might not …
[Ballot discuss]
I have a couple of smaller discuss points with should be straight-forward to address and one more high-level discussion point that might not have a solution (depending on the deployment status of LISP I guess) but I would like to at least have a discussion. I start with the straight-forward onces:

1) Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)! (Also it seems like the text on ECN is simply just twice in sec 5.3; not sure that is helpful).

2) Further, also in sec 5.3:
"The inner-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) considering the exception listed below."
However, I didn't find any exceptions listed later in the doc. However, setting the DSCP field might also be matter of local policy. E.g. if DSCP is not used for a different purpose in the receiver side LISP network, it could make sense to restore/keep the original value in the inner header.

3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

4) I would like to see another sentence in section 12 explicitly stating that the source port SHOULD be the same for all packet belong to the same flow.

5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet."
What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or maybe the packet should be dropped or something? Please clarify in the doc!

6) And now the more-discussion-needed point:
So my underlying concern is the same as brought up by the TSV-ART review that lisp information are not end-to-end integrity protected or authenticated. However, while briefly thinking about how this could be eventually realized, I noticed that there is actually no mechanism to extend the LISP header in any way. There is no version, no option and the LISP header seems to have a fixed, implicitly specified length without an explicit length field. This seems too late to add any kind of extensibility mechanism at this stage of the protocols lifetime, however, I would still like to discuss if there was any discussion about extensibility, what was the reason to chose this approach, and potential if some background about the choice should be given in the doc.
2018-09-11
16 Mirja Kühlewind
[Ballot comment]
1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the language to more what RFC4459 recommends:
OLD …
[Ballot comment]
1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the language to more what RFC4459 recommends:
OLD
"This behavior is performed by the ITR when the source host originates
  a packet with the 'DF' field of the IP header set to 0."
MAYBE:
"This behavior MAY be performed by the ITR only when the source host originates
  a packet with the 'DF' field of the IP header set to 0.

2) Sec 4: "...this document recommends that a maximum of two
  LISP headers can be prepended to a packet."
MAYBE:
"it is RECOMMENDED that a maximum of two
  LISP headers can be prepended to a packet."
?
2018-09-11
16 Mirja Kühlewind Ballot comment and discuss text updated for Mirja Kühlewind
2018-09-11
16 Mirja Kühlewind
[Ballot discuss]
Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also …
[Ballot discuss]
Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)! (Also it seems like the text on ECN is simply just twice in sec 5.3; not sure that is helpful).

Further, also in sec 5.3:
"The inner-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) considering the exception listed below."
However, I didn't find any exception listed. However seeting the DSCP field might also be matter of local policy. E.g. if DSCP is not used for a different purposed in the receiver side lisp network, it could make sense to restore/keep the orginial value in the inner header.

Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

I would like to see another need in section 12 explicitly stating that the source port SHOULD be the same for all packet belong to the same flow.

Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet."
What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or maybe the packet should be dropped or something? Please clarify in the doc!
2018-09-11
16 Mirja Kühlewind Ballot discuss text updated for Mirja Kühlewind
2018-09-10
16 Alvaro Retana
[Ballot comment]
Thanks for the work on this document!

I have some relatively minor comments/nits:

(1) §18: s/RFC8060/RFC8061

(2) §1: "Finally, [I-D.ietf-lisp-introduction] describes …
[Ballot comment]
Thanks for the work on this document!

I have some relatively minor comments/nits:

(1) §18: s/RFC8060/RFC8061

(2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture."  First of all, it would seem to me that the Architecture should be a Normative reference...but I-D.ietf-lisp-introduction says that it "is used for introductory purposes, more details can be found in RFC6830, the protocol specification."  This document obsoletes rfc6830...so it seems to me that there is a failed circular dependency.

(3) References to rfc2119/rfc8174 and rfc8126 should be Normative.
2018-09-10
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-09-10
16 Mirja Kühlewind
[Ballot discuss]
Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also …
[Ballot discuss]
Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)! (Also it seems like the text on ECN is simply just twice in sec 5.3; not sure that is helpful).

Further, also in sec 5.3:
"The inner-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) considering the exception listed below."
However, I didn't find any exception listed. However seeting the DSCP field might also be matter of local policy. E.g. if DSCP is not used for a different purposed in the receiver side lisp network, it could make sense to restore/keep the orginial value in the inner header.

Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

I would like to see another need in section 12 explicitly stating that the source port SHOULD be the same for all packet belong to the same flow.
2018-09-10
16 Mirja Kühlewind
[Ballot comment]
In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the language to more what RFC4459 recommends:
OLD
"This …
[Ballot comment]
In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the language to more what RFC4459 recommends:
OLD
"This behavior is performed by the ITR when the source host originates
  a packet with the 'DF' field of the IP header set to 0."
MAYBE:
"This behavior MAY be performed by the ITR only when the source host originates
  a packet with the 'DF' field of the IP header set to 0.


Sec 4: "...this document recommends that a maximum of two
  LISP headers can be prepended to a packet."
MAYBE:
"it is RECOMMENDED that a maximum of two
  LISP headers can be prepended to a packet."
?
2018-09-10
16 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2018-09-05
16 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2018-08-29
16 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2018-08-29
16 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2018-08-29
16 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2018-08-29
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2018-08-28
16 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-08-28
16 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-rfc6830bis-14. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-rfc6830bis-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

we will update the following existing registration to refer to the current version of this document:

Service Name: lisp-data
Port Number: 4341
Transport Protocol: udp
Description: LISP Data Packets
Reference: [ RFC-to-be ]

We understand that this is the only action required of the IANA Functions Operator upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-08-28
16 Cindy Morgan Placed on agenda for telechat - 2018-09-13
2018-08-28
16 Deborah Brungard Ballot has been issued
2018-08-28
16 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2018-08-28
16 Deborah Brungard Created "Approve" ballot
2018-08-28
16 Deborah Brungard Ballot writeup was changed
2018-08-28
16 Scott Bradner Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Scott Bradner. Sent review to list.
2018-08-27
16 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-16.txt
2018-08-27
16 (System) New version approved
2018-08-27
16 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-08-27
16 Dino Farinacci Uploaded new revision
2018-08-27
15 Brian Trammell Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Brian Trammell. Sent review to list.
2018-08-24
15 Kyle Rose Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Kyle Rose. Sent review to list.
2018-08-24
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-08-24
15 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-15.txt
2018-08-24
15 (System) New version approved
2018-08-24
15 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-08-24
15 Dino Farinacci Uploaded new revision
2018-08-23
14 Magnus Westerlund Request for Last Call review by TSVART is assigned to Brian Trammell
2018-08-23
14 Magnus Westerlund Request for Last Call review by TSVART is assigned to Brian Trammell
2018-08-23
14 Magnus Westerlund Request for Last Call review by TSVART is assigned to Joerg Ott
2018-08-23
14 Magnus Westerlund Request for Last Call review by TSVART is assigned to Joerg Ott
2018-08-20
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2018-08-20
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2018-08-16
14 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2018-08-16
14 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2018-08-16
14 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-08-16
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kyle Rose
2018-08-16
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kyle Rose
2018-08-15
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-08-15
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-08-29):

From: The IESG
To: IETF-Announce
CC: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, db3546@att.com, Luigi Iannone , …
The following Last Call announcement was sent out (ends 2018-08-29):

From: The IESG
To: IETF-Announce
CC: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, db3546@att.com, Luigi Iannone , ggx@gigix.net, lisp@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Locator/ID Separation Protocol (LISP)) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'The Locator/ID Separation
Protocol (LISP)'
  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
ietf@ietf.org mailing lists by 2018-08-29. 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 Data-Plane protocol for the Locator/ID
  Separation Protocol (LISP).  LISP defines two namespaces, End-point
  Identifiers (EIDs) that identify end-hosts and Routing Locators
  (RLOCs) that identify network attachment points.  With this, LISP
  effectively separates control from data, and allows routers to create
  overlay networks.  LISP-capable routers exchange encapsulated packets
  according to EID-to-RLOC mappings stored in a local Map-Cache.

  LISP requires no change to either host protocol stacks or to underlay
  routers and offers Traffic Engineering, multihoming and mobility,
  among other features.

  This document obsoletes RFC 6830.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-lisp-6834bis: Locator/ID Separation Protocol (LISP) Map-Versioning (None - IETF stream)



2018-08-15
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-08-15
14 Deborah Brungard Last call was requested
2018-08-15
14 Deborah Brungard Ballot approval text was generated
2018-08-15
14 Deborah Brungard Ballot writeup was generated
2018-08-15
14 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2018-08-15
14 Deborah Brungard Last call announcement was generated
2018-08-12
14 Min Ye Request for Last Call review by RTGDIR Completed: Ready. Reviewer: John Drake.
2018-07-31
14 Min Ye Request for Last Call review by RTGDIR is assigned to John Drake
2018-07-31
14 Min Ye Request for Last Call review by RTGDIR is assigned to John Drake
2018-07-31
14 Deborah Brungard Requested Last Call review by RTGDIR
2018-07-25
14 Luigi Iannone
draft-ietf-lisp-6830bis-14.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(1) What type of RFC is …
draft-ietf-lisp-6830bis-14.txt Document Write-up

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.


(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 draft is targeting Standard Track publication. It is the proper type of RFC, since is the evolution of RFC 6830, which is experimental and is one of items in the LISP WG charter. The RFC type is indicated in the 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 provides the specifications for the data-plane of LISP  (Locator/Id Separation Protocol).  LISP defines two namespaces, End-point  Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. In this way, LISP effectively separates control from data, and allows routers to create overlay networks.  LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.


Working Group Summary:

The current LISP WG charter has as main task porting the main LISP specifications on Standard Track. The WG has decided to focus on two main documents, one with the specifications of the data-plane and the other with the specifications of the control-plane. This document concerns the data-plane. The WG has showed support to the document from its first submission as individual draft and adopted it right away. On the technical side there was agreement in the WG and little discussion took place, mainly related include some features/improvements not present in RFC 6830. On the organisation of the document, more specifically on what to put in the data-plane document and what to put in the control-plane document there has been quite some discussion. The current version is the trade-off the WG  achieved and for which clear consensus has been reached. The version of the document that was approved during WG Last Call is -12. As a shepherd I required a few editorial changes to the document to fix some nits.



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, 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?

There are several independent implementations of the LISP data-plane.


Personnel:

Who is the Document Shepherd?

  Luigi Iannone


Who is the Responsible Area Director?

  Deborah Brungard .



(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 reviewed carefully the document. The text is clear and understandable. I have checked the mailinglist and meeting minutes and publication WG consensus has been reached appropriately. I checked the ID nits and decided to ask the authors to fix them before submitting this writeup. The output of the IDnits tool for the -14 version of the document is provided on point 11.


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

  No broader review is required for this document.



(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?

  All authors have made conforming IPR disclosure.



(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 concerning this specific document. However, there is an IPR disclosure filled by Huawei on RFC 6830, hence, because this document is largely based on that one, the same IPR disclosure may relate to this document.



(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 strong consensus behind this document, showing that the WG as a whole understand and agree 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 extreme 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.

idnits 2.15.01

/tmp/draft-ietf-lisp-rfc6830bis-14.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 (July 17, 2018) is 8 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)

  == Outdated reference: A later version (-11) exists of
    draft-ietf-lisp-rfc6833bis-10


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

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review
criteria, such as the MIB 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?

  Yes.



(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?

There are no normative references in unclear state. For clarification, there is a normative reference to draft-ietf-lisp-rfc6833bis and one to draft-ietf-lisp-6834bis, but these documents passed as well WG Last Call. Worst case the RFC editor can hold this document in the queue until there is a RFC number for them.


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



(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 will obsolete RFC 6830, as mentioned in the header, abstract and introduction.



(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
5226
).

  This document does not make any request to IANA. IANA already allocated UDP port number 4341 for the LISP Data-Plane. This document just state that such allocation exists.


(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, etc.

  The document does not contain anything written in a formal
  language, hence, no validation and/or check has been
  performed.
2018-07-25
14 Luigi Iannone Responsible AD changed to Deborah Brungard
2018-07-25
14 Luigi Iannone IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-07-25
14 Luigi Iannone IESG state changed to Publication Requested
2018-07-25
14 Luigi Iannone IESG process started in state Publication Requested
2018-07-25
14 Luigi Iannone Changed consensus to Yes from Unknown
2018-07-25
14 Luigi Iannone Intended Status changed to Proposed Standard from None
2018-07-25
14 Luigi Iannone Changed document writeup
2018-07-17
14 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-14.txt
2018-07-17
14 (System) New version approved
2018-07-17
14 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-07-17
14 Dino Farinacci Uploaded new revision
2018-07-15
13 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-13.txt
2018-07-15
13 (System) New version approved
2018-07-15
13 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-07-15
13 Dino Farinacci Uploaded new revision
2018-05-02
12 Luigi Iannone Notification list changed to Luigi Iannone <ggx@gigix.net>
2018-05-02
12 Luigi Iannone Document shepherd changed to Luigi Iannone
2018-05-02
12 Luigi Iannone IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-04-05
12 Luigi Iannone IETF WG state changed to In WG Last Call from WG Document
2018-03-19
12 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-12.txt
2018-03-19
12 (System) New version approved
2018-03-19
12 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-03-19
12 Albert Cabellos-Aparicio Uploaded new revision
2018-03-05
11 Albert Cabellos-Aparicio New version available: draft-ietf-lisp-rfc6830bis-11.txt
2018-03-05
11 (System) New version approved
2018-03-05
11 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-03-05
11 Albert Cabellos-Aparicio Uploaded new revision
2018-03-04
10 Albert Cabellos New version available: draft-ietf-lisp-rfc6830bis-10.txt
2018-03-04
10 (System) New version approved
2018-03-04
10 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-03-04
10 Albert Cabellos Uploaded new revision
2018-02-13
09 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-09.txt
2018-02-13
09 (System) New version approved
2018-02-13
09 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-02-13
09 Dino Farinacci Uploaded new revision
2018-01-09
08 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-08.txt
2018-01-09
08 (System) New version approved
2018-01-09
08 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2018-01-09
08 Dino Farinacci Uploaded new revision
2017-11-11
07 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-07.txt
2017-11-11
07 (System) New version approved
2017-11-11
07 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2017-11-11
07 Dino Farinacci Uploaded new revision
2017-10-30
06 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-06.txt
2017-10-30
06 (System) New version approved
2017-10-30
06 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2017-10-30
06 Dino Farinacci Uploaded new revision
2017-08-29
05 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-05.txt
2017-08-29
05 (System) New version approved
2017-08-29
05 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2017-08-29
05 Dino Farinacci Uploaded new revision
2017-07-17
04 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-04.txt
2017-07-17
04 (System) New version approved
2017-07-17
04 (System) Request for posting confirmation emailed to previous authors: Vince Fuller , Darrel Lewis , Dino Farinacci , Albert Cabellos-Aparicio , David Meyer
2017-07-17
04 Dino Farinacci Uploaded new revision
2017-05-04
03 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-03.txt
2017-05-04
03 (System) New version approved
2017-05-04
03 (System) Request for posting confirmation emailed to previous authors: lisp-chairs@ietf.org, Dino Farinacci , Albert Cabellos-Aparicio , Vince Fuller , Darrel Lewis , David Meyer
2017-05-04
03 Dino Farinacci Uploaded new revision
2017-04-11
02 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-02.txt
2017-04-11
02 (System) New version approved
2017-04-11
02 (System) Request for posting confirmation emailed to previous authors: lisp-chairs@ietf.org, Dino Farinacci , Albert Cabellos-Aparicio , Vince Fuller , Darrel Lewis , David Meyer
2017-04-11
02 Dino Farinacci Uploaded new revision
2017-03-28
01 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-01.txt
2017-03-28
01 (System) New version approved
2017-03-28
01 (System) Request for posting confirmation emailed to previous authors: lisp-chairs@ietf.org, Dino Farinacci , Albert Cabellos-Aparicio , Vince Fuller , Darrel Lewis , David Meyer
2017-03-28
01 Dino Farinacci Uploaded new revision
2016-12-06
00 Joel Halpern This document now replaces draft-farinacci-lisp-rfc6830bis instead of None
2016-12-06
00 Dino Farinacci New version available: draft-ietf-lisp-rfc6830bis-00.txt
2016-12-06
00 (System) WG -00 approved
2016-12-06
00 Dino Farinacci Set submitter to "Dino Farinacci ", replaces to draft-farinacci-lisp-rfc6830bis and sent approval email to group chairs: lisp-chairs@ietf.org
2016-12-06
00 Dino Farinacci Uploaded new revision