Comments on draft-bonica-l3vpn-orf-covering-prefixes-01

Xuxiaohu <xuxiaohu@huawei.com> Mon, 03 March 2014 16:30 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775901A0255; Mon, 3 Mar 2014 08:30:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 liPRz_5eFbdG; Mon, 3 Mar 2014 08:30:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5E1A01DA; Mon, 3 Mar 2014 08:30:36 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBR90351; Mon, 03 Mar 2014 16:30:33 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 16:28:44 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 16:29:09 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 00:29:04 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "l2vpn@ietf.org" <l2vpn@ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
Subject: Comments on draft-bonica-l3vpn-orf-covering-prefixes-01
Thread-Topic: Comments on draft-bonica-l3vpn-orf-covering-prefixes-01
Thread-Index: Ac82+ue6KOUnnJrIQLutd1IqTrDcwQ==
Date: Mon, 3 Mar 2014 16:29:04 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0825E8F8@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.77.204]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/d9j_YLiRQXv0bW-6hy3uCLHRsl8
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 16:30:39 -0000

Hi all co-authors,

It seems that you are pursuing a more specific granularity-based route filtering mechanism for L2 and L3 VPNs, i.e., VPN-prefix-granularity-based route filtering. If so, why still rely on the Virtual-HUB-Spoke model [RFC7024] where different RT attributes (e.g.,RT-red-from-HUB, RT-red) need to be configured for a given VPN instance.  

In fact, since we are now seeking VPN-prefix-granularity-based, rather than
VPN-granularity-based, route filtering tools, it seems there is no need to confine operators with the approach proposed by RFC7024 which is actually a type of VPN-granularity-based route filtering mechanism anymore. Insteads, operators could use a more straightforward method to realize VPN-prefix-granularity-based route filtering. For example, operators could just configure a single RT (e.g., RT-red) for a given VPN instance and enable VPN-prefix-based ORF capability between BGP peers. If a PE router acting as RR-client just needs a default IP or MAC route advertised from its RR, it just needs to ask the RR to send a default VPN route associated with RT-red, if that PE router needs a host route for a given destination CE host, it just needs to ask the RR to send a host route for that CE host associated with RT-red. In this way, there is no need to ask the RR to add an additional RT when reflecting a route which is required by the PE router.

Best regards,
Xiaohu