Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt

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.

Regards,

Giuseppe

From: ippm <ippm-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: Wednesday, June 29, 2022 4:16 AM
To: Susan Hares <shares@ndzh.com>; idr wg <idr@ietf.org>
Cc: ippm@ietf.org
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<https://datatracker.ietf.org/doc/html/rfc8799>. 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?

Regards,
Greg

On Fri, Jun 24, 2022 at 8:29 AM Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> 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. draft-wang-idr-ifit-capabilities-05.tt<http://draft-wang-idr-ifit-capabilities-05.tt> – 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
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm