TRILL Working Group                                      Donald
Internet Engineering Task Force (IETF)                   D. Eastlake
INTERNET-DRAFT 3rd
Request for Comments: 7179                                        Huawei
Intended status: Proposed Standard                        Anoop Ghanwani
Updates: 6325                                                A. Ghanwani
Category: Standards Track                                           Dell
                                                          Vishwas
ISSN: 2070-1721                                                V. Manral
                                                                      HP
                                                               Yizhou
                                                             Ionos Corp.
                                                                   Y. Li
                                                                  Huawei
                                                         Caitlin
                                                              C. Bestler
                                                                 Quantum
Expires: December 19, 2012                                 June 20, 2012

                        TRILL:
                                                         Nexenta Systems
                                                              April 2014

 Transparent Interconnection of Lots of Links (TRILL): Header Extension
              <draft-ietf-trill-rbridge-extension-05.txt>

Abstract

   The IETF TRILL (Transparent Transparent Interconnection of Lots of Links) Links (TRILL) base
   protocol (RFC 6325) specifies minimal hooks to safely support TRILL
   Header extensions.  This document specifies an initial extension
   providing additional flag bits and specifies some of those bits.  It
   updates RFC 6325.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this an Internet Standards Track document.

   This document is unlimited. Comments should be sent
   to the TRILL working group mailing list <rbridge@postel.org>.

   Internet-Drafts are working documents a product of the Internet Engineering Task Force (IETF), its areas,
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It
   http://www.rfc-editor.org/info/rfc7179.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is inappropriate subject to use Internet-Drafts BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as reference
   material or they describe your rights and restrictions with respect
   to cite them other than this document.  Code Components extracted from this document must
   include Simplified BSD License text as "work described in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html. The list Section 4.e of Internet-Draft
   Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

INTERNET-DRAFT                                   TRILL: Header Extension
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction............................................3
      1.1 Introduction ....................................................2
      1.1. Conventions used Used in this document......................3 This Document ..........................3
   2. TRILL Header Extensions.................................4
      2.1 Extensions .........................................3
      2.1. RBridge Extended Flag Handling Requirements............5
      2.2 Requirements ................4
      2.2. No Critical Surprises..................................5
      2.3 Surprises ......................................5
      2.3. Extended Header Flags..................................6
      2.3.1 Flags ......................................5
           2.3.1. Critical Summary Bits................................7
      2.4 Bits ...............................6
      2.4. Conflict of Extensions.................................8 Extensions .....................................7
   3. Specific Extended Header Flags..........................9
      3.1 The Flags ..................................8
      3.1. RBridge Channel Alert Extended Flags...............9 Flags .......................8
   4. Additions to IS-IS.....................................10 IS-IS ..............................................9
   5. IANA Considerations....................................10 Considerations .............................................9
   6. Security Considerations................................11 Considerations .........................................9
   7. Acknowledgements.......................................11 Acknowledgements ...............................................10
   8. References .....................................................10
      8.1. Normative References...................................12
      9. References ......................................10
      8.2. Informative References.................................12

      Change History............................................13

INTERNET-DRAFT                                   TRILL: Header Extension References ....................................10

1.  Introduction

   The base IETF TRILL (Transparent Transparent Interconnection of Lots of Links) Links (TRILL)
   protocol [RFC6325] [RFC6326bis] provides a TRILL Header extension feature and
   describes minimal hooks to safely support header
   extension. extensions.  (This
   feature is called "options" in Section 3.8 of [RFC6325].)  But,
   except for the first two bits, the TRILL base protocol document does
   not specify the structure of extensions to the TRILL Header nor the
   details of any particular extension.

   This document is consistent with [RFC6325] and provides further
   details.  It specifies an initial extension word providing additional
   flag bits and specifies some of those bits.  Additional extensions,
   including TLV (Type, Length, Value) encoded TLV-encoded options, may be specified in later documents,
   for example [Options]. example, [Options] and [Options2].

   Section 2 below describes some general principles of TRILL header Header
   extensions and an initial extension.  Section 3 specifies a pair of
   flags in this initial extension.

