IETF Logo Mail Archive

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 22:22 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 AA4AF3A68E2 for <idr@core3.amsl.com>; Sat, 2 Apr 2011 15:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.512
X-Spam-Level:
X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, 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 vTjpkcsqnDI9 for <idr@core3.amsl.com>; Sat, 2 Apr 2011 15:22:07 -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 3F8433A68D4 for <idr@ietf.org>; Sat, 2 Apr 2011 15:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1072; q=dns/txt; s=iport; t=1301783028; x=1302992628; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s42GMWIXUiF5ku+izL3IlBZgJBq/Ok0kPrW6XtZAN6c=; b=RKNz+BuDzny3/KHC5+sx0ac5JXyk7OgmkCJSbGUJybtn00biflZBVXn+ zd7d7583VdKLSifpNqZl4KpbVNA7jtI9E7Q+gkSqgmhEKeWdXC6DScbNm x5wtMuRl1esJ7CI2cIxCwkU3QlE8iuq6IuRb0hn+po0i1jGw1bJDXqAvT g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMWgl02rRDoI/2dsb2JhbAClYneIeZoygnAOAZgfhWsEjSODWw
X-IronPort-AV: E=Sophos;i="4.63,290,1299456000"; d="scan'208";a="674919057"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2011 22:23:48 +0000
Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p32MNliG027706; Sat, 2 Apr 2011 22:23:48 GMT
Message-ID: <4D97A204.8090703@cisco.com>
Date: Sun, 03 Apr 2011 00:24:04 +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> <4D97957B.7050801@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40F@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F74F40F@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 22:22:10 -0000

Hi Jakob,

> If PE3 sends an MPLS packet to PE1, PE1 uses the repair label to send
> to PE2. If CE2 sends an IP packet to PE1, PE1 should use the primary
> label to send it to PE2. It should NEVER use the repair label to send
> that packet.
>
> The reason? If the link PE2 - CE were to fail, PE2 would not use the
> backup to PE3.

Nope - sorry.

1st point: We are working here to protect against single failure not
double failure like in your example.

Now direct answer with sequence of events including time scale for 
better description:

- -10ms CE2 communicates via PE1 with CE without any protection
-  0ms CE is getting re-homed from PE1 to PE3
-  20ms PE1 on data plane is starting to use a backup label and nh=PE2
- 300ms PE1 converges control plane and starts to use primary label as
   advertised by PE2 (in the same time all network is recalculating as
   well removing CE via PE1 path)
- @ next failure - PE2-CE fails PE2 will already have a backup via PE3
   in it's data plane using backup label as advertised by PE3.

Rgs,
R.

v2.23.0 | Report a Bug | By Email