Skip to main content

Locator/ID Separation Protocol (LISP) Generic Protocol Extension
RFC 9305

Revision differences

Document history

Date Rev. By Action
2022-10-25
19 (System) IANA registries were updated to include RFC9305
2022-10-20
19 (System)
Received changes through RFC Editor sync (created alias RFC 9305, changed title to 'Locator/ID Separation Protocol (LISP) Generic Protocol Extension', changed abstract to 'This …
Received changes through RFC Editor sync (created alias RFC 9305, changed title to 'Locator/ID Separation Protocol (LISP) Generic Protocol Extension', changed abstract to 'This document describes extensions to the Locator/ID Separation Protocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.', changed pages to 14, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-10-20, changed IESG state to RFC Published)
2022-10-20
19 (System) RFC published
2022-10-03
19 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-09-19
19 (System) RFC Editor state changed to AUTH48
2022-08-10
19 (System) RFC Editor state changed to RFC-EDITOR from REF
2022-07-19
19 (System) RFC Editor state changed to REF from EDIT
2022-07-14
19 (System) RFC Editor state changed to EDIT from MISSREF
2021-03-10
19 Alvaro Retana Shepherding AD changed to Alvaro Retana
2021-03-10
19 Alvaro Retana Notification list changed to Luigi Iannone <ggx@gigix.net>, aretana.ietf@gmail.com from Luigi Iannone <ggx@gigix.net>
2021-02-11
19 (System) RFC Editor state changed to MISSREF from EDIT
2021-02-11
19 (System) RFC Editor state changed to EDIT from MISSREF
2020-08-19
19 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-08-19
19 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-08-19
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-08-14
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-08-11
19 (System) RFC Editor state changed to MISSREF
2020-08-11
19 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-08-11
19 (System) Announcement was received by RFC Editor
2020-08-11
19 (System) IANA Action state changed to In Progress
2020-08-11
19 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2020-08-11
19 Amy Vezza IESG has approved the document
2020-08-11
19 Amy Vezza Closed "Approve" ballot
2020-08-11
19 Deborah Brungard Ballot writeup was changed
2020-07-28
19 Deborah Brungard Ballot approval text was changed
2020-07-26
19 Fabio Maino New version available: draft-ietf-lisp-gpe-19.txt
2020-07-26
19 (System) New version approved
2020-07-26
19 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Puneet Agarwal , Jennifer Lemon , Michael Smith , Fabio Maino
2020-07-26
19 Fabio Maino Uploaded new revision
2020-07-13
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-13
18 Fabio Maino New version available: draft-ietf-lisp-gpe-18.txt
2020-07-13
18 (System) New version approved
2020-07-13
18 (System) Request for posting confirmation emailed to previous authors: Michael Smith , Darrel Lewis , Puneet Agarwal , Jennifer Lemon , Fabio Maino
2020-07-13
18 Fabio Maino Uploaded new revision
2020-07-10
17 Magnus Westerlund Closed request for Last Call review by TSVART with state 'Overtaken by Events'
2020-07-10
17 Magnus Westerlund Assignment of request for Last Call review by TSVART to Ian Swett was marked no-response
2020-07-09
17 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2020-07-09
17 Magnus Westerlund
[Ballot comment]
Section 4.2:

To me it looks like this is normative reference:

Such new encapsulated payloads, when registered with LISP-
  GPE, MUST be …
[Ballot comment]
Section 4.2:

To me it looks like this is normative reference:

Such new encapsulated payloads, when registered with LISP-
  GPE, MUST be accompanied by a set of guidelines derived from
  [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].

Section 4.3.1:

Thanks for writing relevant guidance on how to mitigate the risks with zero checksum. Especially the one on traffic separation from other traffic so that it can be caught on the boundaries of the network to prevent the risk to other networks from corrupted traffic.
2020-07-09
17 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2020-07-09
17 Magnus Westerlund
[Ballot discuss]
Section 4.2:

To me it looks like this is normative reference to the :

Such new encapsulated payloads, when registered with LISP-
  …
[Ballot discuss]
Section 4.2:

To me it looks like this is normative reference to the :

Such new encapsulated payloads, when registered with LISP-
  GPE, MUST be accompanied by a set of guidelines derived from
  [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
2020-07-09
17 Magnus Westerlund
[Ballot comment]
Section 4.3.1:

Thanks for writing relevant guidance on how to mitigate the risks with zero checksum. Especially the one on traffic separation from …
[Ballot comment]
Section 4.3.1:

Thanks for writing relevant guidance on how to mitigate the risks with zero checksum. Especially the one on traffic separation from other traffic so that it can be caught on the boundaries of the network to prevent the risk to other networks from corrupted traffic.
2020-07-09
17 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2020-07-09
17 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-07-08
17 Benjamin Kaduk
[Ballot comment]

  By default, UDP checksum MUST be used when LISP-GPE is transported
  over IPv6.  A tunnel endpoint MAY be configured for use …
[Ballot comment]

  By default, UDP checksum MUST be used when LISP-GPE is transported
  over IPv6.  A tunnel endpoint MAY be configured for use with zero UDP
  checksum if additional requirements in Section 4.3.1 are met.

This is self-referential; maybe just "additional requirements below"?

Section 4.4

  When encapsulating IP (including over Ethernet) packets [RFC2983]
  provides guidance for mapping DSCP between inner and outer IP
  headers.  The Pipe model typically fits better Network
  virtualization.  The DSCP value on the tunnel header is set based on

nit: missing word(s?), maybe "Pipe model typically fits better for
Network virtualization".

  Though Uniform or Pipe models could be used for TTL (or Hop Limit in
  case of IPv6) handling when tunneling IP packets, Pipe model is more
  aligned with network virtualization.  [RFC2003] provides guidance on
  handling TTL between inner IP header and outer IP tunnels; this model
  is more aligned with the Pipe model and is recommended for use with
  LISP-GPE for network virtualization applications.

Is this left over from an editing pass?  It seems to have high overlap
with the first paragraph of the section (though this one talks about
TTL/hop-limit rather than DSCP).
2020-07-08
17 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2020-07-08
17 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-07-08
17 Roman Danyliw
[Ballot comment]
Section 4.  Per “When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped to, or …
[Ballot comment]
Section 4.  Per “When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance IDentifier (IID) field”, as noted in a DISCUSS item in my ballot on draft-ietf-lisp-rfc6830bis-32, using Instance ID values as 802.1Q tags without integrity protection seems problematic in the public internet scenario.  Please add cautionary language recommending integrity protection.

Section 7.  Per “LISP-GPE, as many encapsulations that use optional extensions, is subject to on-path adversaries that by manipulating the P-Bit and the packet itself can remove part of the payload or claim to encapsulate any protocol payload type”, it’s worse than that – (in the absence of integrity protection and like LISP in general) an on-path attacker make arbitrary modifications to the packet (like a 802.1Q tag in the encapsulated ethernet; or the Instance ID using an 802.1.Q tag)
2020-07-08
17 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-07-08
17 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-07-07
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-07-07
17 Fabio Maino New version available: draft-ietf-lisp-gpe-17.txt
2020-07-07
17 (System) New version approved
2020-07-07
17 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Jennifer Lemon , Michael Smith , Puneet Agarwal , Fabio Maino
2020-07-07
17 Fabio Maino Uploaded new revision
2020-07-07
16 Robert Wilton
[Ballot comment]
Hi,

I found this document easy to read and understand.

A couple of minor comments:

4.3.  UDP Checksum

  By default, UDP checksum …
[Ballot comment]
Hi,

I found this document easy to read and understand.

A couple of minor comments:

4.3.  UDP Checksum

  By default, UDP checksum MUST be used when LISP-GPE is transported
  over IPv6.  A tunnel endpoint MAY be configured for use with zero UDP
  checksum if additional requirements in Section 4.3.1 are met.

This paragraph could probably be moved/merged into section 4.3.1?

4.4.  DSCP, ECN and TTL

  When a LISP-GPE router performs Ethernet encapsulation, the inner
  header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped
  to, or used to determine the LISP Instance IDentifier (IID) field.

This text doesn't appear to be related to DSCP, ECN or TTL.  Perhaps tweak the title of this section to cover this text?

Regards,
Rob
2020-07-07
16 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-07-07
16 É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.

Please find …
[Ballot comment]
Thank you for the work put into this document. This is really useful work and the document is easy to read.

Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
As this document is in the same 'batch'/timing as the RFC 6830 bis, is there a reason why this extension is not in the bis document itself?

-- Section 3 --
What is the reason why not reusing an existing 'next protocol' registry? Or using a 16-bit Ethernet type like field (as in GRE) ?

As a side cosmetic note, I would have preferred to have 0x04 for IPv4 and 0x06 for IPv6.

"the shim header MUST come before the further protocol" but, if there are other headers defined in LISP (I must confess my ignorance on this), should the shim header be just after the LISP header ? I.e. the first one of a potential chain (cfr IPv6 extension header chains) ?

It is unclear whether a shim header 'next protocol' field can also have a value associated to yet another shim header.

== NITS ==
The document title "LISP Generic Protocol Extension" is generic while the document is mainly about "multi-protocol encapsulation". Should the title be changed? As a non-English speaker, I read the title as how to make any/generic extension to the LISP protocol and not as a LISP extension to support the transport of generic/any protocol.

-- Section 3 --
Strongly suggest to make it clear by adding a MUST in  "and ignored on receipt", i.e., "and MUST be ignored on receipt"

"0x05 to 0x7D " the final ':' is missing.

Why not writing " 0x7E, 0x7F:" ?

"deploy new GPE features", GPE is not expanded before this first use (even if quite obvious in this document).

s/octect/octet/
2020-07-07
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-07-06
16 Martin Duke
[Ballot comment]
I found the requirements in Section 4.3.1 (IPv6 zero checksum) quite onerous and can’t help but wonder if it’s worth the complexity, or …
[Ballot comment]
I found the requirements in Section 4.3.1 (IPv6 zero checksum) quite onerous and can’t help but wonder if it’s worth the complexity, or just that people already have it implemented in hardware.

This seems like a very useful extension for LISP.

s/octet/octet

s/payolads/payloads
2020-07-06
16 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-07-05
16 Murray Kucherawy [Ballot comment]
In Section 4.2, the "(TMCE)"s seem out of place.
2020-07-05
16 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-06-22
16 Amy Vezza Telechat date has been changed to 2020-07-09 from 2018-09-27
2020-06-22
16 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-06-22
16 Deborah Brungard Ballot has been issued
2020-06-22
16 Deborah Brungard Ballot writeup was changed
2020-06-18
16 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-06-18
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-06-17
16 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2020-06-17
16 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-gpe-16. 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-gpe-16. 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.

A new registry is to be created called the LISP-GPE Next Protocol Registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The registry is to be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+--------------+-------------------------------------+--------------+
| Next | Description | Reference |
| Protocol | | |
+--------------+-------------------------------------+--------------+
| 0x00 | Reserved |[ RFC-to-be ] |
| 0x01 | IPv4 |[ RFC-to-be ] |
| 0x02 | IPv6 |[ RFC-to-be ] |
| 0x03 | Ethernet |[ RFC-to-be ] |
| 0x04 | NSH |[ RFC-to-be ] |
| 0x05..0x7D | Unassigned | |
| 0x7E..0x7F | Experimentation and testing |[ RFC-to-be ] |
| 0x80..0xFD | Unassigned (shim headers) | |
| 0x8E..0x8F | Experimentation and testing (shim |[ RFC-to-be ] |
| | headers) | |
+--------------+-------------------------------------+--------------+

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-08
16 Wesley Eddy Request for Last Call review by TSVART is assigned to Ian Swett
2020-06-08
16 Wesley Eddy Request for Last Call review by TSVART is assigned to Ian Swett
2020-06-04
16 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-06-18):

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

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


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP Generic Protocol Extension'
  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 extensions to the Locator/ID Separation
  Protocol (LISP) Data-Plane, via changes to the LISP header, to
  support multi-protocol encapsulation.




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



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




2020-06-04
16 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-06-04
16 Deborah Brungard Last call was requested
2020-06-04
16 Deborah Brungard IESG state changed to Last Call Requested from IESG Evaluation
2020-06-04
16 Deborah Brungard Last call announcement was changed
2020-06-04
16 Deborah Brungard Last call announcement was generated
2020-06-03
16 Fabio Maino New version available: draft-ietf-lisp-gpe-16.txt
2020-06-03
16 (System) New version approved
2020-06-03
16 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Jennifer Lemon , Fabio Maino , Puneet Agarwal , Michael Smith
2020-06-03
16 Fabio Maino Uploaded new revision
2020-05-31
15 Fabio Maino New version available: draft-ietf-lisp-gpe-15.txt
2020-05-31
15 (System) New version approved
2020-05-31
15 (System) Request for posting confirmation emailed to previous authors: Puneet Agarwal , Fabio Maino , Jennifer Lemon , Darrel Lewis , Michael Smith
2020-05-31
15 Fabio Maino Uploaded new revision
2020-01-24
14 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2020-01-08
14 Fabio Maino New version available: draft-ietf-lisp-gpe-14.txt
2020-01-08
14 (System) New version approved
2020-01-08
14 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2020-01-08
14 Fabio Maino Uploaded new revision
2020-01-06
13 Fabio Maino New version available: draft-ietf-lisp-gpe-13.txt
2020-01-06
13 (System) New version approved
2020-01-06
13 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2020-01-06
13 Fabio Maino Uploaded new revision
2019-12-30
12 Benjamin Kaduk
[Ballot comment]
Thanks for the updates in -10 through -12 to leave nonce/versioning to
additional shim headers/extensions; that does alleviate the concerns that
left me …
[Ballot comment]
Thanks for the updates in -10 through -12 to leave nonce/versioning to
additional shim headers/extensions; that does alleviate the concerns that
left me balloting Abstain on the -09.

I do have some (new) comments on the -12.

Section 3
 
Conceptually, I'm thinking about this document as allocating the 'P' bit in
the header and specifying its format when the P bit is set to 1; I don't
expect it to be making changes to generic non-GPE LISP behavior.  So it's
a little surprising to see that bits 0-3 are now marked as Reserved (though
that could probably be wordsmithed away, and the existing Section 2 probably
sets the reader up to do the right thing already), and fairly surprising to
see the following in the P-Bit description:

      If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
      to the definition in [I-D.ietf-lisp-rfc6830bis] with bits N, L, E
      and V set to 0.

Is the claim that once an implementation supports GPE, it will never use the
non-shim-header versions of echo-nonce, map-versioning, etc?  If not, then I
don't think it's appropriate to say "with bits N, L, E, and V set to 0"
here.

I'm also not sure I fully understand the motivation for pulling out
the Locator-Status-Bits, as that field's width is unchanged from stock
6830bis.  Leaving them to a TBD shim-header does prevent the conflict with
the Instance ID field, and perhaps the current usage patterns justify such a
shift, so this may be more of a side note than an indication of a flaw in
the document.
 
Section 7
 
  LISP-GPE, as many encapsulations that use optional extensions, is
  subject to on-path adversaries that by manipulating the g-Bit and the
  packet itself can remove part of the payload.  Typical integrity

Is "g-Bit" supposed to be "P-Bit"?  I am failing to remember what the g-Bit
is, at least...

  With LISP-GPE, issues such as data-plane spoofing, flooding, and
  traffic redirection may depend on the particular protocol payload
  encapsulated.

I'd consider adding another clause, "noting that an attacker that is
spoofing LISP-GPE traffic can claim to encapsulate any protocol payload
type" -- the risk here is based on what types the receiver's implementation
supports, not just what the legitimate sender is encapsulating.
2019-12-30
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Abstain
2019-11-18
12 Fabio Maino New version available: draft-ietf-lisp-gpe-12.txt
2019-11-18
12 (System) New version approved
2019-11-18
12 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2019-11-18
12 Fabio Maino Uploaded new revision
2019-11-17
11 Luigi Iannone Added to session: IETF-106: lisp  Tue-1000
2019-11-04
11 Fabio Maino New version available: draft-ietf-lisp-gpe-11.txt
2019-11-04
11 (System) New version approved
2019-11-04
11 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2019-11-04
11 Fabio Maino Uploaded new revision
2019-11-04
10 Fabio Maino New version available: draft-ietf-lisp-gpe-10.txt
2019-11-04
10 (System) New version approved
2019-11-04
10 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2019-11-04
10 Fabio Maino Uploaded new revision
2019-10-25
09 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my Discuss-level points (I can accept that for the -09
that RFC 8060 need not be a normative reference).  …
[Ballot comment]
Thank you for addressing my Discuss-level points (I can accept that for the -09
that RFC 8060 need not be a normative reference).  I am balloting Abstain because
I am uncomfortable with only 16 bits of nonce, but I recognize that there is a need
for this sort of encapsulation and it must fit within the constraints of the core protocol.
Though, given Alissa's Discuss, it is technically still possible for the core protocol to
grow a larger nonce that would alleviate my concerns.  But, since the issue stems from
a different document (and because I did not raise the issue earlier), it is not appropriate
for me to ballot Discuss on this document for that point.

[original COMMENT section unchanged; contents presumably stale]

Section 1

  LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
  has allocated all by defining a Next Protocol "shim" header that

nit: allocated all of what?

Section 3

This is not exactly the responsibility of LISP-GPE merely because it
allocates the last bit in this bitmap, but it seems like it would be quite
useful to have a table of which combinations of values are valid vs.
nonsensical, given the somewhat complicated interaction between some of
these flag bits.

      Similarly, the encoding of the Source and Dest Map-Version fields,
      compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
      bits.  This still allows to associate 256 different versions to
      each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
      to inform commmunicating ITRs and ETRs about modifications of the
      mapping.

Are we limited to 256 versions total, or is there some sort of larger
version space that we truncate to send (a la a wraparound process)?
I understand that map-versioning is primarily in a separate document but it
seems important for this document to describe to what extent it is limiting
functionality.

Section 3.1

  To ensure that protocols that are encapsulated in LISP-GPE will work
  well from a transport interaction perspective, the specification of a
  new encapsulated payload MUST contain an analysis of how LISP-GPE
  SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
  Congestion Notification (ECN) bits whenever they apply to the new
  encapsulated payload.

This MUST is duplicated in the next three paragraphs; I would suggest
leaving this introduction as non-normative, with something like "needs to
contain an analysis of how LISP-GPE will deal with [...]"
Also, nit: "the outer UDP Checksum"

Section 4

  When encapsulating IP packets to a non LISP-GPE capable router the
  P-bit MUST be set to 0.  [...]

  A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
  P-bit set to 1) to a non-LISP-GPE capable router.