1.1

1.1.  Conventions used Used in this document This Document

   The terminology and acronyms defined in [RFC6325] are used herein
   with the same meaning.  Devices implementing the TRILL protocol are
   referred to as RBridges (Routing Bridges) or TRILL Switches.

   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].

INTERNET-DRAFT                                   TRILL: Header Extension

2.  TRILL Header Extensions

   The base TRILL Protocol protocol includes a feature for extension of the TRILL
   Header (see [RFC6325] [RFC6325], Sections 3.5 and 3.8).  The 5-bit Op-Length
   header field gives the length of the extensions to the TRILL Header
   in units of 4 octets, which allows up to 124 octets of header
   extension.  If Op-Length is zero zero, there are no header extensions
   present; else, the extension area follows immediately after the
   Ingress RBridge (Routing Bridge) Nickname field of the TRILL Header.  The first 32-bit
   word of the optional extensions area consists of an extended flags
   area and critical summary bits as specified in this document.

   As described below, provision is made for

   o  hop-by-hop flags, which might affect any RBridge that receives a
      TRILL Data frame with such a flag set,

   o  ingress-to-egress flags, which would only necessarily affect the
      RBridge(s) where a TRILL frame is decapsulated,

   o  flags affecting an as yet unspecified as-yet-unspecified class of RBridges, for
         example
      example, border RBridges in a TRILL campus extended to support
      multi-level IS-IS (Intermediate System to Intermediate System)
      [MultiLevel], and

   o  both "critical" and "non-critical" flags.

   Any RBridge receiving a frame with a critical hop-by-hop extension
   that it does not implement MUST discard the frame because it is
   unsafe to process the frame without understanding such a critical
   extension.

   Any egress RBridge receiving a frame with a critical ingress-to-
   egress extension it does not implement MUST drop the frame if it is a
   unicast frame (TRILL Header M bit = 0); if it is a multi-destination
   TRILL Data frame (M=1), then it MUST NOT be egressed at that RBridge RBridge,
   but the egress RBridge still forwards such a frame on the
   distribution tree.

   Non-critical extensions can be safely ignored.

   Any extended flag indicating a significant change in the structure or
   interpretation of later parts of the frame which, that, if the extended flag
   were ignored, could cause a failure of service or violation of
   security policy MUST be a critical extension.  If such an extended
   flag affects any fields that transit RBridges will examine, it MUST
   be a hop-by-hop critical extended flag.

      Note: Most RBridges RBridge implementations are expected to be optimized

INTERNET-DRAFT                                   TRILL: Header Extension
      for simple and common cases of frame forwarding and processing.
      Although the hard limit on the header extensions area length, the
      32-bit alignment of the extension area, and the presence of
      critical extension summary bits, as described below, are intended
      to assist in the efficient hardware processing of frames with a
      TRILL header Header extensions area, nevertheless the inclusion of
      extensions may cause frame processing using a "slow path" with
      inferior performance to "fast path" processing.  Limited slow path
      throughput of such frames could cause some of them to be
      discarded.

2.1

2.1.  RBridge Extended Flag Handling Requirements

   All RBridges MUST check whether there are any critical flags set that
   are necessarily applicable to their processing of the frame.  To
   assist in this task, critical summary bits are provided that cover
   not only the extended flags specified herein but will cover any
   further extensions that may be specified in future documents, for
   example [Options].
   example, [Options] and [Options2].  If an RBridge does not implement
   all critical flags in a TRILL Data frame, it MUST treat the frame as
   having an unimplemented critical extension as described in Section 2.
   A transit or egress RBridge may assume that the critical summary bits
   are correct.

   In addition, a transit RBridge:

   o  MAY set or clear hop-by-hop flags as specified for such flags;

   o  MUST adjust the length of the extensions area, including changing
      Op-Length in the TRILL header, Header, as appropriate if it adds or
      removes the word of extended header flags; flags word;

   o  MUST, if it adds the word of extended header flags or changes any
      critical flags, correctly set the critical summary bits in the
      extended header flags word;

   o  MUST NOT remove the extended header flags word unless it is all
      zero (either on arrival or after permitted modifications); and
   o  MUST NOT set or clear ingress-to-egress or reserved extended
      header flags except as specifically permitted in the specification
      of such flags.

