Subject: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Jul 2020 21:52:50 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

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