IPFIX Alternate-Marking Information
draft-gfz-opsawg-ipfix-alt-mark-01

IPPM                                                             T. Graf
Internet-Draft                                                  Swisscom
Intended status: Informational                               G. Fioccola
Expires: 26 October 2024                                         T. Zhou
                                                                  Huawei
                                                                F. Milan
                                                                 M. Nilo
                                                          Telecom Italia
                                                           24 April 2024

                  IPFIX Alternate-Marking Information
                   draft-gfz-opsawg-ipfix-alt-mark-01

Abstract

   This document introduces new IP Flow Information Export (IPFIX)
   Information Elements (IEs) to export Alternate Marking measurement
   data.

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 26 October 2024.

Copyright Notice

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

Graf, et al.             Expires 26 October 2024                [Page 1]
Internet-Draft           ipfix-alternate-marking              April 2024

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  AltMark IPFIX Information Elements  . . . . . . . . . . . . .   3
     2.1.  Flow Decomposition  . . . . . . . . . . . . . . . . . . .   3
     2.2.  Flow Aggregation  . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Flow Correlation  . . . . . . . . . . . . . . . . . . . .   3
     2.4.  Flow Measurements . . . . . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Alternate-Marking Method [RFC9341] [RFC9342] is a technique used to
   measure packet loss, delay, and jitter on in-flight packets.

   [I-D.fz-ippm-alt-mark-deployment] provides a framework for Alternate
   Marking deployments and includes considerations and guidance for
   application and methodology.  The IPFIX protocol is considered for
   data export.

   [RFC7012] defines the data types and management policy for the
   information model of the IPFIX protocol [RFC7011].  This document
   defines the new IPFIX Information Elements (IEs) for the Alternate
   Marking Method.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Graf, et al.             Expires 26 October 2024                [Page 2]
Internet-Draft           ipfix-alternate-marking              April 2024

2.  AltMark IPFIX Information Elements

   This section describes existing IEs of [IANA-IPFIX] that are relevant
   for the Alternate Marking application and also introduces new IEs.

2.1.  Flow Decomposition

   For IPFIX [RFC7011] the data decomposition can be achieved on the
   Alternate-Marking-aware node where IPFIX is exported or on the IPFIX
   data collection.

   The ipPayloadPacketSection(IE314) Information Element carries a
   series of n octets from the IP payload, starting sectionOffset(IE409)
   octets into the IP payload.

   When decomposed at the data collection, the packet header sections,
   as example the IPv6 options type header described in Section 3.1 of
   [RFC9343] or the Segment Routing header TLV as described in
   Section 3.1 of [I-D.fz-spring-srv6-alt-mark] containing the
   FlowMonID, Loss and Delay flag are being exposed as part of
   ipPayloadPacketSection(IE314), defined in Section 4.2 of [RFC7133].

   The IPv4 payload is that part of the packet that follows the IPv4
   header and any options.  The IPv6 payload is the rest of the packet
   following the 40-octet IPv6 header.  Note that any extension headers
   present are considered part of the payload.  The
   sectionExportedOctets(IE410) expresses how much data was observed,
   while the remainder is padding.

2.2.  Flow Aggregation

   An Aggregated Flow is simply an IPFIX Flow generated from Original
   Flows by an Intermediate Aggregation Process.

   When being decomposed on the Alternate-Marking-aware node, new IPFIX
   entities for FlowMonID, Loss and Delay flag are needed so that the
   data can now be aggregated according to section 5 of [RFC7015].

   According to section 4 of [RFC7015] new Flow Keys may be derived from
   existing Flow Keys or "promoted" from specific non-key fields.

   Therefore FlowMonID, Loss and Delay flag are considered Flow Key
   fields.

2.3.  Flow Correlation

   The following IPFIX entities are of interest to describe the
   relationship to the forwarding topology and the control-plane.

