Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

From: "Susan Hares" <[email-masked]>
Date: Mon, 2 Nov 2020 00:56:46 -0500

This begins a 2 week WG adoption call for
draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020). 

The draft can be accessed at: 

https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/

The authors should provide IPR statements by 11/5/2020 so the IDR WG can
consider the IPR status in their 

decision. 

This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the
SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel
types.  Within the IFIT  sub-TLV value field, 5 sub-TLVs may be included (4
for IOAM and 1 for Enhanced Alternate Marking).   

The IDR co-chairs thank the authors for their patience.  The WG adoption
call for this draft has been delayed by the process of switching shepherds
for BGP Tunnel Encaps draft.  Many BESS and IDR drafts currently refer to
the BGP tunnel encapsulation drafts. 

In your review of this draft, please differentiate between the following: 

.         Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing
technology,

.         Support/rejection of alternate marking as a IP routing technology,

.         Support/rejection of adding new sub-TLVS for SR Policy tunnel type
of BGP Tunnel Encap Attribute, and   

.         Specific issues with the descriptions of these features in the
draft. 

Cheers, Susan Hares

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 2 Nov 2020 16:57:48 +0000

Dear Susan, All,
I'm not aware of any IPR related to this draft. I also support its adoption as coauthor.

Best Regards,

Giuseppe

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 6:57 AM
To: [email-masked]
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

The authors should provide IPR statements by 11/5/2020 so the IDR WG can consider the IPR status in their
decision.

This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute for the SR policy tunnel type. This sub-TLV is only valid for SR Policy tunnel types.  Within the IFIT  sub-TLV value field, 5 sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).

The IDR co-chairs thank the authors for their patience.  The WG adoption call for this draft has been delayed by the process of switching shepherds for BGP Tunnel Encaps draft.  Many BESS and IDR drafts currently refer to the BGP tunnel encapsulation drafts.

*       Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing technology,

*       Support/rejection of alternate marking as a IP routing technology,

*       Support/rejection of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute, and

*       Specific issues with the descriptions of these features in the draft.

Cheers, Susan Hares

---

From: wangyali <[email-masked]>
Date: Tue, 3 Nov 2020 01:36:56 +0000

Hi Susan and all,

As a co-author, I support the adoption of this draft. I'm not aware of any IPRs related to this draft.

Best regards,
Yali

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 1:57 PM
To: [email-masked]
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: "qinfengwei" <[email-masked]>
Date: Tue, 3 Nov 2020 10:02:25 +0800

Hi,

         I’m not aware of any IPRs related to this draft and support this
adoption as a co-editor.

Thanks,

Fengwei Qin

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年11月2日 13:57
收件人: [email-masked]
主题: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt
(11/1/2020 to 11/16/2020)

decision. 

・        Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing
technology,

・        Support/rejection of alternate marking as a IP routing technology,

・        Support/rejection of adding new sub-TLVS for SR Policy tunnel type
of BGP Tunnel Encap Attribute, and   

・        Specific issues with the descriptions of these features in the
draft. 

Cheers, Susan Hares

---

From: Huzhibo <[email-masked]>
Date: Tue, 3 Nov 2020 07:10:13 +0000

Yes，support.

Regards,
Zhibo

・         Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing technology,

・         Support/rejection of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute, and

・         Specific issues with the descriptions of these features in the draft.

Cheers, Susan Hares

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 3 Nov 2020 18:10:17 +0800

Hi, WG,
    I have reviewd the draft. It provides a useful method to support ifit application.
    I support the adoption of this draft.

HUANAN CHEN（陈华南）
数据通信研究所
中国电信股份有限公司研究院
Data Communication Research Department
Research Institute of China Telecom Co.,Ltd.
Tel：020-3863-9346
PH：133-1609-7163
QQ：17335837
Mail：[email-masked]
   [email-masked] 
 
From: Susan Hares
Date: 2020-11-02 13:56
To: [email-masked]

 

