Subject: [pcp] You asked about multicast scope

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2012 15:50:36 +0200

Please, if you would, open http://tools.ietf.org/html/rfc4291#section-2.7. 

      scop [sic] is a 4-bit multicast scope value used to limit the scope of
      the multicast group.  The values are as follows:

         0  reserved
         1  Interface-Local scope
         2  Link-Local scope
         3  reserved

         4  Admin-Local scope

         5  Site-Local scope
         6  (unassigned)
         7  (unassigned)
         8  Organization-Local scope
         9  (unassigned)
         A  (unassigned)
         B  (unassigned)
         C  (unassigned)
         D  (unassigned)
         E  Global scope
         F  reserved

In the specification of which I spoke, we wrote:

4.  IANA Considerations

   This note requests of the IANA the assignment of a set of multicast
   addresses as described in Section 2.7 of the IP Version 6 Addressing
   Architecture [RFC4291] from the registry [v6mult].  This set of
   addresses is referred to as "ALL-NPTv6-TRANSLATORS".  One address
   should be assigned for each of the following scopes: Link-Local,
   Admin-Local, Site-Local, and Organization-Local.

5.  Operational Considerations

   This document defines a set of multicast addresses in several scopes.
   Operationally, the choice of which scope is appropriate is made by
   the administration.  A reasonable default value in system
   configurations might be Organization-Local (e.g., all NPTv6
   Translators operated by the organization).  However, a large
   organization might well choose Site-Local or Admin-Local, and
   consider that "site" or "administrative" domain to include the set of
   NPTv6 Translators advertising a default route into a specific part of
   its network.

You asked about scope, and then jumped on me about zero configuration and default scope. I quoted myself incorrectly. I said "administrative scope", by which I meant "admin-local", and in the draft I state "organization-local". I actually think that for most users, either would work, and one could argue for site-local. The definition in RFC 4291 is

         Admin-Local scope is the smallest scope that must be
         administratively configured, i.e., not automatically derived
         from physical connectivity or other, non-multicast-related
         configuration.

         Site-Local scope is intended to span a single site.

         Organization-Local scope is intended to span multiple sites
         belonging to a single organization.

I would expect in most residential/SOHO configurations, they are equivalent - they go to the CPE Router and stop without going to the ISP. The argument *against* organization-local would be that it is by default "all sites in an organization", which is probably not the best possible choice in a large organization. That said, I would expect a large organization to be willing to configure scopes.

You noted at the mike that I was irritated. You were correct. You demonstrated knowledge of multicast addressing in asking about the scope, and I answered you very directly with what the specification says about what scope I might suggest. Since you are an expert on multicast addressing, I expected you to understand the answer you were given. You didn't, and you chose to use the opportunity to dump on me. So, a direct answer in the language of and pointing to the specification you were referring to isn't deemed by you to be an adequate answer. I have little choice but to refer you to the spec. I would be happy to have a conversation with you on the topic when your objective doesn't include dumping on me.

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Mar 2012 10:35:17 +0200

On Mar 27, 2012, at 4:04 PM, Iljitsch van Beijnum wrote:

> The issue is that if there are layers of indirection, a low scope value such as this may prevent the packets from being flooded all the way to the most distant NATs: think ISP-run CGN or NAT64. Or even the edge of a large organization.
> 
> So I think the scope needs to be bigger than this. On the other hand, we don't want these packets to travel _too_ far.

which brings us back to link-local, admin-local, site-local, and organization-local. What I chose yesterday without referring to the draft was admin-local, and back when I was thinking about what the draft should say I picked organization-local.

Let me give you my mental picture of those terms, in view of Cisco. Cisco has, I'm told, 206 buildings world-wide for engineering, plus sales offices in any city of a million people or more. Those tend to be organized into campuses, which in San Jose is buildings A-P, plus buildings 1..30, plus a few others, but in most cases is on the order of 1..10 buildings or as many floors in a single building. In Germany, we have 11 campuses and a total of (this morning) 1145 people; the Munich office is two floors containing ten people. I think of "Cisco" as an "Organization", the various campuses as "sites", and the various buildings as "admin-local". I don't know if Cisco IT has the same viewpoint, but that's my mental picture.

If I were to deploy this in Cisco, I would expect a multicast to ALL-NPT-TRANSLATORS needs to go as far as the nearest DMZ at least, and maybe the nearest two DMZs. We have ~30 DMZs world-wide. That brings me somewhere in the neighborhood of site-local to organization-local.

Now, I suspect that the thought going through your mind is something along the lines of "yes, but Cisco..."

OK, so let's decapitate the problem. If the subject of discussion is a Fortune 5000 company, I would expect it has an IT department, has some concept of multicast zones and how it wants to use them, and little fear of configuring things. The conversation about "zero configuration" and "default scope" is about everyone else - and in such institutions I suspect that admin-local, site-local, and organization-local are the same or very similar. Which means we can pick anything except link-local (too narrow) and global (too wide) as a default and we won't be far wrong.

site-local?

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Mar 2012 12:08:47 +0200

On Mar 28, 2012, at 10:43 AM, Iljitsch van Beijnum wrote:

I haven't read the spec yet, but isn't PCP supposed to work in the service provider run NAT64/CGN case, too? In that case, the multicasts need to escape out of the site or even organization to reach the service provider at least in the SOHO case. So this would be a scope just shy of global, maybe a new "service provider" scope?

I personally rarely use "zero configuration" and "service provider" in the same sentence...

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Mar 2012 13:13:28 +0200

On Mar 29, 2012, at 12:02 PM, Iljitsch van Beijnum wrote:

> On 28 Mar 2012, at 12:08 , Fred Baker wrote:
> 
> Am I understanding you correctly when I take that to mean that the admin (value 4) scope is appropriate because then the people running the multicast routing can determine exactly how far these packets travel?
> 
> That makes sense, but there is one potential issue, that I think some people who are well-steeped in IPv6 multicast should look at: in this situation, the scope value 4 may need wider distribution than side-wide, which is scope 5. I can't find any documentation on whether that's ok or not between sessions right now, but I'm reluctant to assume that a lower scope value can have wider distribution than a higher one without having a spec that explicitly says so or hearing from some implementers.

I imagine. Note that the document actually says "organization scope".

The non-boilerplate part of the document contains 44 sentences; three of them, in sections 4 and 5, mention the specifics of the scope. Is it fair to assume that you have no issue with the remaining sentences?

4.  IANA Considerations

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Mar 2012 23:31:07 +0200

On Mar 29, 2012, at 2:52 PM, Iljitsch van Beijnum wrote:

> On 29 Mar 2012, at 14:15 , Brian Haberman wrote:
> 
>> It is not an assumption, it is stately quite clearly in the Scoped Addressing Architecture (RFC 4007).  From Section 5 :
> 
>>     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.
> 
> Brian, Stig, thanks for the help.
> 
> 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.
> 
> That way, the clients can always use a fixed scope = fixed multicast group, avoiding the need for discovery or configuration here.

I don't think this is a service provider discussion.