[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

Link State Routing Working Group                                 Y. Wang
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                   Z. Hu
Expires: May 2, 2021                                              Huawei
                                                        October 29, 2020


  IGP Extensions for Advertising Hop-by-Hop Options Header Processing
                                 Action
                     draft-wang-lsr-hbh-process-00

Abstract

   This document extends Node and Link attribute TLVs to Interior
   Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header
   processing action and supported services (e.g.  IOAM Trace Option and
   Alternate Marking) at node and link granularity.  Such advertisements
   allow entities (e.g., centralized controllers) to determine whether
   the Hop-by-Hop Options header and specific services can be supported
   in a given network.

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 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 May 2, 2021.








Wang, et al.               Expires May 2, 2021                  [Page 1]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


Copyright Notice

   Copyright (c) 2020 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Hop-by-Hop Options Header Processing Action . . . . . . . . .   4
   4.  Signaling Processing Action Using IS-IS . . . . . . . . . . .   5
     4.1.  IS-IS Node Processing-Action Sub-TLV  . . . . . . . . . .   5
     4.2.  IS-IS Link Processing-Action Sub-TLV  . . . . . . . . . .   6
   5.  Signaling Processing Action Using OSPF  . . . . . . . . . . .   6
     5.1.  OSPF Node Processing-Action TLV . . . . . . . . . . . . .   7
     5.2.  OSPFv2 Link Processing-Action sub-TLV . . . . . . . . . .   7
     5.3.  OSPFv3 Link Processing-Action Sub-TLV . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC8200] specifies IPv6 extension headers, including Hop-by-Hop
   Options header, Destination Options header, Routing header, etc.  An
   IPv6 packet may carry zero, one, or more extension headers that must
   be processed strictly in the order they appear in the packet.  Except
   for the Hop-by-Hop Options header, other extension headers are not
   processed, inserted, or deleted by any transit node along a packet's
   delivery path, until the packet arrives at the Destination node.

   As specified in [RFC8200], although the Hop-by-Hop Options header is
   not inserted or deleted by any transit node along a packet's delivery
   path, it is only examined and processed by nodes along a packet's



Wang, et al.               Expires May 2, 2021                  [Page 2]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


   delivery path if they are explicitly configured to process.  Besides,
   nodes may be configured to ignore the Hop-by-Hop Options header, drop
   packets containing a Hop-by-Hop Options header, or assign packets
   containing a Hop-by-Hop Options header to a slow processing path.  In
   the results, devices of different vendors can be configured to
   process the Hop-by-Hop Options header in different ways.

   Until now, the Hop-by-Hop Options header has been widely used.  In-
   situ Operations, Administration, and Maintenance (IOAM) data fields
   are encapsulated in two types of extension headers in IPv6 packets,
   either Hop-by-Hop Options header or Destination Options header,
   depending on IOAM usage [I-D.ietf-ippm-ioam-ipv6-options].  For
   example, IOAM-tracing options are represented as an IPv6 options in
   Hop-by-Hop extension header.  Similarly, the Alternate Marking
   technique can be carried by the Hop-by-Hop Options header and the
   Destination Options header [I-D.ietf-6man-ipv6-alt-mark].  If nodes
   are not explicitly configured to process the Hop-by-Hop Option
   header, they should ignore them.  In this case, the performance
   measurement does not account for all links and nodes along a path.
   Therefore, such advertisement can be useful for entities (e.g., the
   centralized controller) to determine whether a specific service can
   be implemented in IPv6 netowrk by encoding in the Hop-by-Hop Options
   header.

   BGP-LS defines a way to advertise topology and associated attributes
   and capabilities of the nodes in that topology to a centralized
   controller [RFC7752].  Typically, BGP-LS is configured on a small
   number of nodes that do not necessarily act as head-ends.  In order
   for BGP-LS to signal the processing action of the Hop-by-Hop Options
   header for all the devices in the network, the processing action
   SHOULD be advertised by every IGP router in the network.

   This document defines a mechanism to signal the configured processing
   action of the Hop-by-Hop Options header and supported services at
   node and/or link granularity using IS-IS, OSPFv2 and OSPFv3.

2.  Terminology

   Following are abbreviations used in this document:

   o  IGP: Interior Gateway Protocols

   o  IS-IS: Intermediate System to Intermediate System

   o  OSPF: Open Shortest Path First

   o  BGP-LS: Border Gateway Protocol - Link State




Wang, et al.               Expires May 2, 2021                  [Page 3]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


   o  NLRI: Network Layer Reachability Information

