IETF Logo Mail Archive

Re: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022

"Wanghaibo (Rainsword)" <rainsword.wang@huawei.com> Tue, 30 August 2022 13:09 UTC

Return-Path: <rainsword.wang@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE81C14CF12 for <idr@ietfa.amsl.com>; Tue, 30 Aug 2022 06:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 LXQZgjhQLmcv for <idr@ietfa.amsl.com>; Tue, 30 Aug 2022 06:09:30 -0700 (PDT)
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 9BFD3C14CF16 for <idr@ietf.org>; Tue, 30 Aug 2022 06:09:30 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MH6xP6cj9z67Lmq for <idr@ietf.org>; Tue, 30 Aug 2022 21:05:45 +0800 (CST)
Received: from kwepemi500004.china.huawei.com (7.221.188.17) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 30 Aug 2022 15:09:27 +0200
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi500004.china.huawei.com (7.221.188.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 30 Aug 2022 21:09:25 +0800
Received: from kwepemi500002.china.huawei.com ([7.221.188.171]) by kwepemi500002.china.huawei.com ([7.221.188.171]) with mapi id 15.01.2375.024; Tue, 30 Aug 2022 21:09:25 +0800
From: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022
Thread-Index: AdiySb9LAa1ZOpItTciSP4+WVLsPJAKJIuiQ
Date: Tue, 30 Aug 2022 13:09:25 +0000
Message-ID: <d4f691e27c0241f7bf6dc8c8bcd0c0b3@huawei.com>
References: <BYAPR08MB487272B6440945C76FACC0D8B36A9@BYAPR08MB4872.namprd08.prod.outlook.com>
In-Reply-To: <BYAPR08MB487272B6440945C76FACC0D8B36A9@BYAPR08MB4872.namprd08.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.204]
Content-Type: multipart/alternative; boundary="_000_d4f691e27c0241f7bf6dc8c8bcd0c0b3huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/n0pXZNb0LPdXaMBFizcPuRRAWSE>
Subject: Re: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Aug 2022 13:09:34 -0000

Hi Sue & WG,

I support this adoption.


1)       Yes, I agree.
BTW. The C bit is defined by draft-ietf-idr-flowspec-redirect-ip. It doesn't seem to be relevant to this adoption document?

"This bit augments the Redirect to IP action in RFC8955
And RFC8956. "
My understanding of this sentence may be a bit inaccurate.
It mean that we first want to introduce C bit into RT Redirect Action of RFC8955 & RFC8956?

2)    Yes, I agree. As discussed earlier, it is a different solution for similar scenarios and has its unique advantages.

3)    Yes, it is useful for traffic steering in SRv6 network.

Regards,
Haibo

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, August 17, 2022 10:59 PM
To: idr@ietf.org
Subject: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022

This begins a 2 week WG adoption call for draft-jiang-idr-ts-flowspec-srv6-policy-07.txt
https://datatracker.ietf.org/doc/draft-jiang-idr-ts-flowspec-srv6-policy/

During your discussion of this draft, please consider:

1) Do you agree with extending 8955 and 8956 to carry the
action bit [C] found for IPv4 and IPv6 found
draft-ietf-idr-flowspec-redirect-ip-02.txt

Figure 1 : Local Administrator

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved           |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C = 0 - redirect original flow
C = 1 - redirect copy of original flow

This bit augments the Redirect to IP action in RFC8955
And RFC8956.

2) Do you agree with this document use of this feature
in addition to  draft-ietf-idr-flowspec-path-redirect
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/

See the following thread for a discussion of this in March:
 https://mailarchive.ietf.org/arch/msg/idr/HENTMEoiMJGmcMuVz7LTYclCSdw/

3) Will this work help deployment of SRv6 networks?

We'll discuss this draft at the IDR interim on 8/29/2022.

Cheerily, Susan Hares

v2.23.0 | Report a Bug | By Email