Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06

Hi Greg,
Yes, this is the supposed behavior as specified in IOAM and Alt-Mark documents.
For IPv6, IOAM and Alt-Mark are encapsulated in option data fields using extension headers (either HBH or DOH). Both draft-ietf-6man-ipv6-alt-mark and draft-ietf-ippm-ioam-ipv6-options state that nodes that do not support the Option must ignore it, according to the procedures of RFC8200.
For MPLS, it also applies to draft-ietf-mpls-rfc6374-sfl. Looking at draft-gandhi-mpls-ioam, it is also mentioned that the intermediate node that is not capable of supporting the IOAM functions can simply skip the IOAM processing.

Regards,

Giuseppe

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Saturday, July 2, 2022 4:45 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: wangaj3@chinatelecom.cn; Dhruv Dhody <dd@dhruvdhody.com>; pce@ietf.org; draft-chen-pce-pcep-ifit@ietf.org
Subject: Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06

Hi Giuseppe,
I have a question about your statement:
But if nodes on the path do not support some capabilities, it is not a big issue. Indeed, both Alternate Marking and IOAM documents specify that nodes that do not support a specific functionality will forward the packet without any changes to the data fields and they are simply not considered in the measurement.
Is the expectation that a packet marked with IOAM or AltMarking will be forwarded by a non-supporting node applies to all IETF networking technologies, for example in an MPLS network?

Regards,
Greg

On Fri, Jul 1, 2022 at 8:55 AM Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hi Aijun,
Thanks for the support.
Regarding your question, I think we can clarify this point in the next version. If a PCE instantiates a path on the PCC with an IFIT capability enabled, it is supposed that there are at least two nodes (e.g. starting and ending node) which support it. But if nodes on the path do not support some capabilities, it is not a big issue. Indeed, both Alternate Marking and IOAM documents specify that nodes that do not support a specific functionality will forward the packet without any changes to the data fields and they are simply not considered in the measurement.

Regards,

Giuseppe

From: wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>
Sent: Friday, July 1, 2022 11:26 AM
To: 'Dhruv Dhody' <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>
Cc: draft-chen-pce-pcep-ifit@ietf.org<mailto:draft-chen-pce-pcep-ifit@ietf.org>
Subject: 答复: WG Adoption of draft-chen-pce-pcep-ifit-06

Hi, All:

I support its adoption.

One questions to the authors:
Is it enough that only the headend support the defined iFIT capabilities? What’s the procedures when the nodes on the LSP/SR path doesn’t support the defined iFIT capabilities?

Aijun Wang
China Telecom

发件人: Dhruv Dhody [mailto:dd@dhruvdhody.com]
发送时间: 2022年6月24日 16:59
收件人: pce@ietf.org<mailto:pce@ietf.org>
抄送: draft-chen-pce-pcep-ifit@ietf.org<mailto:draft-chen-pce-pcep-ifit@ietf.org>
主题: WG Adoption of draft-chen-pce-pcep-ifit-06

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-pcep-ifit-06.

https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th July 2022.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce