Re: [lisp] Please Review 6830bis and 6833bis

Dino Farinacci <farinacci@gmail.com> Mon, 13 March 2017 18:16 UTC

Return-Path: <farinacci@gmail.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 C04341299AF; Mon, 13 Mar 2017 11:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yjJ0rAFGN7gQ; Mon, 13 Mar 2017 11:16:19 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3507F1299BD; Mon, 13 Mar 2017 11:16:19 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id f84so14137552ioj.0; Mon, 13 Mar 2017 11:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qftGu8UveRyLxcShNwJm5J/h6YNV9iHGtb6CNTSfD14=; b=VMplODTL6D4dlic1VTIFpOZPozTCqIxT2hG5P2ztWOmwUXYF0Wy3tDv8n0Zh5QzTOj BLcgukL6L7mJjo23eHy83bsMQq6juf/mUAOmrGMFE6RXDXZzF+t5hV7AOTpoY9lqhLjp kRUupU2LxLPgzB1op1KpGkJAFMJvpl7WDKe3D3qbTSSOiXrVW+nVsoH1s5kWmfDCIz7b 2FGiqW17GbLlPiYog/H/8qbKixQECEc46rwBAM6RdDUvKQUvK08v5gtlqFFbcSXVjuWY tmJtQn0A/k+SRhSzpT+mi5HurkzesXyxhpRTK8eOSEsb41oJmJdTTq7iSIvq8BO11ovu m+9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qftGu8UveRyLxcShNwJm5J/h6YNV9iHGtb6CNTSfD14=; b=GBaKk1yNZZhxSkramR5N4NQnpToespn/Fqk4ywcl90Tj/IcP/JPStCDIQ9x1FXAH6u 9RQt7hBdeiVJq2KHtWuDQyPt7yfJPzBz3HEHvT//asqVMEaMGnzCM3eYTYeOeZ/LJ1tb Sqtqtz9eBXzCHa4N3LlszmlLgsqRmMS7t5uP0lVXilbcGvd556eVbaUleyd9/cBzQZmk 6L0s6+R3v8rKf/O22SVu7kMJLEwOdaLDFLHQID6VufD8H/WqEMEav4l8GHCEnMcdqQcF QP0HhdrAO45gH2Y3/Ns2rG4jUQ1SYMs1SZbT1L2KsSPnAD5a8jj///dHT7Uu/K8buYpD WCRQ==
X-Gm-Message-State: AMke39mCCxw7oZdIhW8mWScZ8TstoXEfaBpPKCRd4ib6wNnrIBSPiuyu/oT1rowrjuPNrg==
X-Received: by 10.107.5.137 with SMTP id 131mr31568255iof.87.1489428978525; Mon, 13 Mar 2017 11:16:18 -0700 (PDT)
Received: from [172.19.131.157] ([12.130.117.40]) by smtp.gmail.com with ESMTPSA id d42sm5399034ioj.61.2017.03.13.11.16.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:16:18 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <3BFC5564-5D8A-4023-B228-27CB2658F925@gmail.com>
Date: Mon, 13 Mar 2017 11:16:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B0A9934-0D5C-45BE-B198-B09BC4FBB66A@gmail.com>
References: <993CF58D-1A15-4D9D-B5AA-B281E55985DC@gigix.net> <3BFC5564-5D8A-4023-B228-27CB2658F925@gmail.com>
To: Luigi Iannone <ggx@gigix.net>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/06JCuzP04R9cIJTowiXzD6QWv18>
Cc: lisp-chairs@ietf.org, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Please Review 6830bis and 6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Mar 2017 18:16:21 -0000

Joel had some comments. We agreed (he as a participant) to the following text:

———

ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
   other message type, these bits are set to 0 and ignored on
   receipt.  These bits are used only when the 'Locator Count' field
   is set to 0.  The action bits are encoded only in Map-Reply
   messages.  The actions defined are used by an ITR or PITR when a
   destination EID matches a negative Map-Cache entry.  Unassigned
   values should cause a Map-Cache entry to be created, and when
   packets match this negative cache entry, they will be dropped.
   The current assigned values are:

   (0) No-Action:  The map-cache is kept alive, and no packet
       encapsulation occurs.

   (1) Natively-Forward:  The packet is not encapsulated or dropped
       but natively forwarded.

   (2) Send-Map-Request:  The packet invokes sending a Map-Request.

   (3) Drop/No-Reason:  A packet that matches this map-cache entry is dropped.
       An ICMP Destination Unreachable message SHOULD be sent.

   (4) Drop/Policy-Denied: A packet that matches this map-cache entry is dropped.
       The reason for the Drop action is that a Map-Request for the target-EID is
       being policy denied by either an xTR or the mapping system.

   (5) Drop/Authentication-Failure: A packet that matches this map-cache entry is dropped.
       The reason for the Drop action is that a Map-Request for the target-EID fails
       an authentication verification-check by either an xTR or the mapping system.

———

Note the changes where “Drop” -> “Drop/No-Reason” and the addition of (4) and (5).

Thanks,
Dino

> On Mar 12, 2017, at 5:32 AM, Dino Farinacci <farinacci@gmail.com> wrote:
> 
>> Please review the document and send feedback to the mailing list or come to the mic in the next meeting (which is just 2 weeks away).
> 
> Since we have the opportunity to make minor changes, I would like to ask the working group about Map-Reply Action Values. Currently the spec says this:
> 
> ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
>      other message type, these bits are set to 0 and ignored on
>      receipt.  These bits are used only when the 'Locator Count' field
>      is set to 0.  The action bits are encoded only in Map-Reply
>      messages.  The actions defined are used by an ITR or PITR when a
>      destination EID matches a negative Map-Cache entry.  Unassigned
>      values should cause a Map-Cache entry to be created, and when
>      packets match this negative cache entry, they will be dropped.
>      The current assigned values are:
> 
>      (0) No-Action:  The map-cache is kept alive, and no packet
>          encapsulation occurs.
> 
>      (1) Natively-Forward:  The packet is not encapsulated or dropped
>          but natively forwarded.
> 
>      (2) Send-Map-Request:  The packet invokes sending a Map-Request.
> 
>      (3) Drop:  A packet that matches this map-cache entry is dropped.
>          An ICMP Destination Unreachable message SHOULD be sent.
> 
> I would like to propose we add these:
> 
>      (4) Policy-Denied: The Map-Request for the target-id is being policy 
>          denied and the Map-Reply with this action value contains an empty 
>          RLOC-set.
> 
>      (5) Authentication-Failure: The Map-Request for the target-id fails an 
>          authentication check so the Map-Reply contains an empty RLOC-set.
> 
> Please let me know what you think.
> 
> Thanks,
> Dino