I'm failing to see how these two sentences are not redundant.

Section 5.1

Just to be clear, the intent is that if there is some non-IETF protocol
that we want to encapsulate, we write a two-page Standards-Track RFC that
says "this GPE codepoint means to do what this non-IETF document says"?

Section 6

                      However, the use of common anti-spoofing
  mechanisms such as uRPF prevents this form of attack.

I think "mitigates" is probably better than "prevents" in this case.

  LISP-GPE, as many encapsulations that use optional extensions, is
  subject to on-path adversaries that by manipulating the g-Bit and the
  packet itself can remove part of the payload.  Typical integrity
  protection mechanisms (such as IPsec) SHOULD be used in combination
  with LISP-GPE by those protocol extensions that want to protect from
  on-path attackers.

The g-Bit is present in the Map-Reply message, which can in the general
case be sent via triangle-routing, in which case the establishment and
selection of IPsec security associations is somewhat nontrivial and
probably does not quality as "typical", based on my limited experience.
I think a more general scheme for providing integrity protection for
mapping messages is needed as a mandatory mechanism, but that's a topic for
the control-plane document so I will not belabor it here.
2019-10-25
09 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Abstain from Discuss
2019-10-25
09 Fabio Maino New version available: draft-ietf-lisp-gpe-09.txt
2019-10-25
09 (System) New version approved
2019-10-25
09 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2019-10-25
09 Fabio Maino Uploaded new revision
2019-10-25
08 Luigi Iannone
During IESG review the document has been updated in such a way that ew discussion in WG is needed.
Tentative plan:
Present changes to the …
During IESG review the document has been updated in such a way that ew discussion in WG is needed.
Tentative plan:
Present changes to the WG in Singapore during IETF 106 and make a quick WGLC just to confirm the previous consensus.
2019-10-25
08 Luigi Iannone Tags Other - see Comment Log, Revised I-D Needed - Issue raised by IESG set. Tag AD Followup cleared.
2019-10-24
08 Benjamin Kaduk
[Ballot discuss]
Thank you for the updates in the -08!
Can you please say "partially mitigates" instead of "mitigates" in "However,
the use of common …
[Ballot discuss]
Thank you for the updates in the -08!
Can you please say "partially mitigates" instead of "mitigates" in "However,
the use of common anti-spoofing mechanisms such as uRPF mitigates this
form of attack."?

Now that RFC 8060 is a normative reference, it's a downref that I believe will
need to be IETF LC'd again.
2019-10-24
08 Benjamin Kaduk
[Ballot comment]
[original COMMENT section unchanged; contents presumably stale]

Section 1

  LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
  …
[Ballot comment]
[original COMMENT section unchanged; contents presumably stale]

Section 1

  LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
  has allocated all by defining a Next Protocol "shim" header that

nit: allocated all of what?

Section 3

This is not exactly the responsibility of LISP-GPE merely because it
allocates the last bit in this bitmap, but it seems like it would be quite
useful to have a table of which combinations of values are valid vs.
nonsensical, given the somewhat complicated interaction between some of
these flag bits.

      Similarly, the encoding of the Source and Dest Map-Version fields,
      compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
      bits.  This still allows to associate 256 different versions to
      each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
      to inform commmunicating ITRs and ETRs about modifications of the
      mapping.

Are we limited to 256 versions total, or is there some sort of larger
version space that we truncate to send (a la a wraparound process)?
I understand that map-versioning is primarily in a separate document but it
seems important for this document to describe to what extent it is limiting
functionality.

Section 3.1

  To ensure that protocols that are encapsulated in LISP-GPE will work
  well from a transport interaction perspective, the specification of a
  new encapsulated payload MUST contain an analysis of how LISP-GPE
  SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
  Congestion Notification (ECN) bits whenever they apply to the new
  encapsulated payload.

This MUST is duplicated in the next three paragraphs; I would suggest
leaving this introduction as non-normative, with something like "needs to
contain an analysis of how LISP-GPE will deal with [...]"
Also, nit: "the outer UDP Checksum"

Section 4

  When encapsulating IP packets to a non LISP-GPE capable router the
  P-bit MUST be set to 0.  [...]

  A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
  P-bit set to 1) to a non-LISP-GPE capable router.

I'm failing to see how these two sentences are not redundant.

Section 5.1

Just to be clear, the intent is that if there is some non-IETF protocol
that we want to encapsulate, we write a two-page Standards-Track RFC that
says "this GPE codepoint means to do what this non-IETF document says"?

Section 6

                      However, the use of common anti-spoofing
  mechanisms such as uRPF prevents this form of attack.

I think "mitigates" is probably better than "prevents" in this case.

  LISP-GPE, as many encapsulations that use optional extensions, is
  subject to on-path adversaries that by manipulating the g-Bit and the
  packet itself can remove part of the payload.  Typical integrity
  protection mechanisms (such as IPsec) SHOULD be used in combination
  with LISP-GPE by those protocol extensions that want to protect from
  on-path attackers.

The g-Bit is present in the Map-Reply message, which can in the general
case be sent via triangle-routing, in which case the establishment and
selection of IPsec security associations is somewhat nontrivial and
probably does not quality as "typical", based on my limited experience.
I think a more general scheme for providing integrity protection for
mapping messages is needed as a mandatory mechanism, but that's a topic for
the control-plane document so I will not belabor it here.
2019-10-24
08 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2019-10-24
08 Fabio Maino New version available: draft-ietf-lisp-gpe-08.txt
2019-10-24
08 (System) New version approved
2019-10-24
08 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , Michael Smith , Fabio Maino , Puneet Agarwal , Jennifer Lemon
2019-10-24
08 Fabio Maino Uploaded new revision
2019-10-18
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-10-18
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-10-18
07 Fabio Maino New version available: draft-ietf-lisp-gpe-07.txt
2019-10-18
07 (System) New version approved
2019-10-18
07 (System) Request for posting confirmation emailed to previous authors: lisp-chairs@ietf.org, Puneet Agarwal , Darrel Lewis , John Lemon , Fabio Maino , Michael Smith
2019-10-18
07 Fabio Maino Uploaded new revision
2019-08-19
06 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2019-08-19
06 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Jon Mitchell was marked no-response
2018-09-27
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-09-27
06 Suresh Krishnan
[Ballot comment]
This draft needs to update RFC6830 since it takes the last reserved bit away from there. As a side question, since 6830 is …
[Ballot comment]
This draft needs to update RFC6830 since it takes the last reserved bit away from there. As a side question, since 6830 is being bised right now should this flag be acknowledged in the bis draft?

