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

[Alberto Rodriguez-Natal <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>