2.2

2.2.  No Critical Surprises

   RBridges advertise the extended header flags they support in IS-IS
   PDUs (Protocol Data Units) [RFC6326bis]. [RFC7176].  Unless an RBridge advertises
   support for a critical extended header flag, it will not normally
   receive frames with that flag set.  An RBridge is not required to
   support any extensions.

INTERNET-DRAFT                                   TRILL: Header Extension

   An RBridge SHOULD NOT set a critical extended flag in a frame unless,

   -

   o  for a critical hop-by-hop extended header flag, it has determined
      that the next hop RBridge or RBridges that will accept the frame
      support that flag,
   -

   o  for a critical ingress-to-egress extended header flag, it has
      determined that the RBridge or RBridges that will egress the frame
      support that flag, or
   -

   o  for a critical reserved extended header flag, it may set such a
      flag only if it understands which RBridges it is applicable to and
      has determined that those RBridges that will accept the frame
      support that flag.

   "SHOULD NOT" is specified above since there may be cases where it is
   acceptable for those frames, particularly for the multi-destination
   case, to be discarded or not egressed by any RBridges that do not
   implement the extended flag.

2.3

2.3.  Extended Header Flags

   If any extensions are present in a TRILL Header, as indicated by a
   non-zero Op-Length field, the first 32 bits of the extensions area
   consist of Extended Header Flags, extended header flags, as described below.  The remainder
   of the extensions area, if any, after this the initial 32 bits, bits may be
   specified in later documents [Options]. documents, for example, [Options] and [Options2].

   Any RBridge adding an extensions area to a TRILL Header must set the
   first 32 bits to zero except when permitted or required to set one or
   more of those bits as specified.  For TRILL Data frames with
   extensions present, any transit RBridge that does not discard the
   frame MUST transparently copy the extended flags word, except for
   modifications permitted by an extension implemented by that RBridge.

   The extended header flags word of Extended Header Flags is illustrated below and the meanings
   of these bits is further described in the list following the figure.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... additional optional 32-bit aligned words of extension     |
   |     possibly including TLV extensions ...

INTERNET-DRAFT                                   TRILL: Header Extension

   (The first two critical summary bits are as specified in [RFC6325].
   In this document document, an "S", for Summary, has been added at the end of
   their acronyms.  A third critical summary bit is also specified
   herein and its acronym also ends with an "S" for consistency.)

   Bit(s)

   Bits    Description
   ---------------------

    0-3
   --------------------

   0-2     Crit.: Critical summary bits.
           0 CHbHS: Critical Hop-by-Hop extension(s) are present.
           1 CItES: Critical Ingress-to-Egress extension(s) are present.
           2 CRSVS: Critical reserved Reserved extension(s) are present.

   3-7     CHbH: Critical Hob-by-Hop Hop-by-Hop extended Flag flag bits.
   8-13    NCHbH: Non-critical Hop-by-Hop extended Flag flag bits.

   14-16   CRSV: Critical Reserved extended Flag flag bits.
   17-20   NCRSV: Non-critical Reserved extended Flag flag bits.

   21-26   CItE: Critical Ingress-to-Egress extended Flag flag bits.
   27-31   NCItE: Non-critical Ingress-to-Egress extended Flag flag bits.

2.3.1