I am also interested to see the resolution to Mirja's DISCUSS point about the PCP and VID mappings.
2018-09-27
06 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-09-27
06 Alissa Cooper
[Ballot discuss]
In the thread with the Gen-ART reviewer, the rationale that was given for advancing this document now even though rfc6834bis is nascent was: …
[Ballot discuss]
In the thread with the Gen-ART reviewer, the rationale that was given for advancing this document now even though rfc6834bis is nascent was:

"We do not expect big changes in any bis document, since they are just the PS version of deployed technology."

This seems somewhat less likely given the feedback received on the LISP documents on the telechat this week, so I'd like to discuss whether it really makes sense to advance this one now given its normative dependencies on 6834bis and 6830bis.
2018-09-27
06 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2018-09-27
06 Benjamin Kaduk
[Ballot discuss]
[Unlike for the 683xbis documents, this is a more mundane Discuss, with one
process issue and one issue of clarity with respect to …
[Ballot discuss]
[Unlike for the 683xbis documents, this is a more mundane Discuss, with one
process issue and one issue of clarity with respect to randomness
requirements, that should be fairly easy to resolve.]

I think that 8060 needs to be a normative reference; it seems to be needed to
implement the Multiple Data-Planes LCAF type.  Arguably 6040 also should
be, though that seems less clear-cut to me.
(8060 would be a new normative downref and require another IETF LC, IIUC.)

Section 3 notes:
      The encoding of the Nonce field in LISP-GPE, compared with the one
      used in [I-D.ietf-lisp-rfc6830bis] for the LISP data plane
      encapsulation, reduces the length of the nonce from 24 to 16 bits.
      As per [I-D.ietf-lisp-rfc6830bis], Ingress Tunnel Routers (ITRs)
      are required to generate different nonces when sending to
      different Routing Locators (RLOCs), but the same nonce can be used
      for a period of time when encapsulating to the same Egress Tunnel
      Router (ETR).  The use of 16 bits nonces still allows an ITR to
      determine to and from reachability for up to 64k RLOCs at the same
      time.
That seems to be missing the point of the nonce -- it's not just for unique
identification but also to prevent off-path attackers from guessing a
valid value and spoofing a bogus map-reply!  Using the entire 64k of nonce
space means that such a spoofing attack can succeed pretty reliably (e.g.,
by over-claiming so that the response EID-prefix contains whatever the
request was for).  I think it's important to accurately describe what
properties are required of indivdiual nonces and the combined set of active
nonces, which this text seems to mischaracterize.
2018-09-27
06 Benjamin Kaduk
[Ballot comment]
Section 1

  LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
  has allocated all by defining a Next …
[Ballot comment]
Section 1

  LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
  has allocated all by defining a Next Protocol "shim" header that

nit: allocated all of what?

Section 3

This is not exactly the responsibility of LISP-GPE merely because it
allocates the last bit in this bitmap, but it seems like it would be quite
useful to have a table of which combinations of values are valid vs.
nonsensical, given the somewhat complicated interaction between some of
these flag bits.

      Similarly, the encoding of the Source and Dest Map-Version fields,
      compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
      bits.  This still allows to associate 256 different versions to
      each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
      to inform commmunicating ITRs and ETRs about modifications of the
      mapping.

Are we limited to 256 versions total, or is there some sort of larger
version space that we truncate to send (a la a wraparound process)?
I understand that map-versioning is primarily in a separate document but it
seems important for this document to describe to what extent it is limiting
functionality.

Section 3.1

  To ensure that protocols that are encapsulated in LISP-GPE will work
  well from a transport interaction perspective, the specification of a
  new encapsulated payload MUST contain an analysis of how LISP-GPE
  SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
  Congestion Notification (ECN) bits whenever they apply to the new
  encapsulated payload.

This MUST is duplicated in the next three paragraphs; I would suggest
leaving this introduction as non-normative, with something like "needs to
contain an analysis of how LISP-GPE will deal with [...]"
Also, nit: "the outer UDP Checksum"

Section 4

  When encapsulating IP packets to a non LISP-GPE capable router the
  P-bit MUST be set to 0.  [...]

  A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
  P-bit set to 1) to a non-LISP-GPE capable router.

