Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Dhruv, Julien, Thank you for the update on the adoption call. It is ok. We will post the -00 version next week and then we will work on the -01 version to address the comments received during the adoption call. Best Regards, Giuseppe From: Dhruv Dhody Sent: Tuesday, July 19, 2022 12:54 PM To: pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: Re: WG Adoption of draft-chen-pce-pcep-ifit-06 Hi WG, The adoption call is concluded and we have a new WG I-D. Thanks to those who provided feedback and comments. Authors, Please post a -00 version with no content change when the submission reopens at 2022-07-23 23:59 EDT (IETF-meeting local time). Please handle comments received in -01. Since you also have a slot during the PCE WG meeting, please focus on the comments received and your plan to handle them during the session. Thanks! Dhruv & Julien On Fri, Jun 24, 2022 at 2:28 PM Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi WG, The adoption call is concluded and we have a new WG I-D. Thanks to those who provided feedback and comments. Authors, Please post a -00 version with no content change when the submission reopens at 2022-07-23 23:59 EDT (IETF-meeting local time). Please handle comments received in -01. Since you also have a slot during the PCE WG meeting, please focus on the comments received and your plan to handle them during the session. Thanks! Dhruv & Julien On Fri, Jun 24, 2022 at 2:28 PM Dhruv Dhody wrote: > 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Greg, I think that, since these PCEP extensions for IFIT are valid for all path types, we can just omit the MPLS example for now. Maybe it can be added again in a later version as soon as the MNA solution is clearly defined. Regards, Giuseppe From: Greg Mirsky Sent: Monday, July 11, 2022 9:52 PM To: Tianran Zhou Cc: Giuseppe Fioccola ; wang...@chinatelecom.cn; Dhruv Dhody ; pce@ietf.org; draft-chen-pce-pcep-i...@ietf.org Subject: 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 mailto:zhoutian...@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:gregimir...@gmail.com<mailto:gregimir...@gmail.com>] Sent: Tuesday, July 5, 2022 3:39 AM To: Giuseppe Fioccola mailto:giuseppe.fiocc...@huawei.com>> Cc: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>; Dhruv Dhody mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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 mailto:giuseppe.fiocc...@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 mailto:gregimir...@gmail.com>> Sent: Monday, July 4, 2022 6:40 PM To: Giuseppe Fioccola mailto:giuseppe.fiocc...@huawei.com>> Cc: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>; Dhruv Dhody mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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 mailto:giuseppe.fiocc...@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 mailto:gregimir...@gmail.com>> Sent: Saturday, July 2, 2022 4:45 AM To: Giuseppe Fioccola mailto:giuseppe.fiocc...@huawei.com>> Cc: wang...@chinatelecom.cn<mailto:wang...@chinatel
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 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:gregimir...@gmail.com] > *Sent:* Tuesday, July 5, 2022 3:39 AM > *To:* Giuseppe Fioccola > *Cc:* wang...@chinatelecom.cn; Dhruv Dhody ; > pce@ietf.org; draft-chen-pce-pcep-i...@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.fiocc...@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 > *Sent:* Monday, July 4, 2022 6:40 PM > *To:* Giuseppe Fioccola > *Cc:* wang...@chinatelecom.cn; Dhruv Dhody ; > pce@ietf.org; draft-chen-pce-pcep-i...@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.fiocc...@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 > *Sent:* Saturday, July 2, 2022 4:45 AM > *To:* Giuseppe Fioccola > *Cc:* wang...@chinatelecom.cn; Dhruv Dhody ; > pce@ietf.org; draft-chen-pce-pcep-i...@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 spec
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Dhruv and all, I support the adoption of the draft, I think it will be useful to extend PCEP for signaling IFIT capabilities and attributes between PCE and PCC as part of bigger IFIT framework. SR Policy is a just one use case as it was already mentioned in previous emails. SY,Boris 24.06.2022, 11:59, "Dhruv Dhody" :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 listPce@ietf.orghttps://www.ietf.org/mailman/listinfo/pce___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Adrian, Thank you for the detailed review and for the support. We will address your inputs in the next revision. Please find my further replies inline tagged as [GF]. Best Regards, Giuseppe From: Adrian Farrel Sent: Friday, July 8, 2022 1:18 AM To: 'Dhruv Dhody' ; pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: RE: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06 Hi, I read through this draft as part of the adoption poll. I found it quite hard to work out from the Abstract what the purpose of the document is. The Introduction is a little more informative, but also quite hard work. It turns out, when you read the document, that two things are being defined: 1. A set of attributes to allow a PCE to instruct a PCC as to which IFIT behaviours it should enable on a path. 2. A capabilities flags so that a PCC can indicate which IFIT functions it supports. I think the Abstract might usefully read as follows. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The PCEP extensions described in this document are defined for use with Segment Routing (SR). They could be generalized for all path types, but that is out of scope of this document. [GF]: Good suggestion. We can change the wording as suggested. The Introduction might also usefully change in that way. [GF]: Ok, we will revise the Introduction as well. --- While I appreciate that the authors are primarily concerned with SR, I think the WG should carefully consider taking the authors at their word and pursuing the generalisation to all path types. That can't be much additional work, and it would surely make sense to get the solution to be generic from day one. [GF]: I agree. We will try to better highlight that the draft is general to all path types. We can also move the part on Segment Routing to a later section just as an example. --- Please move the requirements language from the front-matter to its own section (probably 1.1). [GF]: Ok --- With the clarification of the intent of the document, I would support the working group working on this document, and it could be adopted. [GF]: Thank you! Regards, Adrian From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of Dhruv Dhody Sent: 24 June 2022 09:59 To: pce@ietf.org<mailto:pce@ietf.org> Cc: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@ietf.org> Subject: [Pce] 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi WG, I support the adoption as a coauthor. Best, Yali From: Dhruv Dhody [mailto:d...@dhruvdhody.com] Sent: Friday, June 24, 2022 4:59 PM To: pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi, I read through this draft as part of the adoption poll. I found it quite hard to work out from the Abstract what the purpose of the document is. The Introduction is a little more informative, but also quite hard work. It turns out, when you read the document, that two things are being defined: 1. A set of attributes to allow a PCE to instruct a PCC as to which IFIT behaviours it should enable on a path. 2. A capabilities flags so that a PCC can indicate which IFIT functions it supports. I think the Abstract might usefully read as follows. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The PCEP extensions described in this document are defined for use with Segment Routing (SR). They could be generalized for all path types, but that is out of scope of this document. The Introduction might also usefully change in that way. --- While I appreciate that the authors are primarily concerned with SR, I think the WG should carefully consider taking the authors at their word and pursuing the generalisation to all path types. That can't be much additional work, and it would surely make sense to get the solution to be generic from day one. --- Please move the requirements language from the front-matter to its own section (probably 1.1). --- With the clarification of the intent of the document, I would support the working group working on this document, and it could be adopted. Regards, Adrian From: Pce On Behalf Of Dhruv Dhody Sent: 24 June 2022 09:59 To: pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: [Pce] 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
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:gregimir...@gmail.com] Sent: Tuesday, July 5, 2022 3:39 AM To: Giuseppe Fioccola Cc: wang...@chinatelecom.cn; Dhruv Dhody ; pce@ietf.org; draft-chen-pce-pcep-i...@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 mailto:giuseppe.fiocc...@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 mailto:gregimir...@gmail.com>> Sent: Monday, July 4, 2022 6:40 PM To: Giuseppe Fioccola mailto:giuseppe.fiocc...@huawei.com>> Cc: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>; Dhruv Dhody mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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 mailto:giuseppe.fiocc...@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 mailto:gregimir...@gmail.com>> Sent: Saturday, July 2, 2022 4:45 AM To: Giuseppe Fioccola mailto:giuseppe.fiocc...@huawei.com>> Cc: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>; Dhruv Dhody mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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 mailto:40huawei@dmarc.ietf.org>> wrote: Hi Aijun, Thanks for the support. Regarding your question, I think we c
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.fiocc...@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 > *Sent:* Monday, July 4, 2022 6:40 PM > *To:* Giuseppe Fioccola > *Cc:* wang...@chinatelecom.cn; Dhruv Dhody ; > pce@ietf.org; draft-chen-pce-pcep-i...@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.fiocc...@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 > *Sent:* Saturday, July 2, 2022 4:45 AM > *To:* Giuseppe Fioccola > *Cc:* wang...@chinatelecom.cn; Dhruv Dhody ; > pce@ietf.org; draft-chen-pce-pcep-i...@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 40huawei@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 > > > > >
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
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 Sent: Monday, July 4, 2022 6:40 PM To: Giuseppe Fioccola Cc: wang...@chinatelecom.cn; Dhruv Dhody ; pce@ietf.org; draft-chen-pce-pcep-i...@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 mailto:giuseppe.fiocc...@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 mailto:gregimir...@gmail.com>> Sent: Saturday, July 2, 2022 4:45 AM To: Giuseppe Fioccola mailto:giuseppe.fiocc...@huawei.com>> Cc: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>; Dhruv Dhody mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org>; draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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 mailto:40huawei@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: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn> mailto:wang...@chinatelecom.cn>> Sent: Friday, July 1, 2022 11:26 AM To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org> Cc: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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:d...@dhruvdhody.com] 发送时间: 2022年6月24日 16:59 收件人: pce@ietf.org<mailto:pce@ietf.org> 抄送: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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://datatr
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Gyan, Thank you for the support and for sharing your thoughts. Note that, in draft-chen-pce-pcep-ifit, the term IFIT only denotes IOAM and Alt-Mark together. For this reason, I think that this draft can be considered independent from the framework since it defines a PCEP extension to distribute IFIT (IOAM and Alt-Mark) information. Therefore, the IFIT attributes defined in this document simply complement the relevant PCEP data plane extensions. As an example, for Segment Routing, it complements RFC 8664, draft-ietf-pce-segment-routing-ipv6 and draft-ietf-pce-segment-routing-policy-cp to automatically enable IOAM and Alt-Mark behavior when the path is instantiated. But, as you suggested, since this draft could also be considered as one building block of a whole framework, a reference to draft-song-opsawg-ifit-framework may be added. Regards, Giuseppe From: Gyan Mishra Sent: Friday, July 1, 2022 7:37 PM To: Dhruv Dhody Cc: draft-chen-pce-pcep-i...@ietf.org; pce@ietf.org Subject: Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06 Dear WG I support adoption by PCE WG and would be willing to work on the draft. I support IFIT PCE extension to carry the IFIT attributes for in-situ IOAM on path telemetry. I do agree this would be very useful for operators. I was looking for a framework draft for IFIT and this is what I found. I think a framework draft for IFIT solution should be addressed in the draft in the introduction. I noticed that there are a number of ifit related drafts across many WGs with a variety of authors and it appears no common author across all the documents. Is there an IFIT framework draft of the overall IFIT architecture and goals? IFIT is a component of IPPM IOAM but I think it should have its own framework draft. I did find this IFIT framework draft which I don’t see as informational reference in this document. https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ Of all the IFIT related drafts I do see one adopted. https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-ifit/ Kind Regards Gyan On Fri, Jun 24, 2022 at 4:59 AM Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: 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 -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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.fiocc...@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 > *Sent:* Saturday, July 2, 2022 4:45 AM > *To:* Giuseppe Fioccola > *Cc:* wang...@chinatelecom.cn; Dhruv Dhody ; > pce@ietf.org; draft-chen-pce-pcep-i...@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 40huawei@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:* wang...@chinatelecom.cn > *Sent:* Friday, July 1, 2022 11:26 AM > *To:* 'Dhruv Dhody' ; pce@ietf.org > *Cc:* draft-chen-pce-pcep-i...@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:d...@dhruvdhody.com ] > *发送时间:* 2022年6月24日 16:59 > *收件人:* pce@ietf.org > *抄送:* draft-chen-pce-pcep-i...@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 > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Xuerong, Thanks for the support and for the comments. Please see my replies inline tagged as [GF]. Regards, Giuseppe From: 王 雪荣 Sent: Monday, July 4, 2022 11:56 AM To: Dhruv Dhody ; pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: 回复: WG Adoption of draft-chen-pce-pcep-ifit-06 Hi WG, I support the adoption of this draft. I think this is an very useful extension. There are several comments after reviewing the document: 1) It is mentioned the example of SR-MPLS and SRv6 in the draft. What about IPv6? Is it possible to add an example for IPv6 by leveraging draft-ietf-pce-pcep-extension-native-ip? [GF]: Yes, this PCEP extension is general, therefore it can also be applied to the scenario of Native IP network. I can mention this point in the next revision of the draft. 2) What is the relation of the IFIT PCEP extension with the companion draft-ietf-idr-sr-policy-ifit which defines the BGP extension to enable IFIT methods for SR policy? [GF]: For Segment Routing, both PCEP and BGP can be used to instantiate SR Policies, so it makes sense to have the same mechanism for PCEP and BGP. In particular, draft-ietf-idr-sr-policy-ifit simply extends the advertisement of SR Policies in BGP (draft-ietf-idr-segment-routing-te-policy) to include IFIT information. Therefore, this extension is limited to SR-Policy. While, for PCEP, the extension is general and the application to SR Policies is an example. 3) Section 2.1 is about “IFIT for SR Policies” and Section 6 is about “Example of application to SR Policy”. Since the PCEP Extension is general for all path types and SR Policy is just an example, why not merge section 2.1 in section 6? [GF]: Sure, it can be possible to merge the two sections. Thanks Wangxuerong +86 15323320217 xuerongwang_chinatele...@hotmail.com/wang...@chinatelecom.cn<mailto:xuerongwang_chinatele...@hotmail.com/wang...@chinatelecom.cn> 发件人: Dhruv Dhody mailto:d...@dhruvdhody.com>> 发送时间: 2022年6月24日 16:58 收件人: pce@ietf.org<mailto:pce@ietf.org> mailto:pce@ietf.org>> 抄送: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@ietf.org> mailto:draft-chen-pce-pcep-i...@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
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 Sent: Saturday, July 2, 2022 4:45 AM To: Giuseppe Fioccola Cc: wang...@chinatelecom.cn; Dhruv Dhody ; pce@ietf.org; draft-chen-pce-pcep-i...@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 mailto:40huawei@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: wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn> mailto:wang...@chinatelecom.cn>> Sent: Friday, July 1, 2022 11:26 AM To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com>>; pce@ietf.org<mailto:pce@ietf.org> Cc: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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:d...@dhruvdhody.com] 发送时间: 2022年6月24日 16:59 收件人: pce@ietf.org<mailto:pce@ietf.org> 抄送: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi WG, It is necessary to have the control plane support for the covered data plane technologies and the proposal is reasonable, therefore I support the adoption of this draft. Thanks! Haoyu On Fri, Jun 24, 2022 at 4:59 AM Dhruv Dhody mailto:d...@dhruvdhody.com>> wrote: 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-pce-pcep-ifit%2F=05%7C01%7Chaoyu.song%40futurewei.com%7C021c245297784b1d9ea108da5bcd8ef9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637923235732822598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C=BN9IQ3qmWT42vAwaYJoXjFGwGf8cpOjn8lEz%2BaWxEbI%3D=0> 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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpce=05%7C01%7Chaoyu.song%40futurewei.com%7C021c245297784b1d9ea108da5bcd8ef9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637923235732822598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C=nysp65ncMjtUzm%2FU%2BnYmS3aLcUTldmut4EWxUDRVg1w%3D=0> -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F=05%7C01%7Chaoyu.song%40futurewei.com%7C021c245297784b1d9ea108da5bcd8ef9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637923235732822598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C=DPGmWEOUuCHZ2WEj%2FTYxjZN9E4ZKoMYuaonpARZkzc4%3D=0> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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 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:* wang...@chinatelecom.cn > *Sent:* Friday, July 1, 2022 11:26 AM > *To:* 'Dhruv Dhody' ; pce@ietf.org > *Cc:* draft-chen-pce-pcep-i...@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:d...@dhruvdhody.com ] > *发送时间:* 2022年6月24日 16:59 > *收件人:* pce@ietf.org > *抄送:* draft-chen-pce-pcep-i...@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 > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi， all， I support the adoption of this document. Thanks. Chongfeng On Fri, Jun 24, 2022 at 4:59 AM Dhruv Dhody wrote: 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 -- Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com M 301 502-1347 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Dear WG I support adoption by PCE WG and would be willing to work on the draft. I support IFIT PCE extension to carry the IFIT attributes for in-situ IOAM on path telemetry. I do agree this would be very useful for operators. I was looking for a framework draft for IFIT and this is what I found. I think a framework draft for IFIT solution should be addressed in the draft in the introduction. I noticed that there are a number of ifit related drafts across many WGs with a variety of authors and it appears no common author across all the documents. Is there an IFIT framework draft of the overall IFIT architecture and goals? IFIT is a component of IPPM IOAM but I think it should have its own framework draft. I did find this IFIT framework draft which I don’t see as informational reference in this document. https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ Of all the IFIT related drafts I do see one adopted. https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-ifit/ Kind Regards Gyan On Fri, Jun 24, 2022 at 4:59 AM Dhruv Dhody wrote: > 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com * *M 301 502-1347* ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
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: wang...@chinatelecom.cn Sent: Friday, July 1, 2022 11:26 AM To: 'Dhruv Dhody' ; pce@ietf.org Cc: draft-chen-pce-pcep-i...@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:d...@dhruvdhody.com] 发送时间: 2022年6月24日 16:59 收件人: pce@ietf.org<mailto:pce@ietf.org> 抄送: draft-chen-pce-pcep-i...@ietf.org<mailto:draft-chen-pce-pcep-i...@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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Chairs, I support the adoption of this document. Best regards, Jie From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: Friday, June 24, 2022 4:59 PM To: pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: [Pce] 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi all, I support the adoption. It is useful to carry the ifit information in PCEP communications. Best Regards Zongpeng Du duzongp...@foxmail.com & duzongp...@chinamobile.com From: Dhruv Dhody Date: 2022-06-24 17:28 To: pce CC: draft-chen-pce-pcep-ifit Subject: [Pce] 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi Everyone, I support the adoption of this useful document. Best Regards, Huaimo From: Pce on behalf of Dhruv Dhody Sent: Friday, June 24, 2022 4:58 AM To: pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: [Pce] 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-pce-pcep-ifit%2F=05%7C01%7Chuaimo.chen%40futurewei.com%7C572b6ab90f784867a22308da55bfdfb4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637916579842607840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4B97O92bUwZl6WX6n5Sa%2Bq8M7iYtCCaLAkAffIx%2FZoU%3D=0> 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi All, I support the adoption. Best Regards, Zhenbin (Robin) 李振斌 Li Zhenbin Mobile: +86-13651017745/+968-91797068 Email: lizhen...@huawei.com 发件人：Dhruv Dhody 收件人：pce 抄 送：draft-chen-pce-pcep-ifit 时 间：2022-06-24 17:00:57 主 题：[Pce] 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
Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06
Hi WG, I support the adoption as a coauthor. Best, Tianran From: Dhruv Dhody [mailto:d...@dhruvdhody.com] Sent: Friday, June 24, 2022 4:59 PM To: pce@ietf.org Cc: draft-chen-pce-pcep-i...@ietf.org Subject: 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
[Pce] 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