2.3.1.  Critical Summary Bits

   The top three bits of the Extended Header Flags extended header flags area, bits 0, 1, and
   2 above, are called the critical summary bits.  They summarize the
   presence of critical extensions as follows:

   CHbHS: If the CHbHS (Critical Hop by Hop Hop-by-Hop Summary) bit is one, one or
      more critical hop-by-hop extensions are present.  These might be
      critical hop-by-hop extended header flags or critical hop-by-hop
      extensions after the first word in the extensions area.  Transit
      RBridges that do not support all of the critical hop-by-hop
      extensions present, for example example, an RBridge that supported no
      critical hop-by-hop extensions, MUST drop the frame.  If the CHbHS
      bit is zero, the frame is safe, from the point of view of
      extensions processing, for a transit RBridge to forward,
      regardless of what extensions that RBridge does or does not
      support.

   CItES: If the CItES (Critical Ingress to Egress Ingress-to-Egress Summary) bit is a
      one, one or more critical ingress-to-egress extensions are
      present.  These might be critical ingress-to-egress extended
      header flags or critical ingress-to-egress extensions after the
      first word in the extensions area.  If the CItES bit is zero, no
      such extensions are present.  If either CHbHS or CItES is non-zero, non-
      zero, egress RBridges that do not support all critical extensions
      present, for example example, an RBridge that supports no critical

INTERNET-DRAFT                                   TRILL: Header Extension
      extensions, MUST drop the frame.  If both CHbHS and CItES are
      zero, the frame is safe, from the point of view of extensions, for
      an egress RBridge to process, regardless of what extensions that
      RBridge does or does not support.

   CRSVS: If the CRSVS (Critical Reserved Summary) bit is a one, one or
      more critical extensions are present that are reserved to apply to
      a class of RBridges to be specified in the future, for example example,
      border RBridges in a TRILL campus extended to support multi-level
      IS-IS.  This class will be a subset of transit RBridges.  RBridges
      in this class MUST drop frames with the CRSVS bit set unless they
      implement all critical hop-by-hop and all critical reserved
      extensions present in the frame.

   The critical summary bits enable simple and efficient processing of
   TRILL Data frames by egress RBridges that support no critical
   extensions, by transit RBridges that support no critical hop-by-hop
   extensions, and by RBridges in the reserved class that support no
   critical hop-by-hop or reserved extensions.  Such RBridges need only
   check whether Op-Length is non-zero and, if it is, check the top one,
   two, or three bits just after the fixed portion of the TRILL Header.
   Based on those three bits, such RBridges can decide whether to
   discard or
   forward / process forward/process the frame.

2.4

2.4.  Conflict of Extensions

   Defining TRILL extensions including Extended Header Flags extended header flags that
   conflict with each other would be undesirable.  Should conflicting
   extensions appear in the same packet, the results would be
   unpredictable,
   unpredictable if different implementations processed them in
   different orders.  While rules could be defined to specify how to
   predictably process conflicting extensions, such rules would also
   limit implementation flexibility and could impose substantial
   processing burdens.

   Conflicting extensions SHOULD NOT be defined, but if they are,
   careful thought should be given as to whether and how to specify the
   handling of conflicting extensions.

INTERNET-DRAFT                                   TRILL: Header Extension

3.  Specific Extended Header Flags

   The table below shows the state of TRILL Header extended flag
   assignments.  See Section 5 for IANA Considerations.

   Bits    Purpose                                          Section
      ------------------------------------------------------
   ----------------------------------------------------------------
    0-2    Critical Summary Bits                              2.3.1
    3-6    available critical hop-by-hop flags
    7      Critical Channel Alert Flag flag                          3.1
    8      Non-critical Channel Alert Flag flag                      3.1
    9-13   available non-critical hop-by-hop flags
   14-16   available critical reserved flags
   17-20   available non-critical reserved flags
   21-26   available critical ingress-to-egress flags
   27-31   available non-critical ingress-to-egress flags

             Table 1. 1: Extended Header Flags Area

3.1 The

