Internet DRAFT - draft-andersson-mpls-lsp-ping-upd

draft-andersson-mpls-lsp-ping-upd







Network Working Group                                       L. Andersson
Internet-Draft                                                    Huawei
Updates: 4379 (if approved)                                July 15, 2013
Intended status: Standards Track
Expires: January 16, 2014


                    Updates to RFC 4379 IANA section
                  draft-andersson-mpls-lsp-ping-upd-00

Abstract

   The MultiProtocol Label Switching (MPLS) protcol for detecting Label
   Switched Path failures (LSP Ping), as defined in RFC 4379 and several
   extensions, are widely deployed and very popular.

   The IANA sectiion of RFC4379 lack in clarity and need to be updated.

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 RFC 2119 [RFC2119].

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 http://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 January 16, 2014.

Copyright Notice

   Copyright (c) 2013 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



Andersson               Expires January 16, 2014                [Page 1]

Internet-Draft        LSP Ping IANA section Updates            July 2013


   (http://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Update of the RCF 4379 IANA section . . . . . . . . . . . . .   2
     2.1.  Error codes for unrecognized TLV and sub-TLV types  . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   3
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   This document updates the IANA section of RFC 4379 [RFC4379] for LSP
   Ping Parameters.

2.  Update of the RCF 4379 IANA section

   The first 3 paragraphs of sub-section 7.2.  "TLVs" in the IANA
   section of RFC 4379 is considered unclear and is therefore now
   replaced by the following text:

   The IANA has created and will maintain a registry for the Type field
   of top-level TLVs and per-TLV registries for any TLVs which have
   associated sub-TLVs.  Note the meaning of a sub-TLV is scoped by the
   TLV.  The number spaces for the sub-TLVs of various TLVs are
   independent.

   However, it is under some conditions allowable for a new TLV to re-
   use sub-TLVs of another TLV.  In this case where all sub-TLVs are re-
   used and no unique sub-TLVs are defined for the TLV re-uses the sub-
   TLVs no actual sub-TLV registry is created for the new TLV.  Rather
   an entry is made where the registry would have appeared with a note
   saying "Uses the sub-TLVs registered under TLV x", where x is the
   other TLV.  Note that the implication here is that all future sub-
   TLVs of the other TLV apply, as well as those currently defined.

   The valid range for TLV registry is 0-65535 and this is also default
   for each of the sub-TLV registries.  For all these registries,
   assignments in the range 0-16383 and 32768-49161 are made via



Andersson               Expires January 16, 2014                [Page 2]

Internet-Draft        LSP Ping IANA section Updates            July 2013


   Standards Action as defined in [IANA]; assignments in the range
   16384-31743 and 49162-64511 are made via "Specification Required" as
   defined above; values in the range 31744-32767 and 64512-65535 are
   for Vendor Private Use, and MUST NOT be allocated.

   However, a new TLV type might specify the allocation policies for its
   own sub-TLVs.

2.1.  Error codes for unrecognized TLV and sub-TLV types

   For TLV and sub-TLV types that uses the default allocation ranges
   defined above the rules for when error messages defined below
   applies.  TLVs that defines there own sub-TLV ranges, does also need
   to define their own rules for when error messages are returned.

   TLV and sub-TLV types less than 32768 (i.e., with the high-order bit
   equal to 0) are mandatory TLVs that MUST either be supported by an
   implementation or result in the return code of 2 ("One or more of the
   TLVs was not understood") being sent in the echo response.

   TLV and sub-TLV types greater than or equal to 32768 (i.e., with the
   high-order bit equal to 1) are optional TLVs that SHOULD be ignored
   if the implementation does not understand or support them.

   If a TLV or sub-TLV has a Type that falls in the range for Vendor
   Private Use, the Length MUST be at least 4, and the first four octets
   MUST be that vendor's SMI Private Enterprise Number, in network octet
   order.  The rest of the Value field is private to the vendor.

3.  IANA Considerations

   There are no requests for IANA actions in this document.

4.  Security Considerations

   This document is about updating the IANA section of RFC 4379 and does
   not add any new security issues as compared to the the original RFC
   4379.

5.  Acknowledgements

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.






Andersson               Expires January 16, 2014                [Page 3]

Internet-Draft        LSP Ping IANA section Updates            July 2013


   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

Author's Address

   Loa Andersson
   Huawei

   Email: loa@mail01.huawei.com









































Andersson               Expires January 16, 2014                [Page 4]