Subject: RE: rfc2553bis comments

From: Richard Draves <[email-masked]>
Date: Thu, 29 Jun 2000 17:21:25 -0700

> >I'm warming up to Dave's proposal, but I would not invent 
> new zone ids for
> >all the different multicast scope levels. (Or at least I'd leave this
> >optional for implementations.) I'd map the multicast scope 
> levels into the
> >link-local/site-local/global unicast scopes.
> 
> I don't think you have to create zone IDs for all multicast 
> scope levels
> *nor* do I think you have to "map" those levels into the 
> unicast levels.
> Rather, you only need zone IDs for those scopes for which you are a
> boundary (or in other words, only for those zones for which you are
> attached to more than one of the same scope).  Whenever 
> dealing with an
> address (multicast or unicast) of a scope for which you are 
> not a boundary,
> the appropriate zone is unambiguous (all your interfaces 
> belong to a single
> zone of that scope), so you can just use the "unspecified" (e.g., zero
> valued) zone id in the sin6_scope_id that accompanies that address.

I'm (mildly) concerned about how much state an implementation has to
maintain per interface. Right now in the interface structure we have fields
for an interface id and a site id. If our implementation might be used in
boundary situations for the different multicast scope levels, does that mean
the interface structure must grow to accommodate ~16 zone ids at the
different levels?

Of course this isn't the biggest space hit for an interface by far.

Rich
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 21:48:35 -0700

>the interface structure must grow to accommodate ~16 zone ids at the

In theory, yes, though there are probably a number of other, more space-
efficient ways to implement it (e.g., a zone table that is a list of zones,
each with a bitmap identifying the interfaces belonging to that zone).
If you are worried about the size, but want to keep your current
implementation, perhaps you can make each interface's zone list be a
linked-list of dynamically-allocated elements, and in all but the rarest
of cases would be very short lists.

Steve

---

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

In your previous mail you wrote:

=> I think that you already need this if you'd like to implement
scoped multicast forwarding (ie. in order to forward multicast packets
only to interfaces which belong to the right zone, you need to know
zones of each interfaces for each scope). Then I have a zone ID table
per interface and KAME has a similar thing...

=> note you need only 12 new zone IDs and 16 bits per ID are usually enough!

Regards

[email-masked]

PS: my concern is about the routing table (both size and organization).

---

From: "Brian Haberman" <[email-masked]>
Date: Fri, 30 Jun 2000 08:39:42 -0400

Francis,

> PS: my concern is about the routing table (both size and organization).

The added complexity of scoped routing has been known for awhile
now.  My original scoped routing document pointed it out in all
its messy details.

We talk about a conceptual routing table in the scoped address arch.
One way to implement it is to have a "separate" routing table per
scope.  The tables are indexed from the scope zone on the incoming
interface to give you the correct table.  Then the lookup can be
done and the packet forwarded.

Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jun 2000 17:40:53 +0200

=> my concern is not how to do it but the price to pay to have it,
ie. it is not a technical concern (as many concerns in this thread).

Thanks

PS: is the scope routing table implemented by a router vendor?
(I'd like to get opinion from router vendors)
--------------------------------------------------------------------
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: "Brian Haberman" <[email-masked]>
Date: Fri, 30 Jun 2000 12:18:30 -0400

Francis,
     I actually was implementing the scoped routing draft at
my previous place of employment.  But, since they no longer
sell routers, the code is unavailable.  The mechanism I used
was to add an additional field to the forwarding table to indicate
the scope id.  The route lookups were done using the address and
the id as the key to the lookup.

Regards,
Brian

-- 
Brian Haberman
Nortel Networks
[email-masked]