3.1.  RBridge Channel Alert Extended Flags

   The RBridge Channel Alert Extended Flags indicates extended header flags indicate that the
   frame is an RBridge Channel frame [Channel] [RFC7178] that requests processing
   at each hop.

   If the critical Critical Channel Alert flag (bit 7) is a one and the RBridge
   does not implement the RBridge Channel feature or the particular
   RBridge Channel protocol involved [Channel] [RFC7178] or the frame does not
   actually appear to be an RBridge Channel message, then the frame is
   discarded.  This permits implementation, for example, of a Channel channel
   message requiring strict source routing or the like, with assurance
   that it will be discarded rather than deviate from the directed path.

   If the frame is not discarded as above described above, then the presence
   of either the Critical or Non-critical hop-by-hop Channel Alert flag alerts
   transit RBridges to the presence of an RBridge Channel message
   [Channel]
   [RFC7178] that may require special handling.  The non-critical alert
   flag supports, for example, an RBridge Channel protocol message
   including a "record route" function where not recording transit
   RBridges that do not support this function is acceptable.

INTERNET-DRAFT                                   TRILL: Header Extension

4.  Additions to IS-IS

   RBridges use IS-IS LSP Link State PDUs (LSPs) to inform other RBridges
   which Extended
   Header Flags extended header flags they support.  The IS-IS PDU(s), TLV(s),
   or sub-TLV(s) used to encode and advertise this information are
   specified in a separate document [RFC6326bis]. [RFC7176].

5.  IANA Considerations

   IANA is requested to create has created a "TRILL Extended Header Flags" subregistry within
   the TRILL Parameters
   registry: registry.  The "TRILL Extended Header Flags" subregistry, that
   subregistry is initially populated as specified in Table 1 in Section
   3.  References in that table to sections of this document are to be have been
   replaced in the IANA subregistry by references to this document as an
   RFC.

   New TRILL Extended Header Flags extended header flags are allocated by IETF Review
   [RFC5226].

INTERNET-DRAFT                                   TRILL: Header Extension

   To indicate support of extended header flags, IANA has assigned the
   following bits in the TRILL-VER and PORT-TRILL-VER Sub-TLV Capability
   Flag registries created by [RFC7176]:

   o  Bits 3-13 of the PORT-TRILL-VER Sub-TLV Capability Flags have been
      assigned to indicate support of TRILL hop-by-hop extended header
      flags 3-13.

   o  Bits 14-31 of the TRILL-VER Sub-TLV Capability Flags have been
      assigned to indicate support of TRILL extended header flags 14-31.

6.  Security Considerations

   For general TRILL protocol security considerations, see [RFC6325].

   For security considerations related to extended header flags, see the
   document where the flag is specified.

   It is important that the critical summary bits in the Extended Header
   Flags extended header
   flags word be set properly.  If set when critical extensions of the
   appropriate category are not present, frames may be unnecessarily
   discarded.  If not set when critical extensions are present, frames
   may be mishandled or corrupted corrupted, and intended security policies may be
   violated.

   The RBridge Channel Alert extended header flags have the following
   security considerations.  Implementations should keep in mind that
   they might be erroneously set in a frame.  If either RBridge Channel
   Alert flag is found set in a frame that is not an RBridge Channel
   message
   [Channel], [RFC7178], the flag MAY be cleared and should have no effect
   except, possibly, delaying processing of the frame.  If either
   RBridge Channel Alert flag is erroneously omitted from a frame,
   desired per hop per-hop processing for the frame may not occur.

7.  Acknowledgements

   The following, listed in alphabetic order, are thanked for their
   valuable contributions:  Ben Campbell, Adrian Farrel, Barry Leiba,
   and Thomas Narten.

   This document was produced with raw nroff. All macros used were
   defined in the source file

INTERNET-DRAFT                                   TRILL: Header Extension

8.  References

8.1.  Normative References

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

   [RFC5226] -     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 5226, May 2008.

   [RFC6325] -     Perlman, R., D. Eastlake, D. Eastlake 3rd, D., Dutt, S. D., Gai, S., and
                 A. Ghanwani, "Routing Bridges (RBridges): Base Protocol
                 Specification", RFC 6325, July 2011.

   [Channel] - draft-ietf-trill-rbridge-channel, work in progress.

   [RFC6326bis] - draft-eastlake-isis-rfc6326bis, work in progress.

