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

Hi Tianran,
thank you for your response. Your proposal to remove an MPLS network from
the scope of this draft is interesting. What do the authors think of this?

Regards,
Greg

On Mon, Jul 4, 2022 at 11:18 PM Tianran Zhou <zhoutianran@huawei.com> wrote:

> Hi Greg,
>
>
>
> MNA is quite a new thing. And we cannot predict the solution nor analysis.
>
> For example, I am not sure in this case, if the bSPL is on the top or
> always at the bottom.
>
> If the bSPL is on the top for Hop by Hop use, I agree there will be packet
> drop if the node does not support.
>
> It’s also possible to keep the bSPL at the bottom. So the transit nodes do
> not aware.
>
> My suggestion is to exclude the MPLS encapsulation in this draft until we
> have a clear NMA solution.
>
> Best,
>
> Tianran
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Tuesday, July 5, 2022 3:39 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,
>
> thank you for your expedient reply. I understand RFC 9197 differently. In
> my opinion, it applies to nodes that support it, i.e., IOAM, but not all
> trace options or IOAM data types. It seems reasonable to have MNA
> extensions in the control and management plane (e.g., YANG data model)
> advertising MNA capabilities so that an MPLS label stack can be constructed
> in a manner avoiding MNA bSPL coming to the top on MNA unsupporting node.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jul 4, 2022 at 10:35 AM Giuseppe Fioccola <
> giuseppe.fioccola@huawei.com> wrote:
>
> Hi Greg,
>
> Thank you for pointing out the ongoing work on the MPLS Network Actions
> (MNA).
>
> I agree with you that, for MPLS, this is a possibility to consider
> especially in case it will conflict with IOAM specification in RFC 9197,
> where it is stated that a transit node must ignore option types that it
> does not understand.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Monday, July 4, 2022 6:40 PM
> *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,
>
> thank you for your quick response. I agree with your analysis regarding
> the IOAM and AltMark marked packets in an IPv6 network. And yes,
> Synonymous Flow Label can be used in an MPLS network to support the AltMark
> method. But I am not sure that the solution proposed in
> draft-gandhi-mpls-ioam is the one that is going to be adopted. I would like
> to note the ongoing work on the MPLS Network Actions (MNA) in the MPLS WG
> and the IOAM is considered one of the use cases in
> draft-ietf-mpls-mna-usecases
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>. It
> might be that IAOM in MPLS would not be supported using G-ACh but MNA with
> post-stack data (PSD) approach. If that is the case and since MAN will use
> the newly assigned base Special Purpose Label (bSPL), a node that does not
> support MNA will drop the packet when that bSPL is discovered as the top
> label.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Mon, Jul 4, 2022 at 1:27 AM Giuseppe Fioccola <
> giuseppe.fioccola@huawei.com> wrote:
>
> 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> 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 <wangaj3@chinatelecom.cn>
> *Sent:* Friday, July 1, 2022 11:26 AM
> *To:* 'Dhruv Dhody' <dd@dhruvdhody.com>; pce@ietf.org
> *Cc:* 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 <dd@dhruvdhody.com>]
> *发送时间:* 2022年6月24日 16:59
> *收件人:* pce@ietf.org
> *抄送:* 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
> https://www.ietf.org/mailman/listinfo/pce
>
>