IETF Logo Mail Archive

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

"梁艳荣(研发部 北京)" <liangyanrong@ruijie.com.cn> Sat, 27 August 2022 13:06 UTC

Return-Path: <liangyanrong@ruijie.com.cn>
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 C6B16C14F733 for <idr@ietfa.amsl.com>; Sat, 27 Aug 2022 06:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, 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 i6NWNgHiYVYz for <idr@ietfa.amsl.com>; Sat, 27 Aug 2022 06:06:07 -0700 (PDT)
Received: from cxsh.intel-email.com (cxsh.intel-email.com [121.46.250.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABEAC14F748 for <idr@ietf.org>; Sat, 27 Aug 2022 06:06:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by cxsh.intel-email.com (Postfix) with ESMTP id 8F8C0DDA78C; Sat, 27 Aug 2022 21:06:01 +0800 (CST)
X-Virus-Scanned: by SpamTitan at intel-email.com
Received: from cxsh.intel-email.com (localhost [127.0.0.1]) by cxsh.intel-email.com (Postfix) with ESMTP id 1303FDDA785; Sat, 27 Aug 2022 21:06:01 +0800 (CST)
Authentication-Results: cxsh.intel-email.com; none
Received: from BJEX3.ruijie.com.cn (mxbj.ruijie.com.cn [114.251.56.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cxsh.intel-email.com (Postfix) with ESMTPS id 1A08DDDA790; Sat, 27 Aug 2022 21:05:56 +0800 (CST)
Received: from BJEX4.ruijie.com.cn ([fe80::9884:380d:1e38:aa00]) by BJEX3.ruijie.com.cn ([fe80::d89a:2d84:4ea6:e7d8%22]) with mapi id 14.03.0123.003; Sat, 27 Aug 2022 21:05:56 +0800
From: "梁艳荣(研发部 北京)" <liangyanrong@ruijie.com.cn>
To: "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Re: [Idr] draft-jiang-idr-ts-flowspec-srv6-policy-07.txt - (8/17/2022 to 8/31/2022)
Thread-Index: Adi6CsfdcKgFRHGVQWOBoCc9ohuFNg==
Date: Sat, 27 Aug 2022 13:05:52 +0000
Message-ID: <16B7C8DA44B86446B7B15D642D021E3509941528@BJEX4.ruijie.com.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.25.3.165]
Content-Type: multipart/alternative; boundary="_000_16B7C8DA44B86446B7B15D642D021E3509941528BJEX4ruijiecomc_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wXpm6QnDcsqLz2vBVlUZvscMiIU>
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: Sat, 27 Aug 2022 13:06:11 -0000

Hi Susan,

I agree the adoption of this draft(draft-jiang-idr-ts-flowspec-srv6-policy-07) .

My replies to the questions as below:

1)       Yes, I agree. There are many scenarios which might need redirect one cope of the specified flow. For example, in order to analyze the traffic flow, we can redirect the copy to the specified device. And for multicast data, it is useful to directly forward the cope from an area to another remote one through an unicast tunnel.



2)       Yes, I agree. This document use is practical for many scenarios.



3)       As an vendor, we have implemented this feature in our router.

Best Regards,
yanrong


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