Re: [Idr] draft-bashandy-idr-bgp-repair-label-03

Ahmed Bashandy <bashandy@cisco.com> Tue, 03 April 2012 03:36 UTC

Return-Path: <bashandy@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF00821F8437 for <idr@ietfa.amsl.com>; Mon, 2 Apr 2012 20:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level:
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJeBw1KJlL0e for <idr@ietfa.amsl.com>; Mon, 2 Apr 2012 20:36:17 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F73721F876D for <idr@ietf.org>; Mon, 2 Apr 2012 20:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=10469; q=dns/txt; s=iport; t=1333424176; x=1334633776; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7a20T44We4y3fXgMlgazN6Vnl5lpxYpwMFlQW9FGJ9Y=; b=ATPQGRypxMxKUZDVYyoRjA0u3lVIqJ5loXwoBZvwlx3HLYc1ERl601OF Lyc0ywaDWM/STZ/xFsod7v2hJLblugxx8ZBpHX0hEd5i6wrAWgIPQaBPb mknjqMwWS+d47BrlQQLKIjfDNjdDd6IonNLO/riOAinbpdIVlYpa5M5kP 8=;
X-Files: signature.asc : 251
X-IronPort-AV: E=Sophos; i="4.75,361,1330905600"; d="asc'?scan'208,217"; a="35677993"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Apr 2012 03:36:16 +0000
Received: from [10.21.115.227] (sjc-vpn2-995.cisco.com [10.21.115.227]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q333aFUF008673; Tue, 3 Apr 2012 03:36:16 GMT
Message-ID: <4F7A7027.7030702@cisco.com>
Date: Mon, 02 Apr 2012 20:36:07 -0700
From: Ahmed Bashandy <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Xuxiaohu <xuxiaohu@huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3@szxeml525-mbs.china.huawei.com> <4F7A37E1.1010706@cisco.com>
In-Reply-To: <4F7A37E1.1010706@cisco.com>
X-Enigmail-Version: 1.4
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig2FBAB36D01EE58F63BFB414B"
Cc: idr@ietf.org
Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-03
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 03:36:18 -0000

The correct reference is for PE-CE link protection is the paper titled
"Achieving sub-50 milliseconds recovery upon bgp peering link failures,"
published in IEEE/ACM Transactions on Networking, 15(5):1123--1135, 2007

Thanks

Ahmed

On 4/2/2012 4:36 PM, Ahmed Bashandy (bashandy) wrote:
>
> The concept of PE-CE protection is not new. AFAIK it, was introduced
> in the paper titled "Achieving sub-second IGP convergence in large IP
> Networks" published in ACM SIGCOMM Computer Communication Review,
> 35(3):33-44, July 2005. the idea of having a special label was also
> mentioned in the paper
>
> draft-bashandy-idr-bgp-repair-label-03 specifies PE-CE protection
> using repair label in a very concrete manner so that it can be
> implemented. That is why draft-bashandy-idr-bgp-repair-label-03 is a
> standards track draft. For example some of the concrete information in
> draft-bashandy-idr-bgp-repair-label-03 :
> - proposes advertising the repair label as an optional non-transitive
> attribute.
> - specifies the syntax of the proposed attribute section 3.1.2.
> - Unambiguously specifies the semantics of the repair label and the
> forwarding behavior on the nodes participating in the scheme
> - recommends using per-CE repair label allocation
>
> In addition, the loop prevention specified in
> draft-bashandy-idr-bgp-repair-label-03 is independent of the method of
> choosing a repair path. For example, the repair path can be ECMP, 
> best external, or some other future mechanism.
>
> Besides, the concept of repair label is very general and can be used
> in other BGP FRR mechanisms such as draft-bashandy-bgp-edge-node-frr-02.
>
> Thanks
>
> Ahmed
>
>
> On 3/26/2012 1:20 AM, Xuxiaohu wrote:
>>
>> Hi co-authors of the abvove draft,
>>
>>  
>>
>> In you draft, it said"As usual, each PE allocates a local label for
>> each prefix it can reach through an external neighbor CE. This is the
>> primary label used for normal traffic forwarding." and "To provide
>> repair path information to all PEs, the PE also allocates a repair
>> label to the prefix if it can reach that prefix via an external
>> neighbor."
>>
>>  
>>
>> Does it mean the external path which the repair label is associated
>> with is a best external path? If so, could you explain what's
>> difference between the above draft and this draft
>> (http://tools.ietf.org/html/
>> <http://tools.ietf.org/html/draft-xu-idr-best-external-loop-avoidance-00>draft-xu-idr-best-external-loop-avoidance-00
>> <http://tools.ietf.org/html/draft-xu-idr-best-external-loop-avoidance-00>).
>>
>>  
>>
>> BR,
>>
>> Xiaohu
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr