Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)

xiao.min2@zte.com.cn Tue, 12 July 2022 09:08 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A723C157B55 for <ippm@ietfa.amsl.com>; Tue, 12 Jul 2022 02:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.906
X-Spam-Level:
X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwldqCLG8V0F for <ippm@ietfa.amsl.com>; Tue, 12 Jul 2022 02:08:46 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8073BC157B58 for <ippm@ietf.org>; Tue, 12 Jul 2022 02:08:44 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Lhw0T75k8z8R040; Tue, 12 Jul 2022 17:08:41 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl1.zte.com.cn with SMTP id 26C98OmJ045145; Tue, 12 Jul 2022 17:08:24 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Tue, 12 Jul 2022 17:08:24 +0800 (CST)
Date: Tue, 12 Jul 2022 17:08:24 +0800
X-Zmail-TransId: 2afa62cd3a0805ac3c7b
X-Mailer: Zmail v1.0
Message-ID: <202207121708240339451@zte.com.cn>
In-Reply-To: <BYAPR08MB4872FA6FF1C7204ED731867BB3879@BYAPR08MB4872.namprd08.prod.outlook.com>
References: BYAPR08MB4872BA1F22EBD8F6788A4A89B3B49@BYAPR08MB4872.namprd08.prod.outlook.com, 202207111536346720629@zte.com.cn, BYAPR08MB4872FA6FF1C7204ED731867BB3879@BYAPR08MB4872.namprd08.prod.outlook.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: shares@ndzh.com
Cc: giuseppe.fioccola@huawei.com, ippm@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-MAIL: mse-fl1.zte.com.cn 26C98OmJ045145
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 62CD3A19.001 by FangMail milter!
X-FangMail-Envelope: 1657616922/4Lhw0T75k8z8R040/62CD3A19.001/10.5.228.81/[10.5.228.81]/mse-fl1.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62CD3A19.001/4Lhw0T75k8z8R040
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/DXJ6Ub_klOUJHGTzw07CSDGx5F4>
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 09:08:50 -0000

Sue,

