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

xiao.min2@zte.com.cn Wed, 03 April 2024 02:54 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 DE98BC14F70F; Tue, 2 Apr 2024 19:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 di9zd-NEAp3U; Tue, 2 Apr 2024 19:54:07 -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 A5775C14F601; Tue, 2 Apr 2024 19:54:02 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (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 4V8Tpv5fzRz4xPYk; Wed, 3 Apr 2024 10:53:59 +0800 (CST)
Received: from njb2app07.zte.com.cn ([10.55.22.95]) by mse-fl1.zte.com.cn with SMTP id 4332rmkt056892; Wed, 3 Apr 2024 10:53:48 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid201; Wed, 3 Apr 2024 10:53:49 +0800 (CST)
Date: Wed, 03 Apr 2024 10:53:49 +0800
X-Zmail-TransId: 2afb660cc4bdffffffff948-bc3be
X-Mailer: Zmail v1.0
Message-ID: <20240403105349766H6VG2pF8d1gMupLhUrD1Z@zte.com.cn>
In-Reply-To: <c06e68a8d693490791482af8c23d5e9e@swisscom.com>
References: 20240402165757283C0VlQz4t8NA5bu-YIjTsm@zte.com.cn, c06e68a8d693490791482af8c23d5e9e@swisscom.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: Thomas.Graf@swisscom.com
Cc: draft-gfz-opsawg-ipfix-alt-mark@ietf.org, opsawg@ietf.org, ippm@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 4332rmkt056892
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 660CC4C7.000/4V8Tpv5fzRz4xPYk
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Hcr8I2AiMR5iysd76vSI-MZFhV8>
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: Wed, 03 Apr 2024 02:54:11 -0000

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

Original


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