[Idr] 答复: New draft - Flowspec Path Redirect

Liangqiandeng <liangqiandeng@huawei.com> Wed, 23 September 2015 09:01 UTC

Return-Path: <liangqiandeng@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FDB1A92F8 for <idr@ietfa.amsl.com>; Wed, 23 Sep 2015 02:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rne_ZwRx_bX for <idr@ietfa.amsl.com>; Wed, 23 Sep 2015 02:01:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586661A92F0 for <idr@ietf.org>; Wed, 23 Sep 2015 02:01:17 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY27118; Wed, 23 Sep 2015 09:01:15 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 10:01:13 +0100
Received: from NKGEML502-MBS.china.huawei.com ([169.254.4.27]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 17:01:06 +0800
From: Liangqiandeng <liangqiandeng@huawei.com>
To: "VAN DE VELDE, Gunter (Gunter)" <gunter.van_de_velde@alcatel-lucent.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: New draft - Flowspec Path Redirect
Thread-Index: AQHQ9dhhbe2+ZSbC0EiTPnGIEju5O55JzvFA
Date: Wed, 23 Sep 2015 09:01:05 +0000
Message-ID: <FCA9153F864C2646BE37F183391FCADDD6D857@nkgeml502-mbs.china.huawei.com>
References: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com>
In-Reply-To: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.113.180]
Content-Type: multipart/alternative; boundary="_000_FCA9153F864C2646BE37F183391FCADDD6D857nkgeml502mbschina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/Jq7fjnGL5xr6pbkHg__Wc0cQ7gY>
Subject: [Idr] 答复: New draft - Flowspec Path Redirect
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 23 Sep 2015 09:01:20 -0000

Hi G. Van de Velde and co-authors,

It may be a good idea to define a new redirect-to-Path-id flow-spec action. A Path-id as an abstract concept can cover the scenarios of redirecting to VPN instance, RT, target IP, output interface or output tunnel.

So it can be more general. But as you has found, The key of this solution is that the BGP Peers should comprehend the locally available redirection information referenced by the Path-id conformably. what do you think to resolve this issue?

In other hand, a flowspec rule bound a tunnel-encap attribute can satisfy the same requirement in some scenarios as the flowspec rule carried with a "redirect to path-id" action. Could you give me some advice how to use them individually?

Best regards,
Qiandeng

发件人: Idr [mailto:idr-bounces@ietf.org] 代表 VAN DE VELDE, Gunter (Gunter)
发送时间: 2015年9月23日 16:18
收件人: idr@ietf.org
主题: [Idr] New draft - Flowspec Path Redirect

Hi Folks,

We have created a new draft to allow the capability to have Flowspec signal a redirect to tunnel/LSP.

https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00

The base principle is to use the indirection capability of BGP for path redirection.

This proposal defines a new flowspec community to signal a redirect ‘path-id’. This path-id is is either a 128bit or 32bit value
Assumed is that recipient router supporting path-id redirect have a localised path-id indexed table containing LSP/tunnel encapsulation information.
Existing technology can be used to construct/create this table (LDP, SR, RSVP, manual-config, etc…) on a recipient router. The LSP/tunnel encap table is indexed using 32 or 128 bit values.

Flowspec path-id community is used to activate a redirect LSP/tunnel and provide by indirection the LSP/tunnel information for the flowspec identified traffic towards the LSP/tunnel.

Benefits:

  *   no need for signalling labels or extra encap in BGP
  *   Each path-id indexed LSP/tunnel table is a localised construct
  *   existing technology is used to construct the path-id indexed localised table
  *   Compatibility with technologies already using 32 or 128 bit identifiers for paths and sessions
  *   Easy for flow spec to signal as it introduces no need to signal labels etc… no conflicts with existing label exchange technologies
Feedback welcome.

G/