I'm failing to see how these two sentences are not redundant.

Section 5.1

Just to be clear, the intent is that if there is some non-IETF protocol
that we want to encapsulate, we write a two-page Standards-Track RFC that
says "this GPE codepoint means to do what this non-IETF document says"?

Section 6

                      However, the use of common anti-spoofing
  mechanisms such as uRPF prevents this form of attack.

I think "mitigates" is probably better than "prevents" in this case.

  LISP-GPE, as many encapsulations that use optional extensions, is
  subject to on-path adversaries that by manipulating the g-Bit and the
  packet itself can remove part of the payload.  Typical integrity
  protection mechanisms (such as IPsec) SHOULD be used in combination
  with LISP-GPE by those protocol extensions that want to protect from
  on-path attackers.

The g-Bit is present in the Map-Reply message, which can in the general
case be sent via triangle-routing, in which case the establishment and
selection of IPsec security associations is somewhat nontrivial and
probably does not quality as "typical", based on my limited experience.
I think a more general scheme for providing integrity protection for
mapping messages is needed as a mandatory mechanism, but that's a topic for
the control-plane document so I will not belabor it here.
2018-09-27
06 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-09-27
06 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-09-27
06 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-09-26
06 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-09-26
06 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-09-25
06 Alvaro Retana
[Ballot comment]
I have some non-blocking comments (and nits):

(1) §1: "LISP-GPE MAY also be used to extend the LISP Data-Plane header..."  I think that …
[Ballot comment]
I have some non-blocking comments (and nits):

(1) §1: "LISP-GPE MAY also be used to extend the LISP Data-Plane header..."  I think that MAY is out of place because there's nothing normative about the statement.

(2) §3: "If the P-bit is clear (0) the LISP header conforms to the definition in [I-D.ietf-lisp-rfc6830bis]."  I find this statement a little confusing because even with the bit set, the header still conforms to rfc6830bis, except for the Nonce/Map-Version field. IOW, it sounds as if the bit makes the header non-conforming.

(3) §3: For clarity, it would be nice to add a figure showing the header with the P and V bits set.

(4) §3.1: "...the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with..."  s/SHOULD/should  In this case the "SHOULD" is not normative.

(5) For IP packets, two encapsulation mechanisms exist, the base one defined in rfc6830bis and the generic one defined in this document.  When encapsulating towards a GPE-capable router, which mechanisms should be used?  Should one have preference over the other?  I'm thinking it probably doesn't matter (since the receiving router can understand both) -- I'm trying to figure out whether there are operational considerations or guidance that are worth mentioning.
2018-09-25
06 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-09-25
06 Alexey Melnikov
[Ballot comment]
3.1.1.  Payload Specific Transport Interactions for Ethernet
        Encapsulated Payloads

  When a LISP-GPE router performs Ethernet encapsulation, the inner …
[Ballot comment]
3.1.1.  Payload Specific Transport Interactions for Ethernet
        Encapsulated Payloads

  When a LISP-GPE router performs Ethernet encapsulation, the inner
  header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped
  to, or used to determine the LISP Instance IDentifier (IID) field.

3.1.2.  Payload Specific Transport Interactions for NSH Encapsulated
        Payloads

  When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN
  values MAY be mapped as specified for the Next Protocol encapsulated
  by NSH (namely IPv4, IPv6 and Ethernet).

Not being a specialist in this technology it is not clear to me whether "MAY be mapped" above (in 2 places)
provides enough details to implement. Are there any extra references that you should insert above?
2018-09-25
06 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-09-23
06 Warren Kumari
[Ballot comment]
This review is incomplete -- I'm traveling and hope to be able to get back to it later, but for now I have …
[Ballot comment]
This review is incomplete -- I'm traveling and hope to be able to get back to it later, but for now I have a comment:

Section 1. Introduction:
"LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
  has allocated all by defining a Next Protocol "shim" header that
  implements new data plane functions not supported in the LISP header."

I'm unable to parse the above, especially around the "that has allocated all by defining" but.
2018-09-23
06 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-09-21
06 Magnus Westerlund Request for Telechat review by TSVART Completed: On the Right Track. Reviewer: Magnus Westerlund. Sent review to list.
2018-09-21
06 Magnus Westerlund Request for Telechat review by TSVART is assigned to Magnus Westerlund
2018-09-21
06 Magnus Westerlund Request for Telechat review by TSVART is assigned to Magnus Westerlund
2018-09-20
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-09-20
06 Fabio Maino New version available: draft-ietf-lisp-gpe-06.txt
2018-09-20
06 (System) New version approved
2018-09-20
06 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , John Lemon , Fabio Maino , Puneet Agarwal , Michael Smith
2018-09-20
06 Fabio Maino Uploaded new revision
2018-09-19
05 Mirja Kühlewind
[Ballot discuss]
Thanks for addressing the TSV-ART review (and Magnus for doing the review)! I assume that the proposed text will be incorporated in the …
[Ballot discuss]
Thanks for addressing the TSV-ART review (and Magnus for doing the review)! I assume that the proposed text will be incorporated in the next version. (Would have been even better if those (larger) changes would have been added before the doc was put on the telechat; please update as soon as possible so other AD can review that text as well).

However, I think the text still needs to say more about HOW the PCP should be mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 802.11. Is the same mapping applicable here?

Also, I'm not an expert for that part, but I guess there also is further guidance needed on HOW to map the VID...?
2018-09-19
05 Mirja Kühlewind
[Ballot comment]
Given this doc uses the last reserved bit in the lisp header, I would really like to see more discussion how the data …
[Ballot comment]
Given this doc uses the last reserved bit in the lisp header, I would really like to see more discussion how the data plane lisp can still be extended. I think the solution is straight-forward (define a shim layer for the extension and announce this capability in the Map-Reply), however, spelling this out seems to be appropriate for this doc.
2018-09-19
05 Mirja Kühlewind Ballot comment and discuss text updated for Mirja Kühlewind
2018-09-19
05 Mirja Kühlewind
[Ballot discuss]
Sorry not an expert on 802.1Q, however, I think section 4.2 would need to say more about HOW the PCP should be mapped …
[Ballot discuss]
Sorry not an expert on 802.1Q, however, I think section 4.2 would need to say more about HOW the PCP should be mapped to DSCPs. RFC8325 has shown that there is usually no straight forward approach and therefore more guidance might be needed.

Further, I would guess one would also need to define a more concrete mapping for section 4.3 but here I'm really not an expert at all.
2018-09-19
05 Mirja Kühlewind
[Ballot comment]
Given this doc uses the last reserved bit in the lisp header, I would really like to see more discussion how the data …
[Ballot comment]
Given this doc uses the last reserved bit in the lisp header, I would really like to see more discussion how the data plane lisp can still be extended. I think the solution is straigh-forward (define a shim layer with your extension and annouce this capability in the Map-Reply), however, spelling this out seems to be appropriate for this doc.
2018-09-19
05 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2018-09-12
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Christopher Wood.
2018-09-12
05 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-09-10
05 Cindy Morgan Placed on agenda for telechat - 2018-09-27
2018-09-10
05 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2018-09-10
05 Deborah Brungard Ballot has been issued
2018-09-10
05 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2018-09-10
05 Deborah Brungard Created "Approve" ballot
2018-09-10
05 Deborah Brungard Ballot writeup was changed
2018-09-06
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-09-05
05 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-09-05
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lisp-gpe-05. 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-gpe-05. 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 are two actions which we must complete.

First, a new registry will be created called the LISP-GPE Next Protocol registry.

IANA Question --> is this new registry to be added to the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

or, does it belong in an existing category at http://www.iana.org/protocols?

Values to be registered will be 8-bit values ranging from 0 - 255. The new registry will be managed via Standards Action as defined by RFC 8126. There are initial values in the new registry as follows:

+---------------+-------------+---------------+
| Next Protocol | Description | Reference |
+---------------+-------------+---------------+
| 0 | Reserved | This Document |
| 1 | IPv4 | This Document |
| 2 | IPv6 | This Document |
| 3 | Ethernet | This Document |
| 4 | NSH | This Document |
| 5..255 | Unassigned | |
+---------------+-------------+---------------+

Second, a new registry is to be created called the Multiple Data-Planes Encapsulation Bitmap registry.

IANA Question --> is this new registry to be added to the Locator/ID Separation Protocol (LISP) Parameters registry page located at:

https://www.iana.org/assignments/lisp-parameters/

or, does it belong in an existing category at http://www.iana.org/protocols?

The values are a 32-bit bitmap.

Bits 0-23 are unassigned. This document assigns bit 24 (g-bit) to LISP-GPE. Bits 25-31 are assigned in RFC 8060. The new registry will be managed via Standards Action as defined by RFC 8126. There are initial values in the new registry as follows:

+----------+-------+------------------------------------+-------------+
| Bit | Bit | Assigned to | Reference |
| Position | Name | | |
+----------+-------+------------------------------------+-------------+
| 0-23 | | Unassigned | |
| 24 | g | LISP Generic Protocol Extension | |
| | | (LISP-GPE) |[ RFC-to-be ]|
| 25 | U | Generic UDP Encapsulation (GUE) | [RFC8060] |
| 26 | G | Generic Network Virtualization | [RFC8060] |
| | | Encapsulation (GENEVE) | |
| 27 | N | Network Virtualization - Generic | [RFC8060] |
| | | Routing Encapsulation (NV-GRE) | |
| 28 | v | VXLAN Generic Protocol Extension | [RFC8060] |
| | | (VXLAN-GPE) | |
| 29 | V | Virtual eXtensible Local Area | [RFC8060] |
| | | Network (VXLAN) | |
| 30 | l | Layer 2 LISP (LISP-L2) | [RFC8060] |
| 31 | L | Locator/ID Separation Protocol | [RFC8060] |
| | | (LISP) | |
+----------+-------+------------------------------------+-------------+

The IANA Functions Operator understands that these are the only actions 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
2018-08-30
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2018-08-30
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2018-08-29
05 Magnus Westerlund Request for Last Call review by TSVART Completed: Not Ready. Reviewer: Magnus Westerlund. Sent review to list.
2018-08-29
05 Magnus Westerlund Request for Last Call review by TSVART is assigned to Magnus Westerlund
2018-08-29
05 Magnus Westerlund Request for Last Call review by TSVART is assigned to Magnus Westerlund
2018-08-28
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2018-08-28
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2018-08-24
05 Stewart Bryant Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list.
2018-08-23
05 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2018-08-23
05 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2018-08-23
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-08-23
05 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-09-06):

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

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


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP Generic Protocol Extension'
  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-09-06. 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 extentions to the Locator/ID Separation
  Protocol (LISP) Data-Plane, via changes to the LISP header, to
  support multi-protocol encapsulation.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/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-23
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-08-23
05 Deborah Brungard Last call was requested
2018-08-23
05 Deborah Brungard Ballot approval text was generated
2018-08-23
05 Deborah Brungard Ballot writeup was generated
2018-08-23
05 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2018-08-23
05 Deborah Brungard Last call announcement was generated
2018-08-15
05 Fabio Maino New version available: draft-ietf-lisp-gpe-05.txt
2018-08-15
05 (System) New version approved
2018-08-15
05 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , John Lemon , Fabio Maino , Puneet Agarwal , Michael Smith
2018-08-15
05 Fabio Maino Uploaded new revision
2018-08-09
04 Adrian Farrel Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Adrian Farrel. Sent review to list.
2018-07-31
04 Min Ye Request for Last Call review by RTGDIR is assigned to Adrian Farrel
2018-07-31
04 Min Ye Request for Last Call review by RTGDIR is assigned to Adrian Farrel
2018-07-31
04 Deborah Brungard Requested Last Call review by RTGDIR
2018-07-25
04 Luigi Iannone
draft-ietf-lisp-gpe-04.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-gpe-04.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 it extents the LISP data plane
  so to support multi-protocol encapsulation. Hence, it will extend
  what is defined in draft-ietf-lisp-6830bis, which just passed WG LC as
  well and is also Standard Track.



