headers
Masataka Ohta | 1 Mar 21:28
Picon

Re: Draft: PI addressing derived from AS numbers

Brian;

> > > So what I'm getting from this discussion is that 8+8 is too late but
> > > 16+16 is too large???  I would agree that 16+16 is too large.  How
> > > about 4+16?
> > >
> > 
> > I am still curious as to why people think that 16+16 would be any
> > different to 8+8.
> 
> Because, like 4+16, it can coexist with plain 16. Whether people like
> it or not, the product investments in RFC 2460 at this point oblige
> any plausible solution to behave as an upgrade to plain 16.

No problem.

First, it is not RFC2460 but RFC2373.

When I proposed to modify IPv6 addressing architecuture from 10+6
(with 48 bit MAC) to 8+8 (with 64 bit MAC, the current one in
RFC2373), I have been carefully watching that universal/local and
individual/group bits are not overridden.

Thus, it is OK to give special meaning on local group MAC addresses.

When both source and destinaiton addresses looks like local group
MAC address, IP, TCP and other stacks should behave diffferently
from leagacy ones.

People who still need local addresses should be careful not to make
(Continue reading)

Permalink | Reply | 6 comments |
headers
Masataka Ohta | 1 Mar 21:45
Picon

Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses]

Michel;

> > Kurt Erik Lindqvist wrote:
> > This I thought was more or less standard. I was talking about
> > less than 100ms convergence.
> 
> Dude, this requires a keepalive or hello at 10ms intervals and a 25~30
> ms rtt. You might need to talk to a guy named Albert Einstein; he wrote
> interesting RFCs about the speed of light that, as far as I know, have
> not been debunked yet.

A simple end to end solution is to send multiple copies of a data to
multiple pathes. Mission critical application over SONET is already
doing so and it is said that, even if a path fails, not even a single
bit is lost.

As for IP multihoming, it is already implemented with a VoIP protocol
and is working fine. Senders send multiple copies of a RTP data. At
the receivers, RTP takes care of duplicate packet deletion. Having a
few voice streams is not a problem at all, of course.

							Masataka Ohta
--------------------------------------------------------------------
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 majordomo <at> sunroof.eng.sun.com
--------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 3 Mar 10:46
Picon

Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses]

> A simple end to end solution is to send multiple copies of a data to
> multiple pathes. Mission critical application over SONET is already
> doing so and it is said that, even if a path fails, not even a single
> bit is lost.

No.

- kurtis -
Permalink | Reply | 0 comments |
headers
Masataka Ohta | 3 Mar 12:40
Picon

Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses]

Kurtis;

> > A simple end to end solution is to send multiple copies of a data to
> > multiple pathes. Mission critical application over SONET is already
> > doing so and it is said that, even if a path fails, not even a single
> > bit is lost.
> 
> No.

Which part are you arguing against?

							Masataka Ohta
--------------------------------------------------------------------
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 majordomo <at> sunroof.eng.sun.com
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Tim Chown | 11 Mar 15:03
Picon
Favicon

Again no multi6 at IETF#56

Hi,

What is required to break the impasse of no progress within the IETF on
multi6?

There are some good ideas in the "rebel" ipv6mh group (e.g. Christian's
ideas for incremental solutions using existing tools).  Even the multi6
chairs were seen in ipv6mh meetings :)

We really don't want to be appraoching IETF#57 with this bizarre situation
continuing, or do we? 

Tim
Permalink | Reply | 7 comments |
headers
Peter Tattam | 11 Mar 15:29
Picon

Re: Again no multi6 at IETF#56

I am interested in completing a solution which I sketched out a couple of
months back, but my schedule is rather full so it won't be ready for the coming
IETF meeting, but I had planned on something by the next meeting.

Peter

On Tue, 11 Mar 2003, Tim Chown wrote:

