Re: [ippm] [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00

xiao.min2@zte.com.cn Thu, 25 April 2024 06:10 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 46CB3C151990; Wed, 24 Apr 2024 23:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.892
X-Spam-Level:
X-Spam-Status: No, score=-6.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 8mHq4oJSakvp; Wed, 24 Apr 2024 23:10:46 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB416C15199D; Wed, 24 Apr 2024 23:10:42 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (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 4VQ57g5Tq0z6G3wb; Thu, 25 Apr 2024 14:10:39 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4VQ5730fvgz501gV; Thu, 25 Apr 2024 14:10:07 +0800 (CST)
Received: from njy2app04.zte.com.cn ([10.40.12.64]) by mse-fl2.zte.com.cn with SMTP id 43P6A116098842; Thu, 25 Apr 2024 14:10:01 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njb2app06[null]) by mapi (Zmail) with MAPI id mid201; Thu, 25 Apr 2024 14:10:03 +0800 (CST)
Date: Thu, 25 Apr 2024 14:10:03 +0800
X-Zmail-TransId: 2afe6629f3bbffffffffbb8-7f689
X-Mailer: Zmail v1.0
Message-ID: <20240425141003017QieLHILphfCAvhuSGcRyU@zte.com.cn>
In-Reply-To: <7d5ba1f734f54d6a8d9cd0ad5b862b2f@huawei.com>
References: 20240403105349766H6VG2pF8d1gMupLhUrD1Z@zte.com.cn, 20240403181838982SZwwtBLEGhhgPH5XW6TT3@zte.com.cn, 7d5ba1f734f54d6a8d9cd0ad5b862b2f@huawei.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: giuseppe.fioccola@huawei.com
Cc: Thomas.Graf@swisscom.com, draft-gfz-opsawg-ipfix-alt-mark@ietf.org, opsawg@ietf.org, ippm@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 43P6A116098842
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6629F3DF.002/4VQ57g5Tq0z6G3wb
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/FwEpevI-yvas-To_m3OAVIVd4b8>
Subject: Re: [ippm] [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00
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: Thu, 25 Apr 2024 06:10:50 -0000

Hi Giuseppe,

Thank you for addressing my comments.
The added clarification text looks good to me.

Best Regards,
Xiao Min


Original


From: GiuseppeFioccola <giuseppe.fioccola@huawei.com>
To: 肖敏10093570;Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>;
Cc: draft-gfz-opsawg-ipfix-alt-mark@ietf.org <draft-gfz-opsawg-ipfix-alt-mark@ietf.org>;opsawg@ietf.org <opsawg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;
Date: 2024年04月25日 00:33
Subject: RE: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00




Hi Xiao, All,
We have just uploaded the new revision of draft-gfz-opsawg-ipfix-alt-mark and we added some text to clarify the point you raised about the LAG interface.
 
Regards,
 
Giuseppe
 

From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> 
 Sent: Wednesday, April 3, 2024 12:19 PM
 To: Thomas.Graf@swisscom.com
 Cc: draft-gfz-opsawg-ipfix-alt-mark@ietf.org; opsawg@ietf.org; ippm@ietf.org
 Subject: Re: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00


 
Got it. Thank you Thomas!
If some text can be added to clarify this usage of ingressInterface/egressInterface and ingressPhysicalInterface/egressPhysicalInterface, that would help the implementer.
 
Cheers,
Xiao Min

Original

From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>



To: 肖敏10093570;



Cc: draft-gfz-opsawg-ipfix-alt-mark@ietf.org <draft-gfz-opsawg-ipfix-alt-mark@ietf.org>;opsawg@ietf.org <opsawg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;



Date: 2024年04月03日 11:41



Subject: Re: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00




Dear Xiao,


 

Correct. Obviously this will be exported per flow and the interface entities have to be key fields as the flow entities as well.


 

Best wishes



Thomas




 
 


On 3 Apr 2024, at 04:54, xiao.min2@zte.com.cn wrote:







Be aware: This is an external email.



 
Correcting the email address ippm@ietf.org.
 
Hi Thomas,
 
If I understand you correctly, you mean the IE exporter can use ingressInterface/egressInterface to indicate LAG port and ingressPhysicalInterface/egressPhysicalInterface to indicate LAG member port, so the receiver can deduce the implicit meanings of them if they have different values, is that right?
 
 
Cheers,
Xiao Min
 







From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>



To: 肖敏10093570;draft-gfz-opsawg-ipfix-alt-mark@ietf.org <draft-gfz-opsawg-ipfix-alt-mark@ietf.org>;



Cc: opsawg@ietf.org <opsawg@ietf.org>;'ippm@ietf.org <'ippm@ietf.org>;



Date: 2024年04月02日 19:32



Subject: RE: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00




Dear Xiao,
 
I agree that the description and the additional information does not provide information to distinguish between
 
ingressInterface, egressInterface
 
and
 
ingressPhysicalInterface, egressPhysicalInterface
 
However from an implementation perspective I have observed that in all cases ingressInterface and egressInterface refer to logical and ingressPhysicalInterface and egressPhysicalInterface to physical interfaces.
 
Where ingressInterfaceType and egressInterfaceType, which references to https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, is describing what type of interface it is.
 
I would expect in a LAG configuration that the lag interface is ingressInterface resp. egressInterface and the member interfaces are ingressPhysicalInterface resp. egressPhysicalInterface.
 
I hope that helps.
 
Best wishes
Thomas
 


From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of xiao.min2@zte.com.cn
 Sent: Tuesday, April 2, 2024 10:58 AM
 To: draft-gfz-opsawg-ipfix-alt-mark@ietf.org
 Cc: opsawg@ietf.org; 'ippm@ietf.org
 Subject: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00



 



Be aware: This is an external email.



 
Hi authors,
 
At the request of Giuseppe, I had a read on draft-gfz-opsawg-ipfix-alt-mark-00.
There are IPFIX IEs ingressInterface, egressInterface, ingressPhysicalInterface and egressPhysicalInterface, is there an IE indicating a LAG interface? 
 
Best Regards,
Xiao Min