[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03                                                   
Link State Routing Working Group                            Y. Wang, Ed.
Internet-Draft                                              T. Zhou, Ed.
Intended status: Standards Track                                  Huawei
Expires: August 31, 2020                               February 28, 2020


        Extensions to OSPF for Advertising IFIT Node Capability
              draft-wang-lsr-ospf-ifit-node-capability-00

Abstract

   This document defines a way for an Open Shortest Path First (OSPF)
   router originating the RI LSA to announce IFIT node capabilities
   within the entire routing domain.  A new optional TLV is extended to
   the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
   information.  Such advertisements enable IFIT applications in an
   operational network domain.  Here, the term "OSPF" includes both
   OSPFv2 and OSPFv3.

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 August 31, 2020.

Copyright Notice

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





Wang & Zhou              Expires August 31, 2020                [Page 1]


Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-00 February 2020


   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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  IFIT Domain . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  IFIT Node Capability Information  . . . . . . . . . . . .   3
   3.  IFIT Node Capabilities Advertisement  . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  TLVs within the body of the OSPF RI Opaque LSA  . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   IFIT provides a complete framework architecture and a reflection-loop
   working solution for on-path flow telemetry
   [I-D.song-opsawg-ifit-framework].  At present, there are a family of
   emerging on-path flow telemetry techniques, including In-situ OAM
   (IOAM) [I-D.ietf-ippm-ioam-data], PBT
   [I-D.song-ippm-postcard-based-telemetry] , IOAM Direct Export (DEX)
   [I-D.ioamteam-ippm-ioam-direct-export] , Enhanced Alternate Marking
   (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc.  IFIT is a
   solution focusing on network domains.  The "network domain" consists
   of a set of network devices or entities within a single
   administration.  For example, a network domain can be one or more IGP
   routing domains.  The family of emerging on-path flow telemetry
   techniques may be selectively or partially implemented in different
   vendors' devices as an emerging feature for various use cases of
   application-aware network operations.  Hence, in order to enable IFIT
   applications in an operational network domain, IFIT node capabilities
   SHOULD be advertised by every Intermediate System to Intermediate
   System (IS-IS) router in the network domain.




Wang & Zhou              Expires August 31, 2020                [Page 2]


Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-00 February 2020


1.1.  Terminology

   OSPF: Open Shortest Path First

   LSA: Link State Advertisement

   RI: Router Information

2.  Concepts

2.1.  IFIT Domain

   IFIT is expected to be deployed in a specific domain referred as the
   IFIT domain.  An IFIT domain may cross multiple network domains.  One
   network domain may consists of multiple IFIT domain.  Within the IFIT
   domain, the IFIT data fields of flow information head MAY be updated
   by network nodes that the packet traverses.

2.2.  IFIT Node Capability Information

   Each IFIT node is configured with a node-id which uniquely identifies
   a node within the associated IFIT domain.  To accommodate the
   different use cases or requirements of in-situ flow information
   telemetry, IFIT data fields updated by network nodes fall into
   different categories which are referred as different IFIT option
   types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data],
   IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM
   DEX Option-Type [I-D.ioamteam-ippm-ioam-direct-export] and Enhanced
   Alternate Marking (EAM) Option-Type
   [I-D.zhou-ippm-enhanced-alternate-marking].  So IFIT Option Types
   SHOULD be carried in IFIT node capability advertisment.

3.  IFIT Node Capabilities Advertisement

   Given that OSPF uses the options field in LSAs and hello packets to
   advertise optional router capabilities [RFC7770], this document
   defnes a new IFIT Node Capability TLV within the body of the OSPF RI
   Opaque LSA [RFC7770] to carry the IFIT node capabilities of the
   router originating the RI LSA.  The IFIT Node Capability TLV is
   composed of three fields, a two-octet Type field, a two-octet Length
   field, and 4-octet Value field.  The Type field indicates the type of
   items in the Value field.  The Length field indicates the length of
   the Value field in octets.  The Value field indicates the IFIT Node
   Capability, which is a 4-octet IFIT Option Type-enabled Flag.  The
   TLV is padded to 4-octet alignment.

   The IFIT Node-capability Sub-TLV has the following format:




Wang & Zhou              Expires August 31, 2020                [Page 3]


Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-00 February 2020


        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             |
       +---------------------------------------------------------------+
       |                 IFIT Option Type-enabled Flag                 |
       +---------------------------------------------------------------+


                Fig. 1 IFIT Node Capability sub-TLV Format

   Type: To be assigned by IANA

   Length: A 8-bit field that indicates the length of the value portion
   in octets and will be a multiple of 4 octets dependent on the number
   of capabilities advertised.

   IFIT Option Type-enabled Flag: A 4-octet field, which is defined as
   following:

        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
       +---------------------------------------------------------------+
       |p|i|d|e|m|                      Reserved                       |
       +---------------------------------------------------------------+


   Where:

   p-Flag: iOAM Pre-allocated Trace Option Type-enabled flag.  If p bit
   is set (1), the router is capable of iOAM Pre-allocated Trace
   [I-D.ietf-ippm-ioam-data].

   i-Flag: iOAM Incremental Trace Option Type-enabled flag.  If i bit is
   set (1), the router is capable of iOAM Incremental Tracing
   [I-D.ietf-ippm-ioam-data].

   d-Flag: iOAM DEX Option Type-enabled flag.  If d bit is set (1), the
   router is capable of iOAM DEX [I-D.ioamteam-ippm-ioam-direct-export].

   e-Flag: iOAM E2E Option Type-enabled flag.  If e bit is set (1), the
   router is capable of iOAM E2E processing [I-D.ietf-ippm-ioam-data].

   m-Flag: Enhanced Alternative Marking enabled flag.  If m bit is set
   (1), then the router is capable of processing Enhanced Alternative
   Marking packets [I-D.zhou-ippm-enhanced-alternate-marking].

   Reserved: MUST be set to zero upon transmission and ignored upon
   receipt.



Wang & Zhou              Expires August 31, 2020                [Page 4]


Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-00 February 2020


   An IFIT node SHALL be capable of more than one IFIT option types.  So
   in this case, IFIT Option Type-enabled Flag bitmap SHOULD has more
   than one bit being set.

4.  IANA Considerations

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

4.1.  TLVs within the body of the OSPF RI Opaque LSA

   This document makes the following registrations for a TLV type of the
   new IFIT Node Capability TLV proposed in Section 3 of this document
   within the body of the OSPF RI Opaque LSA.

                      +------+----------------------+
                      | Type | Description          |
                      +------+----------------------+
                      | TBD  | IFIT Node Capability |
                      +------+----------------------+

5.  Security Considerations

   This document introduces new TLVs within the existing OSPF RI Opaque
   LSA.  It does not introduce any new security risks to OSPF.

6.  Acknowledgements

7.  References

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

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

7.2.  Informative References

   [I-D.ietf-ippm-ioam-data]
              "Data Fields for In-situ OAM".







Wang & Zhou              Expires August 31, 2020                [Page 5]


Internet-Draft draft-wang-lsr-ospf-ifit-node-capability-00 February 2020


   [I-D.ioamteam-ippm-ioam-direct-export]
              "In-situ OAM Direct Exporting",
              <https://datatracker.ietf.org/doc/draft-ioamteam-ippm-
              ioam-direct-export/>.

   [I-D.song-ippm-postcard-based-telemetry]
              "Postcard-based On-Path Flow Data Telemetry",
              <https://datatracker.ietf.org/doc/draft-song-ippm-
              postcard-based-telemetry/>.

   [I-D.song-opsawg-ifit-framework]
              "In-situ Flow Information Telemetry Framework",
              <https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-
              framework/>.

   [I-D.zhou-ippm-enhanced-alternate-marking]
              "Enhanced Alternate Marking Method",
              <https://datatracker.ietf.org/doc/draft-zhou-ippm-
              enhanced-alternate-marking/>.

Authors' Addresses

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

   Email: wangyali11@huawei.com


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

   Email: zhoutianran@huawei.com













Wang & Zhou              Expires August 31, 2020                [Page 6]