[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 2402) Masataka's 8+8
From:       Masataka Ohta <mohta () necom830 ! hpcl ! titech ! ac ! jp>
Date:       1996-10-29 18:22:17
[Download RAW message or body]

> Yes your right about the Danvers meeting.  We let this one sit around
> too long I think.

I have been waiting some real standard use more than 48 bit ID and
IEEE 1394 is the one.

Still, Mike says 45 bits... Sigh...

> I think your stating plagarism has taken place on both counts?  You
> might want to take that offline with with the authors?

As the proposals are so broken, I don't think it worth doing so.

> If it was me 
> I would and if it was true I would be upset too.  

I rather upset with the poor modification on the idea.

So, technically beating the proposal is enough for me.

> But orginal
> ideas are key to any patent and architecture is very hard to prove was
> a sole original idea for addressing (and most architectures).

It's not productive nor technical to claim originality over slightly
modified proposals.

So, can we concentrate on the technical points?

Do you think we should solve site multihoming and site renumbering
only, even though people want to remove warts from multicast, mobility
and, in the future, want to support process migration?

> For example the first 8+8 like idea I recall was Paul Francis's PIP in
> 1992 I think.

It was 2+2+2+... and I acknowledged PIP in my 8+8 draft of course.

Am I polite enough?

> I bet though that if you worked with Mike or Fred they would listen to
> the input.

Why do you think I work for them, even though I already worked
for myself and produced a lot better solution?

Even if I do, they, who designed the bad designs, can't understand
the issues, which is what I have learned from my IETF experience.

So, it's really a waste of time.

> It sounds like you agree with both principles architecturally?

No, because the slight modifications are architecturally fatal.

Neither best effort IP switching nor best effort TAG switching
scales, while I know how to scalablly switch best effort
packets.

Ethernet local MAC or ATM VPI/VCI is a lot more than enough for
IP or TAG switching.

IPv6 flow label has nothing to do with IP nor TAG switching.

*ID MUST be topology independent.

*ID MUST have hierarchy.

> It would be good if we could get these two solved
> quickly

They are already solved.

IPv6 WG ignore IP or TAG switching.

Make *ID 64 bit long.

Make *ID independent of any topology.

Let *ID have hierarchy.

Have 64 bit locator to locate a subnet.

The only possible overloading is to use *ID as an intra-subnet,
thus topology independent, locator.

And, there are REASONS to do so.

Moreover, we can still support 10**12 subnets and 10**15 hosts.

> if you
> would give details on where you think the specs specifically are in
> error it would be very useful to me and I am sure to others.

If you don't think my specs are not good enough, it would be very
useful to me and I am sure to others if you would give details on
where you think the specs specifically are in error.

> So I have a
> selfish reason to hear your input and I admit it.  We need to get all
> the folks input on these a.s.a.p.

Strange.

The solution has been available for more than a year.

Why didn't you give any comment on it for such a long time?

> Plus its going to affect the existing
> code base and specs somewhat and we should get that done too.

To your surprise, the modification is minimal to use the upper
64 bits of IPv6 address only for the forwarding decision of best
effort packets beyond routers.

For other purposes, including ND and forwarding of packets with flow
label, lower 64 bits should be referenced.

							Masataka Ohta
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          	      http://playground.sun.com/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]