From nobody Mon Nov 16 00:43:42 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578453A11AB; Mon, 16 Nov 2020 00:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZDPGi9dUdvx; Mon, 16 Nov 2020 00:43:33 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DF33A15C7; Mon, 16 Nov 2020 00:43:27 -0800 (PST) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CZMxt38kdz67Dnv; Mon, 16 Nov 2020 16:41:54 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 16 Nov 2020 09:43:25 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 16 Nov 2020 09:43:25 +0100 From: Giuseppe Fioccola To: "Ketan Talaulikar (ketant)" , Susan Hares , "idr@ietf.org" CC: "spring@ietf.org" , "spring-chairs@ietf.org" Thread-Topic: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) Thread-Index: Adaw2PtgBctpKEXkRb++HOEf6MFzKAAXn49QAhq0TSAAkCn8MAABrv4QAAGxpCA= Date: Mon, 16 Nov 2020 08:43:25 +0000 Message-ID: <97b2cfd508c84da19d9483d80427bd3b@huawei.com> References: <055301d6b0dc$f84da4a0$e8e8ede0$@ndzh.com> <1057d25807be466c97af61844fddfa35@huawei.com> <832cd20c50a941e19d06e41b339a6c8c@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.215.142] Content-Type: multipart/alternative; boundary="_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 08:43:37 -0000 --_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Archite= cture and a new SPRING document that describes the SRPM operations and proc= edures for IFIT (IOAM and AltMark) would be the best choice. Considering yo= ur 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:ketant@cisco.com] Sent: Monday, November 16, 2020 8:39 AM To: Giuseppe Fioccola ; Susan Hares ; idr@ietf.org Cc: spring@ietf.org; spring-chairs@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Giuseppe, Thanks for your response. Perhaps my point was not clear and so let me plea= se clarify. I am seeing the IFIT signalling related drafts for BGP and PCEP (it was als= o there in LSR?) in their individual protocol working groups. While what th= ese protocols are doing is only "carrying" (in case of BGP somewhat opaquel= y) the information and conveying it to the SR Policy Module (SRPM). The fol= lowing may clarify the picture better : https://tools.ietf.org/html/draft-f= ilsfils-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 sugg= estion and request to the authors - not to add all of this into an IDR docu= ment since that is not where you will find the right expertise to review th= ese aspects. Without that, it might seem like an uncoordinated protocol development effo= rt for those of us who are not intimately aware of all the IFIT internals/d= etails. Rest, I will leave it up to the chairs of the WGs involved. Thanks, Ketan From: Giuseppe Fioccola > Sent: 16 November 2020 12:42 To: Ketan Talaulikar (ketant) >; = Susan Hares >; idr@ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) Hi Ketan, Thanks a lot for your revision. My answers inline tagged as [GF] Regards, Giuseppe From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Friday, November 13, 2020 12:12 PM To: Giuseppe Fioccola >; Susan Hares >; idr@= ietf.org Cc: spring@ietf.org Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) 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 cl= earer to me now. Sec 3 says (and I am trying to paraphrase here - so please correct me), tha= t 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. [GF]: Yes, this is correct. Is there a Spring WG document that describes the implications of actually h= ow this would get applied to the SR Policy forwarding planes (SR-MPLS and S= Rv6) and what types of Steering would be possible to be used for such SR Po= licies (ref https://tools.ietf.org/html/draft-ietf-spring-segment-routing-p= olicy-09#section-8). ? E.g. if a packet is arriving at the headend with a s= tack of labels and gets steered via BSID into such an SR Policy where "IFIT= is applied", how does that work? [GF]: Good point, in the next revision we can add some considerations on th= e Steering into an SR Policy. This can be useful also for the data plane dr= afts. Regarding SRv6, the relevant documents are already adopted: draft-iet= f-ippm-ioam-ipv6-options for IOAM and draft-ietf-6man-ipv6-alt-mark for Alt= Mark. These Options are defined for IPv6 and can be used with any Routing H= eader (including SRH). For SR-MPLS the relevant documents (e.g. draft-gandh= i-spring-ioam-sr-mpls) are still individual. 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 actuall= y "handled" by the SRPM? [GF]: draft-ietf-idr-segment-routing-te-policy also mentions some high-leve= l functionality of SRPM. I think we need to include more details in draft-q= in-idr-sr-policy-ifit in order to describe the functionalities that are spe= cific for IFIT (IOAM and AltMark). I understand that there is a similar draft in PCE WG as well, but it is als= o missing this information. [GF]: I can address this comment in both drafts. 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. [GF]: Some details about the SRPM operation for IFIT could be added in this= draft. Please do point/clarify if I am missing something here. Thanks, Ketan From: Idr > On Behalf Of = Giuseppe Fioccola Sent: 02 November 2020 22:28 To: Susan Hares >; idr@ietf.org Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifi= t-04.txt (11/1/2020 to 11/16/2020) 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:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, November 2, 2020 6:57 AM To: idr@ietf.org 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.t= xt (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 co= nsider 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 typ= es. Within the IFIT sub-TLV value field, 5 sub-TLVs may be included (4 fo= r IOAM and 1 for Enhanced Alternate Marking). The IDR co-chairs thank the authors for their patience. The WG adoption ca= ll for this draft has been delayed by the process of switching shepherds fo= r 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 te= chnology, * 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 --_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

