Skip to main content

2. Application of the Alternate-Marking Method to SRv6

This section preserves the RFC text for the SRH AltMark TLV experiment, including Alternate-Marking Method, SRv6, SRH, FlowMonID, L and D flags, NH, enhanced fields, controlled-domain requirements, security, and IANA considerations.

Original RFC Text​

2.  Application of the Alternate-Marking Method to SRv6

   SRv6 leverages the IPv6 SRH, which can embed TLVs to provide metadata
   for segment processing, as described in [RFC8754].  This document
   defines the SRH AltMark TLV to carry Alternate-Marking data fields
   for use in SRv6 networks, and it is an alternative to the method
   described in [RFC9343].  [RFC9343] defines how the Alternate-Marking
   Method can be carried in the Option Headers (Hop-by-Hop or
   Destination) of an IPv6 packet.  The AltMark data fields format
   defined in [RFC9343] is the basis of the AltMark SRH TLV introduced
   in Section 3.

   In addition to the base data fields of [RFC9343], the insertion of
   optional extended data fields that are not present in [RFC9343] is
   also allowed.  These extended data fields can support metadata for
   additional telemetry requirements, as further described below.

2.1.  Controlled Domain

   [RFC8799] introduces the concept of specific limited domain solutions
   and notes the application of the Alternate-Marking Method as an
   example.

   Despite the flexibility of IPv6, when innovative applications are
   proposed, they are often applied within controlled domains to help
   constrain the domain-wide policies, options supported, the style of
   network management, and security requirements.  This is also the case
   for applying the Alternate-Marking Method to SRv6.

   Therefore, the experiment of applying the Alternate-Marking Method to
   SRv6 MUST only be deployed within a controlled domain.  For SRv6, the
   controlled domain corresponds to an SR domain, as defined in
   [RFC8402].  The Alternate-Marking measurement domain overlaps with
   the controlled domain.

   The use of a controlled domain is also appropriate for the deployment
   of an experimental protocol extension.  Carefully bounding the domain
   reduces the risk of the experiment leaking out and clashing with
   other experiments or causing unforeseen consequences in wider
   deployments.