In your review of this draft, please differentiate between the following: 
·         Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing technology,
·         Support/rejection of alternate marking as a IP routing technology,  
·         Support/rejection of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute, and   
·         Specific issues with the descriptions of these features in the draft. 
 
Cheers, Susan Hares

---

From: Chenshuanglong <[email-masked]>
Date: Tue, 3 Nov 2020 10:18:53 +0000

Hi All,

I support the WG adoption of the draft.

Regards,

Shuanglong (Evan)

From: Susan Hares<mailto:[email-masked]>
Date: 2020-11-02 13:56
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)
This begins a 2 week WG adoption call for draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).

•         Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing technology,

•         Support/rejection of alternate marking as a IP routing technology,

•         Support/rejection of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attribute, and

•         Specific issues with the descriptions of these features in the draft.

Cheers, Susan Hares

---

From: "Bulgarella Fabio (Guest)" <[email-masked]>
Date: Tue, 3 Nov 2020 11:13:08 +0000

Dear All,

I support the adoption of this draft that implement IOAM and Alternate Marking in the context of SR Policy.

Regards,

Fabio B.

Cheers, Susan Hares

---

From: Nilo Massimo <[email-masked]>
Date: Tue, 3 Nov 2020 11:16:45 +0000

Dear all,

I support the adoption of this draft, because it is a implementation of Alternate Marking related to the SR Policy.

Best regards,
Massimo N.

Cheers, Susan Hares

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 4 Nov 2020 02:02:18 +0000

Hi Sue,

I support the adoption of this document. It provides an useful mechanism to automatically enable the required OAM functions on SR policy.

Best regards,
Jie

Cheers, Susan Hares

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Wed, 4 Nov 2020 17:06:46 +0800

I support of the adoption.

decision. 

・         Support/rejection of In-situ Flow Telemetry (IFIT) as a IP
routing technology,

・         Support/rejection of alternate marking as a IP routing
technology,  

・         Support/rejection of adding new sub-TLVS for SR Policy tunnel
type of BGP Tunnel Encap Attribute, and   

Cheers, Susan Hares

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Wed, 4 Nov 2020 13:26:26 +0000

Hi, WG,

   I support the adoption of the draft. It will be useful to implement IOAM and Alternate Marking in SR policy.

Best regards,
Pang Ran

Cheers, Susan Hares

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 5 Nov 2020 03:16:53 +0000

Hi Chairs and WG,

I support the adoption as coauthor.
I am not aware of any IPR that has not been disclosed.

Best,
Tianran

Cheers, Susan Hares

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 6 Nov 2020 04:43:16 +0000

Support.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Sent: Monday, November 2, 2020 12:56 AM
To: [email-masked] <[email-masked]>
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhu-idr-bgp-ls-path-mtu%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C0be7a78d580c401f98b108d87ef42b1c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637398934447663082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=L47QrtIioX%2FSnN%2FvytOMf0Q%2B7zjrlQtrXhF7UTjCrFk%3D&reserved=0>

decision.

Cheers, Susan Hares

---

From: Mach Chen <[email-masked]>
Date: Mon, 9 Nov 2020 07:15:15 +0000

Hi,

I have read the draft, and support the adoption of the draft.

Best regards,
Mach

Cheers, Susan Hares

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 11 Nov 2020 16:38:54 +0530

Hi Sue, WG,

I support adoption of this draft. Thanks the authors to maintain
parity and sync with PCEP draft as well. Some non-blocking comments
that could be useful to the authors -

Minor
- Update to RFC 8174 requirement language (from RFC 2119)
- Section 3, last paragraph only mentions SRv6. Should this also
include SR-MPLS as done in other places?
- Section 4, Sync it with the latest encoding structure at
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-10#section-2.2
(SRv6 Binding SID is missing)
- Section 5, what happens in case of empty IFIT Attributes Sub-TLV
i.e. no further IOAM sub-TLV and Length=0?
- Section 5, what happens if two conflicting IOAM sub-TLVs are
present? Say both Pre-allocated and incremental are included.
- Section 5, what happens if there is more than one instance of the
sub-TLV of the same type? More text for these error conditions is
required.
- Section 5.1, Add "and ignored on receipt" for the description of the
Rsvd field. (applicable at other instances as well)
- Some description about stopping IOAM or about modifying IOAM
techniques should also be added.
- Some text on backward compatibility i.e. an implementation that does
not understand IFIT Attributes Sub-TLV should be added

