IETF Logo Mail Archive

Re: [Softwires] Why RFC5512 can not be used for inter-AS softwire mesh

"Yiu L. Lee" <yiu_lee@cable.comcast.com> Tue, 10 August 2010 20:47 UTC

Return-Path: <yiu_lee@cable.comcast.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 7C1793A682F for <softwires@core3.amsl.com>; Tue, 10 Aug 2010 13:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.969
X-Spam-Level:
X-Spam-Status: No, score=-98.969 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
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 isDDMh78xhgG for <softwires@core3.amsl.com>; Tue, 10 Aug 2010 13:47:09 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 4C25F3A6A75 for <softwires@ietf.org>; Tue, 10 Aug 2010 13:47:09 -0700 (PDT)
Received: from ([147.191.124.12]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.6139013; Tue, 10 Aug 2010 14:52:43 -0600
Received: from PAOAKEXCSMTP01.cable.comcast.com (10.52.116.30) by copdcexhub01.cable.comcast.com (147.191.124.12) with Microsoft SMTP Server id 14.0.702.0; Tue, 10 Aug 2010 14:47:40 -0600
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 16:47:39 -0400
Received: from 82.242.9.241 ([82.242.9.241]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Tue, 10 Aug 2010 20:47:38 +0000
User-Agent: Microsoft-Entourage/12.25.0.100505
Date: Tue, 10 Aug 2010 16:47:36 -0400
From: "Yiu L. Lee" <yiu_lee@cable.comcast.com>
To: xuxiaohu 41208 <xuxh@huawei.com>, softwires@ietf.org
Message-ID: <C8873328.3088A%yiu_lee@cable.comcast.com>
Thread-Topic: [Softwires] Why RFC5512 can not be used for inter-AS softwire mesh
Thread-Index: Acs4zUNf7mv4ixtTSkOZJrCvR1wEFg==
In-Reply-To: <fb969fb31b55.1b55fb969fb3@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Aug 2010 20:47:39.0277 (UTC) FILETIME=[4553EBD0:01CB38CD]
Subject: Re: [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: Tue, 10 Aug 2010 20:47:13 -0000

Hi Xiaohu,

I agree that RFC5512 alone can't solve the problem because of the reason you
pointed out. Using extcommunity is an option for an operator who owns
multiple ASes to form Inter-AS softwire mesh inside its domain. However, you
may also want to mention that two different operators may want to directly
peer to each other for Inter-AS softwire because creating softwire requires
resource, an operator may want to have explicit peering relationship to
another operator to form the mesh.

Regards,
Yiu 


On 7/30/10 5:30 AM, "xuxiaohu 41208" <xuxh@huawei.com> wrote:

> 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 mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

v2.28.0 | Report a Bug | By Email | System Status