Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)

Giuseppe Fioccola <> Wed, 29 June 2022 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B2B0C15AAC8; Wed, 29 Jun 2022 00:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BerDfPmShjte; Wed, 29 Jun 2022 00:41:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F091C15A754; Wed, 29 Jun 2022 00:41:47 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4LXtgG3yC3z685PJ; Wed, 29 Jun 2022 15:40:58 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 29 Jun 2022 09:41:43 +0200
Received: from ([]) by ([]) with mapi id 15.01.2375.024; Wed, 29 Jun 2022 09:41:43 +0200
From: Giuseppe Fioccola <>
To: Greg Mirsky <>, Susan Hares <>, idr wg <>
CC: "" <>
Thread-Topic: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Thread-Index: AdiH3wDOZoF+C+T2QMi2y4hchL4BsgDbmcgAAAv60eA=
Date: Wed, 29 Jun 2022 07:41:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_29fda6076e1143c58e8c79bbf545501chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jun 2022 07:41:51 -0000

Hi Greg,
Thanks for the feedback.
Please note that following use cases are considered:

  *   Regarding draft-ietf-idr-sr-policy-ifit, it is simply extended draft-ietf-idr-segment-routing-te-policy in order to distribute SR policies carrying IFIT information. The extension is limited to SR-Policy and, since the CPE (or the PE) is most likely to be the starting or ending node of an SR candidate path, it can delimit a controlled domain only if it is fully managed by the service provider. As also mentioned in draft-ietf-idr-segment-routing-te-policy, SR operates within a trusted SR domain (RFC8402) and its security considerations also apply to BGP sessions when carrying SR Policy information.

  *   Regarding draft-wang-idr-ifit-capabilities, it only leverages the BGP Next-Hop Capability (draft-ietf-idr-next-hop-capability) which is a non-transitive BGP attribute. Since IOAM and Alt-Mark are applied to controlled domains, the decapsulating node (e.g. PE2) must be able to handle and remove the IOAM and/or Alt-Mark header and the encapsulating node (e.g. PE1) must know which capabilities can be enabled. In this scenario, the IFIT Capabilities can be encoded as a BGP Next-Hop IFIT Attribute and indicates that the BGP Next-Hop supports the IFIT capability. Since this attribute is non-transitive (not allowed to be sent to others other than the BGP Next-Hop) and it is removed when the BGP Next-Hop is changed, these characteristics help to meet the controlled domain requirement.



From: ippm <> On Behalf Of Greg Mirsky
Sent: Wednesday, June 29, 2022 4:16 AM
To: Susan Hares <>; idr wg <>
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)

Hi Susan,
thank you for bringing these drafts to my attention. As I understand the scope of IFIT, it combines various on-path telemetry mechanisms, including IOAM and Alternate Marking. Both IOAM and Alternate Marking are intended for deployment in limited domains (per the definition of a limited domain in RFC 8799<>. And an example of a limited domain is an enterprise network, a home network. Given that IOAM and Alternate marking to be deployed in a limited domain, what could be a use case for the extension of BGP in support of the IFIT?


On Fri, Jun 24, 2022 at 8:29 AM Susan Hares <<>> wrote:
Marcus, Tommy and ippm WG:

The IDR WG would like your feedback on two drafts in IDR:

1. draft-ietf-idr-sr-policy-ifit-03.txt – The IDR WG is planning WG LC on this draft in August.
2.<> – The IDR WG has consensus on adopting this draft.

Please let us know if you have any concerns regarding these drafts.

We note that these drafts reference:

1) draft-ietf-6man-ipv6-alt-mark
2) draft-ietf-ippm-ioam-data
3) draft-ietf-ippm-ioam-direct-export
4) draft-ietf-ippm-ioam-flags
5) draft-ietf-ippm-ioam-ipv6-options

Please let me know if you have any questions regarding these two drafts.

I am one of the IDR WG co-chairs and the shepherd for these two drafts.

You can reply to this thread or provide information to your WG chairs.

Cheers, Susan Hares
ippm mailing list<>