Nits
- Expand OAM, PCEP, on first use!
- Section 5.3, fields should be listed in the same order as the figure.
- Section 8, s/SHOULD not/SHOULD NOT/

Thanks!
Dhruv

On Mon, Nov 2, 2020 at 11:27 AM Susan Hares <[email-masked]> wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 11 Nov 2020 17:16:48 +0000

Hi Dhruv,
Thanks a lot for your comments. I have noted them and we will apply in the next revision.
In particular, I agree, in Section 5 we need to describe what happens for the error conditions you mentioned. We will specify the error handling actions to be aligned with draft-ietf-idr-segment-routing-te-policy.

Regards,

Giuseppe

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Wednesday, November 11, 2020 12:09 PM
To: Susan Hares <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Sue, WG,

I support adoption of this draft. Thanks the authors to maintain parity and sync with PCEP draft as well. Some non-blocking comments that could be useful to the authors -

Minor
- Update to RFC 8174 requirement language (from RFC 2119)
- Section 3, last paragraph only mentions SRv6. Should this also include SR-MPLS as done in other places?
- Section 4, Sync it with the latest encoding structure at
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-10#section-2.2
(SRv6 Binding SID is missing)
- Section 5, what happens in case of empty IFIT Attributes Sub-TLV i.e. no further IOAM sub-TLV and Length=0?
- Section 5, what happens if two conflicting IOAM sub-TLVs are present? Say both Pre-allocated and incremental are included.
- Section 5, what happens if there is more than one instance of the sub-TLV of the same type? More text for these error conditions is required.
- Section 5.1, Add "and ignored on receipt" for the description of the Rsvd field. (applicable at other instances as well)
- Some description about stopping IOAM or about modifying IOAM techniques should also be added.
- Some text on backward compatibility i.e. an implementation that does not understand IFIT Attributes Sub-TLV should be added

Nits

Thanks!
Dhruv

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 12 Nov 2020 03:28:01 +0000

Yes, support. IFIT provides a useful method for IOAM and EAM, and the protocol extension looks reasonable for me.

Thanks,
Cheng

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 13 Nov 2020 11:12:19 +0000

Hi Giuseppe,

First of all, thanks for making the updates to the document to clarify the objective and applicability of IFIT and this draft extensions specifically to the SR Policy signalled by BGP. A good part of the puzzle is at least clearer to me now.

Sec 3 says (and I am trying to paraphrase here - so please correct me), that these IFIT attributes (new TLVs) are signalled via BGP along with the SR Policy Candidate Path to "enable IOAM and Alternate Marking" mechanisms for that SR Policy. This way all traffic steered over that SR Policy with have the IOAM and Alt Marking headers inserted on them.

Is there a Spring WG document that describes the implications of actually how this would get applied to the SR Policy forwarding planes (SR-MPLS and SRv6) and what types of Steering would be possible to be used for such SR Policies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-09#section-8). ? E.g. if a packet is arriving at the headend with a stack of labels and gets steered via BSID into such an SR Policy where "IFIT is applied", how does that work?

Sec 6 (SR Policy operations with IFIT Attributes) says the following:

The validation of the individual fields of the IFIT
   Attributes sub-TLVs are handled by the SRPM (SR Policy Module).

However, I am still missing a document that describes how these are actually "handled" by the SRPM?

I understand that there is a similar draft in PCE WG as well, but it is also missing this information.

My concern is that we have documents for the protocol signaling mechanisms for IFIT but I am not able to locate a document that describes how exactly this information is going to get used/applied by SRPM.

Please do point/clarify if I am missing something here.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Giuseppe Fioccola
Sent: 02 November 2020 22:28
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Dear Susan, All,

Best Regards,

Giuseppe

