Re: Advancing the Protocol and Morin Drafts

Robert Raszuk <raszuk@juniper.net> Tue, 14 October 2008 20:51 UTC

Return-Path: <l3vpn-bounces@ietf.org>
X-Original-To: l3vpn-archive@megatron.ietf.org
Delivered-To: ietfarch-l3vpn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270FB3A6B2C; Tue, 14 Oct 2008 13:51:02 -0700 (PDT)
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176553A6874 for <l3vpn@core3.amsl.com>; Tue, 14 Oct 2008 13:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.338
X-Spam-Level:
X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ml7IBx+q6u8C for <l3vpn@core3.amsl.com>; Tue, 14 Oct 2008 13:51:00 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id BB2163A6B8B for <l3vpn@ietf.org>; Tue, 14 Oct 2008 13:50:56 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 14 Oct 2008 13:50:49 PDT
Received: from [172.26.250.98] ([172.26.250.98]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:49:47 -0700
Message-ID: <48F505E6.6090606@juniper.net>
Date: Tue, 14 Oct 2008 13:49:42 -0700
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "NAPIERALA, MARIA H, ATTLABS" <mnapierala@att.com>
Subject: Re: Advancing the Protocol and Morin Drafts
References: <A834346E-E29F-4CD5-94AF-D6B99D1E2D42@multicasttech.com><2F1DE4DFCFF32144B771BD2C246E6A20E721CD@misout7msgusr7e.ugd.att.com><200810101608.m9AG86M66693@magenta.juniper.net><03D8DAB8DC0DE545A222EAA08C22C43A01F2BCA1@TSMAIL3.ad.tri.sbc.com> <48F4FE70.2090706@juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A20A5F361@misout7msgusr7e.ugd.att.com>
In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A20A5F361@misout7msgusr7e.ugd.att.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Oct 2008 20:49:47.0687 (UTC) FILETIME=[6529FB70:01C92E3E]
Cc: Ross Callon <rcallon@juniper.net>, Yakov Rekhter <yakov@juniper.net>, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@juniper.net
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
Sender: l3vpn-bounces@ietf.org
Errors-To: l3vpn-bounces@ietf.org

Hi Maria,

PIM Join latency would be in unicast world comparable to single prefix 
propagation by BGP.

Configuration I was talking about is not special .. but just correct :).

So in your network are you saying that single VPN prefix propagation in 
loaded production takes order of seconds from the moment one CE sends it 
to it's closest PE and the other CEs installs it in the RIB/FIB ? That's 
way too much I agree.

The only possible cause I could think of would be MRAI timer but most 
implementation I am familiar with have either this default to zero or it 
possible to be set as zero by single knob.

Perhaps what you are saying is that you may not have control over CEs 
and some BGP code there by default applies MRAI while PIM does not have 
such concept. That scenario indeed would be the cause of the delay for 
BGP propagation and not for PIM even if your core's BGP configuration 
would be already optimal.

Thx,
R.

> Hi Robert,
> we can achieve < 150 ms PIM Join latency (US cost-to-cost) without any
> special configuration. This yet has to be demonstrated with any other
> protocol in a loaded production environment...
> 
> Maria