Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Tue, 25 Sep 2018 11:14:21 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-lisp-gpe-06: 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:
----------------------------------------------------------------------

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.

---

From: Fabio Maino <[email-masked]>
Date: Fri, 28 Sep 2018 14:30:31 -0700

Thanks for  your comments Alvaro. Please see below.

> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

ok. I'll fix in -07 with s/MAY/can/.

> for the Nonce/Map-Version field. IOW, it sounds as if the bit makes the header
ok. I'll fix in -07 with s/conform/is bit-by-bit equivalent/

> (3) §3: For clarity, it would be nice to add a figure showing the header with

A similar comment was raised by another reviewer. It was decided that 
this document will use the same convention of 6830bis (that doesn't have 
a figure with the V bit set).

> the "SHOULD" is not normative.
ok. will fix in -07

> are operational considerations or guidance that are worth mentioning.
I can't think of a strong reason why one would be better than the other, 
and I see no harm in allowing both behaviors. I'd leave the choice to 
the implementors.

Thanks,

Fabio