Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

John Zwiebel <jzwiebel@cisco.com> Sun, 19 July 2009 18:07 UTC

Return-Path: <jzwiebel@cisco.com>
X-Original-To: pim@core3.amsl.com
Delivered-To: pim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D7B3A6C60 for <pim@core3.amsl.com>; Sun, 19 Jul 2009 11:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4l3yOw2sPrbS for <pim@core3.amsl.com>; Sun, 19 Jul 2009 11:07:50 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3B8753A6A61 for <pim@ietf.org>; Sun, 19 Jul 2009 11:07:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsFAN/9YkqrR7O6/2dsb2JhbACCJC+xUIgjjkkFhAw
X-IronPort-AV: E=Sophos; i="4.43,230,1246838400"; d="scan'208,217"; a="216114442"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2009 18:07:50 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6JI7o2q010717; Sun, 19 Jul 2009 11:07:50 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6JI7oLJ009117; Sun, 19 Jul 2009 18:07:50 GMT
Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Jul 2009 11:07:50 -0700
Received: from [10.0.1.5] ([10.21.94.25]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Jul 2009 11:07:49 -0700
In-Reply-To: <4A629A13.9050806@venaas.com>
References: <20090625174502.0FEDC3A6DE0@core3.amsl.com> <001729A7-308F-4F87-A98D-D42B87D84478@cisco.com> <4A629A13.9050806@venaas.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: multipart/alternative; boundary="Apple-Mail-18--863277459"
Message-Id: <4F52AD33-C3C3-4D00-945C-E1816C68EE81@cisco.com>
From: John Zwiebel <jzwiebel@cisco.com>
Date: Sun, 19 Jul 2009 08:07:42 -1000
To: Stig Venaas <stig@venaas.com>
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 19 Jul 2009 18:07:49.0395 (UTC) FILETIME=[D372CE30:01CA089B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6517; t=1248026870; x=1248890870; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20<jzwiebel@cisco.com> |Subject:=20Re=3A=20[pim]=20I-D=20ACTION=3Adraft-ietf-pim-g roup-rp-mapping-01.txt |Sender:=20; bh=S3aOT4p7MkdFFYZkd0wOiK9esxIF2I80WrPrp+dfua8=; b=soXpSmK7ZfBiqYrDLd2d5qSNtD9QNgR3j2yW38DUerhn0ynQQ21h9CY856 Ma6SUbAgTIlXSDPZZGDaTsGgg520LOaQf4A6AAqwynORJQkQ3YzqZolx4cVN gImpOACbSL;
Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Cc: pim@ietf.org
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pim>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jul 2009 18:07:51 -0000

On Jul 18, 2009, at 5:59 PM, Stig Venaas wrote:

>
> I completely agree, but I don't think this draft implicitly  
> mandates it.
> If you think it does, then we have a problem and we must make that  
> clear
> in the draft.
>

If I didn't think support of Auto-RP was mandatory to implement
this proposal, then I wouldn't have any problems with it.
On the other hand, I would wonder why one would bother writing it.

>  It just say that _if_ you have mappings from both, here
> is how to resolve it...

I didn't read any "..if.."

I support the idea of defining a better method of selecting group to  
RP mappings.
But if you are going to do that, then I think it better to not leave  
any holes.

Given what Pekka said in 5110, perhaps a BCP would be a better approach
than an RFC.

Also, it isn't clear if this is suppose to be a standard or just  
informational.
If it is a standard, I would remove support for auto-RP from my OS so
I wouldn't have to worry about ensuring that they work well together.

I understood you to say, "if you support auto-rp you need to follow  
this draft."

Given my experience with auto-RP and BSR at the same time, granted only
in test situations, where the allocation of groups in the BSR and  
those in
auto-RP overlap each other and have wildly different prefix-lengths, I
would never deploy auto-RP and BSR at the same time.

I'll grant you my test cases were probably unrealistic.  But if you  
make the case
to me simpler then it would be just as easy to deploy only one protocol
when merging organizations.  Ie, in the simplest case, two organizations
might define only 224/4 for the single RP for each organization.  If one
is running BSR and the other is running auto-RP, given the algorithm  
defined
in this proposal, the BSR RP would always be chosen anyway.

And if one organization runs BSR while the other auto-RP, if this  
draft is
followed, you'll have to configure auto-RP in the BSR routers and BSR  
in the
auto-RP routers.  Wouldn't it be easier to deploy BSR everywhere and
then remove auto-RP?

WRT dense-mode and ssm, I'm only saying that I view the purpose of this
draft to clearly define how group ranges are allocated.  Why not include
SSM and dense?