About loop avoidance when using BGP best external

Xu Xiaohu <xuxh@huawei.com> Fri, 08 April 2011 04:13 UTC

Return-Path: <xuxh@huawei.com>
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318EF3A6A43 for <l2vpn@core3.amsl.com>; Thu, 7 Apr 2011 21:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.925
X-Spam-Level:
X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, 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 iJuWiG0Mie-p for <l2vpn@core3.amsl.com>; Thu, 7 Apr 2011 21:13:27 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2C4E53A6784 for <l2vpn@ietf.org>; Thu, 7 Apr 2011 21:13:27 -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 <0LJB00397FNKXG@szxga04-in.huawei.com> for l2vpn@ietf.org; Fri, 08 Apr 2011 12:11:44 +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 <0LJB00JYRFNKIT@szxga04-in.huawei.com> for l2vpn@ietf.org; Fri, 08 Apr 2011 12:11:44 +0800 (CST)
Received: from x41208c ([10.110.98.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJB009FDFNKZ7@szxml04-in.huawei.com> for l2vpn@ietf.org; Fri, 08 Apr 2011 12:11:44 +0800 (CST)
Date: Fri, 08 Apr 2011 12:20:05 +0800
From: Xu Xiaohu <xuxh@huawei.com>
Subject: About loop avoidance when using BGP best external
To: raszuk@cisco.com
Message-id: <002901cbf5a4$3cf3e690$60626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: Acv1pDybf4GWxtrWRK2CBTxtUvJ4Xw==
Cc: l2vpn@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 08 Apr 2011 04:13:28 -0000

-----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of 
> Robert Raszuk
> Sent: Sunday, April 03, 2011 2:26 AM
> To: Jakob Heitz
> Cc: idr
> Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does 
> PE revert back to standard label?
> 
> Hi Jakob,
> 
> > I think the draft needs to state that a received native IP packet is 
> > NEVER sent using the repair label. Specifically, if the IP path to 
> > the CE is broken, a packet received as a native IP packet shoul be 
> > sent to the PE next hop using the regular label, not the repair 
> > label. The repair label should only be used for packets received 
> > from MPLS.
> 
> The draft already states this:
> 
>     In a BGP free core, where traffic is tunneled between edge routers
>     and edge routers assign labels to prefixes, BGP speakers advertise
>     reachability information about prefixes and associate a local label
>     with each prefix such as L3VPN [9], 6PE [10], and Softwire [8].
> 
> But thinking further I do not see perhaps anything wrong on attaching 
> this attribute to unicast IPv4 and IPv6 AFIs where ASBRs and network 
> between them are MPLS enabled.
> 
> In fact if we would explicitly permit this in 
> draft-bashandy-idr-bgp-repair-label it will automatically address the 
> problem as described in draft-xu-idr-best-external-loop-avoidance.

Hi Robert,

Sorry that I just notice this email mentioning my draft
(draft-xu-idr-best-external-loop-avoidance).

IMO, the repair-label draft (draft-bashandy-idr-bgp-repair-label) and my
draft have many differences as listed below (here I just refer the L3VPN CE
multi-homing scenario):

1. Different target scenarios:
The repair-label draft targets the scenario where the best route for the
local CE site on each multi-homing PE router is pointed to the CE router,
while my draft targets the scenario of best external.  

2. Different achievements:
The repair-label draft only solves the problem of transient loop in case the
CE router is down (anyway, the CE destination is unreachable at this time).
While my draft not only solves the transient loop problem, but also speeds
up the convergence in case the best external route is still available. 

3. Different approaches:
The repair-label draft requires some changes to the BGP protocol while my
draft doesn’t require any change to the BGP protocol.
  
Best wishes,
Xiaohu
  
> Thx,
> R.
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr