[lisp] Review draft-ietf-lisp-vendor-lcaf
Luigi Iannone <ggx@gigix.net> Sun, 18 March 2018 16:35 UTC
Return-Path: <ggx@gigix.net>
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 4AD9B127275 for <lisp@ietfa.amsl.com>; Sun, 18 Mar 2018 09:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=gigix-net.20150623.gappssmtp.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 wsEjOpA1nMme for <lisp@ietfa.amsl.com>; Sun, 18 Mar 2018 09:35:29 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 57E6B126C25 for <lisp@ietf.org>; Sun, 18 Mar 2018 09:35:29 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id n12so16245459wra.2 for <lisp@ietf.org>; Sun, 18 Mar 2018 09:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=sznfjrMKLaVgHfP+7mGutChrw7/eoxb9mdz31/tI+Pk=; b=pQkqQs6d386ZHLVmU+rShOxDcXxXdbBxJCI1Tg7vMfuTfUog6Ydv1nnW4UZEUSd50r dwYlvltOTBuFot51g4ZZ/ZssLyAF13ecg7PAf5CRHWz3SXLFMe0vxkP0ajAF2/5ToCAO 2lAdL9SOzc6/uPDFDa5wh8ywjcYqhhCw7uii6xsdaTCNvE6BIr+h7jYg+EpL5mUrSx2t TCG/rhbuuymvvbckSQ8cwRE9nkSoogs20twsqL4m/oHIF/K5zQae/+gpn/ll6DVqwGeg ShFbrlaGB3pOWjBqRZPBp1NQ199ui1b5UKwTHB35vTHOJPg17sdW3Wpdf9YrZKOW+Hql onvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=sznfjrMKLaVgHfP+7mGutChrw7/eoxb9mdz31/tI+Pk=; b=KTsST5oydVKv8cbOJVWysHfA/LIV/lA0L6WFynPiQwig5J0+FvAJA2BwuRfIMhl/ef 1nAlccJdMGmkIvGl8mOaOhfWNKKmqYYwQJtVRwQrLROyMY6CMzlKj7LZ/2gOJNRLDWjK Xwb3pWfnpukJLfSgqZwAR6wGuO/vZpxe/XoNnxiuyg3ktzmkUHtuHYTl4qWvAoR/Mfa8 96scNpD2K/Er8yrNxMPneO9bhATpbIXylb2XLcq0Kw9o65SLEyu59PurZ7fymm8aWUSG JhH/S4UCkc45S384gSH/x6llBy89hDZJRm3me8IJAghmJdEaP53Fw8IQshHgi9MHho3c 326w==
X-Gm-Message-State: AElRT7GliUJA8E6qK5codFD5agoJjRBa8JAtI3zj4ULObI1I5+8VIdl0 NchwGubSOrXexV5ocmxBheA6J/AS5R8=
X-Google-Smtp-Source: AG47ELs8jSthhchqi7CaNSZPuOtHuKgc/B9XtDD4wt4lwwQWwosqMgH0+Z0dpwguuAynj+FvQ+0Mrg==
X-Received: by 10.223.198.199 with SMTP id c7mr707625wrh.125.1521390927366; Sun, 18 Mar 2018 09:35:27 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:a531:7ab:91a1:6942? ([2001:67c:1232:144:a531:7ab:91a1:6942]) by smtp.gmail.com with ESMTPSA id v5sm8172327wrf.41.2018.03.18.09.35.25 for <lisp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 09:35:25 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1D845A1F-B92E-4D3A-BFA7-F166241E99E5"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <650BB047-3B72-4C20-9FE1-9C11BC54FCDA@gigix.net>
Date: Sun, 18 Mar 2018 16:35:24 +0000
To: "lisp@ietf.org list" <lisp@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/Qb0QqVUjF4iZynbf8DDQeFr4GjI>
Subject: [lisp] Review draft-ietf-lisp-vendor-lcaf
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 18 Mar 2018 16:35:34 -0000
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.
- Re: [lisp] Review draft-ietf-lisp-vendor-lcaf Alberto Rodriguez-Natal
- [lisp] Review draft-ietf-lisp-vendor-lcaf Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-vendor-lcaf Alberto Rodriguez-Natal