Graf, et al.             Expires 26 October 2024                [Page 3]
Internet-Draft           ipfix-alternate-marking              April 2024

   *  Hostname, ingressInterface(IE10) and egressInterface(IE14)
      describes on which node which logical ingress and egress
      interfaces have been used to forward the packet.

   *  Hostname and egressPhysicalInterface(IE253) describes on which
      node which physical egress interfaces have been used to forward
      the packet.

   *  Hostname and ipNextHopIPv4Address(IE15) or
      ipNextHopIPv6Address(IE62), describes the forwarding path to which
      next-hop IP address the packets are forwarded to.

   *  Hostname and mplsTopLabelIPv4Address(IE47) or srhActiveSegmentIPv6
      from [I-D.ietf-opsawg-ipfix-srv6-srh] describes the forwarding
      path to which MPLS top label IPv4 address or SRv6 active segment
      the packets are forwarded to.

   *  BGP communities are often used for setting a path priority or
      service selection. bgpDestinationExtendedCommunityList(IE488) or
      bgpDestinationCommunityList(IE485) or
      bgpDestinationLargeCommunityList(IE491) describes which group of
      prefixes have been used to forward the packet.

   *  Hostname and destinationIPv4Address(IE13),
      destinationTransportPort(IE11), protocolIdentifier(IE4) and
      sourceIPv4Address(IE8) describes the forwarding path on each node
      from each IPv4 source address to a specific application in the
      network.

   Note that, in case of Link Aggregation Group (LAG) interface, the
   ingressInterface IE and egressInterface IE can be used to refer the
   logical LAG port, while ingressPhysicalInterface IE and
   egressPhysicalInterface IE can be used to indicate the physical
   interfaces which are members of the LAG port.

2.4.  Flow Measurements

   To calculate loss, the packet count can be done with
   octetDeltaCount(IE1) or packetDeltaCount(IE2).

   While, to calculate delay, either flowStartSeconds(IE150),
   flowStartMilliseconds(IE152), flowStartMicroseconds(IE154) or
   flowStartNanoseconds(IE156), can be used depending on timestamp
   granularity requirements.  It is also possible to use
   flowEndSeconds(IE151), flowEndMilliseconds(IE153),
   flowEndMicroseconds(IE155) or flowEndNanoseconds(IE157).

Graf, et al.             Expires 26 October 2024                [Page 4]
Internet-Draft           ipfix-alternate-marking              April 2024

   It is also defined the PeriodID, which is needed for Alternate-
   Marking measurement correlation as per
   [I-D.fz-ippm-alt-mark-deployment].

3.  IANA Considerations

   This document requests IANA to create a new subregistry called "IPFIX
   Alternate-Marking" under the "IPFIX Information Elements" registry
   [RFC7012] available at [IANA-IPFIX].

   The allocation policy of this new subregistry is Expert Review
   (Section 4.5 of [RFC8126]).

   The designated experts for this registry should be familiar with
   Alternate-Marking.  The guidelines that are being followed by the
   designated experts for the IPFIX registry should be followed for this
   subregistry.  In particular, criteria that should be applied by the
   designated experts include determining whether the proposed
   registration duplicates existing entries and whether the registration
   description is clear and fits the purpose of this registry.  Within
   the review period, the designated experts will either approve or deny
   the registration request, communicating this decision to IANA.
   Denials should include an explanation and, if applicable, suggestions
   as to how to make the request successful.

   Initial values in the registry are defined in Table 1.

      +-------+---------------------+----------------------------------+
      | Value |     Description     |            Reference             |
      +-------+---------------------+----------------------------------+
      | TBD1  | FlowMonID           | [RFC-to-be],                     |
      |       |                     | RFC9341, RFC9342, RFC9343        |
      +-------+---------------------+----------------------------------+
      | TBD2  | L flag              | [RFC-to-be],                     |
      |       |                     | RFC9341, RFC9342, RFC9343        |
      +-------+---------------------+----------------------------------+
      | TBD3  | D flag              | [RFC-to-be],                     |
      |       |                     | RFC9341, RFC9342, RFC9343        |
      +-------+---------------------+----------------------------------+
      | TBD4  | PeriodID            | [RFC-to-be],                     |
      |       |                     | [I-D.fz-ippm-alt-mark-deployment]|
      +-------+---------------------+----------------------------------+

         Table 1: "IPFIX Alternate-Marking" subregistry

Graf, et al.             Expires 26 October 2024                [Page 5]
Internet-Draft           ipfix-alternate-marking              April 2024

