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

Fabio Maino <> Fri, 28 September 2018 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE0E012872C; Fri, 28 Sep 2018 14:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m25cJajdR8ut; Fri, 28 Sep 2018 14:30:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F13C7127148; Fri, 28 Sep 2018 14:30:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2724; q=dns/txt; s=iport; t=1538170234; x=1539379834; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YNPLbhr9xCcISvL4lsv8gRpzaOiRHKEpBgzi1HKGqNk=; b=iCUJ4tG0UdpQzE9w3slbBoC/MR9LFCA91DgySTkojSe9BjvflcRasq36 xwBmxE1cytRH+aw/tm4EhulSOyrts/LmAluPPXYutGHExjhIX/QZHVjo4 5vxTKLcmPlBH+zdZ0FmnNeO/oXUWHEVyclSBqJpEXsOzZjHxDL+IYb2gC 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAAA/na5b/5FdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVIILZn8og3SURoFgCCWWaoFmCyOESQKDeyE3FQEDAQE?= =?us-ascii?q?CAQECbRwMhTkBBSMPAQVBEAsOCgICJgICVwYBDAgBAYMdAYIBD6RWgS6EMwc?= =?us-ascii?q?9hREFgQuJcxeBQT+BEicMgl+DGwIBAgGBKgESAYMgglcCiEyGLI4lCYZDiWc?= =?us-ascii?q?GF4FHhFqCY4N1gk+MBokdgVgiZFgRCDMaCBsVgyeLFoVeHzABiwoGCReCJwE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.54,316,1534809600"; d="scan'208";a="178278499"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 21:30:32 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTP id w8SLUVxr002730; Fri, 28 Sep 2018 21:30:32 GMT
To: Alvaro Retana <>, The IESG <>
Cc:, Luigi Iannone <>,,
References: <>
From: Fabio Maino <>
Message-ID: <>
Date: Fri, 28 Sep 2018 14:30:31 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Sep 2018 21:30:36 -0000

Thanks for  your comments Alvaro. Please see below.

On 9/25/18 11:14 AM, Alvaro Retana wrote:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.

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

> (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.
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
> the P and V bits set.

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

> (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.
ok. will fix in -07

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