9.

   [RFC7176]     Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
                 D., and A. Banerjee, "Transparent Interconnection of
                 Lots of Links (TRILL) Use of IS-IS", RFC 7176, April
                 2014.

   [RFC7178]     Eastlake 3rd, D., Manral, V., Yizhou, L., Aldrin, S.,
                 and D. Ward, "Transparent Interconnection of Lots of
                 Links (TRILL): Routing Bridge (RBridge) Channel
                 Support", RFC 7178, April 2014.

8.2.  Informative References

   [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work  Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H.
                 Zhai, "Flexible Multilevel TRILL (Transparent
                 Interconnection of Lots of Links)", Work in
         progress. Progress,
                 January 2014.

   [Options] - draft-ietf-trill-rbridge-options, work in progress.
         - draft-eastlake-trill-rbridge-more-options, work in progress.

INTERNET-DRAFT                                   TRILL: Header Extension

Change History

   The sections below summarize changes between successive versions of
   this draft. RFC Editor: Please delete this section before
   publication.

   Version 00 of this draft is an extract and simplification of draft-
   ietf-trill-rbridge-options-05.txt as discussed at the TRILL Working
   Group meeting at IETF 81 and on the TRILL WG mailing list.

From -00 to -01

   1. Update Author Addresses.

   2. Assorted editorial changes.

From -01 to -02

   1. Addition of the Critical RBridge Channel Alert Flag.

   2. Assorted editorial and author changes.

From -02 to -03

   1. Replacement of Section 2.4 to eliminate detailed constraints on
      the processing of conflicting extensions     Eastlake 3rd, D., Ghanwani, A., Manral, V., and to warn against the
      future specification of conflicting options.

   2. Minor editorial changes.

From -03 to -04

   Editorial changes including the deletion of Section 2.3.2 that was
   completely redundant with earlier parts of Section 2.3.

From -04 to -05

   1. Add "Updates: 6325" to the first page header as this document
      provides more details on the C.
                 Bestler, "RBridges: Further TRILL Header options area.

INTERNET-DRAFT                                   TRILL: Header Extension

   2. Expand first use of some acronyms and other editorial changes.

   3. Change criteria for allocation of extended header flags from
      Standards Action to IETF Review.

   4. Editorial changes primarily based on IESG review.

INTERNET-DRAFT                                   TRILL: Extensions",
                 Work in Progress, June 2012.

   [Options2]    Eastlake 3rd, D., "RBridges: More Proposed TRILL Header Extension
                 Options", Work in Progress, October 2011.

Authors' Addresses

   Donald Eastlake 3rd
   Huawei R&D USA
   155 Beaver Street
   Milford, MA 01757
   USA

   Phone: +1-508-333-2270
   email:
   EMail: d3e3e3@gmail.com

   Anoop Ghanwani
   Dell
   350 Holger Way
   San Jose,
   5450 Great America Parkway
   Santa Clara, CA 95134  95054
   USA

   Phone: +1-408-571-3500
   Email:

   EMail: anoop@alumni.duke.edu

   Vishwas Manral
   HP Networking
   19111 Pruneridge Avenue
   Cupertino,
   Ionos Corp.
   4100 Moorpark Ave.
   San Jose, CA 95014  95117
   USA

   Phone: +1-408-477-0000

   EMail: vishwas.manral@hp.com vishwas@ionosnetworks.com

   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012, 210012
   China

   Phone: +86-25-56622310
   Email:
   EMail: liyizhou@huawei.com
   Caitlin Bestler
   Quantum
   1650 Technology Drive , Suite 700
   San Jose,
   Nexenta Systems
   455 El Camino Real
   Santa Clara, CA 95110 95050
   USA

   Phone: +1-408-944-4000
   email: cait@asomi.com

INTERNET-DRAFT                                   TRILL: Header Extension

Copyright and IPR Provisions

   Copyright (c) 2012 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
   (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.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

   EMail: caitlin.bestler@nexenta.com