Re: [Idr] New draft - Flowspec Path Redirect

Lucy yong <lucy.yong@huawei.com> Thu, 24 September 2015 14:56 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 B9CA11AD2F2 for <idr@ietfa.amsl.com>; Thu, 24 Sep 2015 07:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0CXOTTR0W1Lp for <idr@ietfa.amsl.com>; Thu, 24 Sep 2015 07:56:56 -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 7DA901AD190 for <idr@ietf.org>; Thu, 24 Sep 2015 07:56:53 -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 CBR41977; Thu, 24 Sep 2015 14:56:52 +0000 (GMT)
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Sep 2015 15:56:51 +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; Thu, 24 Sep 2015 07:56:47 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] New draft - Flowspec Path Redirect
Thread-Index: AQHQ9kQCP5L1nukWfkqN0w8b2ysrW55KnZ4wgAB9nQCAAKXWEA==
Date: Thu, 24 Sep 2015 14:56:48 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F7656@dfweml701-chm>
References: <D0CC3567-AE4A-4770-B31A-0BFEB72CA577@alcatel-lucent.com> <2691CE0099834E4A9C5044EEC662BB9D571F7224@dfweml701-chm> <CA+b+ERkhphXp+aQD-Pd92YNig7=Uj9F=0r=Y4Qc+GvOcfYvz1Q@mail.gmail.com> <2691CE0099834E4A9C5044EEC662BB9D571F7294@dfweml701-chm> <CA+b+ERn8iLa6FBSO1V4ThNmMfyOum3AX9rE=4Jb2FtXKYqd_8w@mail.gmail.com>
In-Reply-To: <CA+b+ERn8iLa6FBSO1V4ThNmMfyOum3AX9rE=4Jb2FtXKYqd_8w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.144.130]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/DMYXOj0pCGvWXxbGyWYvZzguNA0>
Cc: idr wg <idr@ietf.org>
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 14:56:57 -0000

Inline with [lucy1]

-----Original Message-----
From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Wednesday, September 23, 2015 4:46 PM
To: Lucy yong
Cc: idr wg
Subject: Re: [Idr] New draft - Flowspec Path Redirect

> [Lucy] You mean that the PATH_ID semantics need to be specified first and it can apply to a route and flow redirect, is that right?

Yes precisely right on the spot.

Moreover I do not think this is IDR WG which should define it. The concept is clearly much broader then related to BGP Flowspec :)
[Lucy1] Agree. The Path_ID associated path may not be implemented by IP or MPLS. The work related to IDR is only how to distribute a flow (or a route) and path binding by BGP.

The closest I can think of in the analogy space would be the notion of forwarding adj where LSP is injected and flooded by link state protocol as a new type of link.

Here however we are dealing with a new description for concatenated set of encapsulations, segments or LSPs. I am not clear which WG has such responsibility in the charter .. as mentioned maybe RTGWG ..
maybe PCE ?
[Lucy1] According RT Area rule, in this case, RTG WG will be the best place to start since the path implementations relate to many WGs unless we are clear that one particular path implementation makes a sense to this usage. 

Thx,
Lucy