4.  Security Considerations

   Alternate Marking [RFC9341] and Multipoint Alternate Marking
   [RFC9342] analyze different security concerns and related solutions.
   These aspects are valid and applicable also to this document.  In
   particular the fundamental security requirement is that Alternate
   Marking MUST only be applied in a specific limited domain, as also
   mentioned in [RFC8799].

5.  Acknowledgements

   TBD

6.  References

6.1.  Normative References

   [I-D.ietf-opsawg-ipfix-srv6-srh]
              Graf, T., Claise, B., and P. Francois, "Export of Segment
              Routing over IPv6 Information in IP Flow Information
              Export (IPFIX)", Work in Progress, Internet-Draft, draft-
              ietf-opsawg-ipfix-srv6-srh-14, 25 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              ipfix-srv6-srh-14>.

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

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/info/rfc7011>.

   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
              for IP Flow Information Export (IPFIX)", RFC 7012,
              DOI 10.17487/RFC7012, September 2013,
              <https://www.rfc-editor.org/info/rfc7012>.

   [RFC7015]  Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
              for the IP Flow Information Export (IPFIX) Protocol",
              RFC 7015, DOI 10.17487/RFC7015, September 2013,
              <https://www.rfc-editor.org/info/rfc7015>.

Graf, et al.             Expires 26 October 2024                [Page 6]
Internet-Draft           ipfix-alternate-marking              April 2024

   [RFC7133]  Kashima, S., Kobayashi, A., Ed., and P. Aitken,
              "Information Elements for Data Link Layer Traffic
              Measurement", RFC 7133, DOI 10.17487/RFC7133, May 2014,
              <https://www.rfc-editor.org/info/rfc7133>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
              and T. Zhou, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

   [RFC9342]  Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
              T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
              DOI 10.17487/RFC9342, December 2022,
              <https://www.rfc-editor.org/info/rfc9342>.

   [RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate-Marking Method",
              RFC 9343, DOI 10.17487/RFC9343, December 2022,
              <https://www.rfc-editor.org/info/rfc9343>.

6.2.  Informative References

   [I-D.fz-ippm-alt-mark-deployment]
              Fioccola, G., Zhou, T., Graf, T., Milan, F., Nilo, M.,
              Keyi, Z., and L. Zhang, "Alternate Marking Deployment
              Framework", Work in Progress, Internet-Draft, draft-fz-
              ippm-alt-mark-deployment-01, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-fz-ippm-alt-
              mark-deployment-01>.

   [I-D.fz-spring-srv6-alt-mark]
              Fioccola, G., Zhou, T., Cociglio, M., Mishra, G. S., wang,
              X., and G. Zhang, "Application of the Alternate Marking
              Method to the Segment Routing Header", Work in Progress,
              Internet-Draft, draft-fz-spring-srv6-alt-mark-08, 8
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-fz-spring-srv6-alt-mark-08>.

   [IANA-IPFIX]
              "IANA, IPFIX",
              <https://www.iana.org/assignments/ipfix/ipfix.xhtml>.

Graf, et al.             Expires 26 October 2024                [Page 7]
Internet-Draft           ipfix-alternate-marking              April 2024

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

Authors' Addresses

   Thomas Graf
   Swisscom
   Binzring 17
   CH-8045 Zurich
   Switzerland
   Email: thomas.graf@swisscom.com

   Giuseppe Fioccola
   Huawei
   Palazzo Verrocchio, Centro Direzionale Milano 2
   20054 Segrate (Milan)
   Italy
   Email: giuseppe.fioccola@huawei.com

   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhoutianran@huawei.com

   Fabrizio Milan
   Telecom Italia
   Via Reiss Romoli, 274
   10148 Torino
   Italy
   Email: fabrizio.milan@telecomitalia.it

Graf, et al.             Expires 26 October 2024                [Page 8]
Internet-Draft           ipfix-alternate-marking              April 2024

   Massimo Nilo
   Telecom Italia
   Via Reiss Romoli, 274
   10148 Torino
   Italy
   Email: massimo.nilo@telecomitalia.it

Graf, et al.             Expires 26 October 2024                [Page 9]