Subject: RE: rfc2553bis comments

From: "Dave Thaler" <[email-masked]>
Date: Thu, 29 Jun 2000 17:59:17 -0700

Steve Deering replied:
> At 4:42 PM -0700 6/29/00, Dave Thaler wrote:
> >For example scop 4, being smaller than site-local scope,
> >should use the site-local scope ids.  If you're
> >in multiple sites, you can't assume all interfaces
> >are in the same scop 4 zone.
> 
> Hmm, yes, I can see how you can use that approach to avoid creating
> zone indices for scop 4 on site-boundary nodes.  I was working from
> the assumption that you *would* have scop 4 zone ids on such a node,
> i.e., *if* scop 4 were configured to be used within a site, it
> would have to be configured on all site-boundary nodes.

Re "if scop 4 were configured to be used within a site"...
So if we have a host with interfaces in two sites, and
there's no manual configuration related to scop 4, and
if an app tried to send to or join a multicast group
in scop 4 are you saying that the send/join would fail?
I'd rather be liberal in what we accept here and have it
succeed, which is what I was trying to allow.

> However, you still need the capability to explicitly configure scop 4
> zone ids on site-boundary nodes, in case the node is attached (via
> different interfaces) to more than one scop 4 zone within the 
> same site.

Agree.

> And you also need the capability to configure scop 4 zone ids on nodes
> that are internal to a site, i.e., not site-boundary nodes.

I didn't follow this.  I was suggesting that you don't need
separate scop 4 zone ids in this config, you use the same ids
as for scop 5 (and you use a disjoint numbering space as Erik
suggested to disambiguate this).

> >So my proposed correction to Steve's rule is:
> >"Whenever dealing with an address (multicast or unicast) of
> >a scope for which you are not a boundary, the appropriate zone
> >is unambiguous, so the sin6_scope_id is the same zone id of
> >the next larger scope for which you are a boundary (e.g., zero
> >if you are not a boundary for any larger scope level)."
> 
> That's still not quite right, because if you are a boundary for
> scope x, you are *necessarily* a boundary for all configured scopes
> less than x, since a smaller zone cannot span across boundaries
> of a larger zone.

I agree the wording "are not a boundary" is problematic here.

-Dave

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 21:53:25 -0700

>in scop 4 are you saying that the send/join would fail?

I guess that is what I was saying (or, at least, an consequence of what
I was saying).

>succeed, which is what I was trying to allow.

I'm not sure how lax you want to be with zone-boundary configuration.
Seems to me that, in the IPv4 admin multicast scope case, we were quite
worried abou the hazards of "leaky" zone boundaries.

>suggested to disambiguate this).

I meant for nodes that are scop 4 boundaries but not site boundaries.

Steve

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jun 2000 10:27:59 +0200

In your previous mail you wrote:

=> the unspecified zone (ie. zero sin6_scope_id) can give a default
zone in scop 4 if a default rule has been configurated (the existence
of a default rule should be optional).

   
=> we have not (yet) defined the meaning of a zone ID for a scope larger
than the address. The only hairy case is where it is ambiguous, for instance
in this context one specify a site when the node has interfaces in two
zones of scope 4 in this site. Again we can introduce an optional
default rule (a new one if this site is not the default site)...

   Content-Type: text/html;

=> I think this part has no more information (ie. its purpose is just
to make the message far larger :-) ?

Regards

[email-masked]

PS: here my concern is still with the routing table...