IETF Logo Mail Archive

Re: [Idr] New draft - Flowspec Path Redirect

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 24 September 2015 00:58 UTC

Return-Path: <jheitz@cisco.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 D97181B2FB7 for <idr@ietfa.amsl.com>; Wed, 23 Sep 2015 17:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 26C0G1EDzubn for <idr@ietfa.amsl.com>; Wed, 23 Sep 2015 17:58:01 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA6F1B2FC3 for <idr@ietf.org>; Wed, 23 Sep 2015 17:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25054; q=dns/txt; s=iport; t=1443056281; x=1444265881; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TFaKPCdR7PbDG2x3h4go4ywjhC6QnhOcAof5CH1IJ/Q=; b=hfbyUZMYiGEGQG53KdvWIbrEv4BzL3KZHbC0wyJuP+3xJP40/xsJj1Lt Zw704k3BdMtOA0L0RjX1zhPbGUK/Uq6eWboNV3gOAI1ZgO65zijHfPhzS BxXjH1U3UPsZgezHx4hCFLHkCfwHRGzhNgg8JIVu45UjMs7N7Vhw8Irh8 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0APAgBPSQNW/4wNJK1dgldNVGkGgyS6MQENgXyFdwIcgS04FAEBAQEBAQGBCoQkAQEBBCMKOiICAQYCEQQBAQsdAwICAjAUCQgCBAESCAwHiBMNmgadK5Q5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R9hFwtCgGCaS+BFAWSPoMpAYURoyMfAQFCghYXgVRxiGeBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,579,1437436800"; d="scan'208,217";a="191000150"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 24 Sep 2015 00:58:01 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8O0w0p4024269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 00:58:00 GMT
Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Sep 2015 19:57:59 -0500
Received: from xhc-aln-x02.cisco.com (173.36.12.76) by xch-rcd-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 23 Sep 2015 19:57:59 -0500
Received: from xmb-aln-x02.cisco.com ([169.254.5.144]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 19:57:59 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Liangqiandeng <liangqiandeng@huawei.com>, "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+ZSbC0EiTPnGIEju5O55JzvFAgAENGDA=
Date: Thu, 24 Sep 2015 00:57:59 +0000
Message-ID: <075DE01702BBC249BE1357EFD20DCFE53BD3D1BD@xmb-aln-x02.cisco.com>
References: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com> <FCA9153F864C2646BE37F183391FCADDD6D857@nkgeml502-mbs.china.huawei.com>
In-Reply-To: <FCA9153F864C2646BE37F183391FCADDD6D857@nkgeml502-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.19]
Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE53BD3D1BDxmbalnx02ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/-cC_lRES3n4GjnQPgSpk_1xri60>
Subject: Re: [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: Thu, 24 Sep 2015 00:58:04 -0000

When using extended communities, you can list more than one.
You can only put one copy of an attribute.

--Jakob

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Liangqiandeng
Sent: Wednesday, September 23, 2015 2:01 AM
To: VAN DE VELDE, Gunter (Gunter) <gunter.van_de_velde@alcatel-lucent.com>; idr@ietf.org
Subject: [Idr] 答复: New draft - Flowspec Path Redirect

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/

v2.23.0 | Report a Bug | By Email