As discussed at the ID= R session, I see your point.

draft-qin-idr-sr-polic= y-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 coopera= te 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:ketan= t@cisco.com]
Sent: Monday, November 16, 2020 8:39 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Susan Ha= res <shares@ndzh.com>; idr@ietf.org
Cc: spring@ietf.org; spring-chairs@ietf.org
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

 

Hi Giuseppe,<= /p>

 

Thanks for your response. Perha= ps 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 indiv= idual 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 han= dled 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 in= to an IDR document since that is not where you will find the right expertis= e to review these aspects.

 

Without that, it might seem lik= e 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 <giuseppe.fioccola@huawei.com>
Sent: 16 November 2020 12:42
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
Cc: spring@ietf.org
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

 

Hi Ketan,

Thanks a lot for your = revision.

My answers inline tagg= ed as [GF]

 

Regards,

 

Giuseppe

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Friday, November 13, 2020 12:12 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Susan Hares <shares@ndzh.com>; idr@ietf.org
Cc: spring@ietf.org
Subject: RE: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

 

Hi Giuseppe,<= /p>

 

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 B= GP. 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.

&n= bsp;

[GF]: Yes, this is cor= rect.=

 

Is there a Spring WG document t= hat describes the implications of actually how this would get applied to th= e 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://to= ols.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 ste= ered via BSID into such an SR Policy where “IFIT is applied”, h= ow does that work?

&n= bsp;

[GF]: Good point, in t= he 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-ma= rk 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. d= raft-gandhi-spring-ioam-sr-mpls) are still individual.

&n= bsp;

 

Sec 6 (SR Policy operations wit= h IFIT Attributes) says the following:

 

The validation of the individua= l fields of the IFIT

   Attributes sub-TLV= s are handled by the SRPM (SR Policy Module).

 

However, I am still missing a d= ocument that describes how these are actually “handled” by the = SRPM?

 

[GF]: draft-ietf-idr-s= egment-routing-te-policy also mentions some high-level functionality of SRP= M. 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).=

 

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

 

[GF]: I can address th= is comment in both drafts.

 

My concern is that we have docu= ments for the protocol signaling mechanisms for IFIT but I am not able to l= ocate a document that describes how exactly this information is going to ge= t used/applied by SRPM.

 

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

 

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

 

Thanks,

Ketan

 

From: Idr <idr-bounces@ietf.org> On Behalf Of Giuseppe Fioccola
Sent: 02 November 2020 22:28
To: Susan Hares <shares@ndzh.c= om>; idr@ietf.org
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-pol= icy-ifit-04.txt (11/1/2020 to 11/16/2020)

 

Dear Susan, All,<= /o:p>

I'm not aware of any I= PR related to this draft. I also support its adoption as coauthor.

 

Best Regards,

 

Giuseppe

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 6:57 AM
To: idr@ietf.org
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 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/20= 20 so the IDR WG can consider the IPR status in their

decision.

 

This draft adds the IFIT sub-TLV to the BGP Tunnel E= ncaps attribute for the SR policy tunnel type. This sub-TLV is only valid f= or 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 patien= ce.  The WG adoption call for this draft has been delayed by the proce= ss 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 b= etween the following:

  • Support/rejection= of In-situ Flow Telemetry (IFIT) as a IP routing technology,
  • Support/rejecti= on of alternate marking as a IP routing technology,  
    • <= li class=3D"MsoNormal" style=3D"mso-list:l1 level1 lfo3">Support/rejection = of adding new sub-TLVS for SR Policy tunnel type of BGP Tunnel Encap Attrib= ute, and   
  • Specific issues with the descriptions of these features= in the draft.

 

Cheers, Susan Hares

 

 

 

--_000_97b2cfd508c84da19d9483d80427bd3bhuaweicom_--