[spring] 答复: [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network

Qiuyuanxiang <qiuyuanxiang@h3c.com> Tue, 08 June 2021 07:25 UTC

Return-Path: <qiuyuanxiang@h3c.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A93D63A25CC for <spring@ietfa.amsl.com>; Tue, 8 Jun 2021 00:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.097
X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.998, HK_RANDOM_FROM=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZGIMAAdeitwi for <spring@ietfa.amsl.com>; Tue, 8 Jun 2021 00:25:17 -0700 (PDT)
Received: from h3cspam02-ex.h3c.com (smtp.h3c.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B752B3A25C8 for <spring@ietf.org>; Tue, 8 Jun 2021 00:25:16 -0700 (PDT)
Received: from DAG2EX01-BASE.srv.huawei-3com.com ([]) by h3cspam02-ex.h3c.com with ESMTP id 1587OSNT099153; Tue, 8 Jun 2021 15:24:28 +0800 (GMT-8) (envelope-from qiuyuanxiang@h3c.com)
Received: from DAG2EX06-IDC.srv.huawei-3com.com ( by DAG2EX01-BASE.srv.huawei-3com.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 8 Jun 2021 15:24:30 +0800
Received: from DAG2EX06-IDC.srv.huawei-3com.com ([::1]) by DAG2EX06-IDC.srv.huawei-3com.com ([fe80::78f8:e244:d48:c15e%9]) with mapi id 15.01.2242.008; Tue, 8 Jun 2021 15:24:30 +0800
From: Qiuyuanxiang <qiuyuanxiang@h3c.com>
To: Tianran Zhou <zhoutianran@huawei.com>, "Wangyali(Yali,Data Communication Standards and Patents Dept)" <wangyali11@huawei.com>, "spring@ietf.org" <spring@ietf.org>
CC: Haoyu Song <haoyu.song@futurewei.com>
Thread-Topic: [spring] [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network
Thread-Index: AddY8jd/cv9xYSWQRDiVo/BrDi55N///8GoA//sA9VD/9NK1QP/pe5jg
Date: Tue, 08 Jun 2021 07:24:30 +0000
Message-ID: <88d7f1d7c4c74c60bbfb7b86d9a035ef@h3c.com>
References: <47a2d3a236ad4d6daa580ed1b8302a70@h3c.com> <ca1cc9da6160433dae9e475bac4ecbbd@huawei.com> <9e56f17c86a046eb90b5a2b919a1d636@h3c.com> <bbc4958a6c2f4fe1858b10a7aff39015@huawei.com>
In-Reply-To: <bbc4958a6c2f4fe1858b10a7aff39015@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
x-sender-location: DAG2
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MAIL: h3cspam02-ex.h3c.com 1587OSNT099153
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/GpLRXzdmi2glPNgLl14VmuVEH_Y>
Subject: [spring] 答复: [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 07:25:22 -0000

Hi Tianran,

My idea is that need to explicitly add scenarios for the Uniform model. If the Trace Option-type in the original packet is Pre-allocated or Edge-to-Edge, Uniform model does not work, and even does not encapsulate the outer iOAM header.
The reason why Edge-to-Edge Trace Option-type doesn't work is that, if the outer iOAM header directly copies the inner one, the tunnel egress will mistakenly assume it is the iOAM end node when it decapsulates the outer header, and reports data to the analyzer.

The second suggested changing "copy" to "selectively partially synchronize ", and lists data fields that must be synchronized, such as FlowMonID, IOAM-Trace-Type, and so on.

Best Regards,

发件人: Tianran Zhou [mailto:zhoutianran@huawei.com] 
发送时间: 2021年6月8日 9:12
收件人: qiuyuanxiang (RD) <qiuyuanxiang@h3c.com>; Wangyali(Yali,Data Communication Standards and Patents Dept) <wangyali11@huawei.com>; spring@ietf.org
抄送: Haoyu Song <haoyu.song@futurewei.com>
主题: RE: [spring] [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network

Hi Yuanxiang,

Please see in-line.


-----Original Message-----
From: Qiuyuanxiang [mailto:qiuyuanxiang@h3c.com] 
Sent: Monday, June 7, 2021 4:17 PM
To: Wangyali(Yali,Data Communication Standards and Patents Dept) <wangyali11@huawei.com>; spring@ietf.org
Cc: Haoyu Song <haoyu.song@futurewei.com>; Tianran Zhou <zhoutianran@huawei.com>
Subject: 答复: [spring] [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network

Hi yali,
Thank you very much for informing me of the existing draft-song-ippm-ioam-tunnel-mode-00.

For draft-song-ippm-ioam-tunnel-mode-00, I have a little question, which is also the problem that bothers me when I write draft-qiu-spring-srv6-ioam-encap-model-00.

In uniform model, draft-song-ippm-ioam-tunnel-mode-00 uses the method of copying the original header directly. But for some reason, it may not be possible to know in advance how many routers are in the tunnel, Whether this method works for Pre-allocated Trace Option-Type may require further discussion. We may need to specify usage scenarios for Uniform model.

ZTR> It looks you raised an valid issue. What's your suggestion on this? Do you want to propose a solution to solve this, or do you want to describe this as operational considerations or so?

In addition, would it be better to selectively partially synchronize the data fields of the IOAM TLV instead of full copies? 
For data field that needs to be modified hop-by-hop, we still need to modify the data after copying it, which will increases data plane processing. For example, the time delay needs to be calculated on the router, and the packet carries a timestamp, which needs to be modified by hop.

ZTR> So, what’s your suggestion in detail?

Best Regards,

发件人: Wangyali(Yali,Data Communication Standards and Patents Dept) [mailto:wangyali11@huawei.com] 
发送时间: 2021年6月4日 18:37
收件人: qiuyuanxiang (RD) <qiuyuanxiang@h3c.com>; spring@ietf.org
抄送: Haoyu Song <haoyu.song@futurewei.com>; Tianran Zhou <zhoutianran@huawei.com>
主题: RE: [spring] [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network

Hi authors,

Glad to see you're also interested in this topic. 

Almost 3 years ago, there was a draft-song-ippm-ioam-tunnel-mode-00 we proposed to discuss the procedure of iOAM processing in tunnels with the uniform model and the pipe model. 

Welcome to join the discussion. Please feel free to let us know your comments and questions.


-----Original Message-----
From: Qiuyuanxiang [mailto:qiuyuanxiang@h3c.com] 
Sent: Friday, June 4, 2021 11:33 AM
To: spring@ietf.org
Subject: [spring] [Spring] A new draft on data fields encapsulation model of IOAM TLV in SRv6 network

Hi WG,

Recently we published a new draft on data fields encapsulation model of IOAM TLV in SRv6 network:

URL:            https://www.ietf.org/archive/id/draft-qiu-spring-srv6-ioam-encap-model-00.txt
Status:         https://datatracker.ietf.org/doc/draft-qiu-spring-srv6-ioam-encap-model/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-qiu-spring-srv6-ioam-encap-model

It introduces the data fields encapsulation model of IOAM TLV for the Segment Routing headend with H.Encaps encapsulation behavior in SRv6 network.

Your review and comments are welcome.

Best regards,

This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!