(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 describes an extension of the LISP Header so to
  enhance the LISP data plane so to support multi-protocol encapsulation.
  The main LISP specifications allow only IPv4 or IPv6 encapsulation.
  Such feature is achieve by allocating the last remaining reserved flag as
  the "next Protocol" bit. If set the flag indicates the presence of a 8 bit next protocol field. Next Protocol code-points are listed in a new IANA LISP registry.

Working Group Summary:

  The document was first published in 2013, but because the WG was not chartered to work on multi-protocol support the document was left to expire. Things changed with the rechartering of the LISP WG, which now explicitly includes multi-protocol support. After the LISP WG concluded the bulk of the work on the bis documents, representing the basic LISP Standard Track specifications, the LISP-GPE document has been updated and the WG adopted it right away. Some technical discussion took place concerning the way LISP-GPE boxes have to interoperate with legacy LISP boxes, but the WG always showed support and willingness to move the document forward.
    The version of the document that was approved during WG Last Call is -03. 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 three independent implementations of the proposed extensions.


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



(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 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-gpe-04.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 19, 2018) is 4 days in the past.  Is this
    intentional?


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

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

    No issues found here.

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

    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 two normative references (draft-ietf-lisp-rfc6830bis and 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.

No existing RFC's status will change due to the publication
of this document.



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

The documents ask IANA to create a new registry for LISP-GPE "Next Protocol".
  These are 8-bit values, new values are assigned via Standards
  Action [RFC5226].  Initial content of the registry will be as follows:
            +---------------+-------------+---------------+
            | Next Protocol | Description | Reference    |
            +---------------+-------------+---------------+
            | 0            | Reserved    | This Document |
            | 1            | IPv4        | This Document |
            | 2            | IPv6        | This Document |
            | 3            | Ethernet    | This Document |
            | 4            | NSH        | This Document |
            | 5..255        | Unassigned  |              |
            +---------------+-------------+---------------+



(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
04 Luigi Iannone Responsible AD changed to Deborah Brungard
2018-07-25
04 Luigi Iannone IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-07-25
04 Luigi Iannone IESG state changed to Publication Requested
2018-07-25
04 Luigi Iannone IESG process started in state Publication Requested
2018-07-23
04 Luigi Iannone Changed consensus to Yes from Unknown
2018-07-23
04 Luigi Iannone Intended Status changed to Proposed Standard from None
2018-07-23
04 Luigi Iannone Changed document writeup
2018-07-19
04 Fabio Maino New version available: draft-ietf-lisp-gpe-04.txt
2018-07-19
04 (System) New version approved
2018-07-19
04 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , John Lemon , Fabio Maino , Puneet Agarwal , Michael Smith
2018-07-19
04 Fabio Maino Uploaded new revision
2018-04-25
03 Luigi Iannone Notification list changed to Luigi Iannone <ggx@gigix.net>
2018-04-25
03 Luigi Iannone Document shepherd changed to Luigi Iannone
2018-04-25
03 Luigi Iannone IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-04-05
03 Luigi Iannone WG reached consensus for LC during 101 IETF in London.
Now checking for objections as for the normal IETF procedure.
2018-04-05
03 Luigi Iannone IETF WG state changed to In WG Last Call from WG Document
2018-04-05
03 Fabio Maino New version available: draft-ietf-lisp-gpe-03.txt
2018-04-05
03 (System) New version approved
2018-04-05
03 (System) Request for posting confirmation emailed to previous authors: Darrel Lewis , John Lemon , Fabio Maino , Puneet Agarwal , Michael Smith
2018-04-05
03 Fabio Maino Uploaded new revision
2018-03-30
02 Fabio Maino New version available: draft-ietf-lisp-gpe-02.txt
2018-03-30
02 (System) New version approved
2018-03-30
02 (System)
Request for posting confirmation emailed to previous authors: Paul Quinn , lisp-chairs@ietf.org, Puneet Agarwal , Navindra Yadav , Darrel Lewis , John Lemon , …
Request for posting confirmation emailed to previous authors: Paul Quinn , lisp-chairs@ietf.org, Puneet Agarwal , Navindra Yadav , Darrel Lewis , John Lemon , Fabio Maino , Michael Smith , Larry Kreeger
2018-03-30
02 Fabio Maino Uploaded new revision
2018-03-05
01 Fabio Maino New version available: draft-ietf-lisp-gpe-01.txt
2018-03-05
01 (System) New version approved
2018-03-05
01 (System)
Request for posting confirmation emailed to previous authors: lisp-chairs@ietf.org, Puneet Agarwal , Navindra Yadav , Darrel Lewis , Paul Quinn , John Lemon , …
Request for posting confirmation emailed to previous authors: lisp-chairs@ietf.org, Puneet Agarwal , Navindra Yadav , Darrel Lewis , Paul Quinn , John Lemon , Fabio Maino , Michael Smith , Larry Kreeger
2018-03-05
01 Fabio Maino Uploaded new revision
2018-01-24
00 Joel Halpern This document now replaces draft-lewis-lisp-gpe instead of None
2018-01-24
00 Fabio Maino New version available: draft-ietf-lisp-gpe-00.txt
2018-01-24
00 (System) WG -00 approved
2018-01-24
00 Fabio Maino Set submitter to "Fabio Maino ", replaces to draft-lewis-lisp-gpe and sent approval email to group chairs: lisp-chairs@ietf.org
2018-01-24
00 Fabio Maino Uploaded new revision