Re: [lisp] Review draft-ietf-lisp-vendor-lcaf

Alberto Rodriguez-Natal <rodrigueznatal@gmail.com> Tue, 03 July 2018 19:00 UTC

Return-Path: <rodrigueznatal@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 4E747130DEA for <lisp@ietfa.amsl.com>; Tue, 3 Jul 2018 12:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 cfGq7uhhaIh2 for <lisp@ietfa.amsl.com>; Tue, 3 Jul 2018 11:59:57 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 128F0130DD8 for <lisp@ietf.org>; Tue, 3 Jul 2018 11:59:57 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id u202-v6so2443649lff.9 for <lisp@ietf.org>; Tue, 03 Jul 2018 11:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JlKdRoKaDa6I/sEMy+HTRoFQ6XkCNpKYMyphcGLSaGs=; b=hbc4HcRMMOgOBwAFjWUz673OeiF7r9zoYdkvfGVfb7G+wlWscUr7FR8MShjO4O7tjQ e3EJk5DjXBMjNDYJc3r787DXL5NQTLw8Odu4HvZKRCWNWHGKmY2qwsdrQ6O5jTWrGHNz 1fTL9HMx9zKLTk+++8GSYz3f7kSPPBRTI9im9jKX5ZI/kTcCFKCEELKU6oUAN8oX6x45 uiTaZSpYDJ4OaSJtfTnuVlcsb+3K2S40cFQigorr0b9/2gCvpNwJgNnKsFDneo9aoiGF e/GqovpKy8AlCQqb25LoD0XwM6deXcl1nOZoKY8MI2uXG1SdWNlzPkOvBVzu48Ci73a2 nKYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JlKdRoKaDa6I/sEMy+HTRoFQ6XkCNpKYMyphcGLSaGs=; b=nxnvyq31O/EYrm7EzZoNmqI0jeW4Q14dLzT7RlmoAe+Yt2/LyjRJEgEPj/5hABFRYp JBnHLOVN66NaYZ45U/o3wbMrOU+e/UaD13KpA1flek5IIZZznmRnDkdA3uD/PYx3qT53 N3VcM95OAek2i14cGj5sASzPw4KWSeTcKPHm31wAz6KOp01WIaJYEMfRr4xDmytX1lVi PjquFuZQgBzyuPlNFQh21ou0JdYq2ZrbTPbSTPgY3HKzap6i00n3akeSymuKdoir15mL G2iGOcs4TnxKjWD3D1jYoYMdlMlGvEzLzNOS+yN5bi6Nja+wHJM8ChhNJMvSRD8plKa2 Ul3w==
X-Gm-Message-State: APt69E2L8DIc0ibxVDdxorADEhatXOCgQWmhbMuRgBfI9yZpmik1cu5V 65C+q2LNQmaPUSdFj8FZQdUEeb0wHI0ayLaVFNA8qVoW
X-Google-Smtp-Source: AAOMgpekLjHViXbrRH5NdmmaXVNsC18FF2pdvkiCwHh58EpsAcu/DfdwMyegsIozZFfgIq8vHR4EWSmqKt1paoBCUHM=
X-Received: by 2002:a19:d890:: with SMTP id r16-v6mr13250010lfi.7.1530644395170; Tue, 03 Jul 2018 11:59:55 -0700 (PDT)
MIME-Version: 1.0
References: <650BB047-3B72-4C20-9FE1-9C11BC54FCDA@gigix.net> <CA+YHcKG8fo-7dLjM9BMPpsB__yjFXmfGgfHG_FXajSojEBR+Cw@mail.gmail.com>
In-Reply-To: <CA+YHcKG8fo-7dLjM9BMPpsB__yjFXmfGgfHG_FXajSojEBR+Cw@mail.gmail.com>
From: Alberto Rodriguez-Natal <rodrigueznatal@gmail.com>
Date: Tue, 3 Jul 2018 11:59:43 -0700
Message-ID: <CA+YHcKH4JEJ5QzoeVZN-di5o8dE5HWs9zSUi8h9GKOG71=pT9w@mail.gmail.com>
To: Luigi Iannone <ggx@gigix.net>
Cc: "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073a13f05701ceb66"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/lprjcxX8fxoZWRa4MfF0hijFf_A>
Subject: Re: [lisp] Review draft-ietf-lisp-vendor-lcaf
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 19:00:02 -0000

Hi all,

After a long delay we have finally pushed an updated version of the Vendor
Specific LCAF [1] addressing the editorial comments from Luigi. There was
rough consensus in London about moving this to last call.

Luigi/Joel, let me know if we can move forward with this one or if anything
else is needed on our end.

Thanks!
Alberto

[1] https://tools.ietf.org/html/draft-ietf-lisp-vendor-lcaf-02


On Sun, Mar 18, 2018 at 11:38 AM Alberto Rodriguez-Natal <
rodrigueznatal@gmail.com> wrote:

> Thanks for the review Luigi. All the proposed changes look good. We'll
> update the draft to reflect them.
>
> Thanks!
> Alberto
>
> On Sun, Mar 18, 2018 at 4:35 PM, Luigi Iannone <ggx@gigix.net> wrote:
> >
> > Hi All,
> > I did a quick review of the short vendor LCAF document.
> > My few comment are inline.
> >
> > Ciao
> >
> > L.
> >
> >
> >
> >
> >
> >
> >
> >
> > LISP Working Group                                    A. Rodriguez-Natal
> > Internet-Draft                                                V. Ermagan
> > Intended status: Experimental                                 A. Smirnov
> > Expires: August 20, 2018                                   V. Ashtaputre
> >                                                            Cisco Systems
> >                                                             D. Farinacci
> >                                                              lispers.net
> >                                                               2 16, 2018
> >
> >
> >                           Vendor Specific LCAF
> >                      draft-ietf-lisp-vendor-lcaf-01
> >
> > Abstract
> >
> >    This document describes a new LCAF for LISP, the Vendor Specific
> >
> > I would but in both the title and the first sentence of the abstract the
> > long version of the LCAF acronym:
> > “LISP Canonical Address Format (LCAF)"
> >
> >
> >    LCAF.  This LCAF enables organizations to have internal encodings for
> >    LCAF addresses.
> >
> > Status of This Memo
> >
> >    This Internet-Draft is submitted in full conformance with the
> >    provisions of BCP 78 and BCP 79.
> >
> >    Internet-Drafts are working documents of the Internet Engineering
> >    Task Force (IETF).  Note that other groups may also distribute
> >    working documents as Internet-Drafts.  The list of current Internet-
> >    Drafts is at https://datatracker.ietf.org/drafts/current/.
> >
> >    Internet-Drafts are draft documents valid for a maximum of six months
> >    and may be updated, replaced, or obsoleted by other documents at any
> >    time.  It is inappropriate to use Internet-Drafts as reference
> >    material or to cite them other than as "work in progress."
> >
> >    This Internet-Draft will expire on August 20, 2018.
> >
> > Copyright Notice
> >
> >    Copyright (c) 2018 IETF Trust and the persons identified as the
> >    document authors.  All rights reserved.
> >
> >    This document is subject to BCP 78 and the IETF Trust's Legal
> >    Provisions Relating to IETF Documents
> >    (https://trustee.ietf.org/license-info) in effect on the date of
> >    publication of this document.  Please review these documents
> >    carefully, as they describe your rights and restrictions with respect
> >    to this document.  Code Components extracted from this document must
> >    include Simplified BSD License text as described in Section 4.e of
> >
> >
> >
> > Rodriguez-Natal, et al.  Expires August 20, 2018                [Page 1]
> >
> > Internet-Draft              LISP-Vendor-LCAF                      2 2018
> >
> >
> >    the Trust Legal Provisions and are provided without warranty as
> >    described in the Simplified BSD License.
> >
> > Table of Contents
> >
> >    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
> >    2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
> >    3.  Vendor Specific LCAF  . . . . . . . . . . . . . . . . . . . .   2
> >    4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
> >    5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   3
> >    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
> >    7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
> >    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4
> >
> > 1.  Introduction
> >
> >    The LISP Canonical Address Format
> >
> > add: “(LCAF)"
> >
> > [RFC8060] defines the format and
> >    encoding for different address types that can be used on LISP
> >    [RFC6830]
> >
> > I would put 6830bis and 6833bis as reference since they are standard
> track.
> >
> > deployments.  However, certain deployments require specific
> >    format encodings that may not be applicable outside of the use-case
> >    for which they are defined.  The Vendor Specific LCAF allows
> >    organizations to create LCAF addresses to be used only internally on
> >    particular LISP deployments.
> >
> > 2.  Requirements Language
> >
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> >    document are to be interpreted as described in [RFC2119]
> >
> > 3.  Vendor Specific LCAF
> >
> >    The Vendor Specific LCAF relies on using the IEEE Organizationally
> >    Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across
> >    vendors or organizations using the LCAF.  The format of the Vendor
> >    Specific LCAF is provided below.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Rodriguez-Natal, et al.  Expires August 20, 2018                [Page 2]
> >
> > Internet-Draft              LISP-Vendor-LCAF                      2 2018
> >
> >
> >      0                   1                   2                   3
> >      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |           AFI = 16387         |     Rsvd1     |     Flags     |
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |   Type = 255  |     Rsvd2     |            Length             |
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |      Rsvd3    |    Organizationally Unique Identifier (OUI)   |
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                        Internal format...                     |
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                            Vendor Specific LCAF
> >
> >    The Vendor Specific LCAF has the following fields.
> >
> >       Rsvd3: This 8-bit field is reserved for future use.  It MUST be
> >       set to 0 on transmit and MUST be ignored on receipt.
> >
> >       Organizationally Unique Identifier (OUI): This is a 24-bit field
> >       that carries the IEEE OUI [IEEE.802_2001] of the organization.
> >
> >       Internal format: This is a variable length field that is left
> >       undefined on purpose.  Each vendor or organization can define its
> >       own internal format(s) to use with the Vendor Specific LCAF.
> >
> >    The definition for the rest of the fields can be found in [RFC8060].
> >
> >    The Vendor Specific LCAF type SHOULD not be used in deployments where
> >    different organizations interoperate.  If a LISP device receives a
> >    LISP message containing a Vendor Specific LCAF with an OUI that it
> >    does not understand, it SHOULD drop the message and a log action MUST
> >    be taken.
> >
> > 4.  Security Considerations
> >
> >    This document enables organizations to define new LCAFs for their
> >    internal use.  It is the responsibility of these organizations to
> >    properly assess the security implications of the formats they define.
> >
> > 5.  Acknowledgments
> >
> >    The authors would like to thank Joel Halpern for his suggestions and
> >    comments regarding this document.
> >
> >
> >
> >
> >
> >
> >
> > Rodriguez-Natal, et al.  Expires August 20, 2018                [Page 3]
> >
> > Internet-Draft              LISP-Vendor-LCAF                      2 2018
> >
> >
> > 6.  IANA Considerations
> >
> >    Following the guidelines of [RFC5226],
> >
> > RFC5226 is obsoleted by RFC 8126, this should be updated
> >
> > that’s all :-)
> >
> > L.
> >
> >
> >
> >
> > _______________________________________________
> > lisp mailing list
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
> >
>