Skip to main content

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

Discuss


Yes

(Deborah Brungard)

No Objection

Erik Kline
(Alissa Cooper)
(Barry Leiba)
(Ignas Bagdonas)
(Martin Vigoureux)
(Terry Manderson)

Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana
No Objection
Comment (2018-09-25 for -06)
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.
Erik Kline
No Objection
Martin Duke
No Objection
Comment (2020-07-06 for -16)
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
Murray Kucherawy
No Objection
Comment (2020-07-05 for -16)
In Section 4.2, the "(TMCE)"s seem out of place.
Robert Wilton
No Objection
Comment (2020-07-07 for -16)
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
Roman Danyliw
No Objection
Comment (2020-07-08 for -17)
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)
Warren Kumari
No Objection
Comment (2018-09-23 for -06)
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.
Éric Vyncke
No Objection
Comment (2020-07-07 for -16)
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/
Mirja Kühlewind Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2018-09-19 for -05)
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...?
Deborah Brungard Former IESG member
Yes
Yes (for -05)

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2018-09-25 for -06)
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?
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (for -14)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -17)

                            
Benjamin Kaduk Former IESG member
(was Abstain, Discuss) No Objection
No Objection (2020-07-08 for -17)
   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).
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -06)

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2020-07-09 for -17)
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.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06)

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (2018-09-27 for -06)
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.
Terry Manderson Former IESG member
No Objection
No Objection (for -06)