Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

Yakov Rekhter <yakov@juniper.net> Mon, 15 December 2008 02:27 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 52E8F3A6964; Sun, 14 Dec 2008 18:27:26 -0800 (PST)
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 1EB8C3A6964 for <l3vpn@core3.amsl.com>; Sun, 14 Dec 2008 18:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.465
X-Spam-Level:
X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 UyCMKP0bdupA for <l3vpn@core3.amsl.com>; Sun, 14 Dec 2008 18:27:24 -0800 (PST)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id EEEFA3A686D for <l3vpn@ietf.org>; Sun, 14 Dec 2008 18:27:22 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSUXAc2HmpT0OR199/qJxQ49zHU6Bf124@postini.com; Sun, 14 Dec 2008 18:27:17 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Sun, 14 Dec 2008 18:21:50 -0800
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Dec 2008 18:21:49 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Dec 2008 18:21:49 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Dec 2008 18:21:49 -0800
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mBF2LnM23614; Sun, 14 Dec 2008 18:21:49 -0800 (PST) (envelope-from yakov@juniper.net)
Message-ID: <200812150221.mBF2LnM23614@magenta.juniper.net>
To: "NAPIERALA, MARIA H, ATTLABS" <mnapierala@att.com>
Subject: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200166D77D@misout7msgusr7e.ugd.att.com>
References: <F9AA9B4C-3FEA-4723-BBBD-7FF91270E07D@tcb.net> <2F1DE4DFCFF32144B771BD2C246E6A200166D5CF@misout7msgusr7e.ugd.att.com> <200812140251.mBE2pLM59678@magenta.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A200166D77D@misout7msgusr7e.ugd.att.com>
X-MH-In-Reply-To: "NAPIERALA, MARIA H, ATTLABS" <mnapierala@att.com> message dated "Sun, 14 Dec 2008 21:00:06 -0500."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <92183.1229307709.1@juniper.net>
Date: Sun, 14 Dec 2008 18:21:49 -0800
From: Yakov Rekhter <yakov@juniper.net>
X-OriginalArrivalTime: 15 Dec 2008 02:21:49.0456 (UTC) FILETIME=[E2A97100:01C95E5B]
Cc: Yakov Rekhter <yakov@juniper.net>, l3vpn@ietf.org, Danny McPherson <danny@tcb.net>
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

Maria,

> Yakov,
> 
> > Could you please provide an example of how "the procedures as described
> > in section 13.1 might lead to useless S-PMSI creation for C-sources
> > operating in sparse groups which are not active".
> 
> Section 13.1 states: "Whenever a PE creates an <C-S,C-G> state as a
> result of receiving a Source Tree Join C-multicast route for <C-S, C-G>
> from some other PE, the PE that creates the state MUST originate a
> Source Active A-D route."
> 
> And section 13.2 states: " When [...] a PE creates in one of its
> MVPN-TIBs a (new) <C-*, C-G> entry with a non-empty outgoing interface
> list that contains one or more PE-CE interfaces, the PE [...] sets up
> its forwarding path to receive (C-S, C-G) traffic from the tunnel the
> originator of the selected Source Active A-D route uses for sending
> (C-S, C-G)."

What all of this has to do with S-PMSI creation ? In other words,
how does all of this support your claim that "the procedures
as described in section 13.1 might lead to useless S-PMSI creation
for C-sources operating in sparse groups which are not active" ?

> The tunnels for (C-S, C-G) traffic could be, for example,
> algorithmically derived or pre-provisioned. 

Could you please point me to the place in the spec that talks about
"algorithmically derived" tunnels.

> In general, I don't think it is a good idea to trigger Source Active A-D
> routes without the knowledge that S is "active".

Yakov.

> > -----Original Message-----
> > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > Sent: Saturday, December 13, 2008 9:51 PM
> > To: NAPIERALA, MARIA H, ATTLABS
> > Cc: Danny McPherson; l3vpn@ietf.org
> > Subject: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> > 
> > Maria,
> > 
> > > PIM-SM/RFC 4601 permits, quote, "a receiver to join a group and
> > specify
> > > that it only wants to receive traffic for a group if that traffic
> > comes
> > > from a particular source. If a receiver does this, and no other
> > receiver
> > > on the LAN requires all the traffic for the group, then the DR may
> > omit
> > > performing a (*,G) join to set up the shared tree, and instead issue
> > a
> > > source-specific (S,G) join only."
> > >
> > > Such behavior of end systems in PIM-SM means that a PE can receive
> > Join
> > > (C-S, C-G) even for sources that are not active.
> > >
> > > Section 13.1 of draft-ietf-l3vpn-2547bis-mcast-bgp-05 requires that
> > > "whenever a PE creates an <C-S,C-G> state as a result of receiving a
> > > Source Tree Join C-multicast route for <C-S, C-G> from some other
> PE,
> > > the PE that creates the state MUST originate a Source Active A-D
> > route."
> > >
> > > The procedure as described in section 13.1 might lead to useless S-
> > PMSI
> > > creation for C-sources operating in sparse groups which are not
> > active.
> > > This procedure should be enhanced to prevent triggering of S-PMSIs
> in
> > > such cases.
> > 
> > Could you please provide an example of how "the procedures as
> described
> > in section 13.1 might lead to useless S-PMSI creation for C-sources
> > operating in sparse groups which are not active".
> > 
> > Yakov.
>