Locator/ID Separation Protocol (LISP) Generic Protocol Extension
draft-ietf-lisp-gpe-19

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

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

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

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

[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)

[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

[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/

[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

(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

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

(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

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)

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.

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

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