Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label?

Robert Raszuk <raszuk@cisco.com> Sat, 02 April 2011 21:28 UTC

Return-Path: <raszuk@cisco.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD163A68C6 for <idr@core3.amsl.com>; Sat, 2 Apr 2011 14:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.218
X-Spam-Level:
X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
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 Rgp2uKfxCr9O for <idr@core3.amsl.com>; Sat, 2 Apr 2011 14:28:38 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4B91A3A68BF for <idr@ietf.org>; Sat, 2 Apr 2011 14:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2028; q=dns/txt; s=iport; t=1301779819; x=1302989419; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yO4LglhLqPbsTzGT/bxfq4AELqJ59zhjoXvTrIGH+kc=; b=GwM43hIbMQ5xOS2NmFOb3TYPvsdVxzndFCIvRkSPaGgLDivBT+3iLC+7 ckZFdTneUstKcv5Dvy5C5VQGjmVSCg5hMFPXMaG6VjS6MeQZxLIBcfIjx 7deyDLCvLDiQbvYn8Nl6q71qAcln2LOSTNw9YNdTVf6J//HYVGoK1KxE2 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAP+Ul02rRDoJ/2dsb2JhbAClYneIeZpGgnAOAZgrhWsEjSODWw
X-IronPort-AV: E=Sophos;i="4.63,290,1299456000"; d="scan'208";a="674915313"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2011 21:30:19 +0000
Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p32LUIUl026893; Sat, 2 Apr 2011 21:30:18 GMT
Message-ID: <4D97957B.7050801@cisco.com>
Date: Sat, 02 Apr 2011 23:30:35 +0200
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@ericsson.com>
References: <5CB44ED0-486E-4CC4-9A92-F7492C25AFB5@ericsson.com> <4D9767BF.1060205@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F409@EUSAACMS0701.eamcs.ericsson.se> <4D979098.9080508@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40B@EUSAACMS0701.eamcs.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-01: when does PE revert back to standard label?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 02 Apr 2011 21:28:40 -0000

Jakob,

>>> PE1 gets no new update from PE2, therefore will continue to use the
>>> repair label to PE2.
>>
>> No update is required to be received from PE2. Loosing PE1's directly
>> attached path and recalculating all information already present in
>> control plane is already sufficient.
>
> That causes the repair label to be used towards PE2.

No. You need to realize that control plane trigger is not equal to data 
plane trigger. Those are two totally separate message paths with 
different forwarding outcome.

Any sort of FRR uses data plane/forwarding event to trigger really fast 
prefix independent switchover (usually less then 50ms) to a backup path.

However control plane is much slower. But will eventually in 100s of ms 
converge completely removing the original directly connected best path 
and it's protection via PE2.

It is really very simple.

>>> Ahmed clarified it for me like this: If PE1 receives a packet
>>> destined for a prefix advertised by CE, PE1 will push the primary
>>> label advertised by the primary egress PE (be it PE2 or any
>> other PE)
>>> and then tunnel the packet to that PE.
>>
>> Yes, but only after the local control plane convergence happens.
>
> Not necessary.

;)

>> Nope. It does not matter what type of packets are received.
>> Described in the other (non orthogonal) mail.
>
> Not described.
> Please read carefully and understand before answering.

I did, but apparently my answer was a little bit implicit but I hoped 
you will parse it. So let me try again ...

The draft says black on white:

"and associate a local label with each prefix such as L3VPN [9], 6PE 
[10], and Softwire [8]"

it directly means to me that as written it is not applicable to IPv4 and 
IPv6 non mpls protection.

And as suggested that can be fixed extending the scope of the draft to 
make it applicable also to unicast IPv4 and IPv6 as this is not only 
safe, but also desired in mpls networks where best external is injected.

R.