IETF Logo Mail Archive

Re: [Idr] New draft - Flowspec Path Redirect

Lucy yong <lucy.yong@huawei.com> Wed, 23 September 2015 19:58 UTC

Return-Path: <lucy.yong@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 8862D1A9062 for <idr@ietfa.amsl.com>; Wed, 23 Sep 2015 12:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 dnOH2ATtRnat for <idr@ietfa.amsl.com>; Wed, 23 Sep 2015 12:58:31 -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 CCB491AD357 for <idr@ietf.org>; Wed, 23 Sep 2015 12:58:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ62424; Wed, 23 Sep 2015 19:58:28 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 20:58:27 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 12:58:18 -0700
From: Lucy yong <lucy.yong@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+ZSbC0EiTPnGIEju5O55KdsXg
Date: Wed, 23 Sep 2015 19:58:17 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F7224@dfweml701-chm>
References: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com>
In-Reply-To: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.153.248]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571F7224dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/wiAW4-nj5EpWrRM6wzajv1ZllH8>
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: Wed, 23 Sep 2015 19:58:34 -0000

Hi Gunter, et al,

What is the coincident! I recently talked (offline) to an author of draft-ietf-idr-flowspec-redirect-ip about covering the third case stated in Section 3 of your draft. Do we really need two distinct extended communities for the redirect purpose? IMO: it is not, should be done by one extended community.

In addition, the redirect tunnel can be the one specified by the BGP encapsulation attribute (in draft-ietf-idr-tunnel-encap). Thus, the solution should allow BGP encapsulation attribute to work with some flowspec’s SAFIs, e.g. 133 and 134, and specify the procedure at tunnel ingress.

Regards,
Lucy




From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of VAN DE VELDE, Gunter (Gunter)
Sent: Wednesday, September 23, 2015 3:18 AM
To: idr@ietf.org
Subject: [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