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 < [email protected]> 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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
