Subject: draft-ipngwg-scoping-arch-01.txt

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 16:43:52 -0400

steve/brian/brian,

I read the spec wearing my ietf spec reveiwer and architecture hat.  I
like the clarification on zones.  It is all clear to me.  I have not one
issue with it at this point.  Clearly as I start to envision what it
means to the IP and transport layer in our implementation and the API
suite other questions may arise.  But thats step 2.

Also my proposed fix for the multisited app server would not interfere
at all with your spec here.

Very roughly.  What I am thinking about is when the address is passed to
the app and its a sitelocal a unique identifier would be embedded in the
sitelocal address which would make it unique across multiple sites or in
cases where two sites merged or whatever.  My intention is NOT to
prevent using the zone/scope semantics but make them transparent to
application servers. I found many holes and have only plugged half of
them thus far but I think they can all be plugged.  The unique
identifier would never be passed on the wire.  There may be one
exception and that is if Erik's draft is to keep moving he may be able
to use the way I want to do this with ND and then they would exist
within the context of a sitelocal ND msg.

Thanks for doing this work we needed it bad.   

regards,
/jim 
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Wed, 28 Jun 2000 13:43:58 -0400

Hi Steve,

I withdraw my thoughts on having to embedd uniqueness in the sitelocal
addresses.  After reviewing this draft I can only come up with limited
cases where the app servers I mentioned cannot be made to work using
the work in draft-ipngwg-scoping-arch-01.txt.  I think each implementor
can figure it out as I have so I won't go into the details (or I don't
think I should to be accurate), but the Basic API sin6_scope_id will
resolve the multisited database problems.  The one area that does seem to 
make it problematic in the spec is:

Just before section 10 Routing:

  Addresses of a given (non-global) scope may be re-used in different 
   zones of that scope.  The zone to which a particular non-global 
   address pertains is not encoded in the address itself, but rather is
  determined by context, such as the interface from which it is sent 
   Routing Header with more than zero Segments Left [RFC 2460, section
  4.4] swaps the original destination address with the next address in
  the Routing Header.  Then the above forwarding rules are applied, 
   using the new destination address.  An implementation MUST NOT 
   examine additional addresses in the Routing header to determine 
   whether they are crossing boundaries for their scopes.  Thus, it is
  possible, though generally inadvisable, to use a Routing Header to 
   convey a non-global address across its associated zone boundary. 

I believe this is very inadvisable.

The other option is for customers that really want to use multisited
servers is to use global addresses, which will not be a scarce resource
in IPv6.

regards,
/jim

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 22:51:31 -0700

At 4:43 PM -0400 6/27/00, Jim Bound wrote:
>issue with it at this point.

Thanks, Jim.  I hope the subsequent email discussion hasn't muddied it
up again.

Steve

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 23:01:17 -0700

>I believe this is very inadvisable.

Yeah, it's not likely to do anything useful.  But I would not want to
impose the cost on implementations of a relatively expensive check (a
scan through all the addresses in a Routing header) for a such an
unlikely event.

>servers is to use global addresses, which will not be a scarce resource

Yes, that's always a choice.

Steve

---

From: Jim Bound <[email-masked]>
Date: Fri, 30 Jun 2000 05:08:50 -0400

>Thanks, Jim.  I hope the subsequent email discussion hasn't muddied it

Not at all.  Great questions and great answers.  Not a big fan of
bit-maps fyi for datastructures anymore as we evolve to multithreaded
multiprocessor implementations reason is that I don't want to search the
darn thing if it gets huge but only where a datum has changed !!!

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 30 Jun 2000 05:11:02 -0400

>scan through all the addresses in a Routing header) for a such an

Agreed.  ALso to early to limit functionality if that can be avoided.

thanks and this spec is really good on my fourth read.........
/jim