Cheers, Susan Hares

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 16 Nov 2020 07:11:32 +0000

Hi Ketan,
Thanks a lot for your revision.
My answers inline tagged as [GF]

Regards,

Giuseppe

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Friday, November 13, 2020 12:12 PM
To: Giuseppe Fioccola <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Giuseppe,

[GF]: Yes, this is correct.

[GF]: Good point, in the next revision we can add some considerations on the Steering into an SR Policy. This can be useful also for the data plane drafts. Regarding SRv6, the relevant documents are already adopted: draft-ietf-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-mark for AltMark. These Options are defined for IPv6 and can be used with any Routing Header (including SRH). For SR-MPLS the relevant documents (e.g. draft-gandhi-spring-ioam-sr-mpls) are still individual.

[GF]: draft-ietf-idr-segment-routing-te-policy also mentions some high-level functionality of SRPM. I think we need to include more details in draft-qin-idr-sr-policy-ifit in order to describe the functionalities that are specific for IFIT (IOAM and AltMark).

[GF]: I can address this comment in both drafts.

[GF]: Some details about the SRPM operation for IFIT could be added in this draft.

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Giuseppe Fioccola
Sent: 02 November 2020 22:28
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Dear Susan, All,

Best Regards,

Giuseppe

Cheers, Susan Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 16 Nov 2020 07:39:09 +0000

Hi Giuseppe,

Thanks for your response. Perhaps my point was not clear and so let me please clarify.

I am seeing the IFIT signalling related drafts for BGP and PCEP (it was also there in LSR?) in their individual protocol working groups. While what these protocols are doing is only "carrying" (in case of BGP somewhat opaquely) the information and conveying it to the SR Policy Module (SRPM). The following may clarify the picture better : https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-06#section-2

The key part of how this is handled by the SRPM, the related procedures and setup in the forwarding plane along with their applicability and any other considerations should be (IMHO) done in a Spring document. This is my suggestion and request to the authors - not to add all of this into an IDR document since that is not where you will find the right expertise to review these aspects.

Without that, it might seem like an uncoordinated protocol development effort for those of us who are not intimately aware of all the IFIT internals/details.

Rest, I will leave it up to the chairs of the WGs involved.

Thanks,
Ketan

From: Giuseppe Fioccola <[email-masked]>
Sent: 16 November 2020 12:42
To: Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

Regards,

Giuseppe

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Friday, November 13, 2020 12:12 PM
To: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Giuseppe,

Thanks,
Ketan

Dear Susan, All,

Best Regards,

Giuseppe

Cheers, Susan Hares

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 16 Nov 2020 08:20:26 +0000

Dear WG,

As discussed during the WG call:

There is an overall framework draft, which is an individual document: https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/

There are also many related protocol-specific iFIT individual drafts in various WGs.

It is better to have a framework draft to reach maturity (adoption) first.

Thanks

Regards … Zafar

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Monday, November 2, 2020 at 12:56 AM
To: "[email-masked]" <[email-masked]>
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 16 Nov 2020 08:43:25 +0000

Hi Ketan,
As discussed at the IDR session, I see your point.
draft-qin-idr-sr-policy-ifit is one building block of the SR Policy Architecture and a new SPRING document that describes the SRPM operations and procedures for IFIT (IOAM and AltMark) would be the best choice. Considering your contributions on related documents, we could also cooperate on that.
So, I agree, there is no need to add this into draft-qin-idr-sr-policy-ifit so far.

Regards,

Giuseppe

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Monday, November 16, 2020 8:39 AM
To: Giuseppe Fioccola <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Giuseppe,

Thanks,
Ketan

From: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
Sent: 16 November 2020 12:42
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Hi Ketan,

Regards,

Giuseppe

Hi Giuseppe,

Thanks,
Ketan

Dear Susan, All,

Best Regards,

Giuseppe

Cheers, Susan Hares

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 16 Nov 2020 08:43:47 +0000

Hi Zafar,

