Re: [Idr] New draft - Flowspec Path Redirect

Lucy yong <lucy.yong@huawei.com> Mon, 28 September 2015 17:18 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 E566F1AD06D for <idr@ietfa.amsl.com>; Mon, 28 Sep 2015 10:18:56 -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 Ui9nis_UNtbf for <idr@ietfa.amsl.com>; Mon, 28 Sep 2015 10:18:53 -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 A043E1ACF5E for <idr@ietf.org>; Mon, 28 Sep 2015 10:18:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYD03943; Mon, 28 Sep 2015 17:18:50 +0000 (GMT)
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 28 Sep 2015 18:18:48 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Mon, 28 Sep 2015 10:18:44 -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+ZSbC0EiTPnGIEju5O55KdsXggAepmQCAAAy2EA==
Date: Mon, 28 Sep 2015 17:18:43 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F843E@dfweml701-chm>
References: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D571F7224@dfweml701-chm> <90EE5875-ED67-45CD-88AF-D5E8ECDE1774@alcatel-lucent.com>
In-Reply-To: <90EE5875-ED67-45CD-88AF-D5E8ECDE1774@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.151.171]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571F843Edfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/fSixp9AeB-UCQdWqoSBfmHVAi_4>
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: Mon, 28 Sep 2015 17:18:57 -0000

Hi Gunter,

There are active/existing/working vendor implementations of draft-ietf-idr-flowspec-redirect-ip and some SP’s are already using this.
At the same time the a redirect-ip and a PATH_ID are totally different aspects, even though both are communities…
[Lucy] if redirect via an IP tunnel, I don’t see much difference for redirect action. BGP can validate the tunnel reachability. If the path identified by PATH_ID is implemented by different technologies and/or protocols, you are right, the aspect can be very different. However, the difference is not at redirect action itself; it is how BGP control plane can validate the path existence on the data plane and control them. If BGP can do that properly, we can apply such path for a router or a flow spec.

A tunnel is setup between head-end and tail-end… so to direct a recipient router to send interesting traffic into an engineered tunnel and at the same time
exchange the tunnel setup parameters is non-trivial.
[Lucy] This is what draft-ietf-idr-redirect-ip specified. To redirect a flow over an IP tunnel brings the benefit to keep the flow packet IP dest on the tunneled packet and carries the redirect point IP address as outer src IP, which is useful for other applications. For example, which location the flow packet is sent to and which location the flow packet is redirected at. To redirect over an IP tunnel, this draft can easily be extended to cover that.
Hence the abstraction as mentioned in draft-vandevelde-idr-flowspec-path-redirect-00<https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-00> draft is a simple solution while still using existing and unchanged traditional technologies.
[Lucy] As Sue pointed out, why you think that is a simple solution? Sometime, simple for one thing but complicate to another/others. Since the path may be constructed by different technology and protocols, we should first think how BGP can integrate its flow spec or a route with a path that is or will be established by other protocols. We need use case integrity inspection. For this reason, I agree with Robert, we need first specifying PATH ID semantics that is relevant to BGP.  Don’t take me wrong, IMO: this is a good idea, but we need to work out the semantics first. In term of documenting, I would prefer flow over IP tunnel to be covered by the redirect-ip draft; sure once we figure out PATH IP semantics, IP tunnel should be naturally supported by the PATH ID approach.

Thanks,
Lucy

G/



From: Lucy yong
Date: Wednesday 23 September 2015 21:58
To: Gunter Van de Velde, "idr@ietf.org<mailto:idr@ietf.org>"
Subject: RE: New draft - Flowspec Path Redirect

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<mailto: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/