3.  Hop-by-Hop Options Header Processing Action

   This document defines the information of processing action formed of
   a tuple of a 1-octet Extension Header Options identifier and 8-bit
   Processing Action Flag.

    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
   +---------------+-------------------------------+---------------+
   |  Action Flag  |          Services Flag        |  Max EH Len   |
   +---------------+-------------------------------+---------------+

                      Fig. 1 Processing Action Format

   Where:

   o  Action Flag: A 8-bit field.  The highest-order 3-bit indicates the
      processing action, i.e., 000 - drop packets; 001 - dispatch to
      control plane; 010 - forward, skip to Next Header; 011 - forward,
      ignoring all extension Options header; 100 - examine and process.

   o  Max EH Len: A one octet field.  The maximum length of the
      Extension Header in 8-octet units can be examined and processed at
      node or link granularity.  The definition is same as the Next
      Header Length in [RFC8200].

   o  Services Flag: A 16-bit bitmap.  The format is defined as follows.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-------------------------------+
   |O|A|          Reserved         |
   +-------------------------------+

                        Fig. 2 Services Flag Format

   where fields are defined as the following:

   o  O (IOAM Trace Option) is a one-bit flag.  The O flag is set to 1
      if the IOAM Trace Option is supported at node or link granularity.

   o  A (Alternate Marking) is a one-bit flag.  The A flag is set to 1
      if the Alternate Marking method is supported at node or link
      granularity.

   o  R - reserved bits for future use.  These flags MUST be zeroed on
      transimit and ignored on receipt.




Wang, et al.               Expires May 2, 2021                  [Page 4]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


   In this document, the processing action at link granularity is
   defined as the supported the Hop-by-Hop Options header processing
   action of the interface associated with the link.  When all
   interfaces associated with links support the same processing action,
   the processing action at node granularity SHOULD represent the Link
   processing action.  Both of Node and Link processing action
   information are formed of a tuple of a 1-octet Extension Header
   Options identifier and 8-bit Processing Action Flag.

   When both of Node and Link processing action are advertised, the Link
   processing action information MUST take precedence over the Node
   processing action.  Besides, when a Link processing action is not
   signaled, then the Node processing action SHOULD be considered to be
   the processing action for this link.

4.  Signaling Processing Action Using IS-IS

   The IS-IS Extensions for advertising Router Information TLV named IS-
   IS Router CAPABILITY TLV [RFC7981], which allows a router to announce
   its capabilities within an IS-IS level or the entire routing domain.

4.1.  IS-IS Node Processing-Action Sub-TLV

   According to the format of IS-IS Router CAPABILITY TLV [RFC7981], the
   Node Processing-Action sub-TLV within the body of the IS-IS router
   CAPABILITY TLV is composed of three fields, a one-octet Type field, a
   one-octet Length field, and a 4-octet Value field.  The following
   format is used:

    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
   +---------------+---------------+
   |      Type     |    Length     |
   +---------------+---------------+-------------------------------+
   |                    Node-Processing-Action                     |
   +---------------------------------------------------------------+

            Fig. 3 IS-IS Node Processing-Action Sub-TLV Format

   Where:

   o  Type: To be assigned by IANA

   o  Length: A one-octet field that indicates the length of the value
      portion in octets.

   o  Node-Processing-Action: A 4-octet field, which is same as defined
      in Section 3.



Wang, et al.               Expires May 2, 2021                  [Page 5]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


4.2.  IS-IS Link Processing-Action Sub-TLV

   The Link Processing-Action sub-TLV is defined for TLVs 22, 23, 25,
   141, 222, and 223 to carry the Processing-Action information of the
   interface associated with the link.  The Link Processing-Action sub-
   TLV is formed of three fields, a one-octet Type field, a one-octet
   Length field, and a 4-octet Value field.  The following format is
   used:

    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
   +---------------+---------------+
   |      Type     |    Length     |
   +---------------+---------------+-------------------------------+
   |                     Link-Processing-Action                    |
   +---------------------------------------------------------------+

            Fig. 4 IS-IS Link Processing-Action Sub-TLV Format

   Where:

   o  Type: To be assigned by IANA

   o  Length: A one-octet field that indicates the length of the value
      portion in octets.

   o  Link-Processing-Action: A 4-octet field, which is same as defined
      in Section 3.

5.  Signaling Processing Action Using OSPF

   Given that OSPF uses the options field in LSAs and hello packets to
   advertise optional router capabilities [RFC7770], this document
   defines a new Node Processing-Action TLV within the body of the OSPF
   RI Opaque LSA [RFC7770] to carry the Processing Action of the router
   originating the RI LSA.

   This document defines the Link Processing-Action sub-TLV to carry the
   Processing-Action information of the interface associated with the
   link.  For OSPFv2, the link-level Processing-Action information is
   advertised as a sub-TLV of the OSPFv2 Extended Link TLV as defined in
   [RFC7684].  For OSPFv3, the link-level Processing-Action information
   is advertised a sub-TLV of the E-Router-LSA TLV as defined in
   [RFC8362].







Wang, et al.               Expires May 2, 2021                  [Page 6]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


