Return-Path: <fred@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
 with ESMTP id 846CE21E8082; Thu, 29 Mar 2012 14:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.542
X-Spam-Level: 
X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057,
 BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONWmINEC-KkN;
 Thu, 29 Mar 2012 14:31:14 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141])
 by ietfa.amsl.com (Postfix) with ESMTP id 4DC0221E801F;
 Thu, 29 Mar 2012 14:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com;
 i=fred@cisco.com; l=1069; q=dns/txt; s=iport; t=1333056674; x=1334266274;
 h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding;
 bh=y92Sah817gY/LhuwhElPkN5uduQx8daL4nB9DW1riII=;
 b=gpBrOTbJ6dJltPNM1sasHzIg74PItp2bHq6IpD8PlILzjjjvqG8ueh3O
 vUOuLGMU7/WMIx/sUUT4uaTHRyFLeNtISxyFdwAuXlOI+VyVKxzdqX8P8
 DQT810DNNY6peaw7Km4RzFEwyY/zy7biaLt9kh0g/3OMkMm3bVcUosPG+ Y=; 
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIHTdE+Q/khL/2dsb2JhbABCuSWBB4IJAQEBAwESASc/BQsLEgYuSQ4GNYdjBZ9Tlz+QKmMElWGFcIhWgWiCaQ
X-IronPort-AV: E=Sophos;i="4.75,339,1330905600"; d="scan'208";a="69692796"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com
 with ESMTP; 29 Mar 2012 21:31:08 +0000
Received: from dhcp-478d.meeting.ietf.org (ams3-vpn-dhcp4703.cisco.com
 [10.61.82.94]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id
 q2TLQWuE023974; Thu, 29 Mar 2012 21:31:08 GMT
Received: from [127.0.0.1] by dhcp-478d.meeting.ietf.org (PGP Universal
 service); Thu, 29 Mar 2012 23:31:08 +0200
X-PGP-Universal: processed;
 by dhcp-478d.meeting.ietf.org on Thu, 29 Mar 2012 23:31:08
 +0200
Subject: Re: You asked about multicast scope
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com>
Date: Thu, 29 Mar 2012 23:31:07 +0200
Message-Id: <AD4972E1-3FB0-4330-86DD-ED503A3567A2@cisco.com>
References: <FF493C74-28AA-4B3D-ABBA-38294010230F@cisco.com>
 <BEEE8260-1AC5-41C9-A9D7-EFF1CCF5CBB4@muada.com>
 <DA8DC604-C36C-4D59-931A-B7C22F8E2051@cisco.com>
 <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com>
 <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com>
 <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com>
 <CABOxzu0yC6Y4gFXKACDSdAy+GNzWGZStjpVMUB5HWXjBoXKUxw@mail.gmail.com>
 <4F74447E.6020506@venaas.com> <4F74526D.6070003@innovationslab.net>
 <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Brian Haberman <brian@innovationslab.net>, pcp@ietf.org,
 6man 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>,
 <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
 <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2012 21:31:15 -0000

On Mar 29, 2012, at 2:52 PM, Iljitsch van Beijnum wrote:

> On 29 Mar 2012, at 14:15 , Brian Haberman wrote:
>=20
>> It is not an assumption, it is stately quite clearly in the Scoped =
Addressing Architecture (RFC 4007).  =46rom Section 5 :
>=20
>>     A zone of a given scope (less than global) falls completely =
within
>>     zones of larger scope.  That is, a smaller scope zone cannot
>>     include more topology than would any larger scope zone with which
>>     it shares any links or interfaces.
>=20
> Brian, Stig, thanks for the help.
>=20
> Fred: I think what would be best is to define a "service provider" =
scope that is smaller than global, and larger than organization. These =
would be defined to be forwarded to ISPs by default, although =
organizations that don't want that can always filter them at the desired =
boundary.
>=20
> That way, the clients can always use a fixed scope =3D fixed multicast =
group, avoiding the need for discovery or configuration here.

I don't think this is a service provider discussion.=