> Hi,
> 
> What is required to break the impasse of no progress within the IETF on
> multi6?
> 
> There are some good ideas in the "rebel" ipv6mh group (e.g. Christian's
> ideas for incremental solutions using existing tools).  Even the multi6
> chairs were seen in ipv6mh meetings :)
> 
> We really don't want to be appraoching IETF#57 with this bizarre situation
> continuing, or do we? 
> 
> Tim
> 
> 

--
Peter R. Tattam                            peter <at> trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210
(Continue reading)

Permalink | Reply | 0 comments |
headers
RJ Atkinson | 11 Mar 16:25
Favicon

Re: Again no multi6 at IETF#56


On Tuesday, Mar 11, 2003, at 09:03 America/Montreal, Tim Chown wrote:
> What is required to break the impasse of no progress within the IETF on
> multi6?

I'm not *recommending* this, but any action/inaction on the part of the 
IESG,
including the ADs for this WG, is appealable provided that one follows
the formal appeals process.

Frankly, I think the ADs and WG Chairs for multi6 are well across the 
line,
outside the boundaries of civilised behaviour to not even permit an 
active WG
with active on-charter list discussions to meet to discuss items listed 
in an
IESG-approved WG charter.  This is particularly true since it is not a 
one-time
occurrance, but a repeated behaviour on their part.

Yours,

Ran
rja <at> extremenetworks.com
Permalink | Reply | 5 comments |
headers
Michel Py | 11 Mar 16:47
Picon
Picon
Favicon

RE: Again no multi6 at IETF#56

ipv6mh does meet in SFO on Sunday March 16 and probably some ad-hoc
meetings during the week as well such as the one Jordi called in
Atlanta. Details on the meeting location will be posted on the ipv6mh
mailing list. Non-members are welcomed too.

                       _   ____  __      __  ____   _    _   _    _
                      | | |  _ \ \ \    / / / ___| | \  / | | |  | |
Michel Py             | | | |_| | \ \  / / | |__   |  \/  | | |__| |
Sr. Network Engineer  | | |  __/   \ \/ /  |  _ \  | \  / | |  __  |
CCIE #6673            | | | |       \  /   | |_| | | |\/| | | |  | |
mpy <at> ieee.org          |_| |_|        \/     \___/  |_|  |_| |_|  |_|
                                IPv6 Multihoming Solutions
                        http://arneill-py.sacramento.ca.us/ipv6mh
                     http://arneill-py.sacramento.ca.us/public/ipv6mh/
Permalink | Reply | 0 comments |
headers
Randy Bush | 11 Mar 17:23

Re: Again no multi6 at IETF#56

>> What is required to break the impasse of no progress within the IETF on
>> multi6?
> 
> I'm not *recommending* this, but any action/inaction on the part of the
> IESG, including the ADs for this WG, is appealable provided that one
> follows the formal appeals process.

i am impressed by your approach to technology and engineering.  welcome
to the new ietf where we care more about process and politics than protocol
and product.  sheesh!

> Frankly, I think the ADs and WG Chairs for multi6 are well across the
> line, outside the boundaries of civilised behaviour to not even permit an
> active WG with active on-charter list discussions to meet to discuss items
> listed in an IESG-approved WG charter.  This is particularly true since it
> is not a one-time occurrance, but a repeated behaviour on their part.

quite an assertion.  can you point to the request sent to agenda <at> ietf.org
to hold a meeting?  if not, ... where the sun don't shine.

to be blunt, where's the protein?  where is any good approach to this
problem that does not derive from 8+8?  and where is any progress on
8+8 that has not been stiffled by a middle-school clique approach to
working on it (thanks, ran)?

randy
Permalink | Reply | 4 comments |
headers
Masataka Ohta | 11 Mar 17:56
Picon

Re: Again no multi6 at IETF#56

Randy;

> to be blunt, where's the protein?

I'm glad to know that you asked for not a requirement draft but the
protein.

							Masataka Ohta
Permalink | Reply | 0 comments |

Gmane