5.1.  OSPF Node Processing-Action TLV

   The Node Processing-Action TLV is composed of three fields, a 2-octet
   Type field, a 2-octet Length field, and a 4-octet Value field.  The
   following format is used:

    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
   +-------------------------------+-------------------------------+
   |               Type            |            Length             |
   +---------------------------------------------------------------+
   |                     Node-Processing-Action                    |
   +---------------------------------------------------------------+


                  Fig. 5 OSPF Node Processing-Action TLV

   Where:

   o  Type: To be assigned by IANA

   o  Length: A 2-octet field that indicates the length of the value
      field.

   o  Node-Processing-Action: A 4-octet field, which is as defined in
      Section 3.

5.2.  OSPFv2 Link Processing-Action sub-TLV

   The Link Processing-Action sub-TLV encoded in the OSPFv2 Extended
   Link TLV as defined in [RFC7684], which is constructed of three
   fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet
   Value field.  The following format is used:

    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
   +-------------------------------+-------------------------------+
   |               Type            |            Length             |
   +---------------------------------------------------------------+
   |                     Link-Processing-Action                    |
   +---------------------------------------------------------------+


               Fig. 6 OSPFv2 Link Processing-Action sub-TLV

   Where:

   o  Type: To be assigned by IANA



Wang, et al.               Expires May 2, 2021                  [Page 7]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


   o  Length: A 2-octet field that indicates the length of the value
      field.

   o  Link-Processing-Action: A 4-octet field, which is as defined in
      Section 3.

5.3.  OSPFv3 Link Processing-Action Sub-TLV

   The Link Processing-Action sub-TLV encoded in the OSPFv3 E-Router-LSA
   TLV as defined in [RFC8362], which is constructed of three fields, a
   2-octet Type field, a 2-octet Length field, and a 4-octet Value
   field.  The following format is used:

    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
   +-------------------------------+-------------------------------+
   |               Type            |            Length             |
   +---------------------------------------------------------------+
   |                     Link-Processing-Action                    |
   +---------------------------------------------------------------+


               Fig. 7 OSPFv3 Link Processing-Action sub-TLV

   Where:

   o  Type: To be assigned by IANA

   o  Length: A 2-octet field that indicates the length of the value
      field.

   o  Link-Processing-Action: A 4-octet field, which is as defined in
      Section 3.

6.  IANA Considerations

   IANA is requested to allocate values for the following new TLV and
   sub-TLVs.

              +------+--------------------------------------+
              | Type | Description                          |
              +------+--------------------------------------+
              | TBA  | IS-IS Node Processing-Action Sub-TLV |
              | TBA  | IS-IS Link Processing-Action Sub-TLV |
              +------+--------------------------------------+






Wang, et al.               Expires May 2, 2021                  [Page 8]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


             +------+---------------------------------------+
             | Type | Description                           |
             +------+---------------------------------------+
             | TBA  | OSPF Node Processing-Action TLV       |
             | TBA  | OSPFv2 Link Processing-Action sub-TLV |
             | TBA  | OSPFv3 Link Processing-Action sub-TLV |
             +------+---------------------------------------+

7.  Security Considerations

   This document introduces new IGP Node and Link Attribute TLVs and
   sub-TLVs for dvertising processing actions of the Hop-by-Hop Options
   header at node and/or link granularity.  It does not introduce any
   new security risks to IS-IS, OSPFv2 and OSPFv3.

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7684]  "OSPFv2 Prefix/Link Attribute Advertisement",
              <https://www.rfc-editor.org/info/rfc7684>.

   [RFC7752]  "North-Bound Distribution of Link-State and Traffic
              Engineering (TE) Information Using BGP",
              <https://datatracker.ietf.org/doc/rfc7752/>.

   [RFC7770]  "Extensions to OSPF for Advertising Optional Router
              Capabilities", <https://www.rfc-editor.org/info/rfc7770>.

   [RFC7981]  "IS-IS Extensions for Advertising Router Information",
              <https://www.rfc-editor.org/info/rfc7981>.

   [RFC8200]  "Internet Protocol, Version 6 (IPv6) Specification",
              <https://datatracker.ietf.org/doc/rfc8200/>.

   [RFC8362]  "OSPFv3 Link State Advertisement (LSA) Extensibility",
              <https://www.rfc-editor.org/info/rfc8362>.





Wang, et al.               Expires May 2, 2021                  [Page 9]


Internet-Draft        draft-wang-lsr-hbh-process-00         October 2020


9.2.  Informative References

   [I-D.ietf-6man-ipv6-alt-mark]
              "IPv6 Application of the Alternate Marking Method",
              <https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-
              alt-mark/>.

   [I-D.ietf-ippm-ioam-ipv6-options]
              "In-situ OAM IPv6 Options",
              <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
              ipv6-options/>.

Authors' Addresses

   Yali Wang
   Huawei
   156 Beiqing Rd., Haidian District
   Beijing
   China

   Email: wangyali11@huawei.com


   Tianran Zhou
   Huawei
   156 Beiqing Rd., Haidian District
   Beijing
   China

   Email: zhoutianran@huawei.com


   Zhibo Hu
   Huawei
   156 Beiqing Rd., Haidian District
   Beijing
   China

   Email: huzhibo@huawei.com












Wang, et al.               Expires May 2, 2021                 [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/