You're welcome.
It's my pleasure if you find my feedback helpful.

Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <shares@ndzh.com>
To: 肖敏10093570;giuseppe.fioccola@huawei.com <giuseppe.fioccola@huawei.com>;
Cc: ippm@ietf.org <ippm@ietf.org>;
Date: 2022年07月11日 23:47
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
" _ue_custom_node_="true">
Xiao:
I will chat with the IPPM chairs to get their viewpoints on the term “IFIT” as an abbreviation.
I will consider the technical discussion regarding draft-ietf-ippm-ioam-conf-state and draft-ietf-idr-bgp-ifit-capabilities closed.
I appreciate your feedback!
Sue
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
Sent: Monday, July 11, 2022 3:37 AM
To: giuseppe.fioccola@huawei.com
Cc: Susan Hares <shares@ndzh.com>; ippm@ietf.org
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Hi Giuseppe,
Thank you for the update of your plan on revision.
Wrt the standard terms, I believe I'v expressed my point of view clearly, I have no more to say.
Wrt the relationship between draft-ietf-ippm-ioam-conf-state and draft-ietf-idr-bgp-ifit-capabilities, your explanation is acceptable to me.
Cheers,
Xiao Min
------------------Original------------------
From: GiuseppeFioccola <giuseppe.fioccola@huawei.com>
To: 肖敏10093570;shares@ndzh.com <shares@ndzh.com>;
Cc: ippm@ietf.org <ippm@ietf.org>;
Date: 2022年07月08日 18:10
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Hi Xiao, Sue,
We plan to work on a new revision of draft-ietf-idr-bgp-ifit-cpabilities to address the points raised in this discussion.
Please see my replies inline tagged as [GF].
Regards,
Giuseppe
-----Original Message-----
From: ippm <ippm-bounces@ietf.org> On Behalf Of xiao.min2@zte.com.cn
Sent: Friday, July 8, 2022 11:18 AM
To: shares@ndzh.com
Cc: ippm@ietf.org
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022)
Hi Sue,
Please see inline...
Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <shares@ndzh.com>
To: 肖敏10093570;
Cc: zhoutianran@huawei.com <zhoutianran@huawei.com>;ippm@ietf.org <ippm@ietf.org>;
Date: 2022年07月08日 05:18
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) " _ue_custom_node_="true">
Xiao:
I’m sorry I missed this email until today.
[XM]>>> That would happen to everyone, never mind :-) 1. on the IFIT versus other IPPM terms.
I will ask the IPPM chairs to help walk through IPPM standard terms.
[XM]>>> That's great. Expect to see an agreement reached among you chairs of the IPPM&IDR WGs.
[GF]: I suggest to better clarify the use of the term. IFIT is just a term which denotes IOAM and Alt-Mark together. No new technology is added to IOAM and Alt-Mark. I can revise the draft to make it clearer. For example in the Abstract,  I can include the following sentence as first paragraph: "In-situ Flow Information Telemetry (IFIT) refers to data plane on-path telemetry techniques, which are In-situ OAM (IOAM) and Alternate Marking."
draft-wang-idr-bgp-ifit-capabilities-05.txt has been accepted, and will be published as draft-ietf-idr-bgp-ifit-capabilities-00.txt
The authors have been notified that feedback from the IPPM chairs may require a revision in their draft.
2. On the reference to the draft-ietf-ippm-ioam-conf-state Are you concerned about interactions between the BGP process (IBGP) and the insitu OAM process within a IGP domain?
Or are you concerned about the information passed between AS in the e-BGP process between domains (e.g. AS1 --- AS2) Interacting with the insitu OAM process?
Or both?
Your comment is a bit vague even with the draft reference.
I need some more details prior to discussing your concerns with the draft-ietf-idr-bgp-ifit-capabilities author team and the IPPM chairs.
[XM]>>> Let me provide an example to explain my concern and suggestion.
Assume a data center network where IFIT capabilities discovery is needed.
Forwarding path of the IFIT encapsulated data packet is as below.
NVE1---SW1---SW2---SW3---NVE2
Using draft-ietf-ippm-ioam-conf-state, NVE1 can obtain the IFIT capabilities of SW1/SW2/SW3/NVE2 through ICMPv6 Echo Request/Reply.
Using draft-ietf-idr-bgp-ifit-capabilities, NVE1 can obtain the IFIT capabilities of NVE2 through BGP signaling.
What I'm not sure is, why does NVE1 need to obtain the IFIT capabilities of NVE2 through BGP if NVE1 has already obtained them through ICMPv6?
Note that this is just an example. I suggest more general answer to my question is added into draft-ietf-idr-bgp-ifit-capabilities.
[GF]: I think we can clarify the relation between draft-ietf-idr-bgp-ifit-capabilities and draft-ietf-ippm-ioam-conf-state in the next revision. I do not think that the overlap is a problem since it depends on the application scenario.  There are different examples in IETF, for instance SR Policy can be advertised in several ways (PCEP, BGP,...). The same applies to IOAM and Alt-Mark, which could be advertised in different ways. As an example, in a SR network where SR Policies are advertised  in BGP, it may be more convenient to advertise IFIT for SR Policies in BGP. While, in other scenarios, BGP may not be a good option and ICMPv6 can be used.
Clarity in the defined interactions between insitu OAM and is important (e.g. some specified interaction or no interaction cheers, Susan Hares
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
Sent: Thursday, June 30, 2022 11:29 PM
To: Susan Hares <shares@ndzh.com>
Cc: zhoutianran@huawei.com; ippm@ietf.org
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) Hi Sue, Please see inline...
Cheers,
Xiao Min
------------------Original------------------
From: SusanHares <shares@ndzh.com>
To: Tianran Zhou <zhoutianran@huawei.com>;肖敏10093570;
Cc: ippm@ietf.org <ippm@ietf.org>;
Date: 2022年06月30日 21:05
Subject: RE: [ippm]  IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) " _ue_custom_node_="true"> Xiao Min:
My understanding is that you are concern about the abbreviation (IFIT) rather than the substance of the draft.
[XM]>>> I suggest the authors to use the terms already defined in IPPM.
This BGP draft deals with passing this information between egress and ingress BGP routers “This document introduces extensions to the Border Gateway Protocol (BGP) to advertise supported IFIT capabilities of the egress node to the ingress  [BGP] node… “ (page 2).
Your comments deal with this technology.
[XM]>>> I suggest the authors to add reference to draft-ietf-ippm-ioam-conf-state and explain the relationship between them.
Thank you,
Sue
From: Tianran Zhou <zhoutianran@huawei.com>
Sent: Wednesday, June 29, 2022 11:46 PM
To: xiao.min2@zte.com.cn; Susan Hares <shares@ndzh.com>
Cc: ippm@ietf.org
Subject: RE: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) I do not see any overlap here.
All the information, the usage and the extended protocol are quite different.
Tianran
-----Original Message-----
From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of xiao.min2@zte.com.cn
Sent: Thursday, June 30, 2022 10:22 AM
To: shares@ndzh.com
Cc: ippm@ietf.org
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) Hi Susan, Thank you for the response.
Please see inline my comments with [XM]>>>.
Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <shares@ndzh.com>
To: 肖敏10093570;
Cc: ippm@ietf.org <ippm@ietf.org>;
Date: 2022年06月30日 05:28
Subject: RE: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) " _ue_custom_node_="true">
Xiao:
Thank you for your feedback regarding this draft.
I need clarification on your feedback.
The introduction of draft-wang-idr-bgp-ifit-capabilities-05.txt
states IFIT is an abbreviation used by their draft as denoted in their abstract:
“This document defines extensions to BGP [RFC4271] to advertise the In-situ Flow Information Telemetry (IFIT) capabilities.”
Since this abbreviation is shared with:
draft-ietf-idr-sr-policy-ifit-03 (ready for WG LC) in their abstract:
“In-situ Flow Information Telemetry
(IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking.”
Are you objecting to their abbreviation or the terms behind the abbreviation?
[XM]>>> Since I started work in IPPM around 2017, both Alternate Marking and In-situ OAM were already there and I've been used to them. If the IPPM WG decides to introduce a new/second term to scope Alternate Marking and/or In-situ  OAM,  that's  fine to me. However, I don't believe it's the common practice to put a new/second term to IPPM techniques from the outside of IPPM.
2.  Would you please provide additional details on the overlap between draft-wang-idr-bgp-ifit-cpabilities-05.txt and draft-ietf-ippm-ioam-conf-state.
[XM]>>> As I said, the term IFIT brings some confusion to me, in IPPM, Alternate Marking and In-situ OAM are targeted by separate documents. If I understand draft-wang-idr-bgp-ifit-cpabilities-05 correctly, this document covers Capabilities  Discovery  for  both Alternate Marking and In-situ OAM, only edge to edge. As a comparison, draft-ietf-ippm-ioam-conf-state-03 covers Capabilities Discovery for In-situ OAM (if necessary, the same mechanism can be used for Alternate Marking as well), both edge  to edge  and  hop by hop.
Thank you Susan Hares
From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
Sent: Wednesday, June 29, 2022 5:06 AM
To: Susan Hares <shares@ndzh.com>
Cc: ippm@ietf.org
Subject: Re: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) Hi Susan, Thank you for this notice, very helpful.
I have two concerns as follow:
1. As far as I know, iFIT is not a standardized term defined in any IPPM RFC or WG draft, however iFIT includes Alternate Marking and In-situ OAM which both are defined in IPPM. I'm not sure it's appropriate, that looks out of order  to  me.  The  right order IMHO is to define iFIT in IPPM first (if necessary), and then to define protocol extensions (e.g. BGP extensions) to support iFIT.
2. In IPPM there is draft-ietf-ippm-ioam-conf-state that achieves the similar function intended by draft-wang-idr-ifit-capabilities, the two documents looks overlapping to some extent.
Best Regards,
Xiao Min
------------------Original------------------
From: SusanHares <shares@ndzh.com>
To: ippm@ietf.org <ippm@ietf.org>;
Date: 2022年06月24日 23:29
Subject: [ippm] IDR adoption of draft-wang-idr-bgp-ifit-cpabilities-05.txt - Request for input (6/24 to 7/8/2022) _______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
Marcus, Tommy and ippm WG:
The IDR WG would like your feedback on two drafts in IDR:
1. draft-ietf-idr-sr-policy-ifit-03.txt – The IDR WG is planning WG LC on this draft in August.
2. draft-wang-idr-ifit-capabilities-05.tt – The IDR WG has consensus on adopting this draft.
Please let us know if you have any concerns regarding these drafts.
We note that these drafts reference:
1) draft-ietf-6man-ipv6-alt-mark
2) draft-ietf-ippm-ioam-data
3) draft-ietf-ippm-ioam-direct-export
4) draft-ietf-ippm-ioam-flags
5) draft-ietf-ippm-ioam-ipv6-options
Please let me know if you have any questions regarding these two drafts.
I am one of the IDR WG co-chairs and the shepherd for these two drafts.
You can reply to this thread or provide information to your WG chairs.
Cheers, Susan Hares
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm