One doubt on RFC 7117

Haoweiguo <haoweiguo@huawei.com> Tue, 08 July 2014 03:23 UTC

Return-Path: <haoweiguo@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 BB52B1B2914 for <l2vpn@ietfa.amsl.com>; Mon, 7 Jul 2014 20:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 2ISowgWgeW8Y for <l2vpn@ietfa.amsl.com>; Mon, 7 Jul 2014 20:23:23 -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 6551D1A00D6 for <l2vpn@ietf.org>; Mon, 7 Jul 2014 20:23:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS71026; Tue, 08 Jul 2014 03:23:22 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 04:23:21 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 11:23:16 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: One doubt on RFC 7117
Thread-Topic: One doubt on RFC 7117
Thread-Index: Ac+aW5oP168O46R8Qem2DvosYqTgMQ==
Date: Tue, 08 Jul 2014 03:23:16 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F7E11AA@nkgeml501-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.135.23.94]
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7E11AAnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/EQsfBTVIlTkkaoyLO38GhhHgKfQ
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: Tue, 08 Jul 2014 03:23:24 -0000

Hi Authors of RFC 7117,

I have one doubt about the following description in RFC 7117.



[description]: The best route procedures ensure that if multiple ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP neighbors, only one of these ASBRs propagates this route in Internal BGP (IBGP).



[weiguo]: How to coordinate differnent ASBRs in an AS to ensure only one of the ASBRs propagates A-D routes to local AS in IBGP?
IMO, all ASBRs can propagate the A-D routes to remote PE in local AS, the remote PE pick one route as best route, the PE can only accept traffic data from the ASBR that advertises the best route.



Thanks

weiguo