Thanks very much for your interest on this work, and pointing out the IFIT framework.
We could cooperate and expedite the framework.
However, when considering the adoption of draft-qin-idr-sr-policy-ifit, we do not have to wait for the framework.
1. The framework is a support document. It’s informational. draft-qin-idr-sr-policy-ifit as a self-contained building block do not have to depend on the it.
2. In an opposite way, we got some suggestions in the community, they want to see each building blocks getting mature, and then consider how they could work together.

IMO, we should deal with these documents in parallel.

Cheers,
Tianran
From: Idr [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Monday, November 16, 2020 4:20 PM
To: Susan Hares <[email-masked]>; [email-masked]
Cc: Zafar Ali (zali) <[email-masked]>
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Dear WG,

Thanks

Regards … Zafar

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 2, 2020 at 12:56 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Cheers, Susan Hares

---

From: John Scudder <[email-masked]>
Date: Thu, 19 Nov 2020 06:53:03 +0000

Hi Sue,

Here’s my tally on this one:

Yes (but co-authors):
- Giuseppe F
- Yali
- Fengwei
- Tianran

Yes:
- Peng Liu
- Yisong
- Huzhibo
- Chen Huan
- Shuanglong
- Fabio B
- Massimo N
- Jie
- Mauro C
- Weiqiang
- Ran Pang
- Huaimo
- Mach
- Dhruv
- Chengli

No:
- Ketan — interaction with SR policy module isn’t clear, "might seem like an uncoordinated protocol development effort”. (Not explicitly ’no’ but I read it that way for now.)
- Zafar — "It is better to have a framework draft to reach maturity (adoption) first.”

Comments/questions:
- Joel H — frame behavior not adopted by relevant WGs, therefore premature to adopt?

Some of the concerns raised are potentially serious. I think we can call Zafar “in the rough”. I’m not sure if Ketan and Giuseppe fully converged during the WG meeting — do you have a sense of this? And I think Joel cleared his concern later. So Ketan’s is the only concern I think is still outstanding, but I’d like to be clearer on it before proceeding.

—John

On Nov 2, 2020, at 12:56 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

The draft can be accessed at:
https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIeftGvCmylR-A$>

Cheers, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIeftGv96xWXpg$

---

From: John Scudder <[email-masked]>
Date: Thu, 19 Nov 2020 06:56:58 +0000

I had not intended to cc IDR on this, but never mind, a little transparency is not a bad thing (sleep deprivation is, though).

Since I *did* cc IDR, I may as well take the opportunity to comment that if I’ve misrepresented or omitted your position, please follow up.

Thanks,

—John

On Nov 19, 2020, at 1:53 AM, John Scudder <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sue,

Yes (but co-authors):
- Giuseppe F
- Yali
- Fengwei
- Tianran

Yes:
- Peng Liu
- Yisong
- Huzhibo
- Chen Huan
- Shuanglong
- Fabio B
- Massimo
- Jie
- Mauro C
- Weiqiang
- Ran Pang
- Huaimo
- Mach
- Dhruv
- Chengli

No:

Comments/questions:

—John

Cheers, Susan Hares

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Nov 2020 02:04:32 -0500

Yes, I have cleared my objection.
Yours,
Joel

On 11/19/2020 1:53 AM, John Scudder wrote:
> - Ketan — interaction with SR policy module isn’t clear, "might seem 
> like an uncoordinated protocol development effort”. (Not explicitly ’no’ 
> but I read it that way for now.)
> Some of the concerns raised are potentially serious. I think we can call 
> Zafar “in the rough”. I’m not sure if Ketan and Giuseppe fully converged 
> during the WG meeting — do you have a sense of this? And I think Joel 
> cleared his concern later. So Ketan’s is the only concern I think is 
> still outstanding, but I’d like to be clearer on it before proceeding.
> 
> —John
> 
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIeftGvCmylR-A$>
>> This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute 
>> for the SR policy tunnel type. This sub-TLV is only valid for SR 
>> Policy tunnel types.  Within the IFIT  sub-TLV value field, 5 sub-TLVs 
>> may be included (4 for IOAM and 1 for Enhanced Alternate Marking).
>> The IDR co-chairs thank the authors for their patience.  The WG 
>> adoption call for this draft has been delayed by the process of 
>> switching shepherds for BGP Tunnel Encaps draft.  Many BESS and IDR 
>> drafts currently refer to the BGP tunnel encapsulation drafts.
>> ·Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing 
>> technology,
>> ·Support/rejection of alternate marking as a IP routing technology,
>> ·Support/rejection of adding new sub-TLVS for SR Policy tunnel type of 
>> BGP Tunnel Encap Attribute, and
>> ·Specific issues with the descriptions of these features in the draft.
>> Cheers, Susan Hares
>> [email-masked] <mailto:[email-masked]>
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIeftGv96xWXpg$>
> 
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 19 Nov 2020 07:20:31 +0000

And I would like to clarify that my comments were not a "No" to the adoption.

It is very difficult (at least for me) to see how the proponents of IFIT solution see it progressing as an IETF standard if they are only trying to standardize the signalling protocol encoding parts and leave out the "middle part (i.e. SRPM related)" as a black box. For me at least, that is the crux - the BGP encoding part is just opaque bits that BGP is doing almost nothing with!

That was essentially my suggestion to Giuseppe - for the authors to work that "middle part" out (I would have preferred doing that first but ...). I thought that Giuseppe got my point and agreed to it - but I will let him confirm/clarify.

Of course, what looks like a black box to me might not be so and I am happy to be pointed to a document that describes these "SRPM related parts".

About the "uncoordinated" part, I've left it to the chairs - if they have any preference for the order in which different parts of this work are taken up in different WGs.

Thanks,
Ketan

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 19 November 2020 12:35
To: John Scudder <jgs=[email-masked]>; Hares Susan <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

On 11/19/2020 1:53 AM, John Scudder wrote:
> Some of the concerns raised are potentially serious. I think we can 
> call Zafar “in the rough”. I’m not sure if Ketan and Giuseppe fully 
> converged during the WG meeting — do you have a sense of this? And I 
> think Joel cleared his concern later. So Ketan’s is the only concern I 
> think is still outstanding, but I’d like to be clearer on it before proceeding.
> 
> —John
> 
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-z
>> hu-idr-bgp-ls-path-mtu/__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQ
>> lCdbDTqTHwgxWJUCrM2yIeftGvCmylR-A$>
>> The authors should provide IPR statements by 11/5/2020 so the IDR WG 
>> can consider the IPR status in their decision.
>> Policy tunnel types.  Within the IFIT  sub-TLV value field, 5 
>> sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).
>> technology, ·Support/rejection of alternate marking as a IP routing 
>> technology, ·Support/rejection of adding new sub-TLVS for SR Policy 
>> tunnel type of BGP Tunnel Encap Attribute, and ·Specific issues with 
>> the descriptions of these features in the draft.
>> Cheers, Susan Hares
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr
>> __;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIef
>> tGv96xWXpg$ 
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/id
>> r__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIe
>> ftGv96xWXpg$>
> 
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 19 Nov 2020 08:10:03 +0000

Hi John, Sue, Ketan, All,
I can confirm what Ketan just said. The IFIT solution is made by several building blocks and this document (draft-qin-idr-sr-policy-ifit) is one of these. When we have defined the IOAM and Alt-Mark methodologies, we did not have the signaling. Now we are defining the signaling and the next step is the middle part.
We agree with Ketan to work on a new SPRING document that describes the SRPM operations and procedures for IFIT (IOAM and Alt-Mark). Anyway no additional changes are needed for draft-qin-idr-sr-policy-ifit so far. We could simply state in the next revision that the SRPM details are described in another document and we will add the reference as soon as it is published.

Meanwhile we believe that this draft, as one building block, is quite stable and can be adopted since it complements draft-ietf-idr-segment-routing-te-policy.

Regards,

Giuseppe

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, November 19, 2020 8:21 AM
To: Joel M. Halpern <[email-masked]>; John Scudder <jgs=[email-masked]>; Hares Susan <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Thanks,
Ketan