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

Fabio Maino <fmaino@cisco.com> Fri, 28 September 2018 21:30 UTC

Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0E012872C; Fri, 28 Sep 2018 14:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m25cJajdR8ut; Fri, 28 Sep 2018 14:30:34 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13C7127148; Fri, 28 Sep 2018 14:30:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 21:30:32 +0000
Received: from [10.32.173.55] ([10.32.173.55]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTP id w8SLUVxr002730; Fri, 28 Sep 2018 21:30:32 GMT
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-lisp-gpe@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, lisp@ietf.org
References: <153789926133.5101.18151906676525764346.idtracker@ietfa.amsl.com>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <3301d278-0ded-9073-9f63-dc426356f1c8@cisco.com>
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: <153789926133.5101.18151906676525764346.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.32.173.55, [10.32.173.55]
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/e3219FwLf3kYJeTvWkXcxNVkjek>
Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=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 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.

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.


Thanks,

Fabio