IETF Logo Mail Archive

RE: Advancing the Protocol and Morin Drafts

"NAPIERALA, MARIA H, ATTLABS" <mnapierala@att.com> Tue, 14 October 2008 21:17 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 BC9393A6C20; Tue, 14 Oct 2008 14:17:29 -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 709B83A6C20 for <l3vpn@core3.amsl.com>; Tue, 14 Oct 2008 14:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.549
X-Spam-Level:
X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 bZ2+XG7b1s1z for <l3vpn@core3.amsl.com>; Tue, 14 Oct 2008 14:17:27 -0700 (PDT)
Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.245.115]) by core3.amsl.com (Postfix) with ESMTP id 76ADE3A6C03 for <l3vpn@ietf.org>; Tue, 14 Oct 2008 14:17:27 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: mnapierala@att.com
X-Msg-Ref: server-6.tower-121.messagelabs.com!1224019101!20224922!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 25092 invoked from network); 14 Oct 2008 21:18:21 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 14 Oct 2008 21:18:21 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m9ELILVR023171; Tue, 14 Oct 2008 17:18:21 -0400
Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m9ELIGPu023140; Tue, 14 Oct 2008 17:18:16 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Advancing the Protocol and Morin Drafts
Date: Tue, 14 Oct 2008 17:17:49 -0400
Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20A5F363@misout7msgusr7e.ugd.att.com>
In-Reply-To: <48F505E6.6090606@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Advancing the Protocol and Morin Drafts
Thread-Index: AckuPrlbxA7hmwDgQiKHK3xxx2lqUAAAUvzA
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> <48F505E6.6090606@juniper.net>
From: "NAPIERALA, MARIA H, ATTLABS" <mnapierala@att.com>
To: raszuk@juniper.net
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
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

Robert,

(btw, I don't think we have incorrect configurations in our network..).

I am not comparing PIM Join latency to unicast route propagation (and
the latter does not takes seconds..) I am just pointing out that
translating PIM J/Ps to BGP updates and propagating (and processing)
them via several (potentially very busy, because of data-driven nature
of PIM) RRs will increase Join latency beyond that of PIM. Wouldn't you
agree with this statement?
There is a danger that this increase in Join latency might not be
acceptable by some multicast applications. 

Maria

>-----Original Message-----
>From: Robert Raszuk [mailto:raszuk@juniper.net] 
>Sent: Tuesday, October 14, 2008 4:50 PM
>To: NAPIERALA, MARIA H, ATTLABS
>Cc: CHASE, CHRIS, ATTLABS; Ross Callon; Yakov Rekhter; l3vpn@ietf.org
>Subject: Re: Advancing the Protocol and Morin Drafts
>
>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
>
>

v2.39.1 | Report a Bug | By Email | System Status