[Softwires] Why RFC5512 can not be used for inter-AS softwire mesh
xuxiaohu 41208 <xuxh@huawei.com> Fri, 30 July 2010 09:30 UTC
Return-Path: <xuxh@huawei.com>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAAD28C2C7 for <softwires@core3.amsl.com>; Fri, 30 Jul 2010 02:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.559
X-Spam-Level: *
X-Spam-Status: No, score=1.559 tagged_above=-999 required=5 tests=[AWL=2.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP9m0+OjzZQN for <softwires@core3.amsl.com>; Fri, 30 Jul 2010 02:30:25 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D53E228C2BA for <softwires@ietf.org>; Fri, 30 Jul 2010 02:30:19 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6D00IIS6EPYW@szxga04-in.huawei.com> for softwires@ietf.org; Fri, 30 Jul 2010 17:30:25 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6D00MPS6EPTV@szxga04-in.huawei.com> for softwires@ietf.org; Fri, 30 Jul 2010 17:30:25 +0800 (CST)
Received: from [172.24.1.3] (Forwarded-For: [130.129.20.89]) by szxmc04-in.huawei.com (mshttpd); Fri, 30 Jul 2010 17:30:25 +0800
Date: Fri, 30 Jul 2010 17:30:25 +0800
From: xuxiaohu 41208 <xuxh@huawei.com>
To: softwires@ietf.org
Message-id: <fb969fb31b55.1b55fb969fb3@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: text/plain; charset="us-ascii"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
Subject: [Softwires] Why RFC5512 can not be used for inter-AS softwire mesh
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2010 09:30:27 -0000
Hi all, The abstract of RFC5512 (The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute) is as follows: Abstract In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header. According to RFC5512, the tunnel is started from one BGP router and terminated another (i.e. the BGP next hop), unless ensuring that an ASBR that is not an AFBR does not change the next hop of the E-IP routes (i.e., option 3 for inter-AS softwire described in Softwire Mesh Framework [RFC5565]), RFC5512 alone can not be used to support inter-AS softwire mesh. As I mentioned during my presentation, the option 3 described in RFC5565 requires all non-AFBR ASBRs to be upgraded in order to support this capability. In contrast, our approach has not such limitation since we use a transitive Extended Community attribute to carry the tunnel endpoint address. Best wishes, Xiaohu
- [Softwires] Why RFC5512 can not be used for inter… xuxiaohu 41208
- Re: [Softwires] Why RFC5512 can not be used for i… Yiu L. Lee
- Re: [Softwires] Why RFC5512 can not be used for i… Xu Xiaohu