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

Ahmed Bashandy <bashandy@cisco.com> Mon, 02 April 2012 23: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 81A9721F8747 for <idr@ietfa.amsl.com>; Mon, 2 Apr 2012 16:36:06 -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 CnL2EhlAPHr5 for <idr@ietfa.amsl.com>; Mon, 2 Apr 2012 16:36:04 -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 7A39121F874A for <idr@ietf.org>; Mon, 2 Apr 2012 16:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=9314; q=dns/txt; s=iport; t=1333409764; x=1334619364; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+vufTPsCO1VTfjA+0Qz1tsyZnM8EI22Ol4thOoaxipg=; b=LswrqpDYAH6Ny6ckB1Bx/BNUBjThNNekeO+A18kE5TTxnerEy8Q8tQ08 NbOdCm31NSXRLIVq8oNrlXT4Ra87ulOhVlnSWMsBz/lnWkgX/7N1Tfo+s 3rvFJAOWnU4516w+Rx9oHoZZsLgoPJsbKH6nU2AAp41jMxiONS+pA4j8g E=;
X-Files: signature.asc : 251
X-IronPort-AV: E=Sophos; i="4.75,359,1330905600"; d="asc'?scan'208,217"; a="35652753"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 23:36:02 +0000
Received: from [171.71.138.240] (dhcp-171-71-138-240.cisco.com [171.71.138.240]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q32Na2ma015378; Mon, 2 Apr 2012 23:36:02 GMT
Message-ID: <4F7A37E1.1010706@cisco.com>
Date: Mon, 02 Apr 2012 16:36:01 -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>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3@szxeml525-mbs.china.huawei.com>
X-Enigmail-Version: 1.4
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigFB9AA8A958A369115D1E9BDA"
Cc: "idr@ietf.org" <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: Mon, 02 Apr 2012 23:36:06 -0000

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