headers
Masataka Ohta | 1 Mar 02:53
Picon

Re: Seoul Multi6 meeting

Brian;

> so although it is good to see such a variety of preliminary
> solution drafts, our main job now is not to design a specific 
> solution, but to conduct the architectural analysis that
> will lead to a choice of approach. That's why these two agenda
> items are very important:

> 4. draft-lear-multi6-things-to-think-about-00.txt, 30 mins, Eliot Lear
> 5. Architectural analysis, Geoff Huston, 20 mins.

g/[Aa]rchitectural/s//requirement/g

> so although it is good to see such a variety of preliminary
> solution drafts, our main job now is not to design a specific 
> solution, but to conduct the requirement analysis that
> will lead to a choice of approach. That's why these two agenda
> items are very important:

> 4. draft-lear-multi6-things-to-think-about-00.txt, 30 mins, Eliot Lear
> 5. requirement analysis, Geoff Huston, 20 mins.

You are looping.

						Masataka Ohta
Permalink | Reply | 0 comments |
headers
Masataka Ohta | 1 Mar 02:57
Picon

List of IDs required to read?

Since chairs worked hard to make ID deadline on proposals
completely fuzzy, it is not clear what are the valid
proposals and what are not.

Can chairs provide list of IDs required to read for the
next session?

Can Geoff provide list of IDs considered in his
presentation?

						Masataka Ohta
Permalink | Reply | 2 comments |
headers
Brian E Carpenter | 1 Mar 09:53
Picon
Favicon

Re: List of IDs required to read?

I believe the list is the drafts mentioned in the agenda at
 http://www.ietf.org/ietf/04mar/multi6.txt
plus draft-toyama-multi6-operational-site-multihoming-00.txt

   Brian

Masataka Ohta wrote:
> 
> Since chairs worked hard to make ID deadline on proposals
> completely fuzzy, it is not clear what are the valid
> proposals and what are not.
> 
> Can chairs provide list of IDs required to read for the
> next session?
> 
> Can Geoff provide list of IDs considered in his
> presentation?
> 
>                                                 Masataka Ohta

--

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM
Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 1 Mar 10:25
Picon
Favicon

Re: draft-savola-multi6-asn-pi-01.txt


Noel Chiappa wrote:
> 
>     > From: Pekka Savola <pekkas <at> netcore.fi>
> 
>     > every branch which connects to ISPs has different addresses. This will
>     > be pure hell for network admins if they have offices in e.g. 100 or 200
>     > countries, but such is life, I guess... :)
> 
> And those 100-200 branches also have different street/mailing addresses,
> right? Which causes all sorts of grief in having to have 200 different kinds
> of pre-printed stationery with street/mailing addresses on it, etc, etc, etc.
> But people don't piss/moan/whine about it, because that's a fundamental
> aspect of street/mailing addresses.
> 
> The routing has to have "names" which are topologically significant. If
> people want a namespace which *doesn't* have those properties, because they
> find those properties *inconvenient*, then they can get off their tailbones
> and add one.
> 
> Harumph.

As a matter of fact, this is today's practice. The trouble is, that in order
to preserve a rational and uniform *internal* addressing plan, it is achieved
by using NAT at each ISP access point. The tricky bit is to achieve the
same effect without NAT and without horrendous address administration
busy-work.

Harumph also.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurtis Lindqvist | 1 Mar 14:31
Picon

BOUNCE multi6 <at> ops.ietf.org: Non-member submission from ["Randall R. Stewart (home)" <randall <at> stewart.chicago.il.us>] (fwd)


Approved: dual-stack
From randall <at> stewart.chicago.il.us Wed Feb 25 13:25:27 2004
Received: from [66.93.186.36] (helo=stewart.chicago.il.us)
	by psg.com with esmtp (Exim 4.30; FreeBSD)
	id 1Avz2U-000Pxe-U8
	for multi6 <at> ops.ietf.org; Wed, 25 Feb 2004 13:25:27 +0000
Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1])
	by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i1PDPHMC064744;
	Wed, 25 Feb 2004 07:25:19 -0600 (CST)
	(envelope-from randall <at> stewart.chicago.il.us)
Message-ID: <403CA23D.90401 <at> stewart.chicago.il.us>
Date: Wed, 25 Feb 2004 07:25:17 -0600
From: "Randall R. Stewart (home)" <randall <at> stewart.chicago.il.us>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen <at> micmac.franken.de>
CC: multi6 <at> ops.ietf.org, Coene Lode <Lode.Coene <at> siemens.com>,
   "'Barany, Pete'" <pbarany <at> qualcomm.com>
Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt
References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2 <at> hrtades7.atea.be>
<4B9D73E0-66C6-11D8-AF58-000A95C37894 <at> micmac.franken.de>
<403B9E51.1040902 <at> stewart.chicago.il.us> <49AD8793-6700-11D8-A77D-000A95DC192A <at> micmac.franken.de>
In-Reply-To: <49AD8793-6700-11D8-A77D-000A95DC192A <at> micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=2.63
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 1 Mar 15:09
Picon

Re: Ad-hoc streaming


On 2004-02-29, at 16.46, Iljitsch van Beijnum wrote:

> In response to my message a while ago, Kurtis has graciously offered 
> to do some ad-hoc streaming for those of us who won't be participating 
> in person.
>
> If you're interested, please have a look at 
> http://www.muada.com/multi6streaming.php and send me a message if you 
> want to participate, so I can make sure there are no bandwidth 
> problems with the streaming server. Expect 300 kbps or less for video, 
> or just 32 kbps audio.
>
> Also note that when the wednesday morning session starts it's still 
> tuesday evening and night in the US and Europe, respectively.  :-)

As for this part, I am all for trying it. However, I do realize that 
there is somewhat more to this. If someone opposes that we will attempt 
to broadcast the session, please let me know.

>
> And if anyone has information on the jabber situation, please send it 
> my way...

It's up an running. We are still trying to find volunteer scribes 
though...

Best regards,

kurtis -
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 1 Mar 15:11
Picon

Re: List of IDs required to read?


There is also a list at http://ops.ietf.org/multi6/draft-list.html. 
However, when I tried to update it with the drafts on the agenda (the 
latest -00 drafts) there was a problem. I will resolve this ASAP. That 
list is meant to be the source of drafts that are part of Geoffs 
review. If someone feels that something is missing, you can address 
that with me and Brian.

Best regards,

kurtis -

On 2004-03-01, at 09.53, Brian E Carpenter wrote:

> I believe the list is the drafts mentioned in the agenda at
>  http://www.ietf.org/ietf/04mar/multi6.txt
> plus draft-toyama-multi6-operational-site-multihoming-00.txt
>
>    Brian
>
> Masataka Ohta wrote:
>>
>> Since chairs worked hard to make ID deadline on proposals
>> completely fuzzy, it is not clear what are the valid
>> proposals and what are not.
>>
>> Can chairs provide list of IDs required to read for the
>> next session?
>>
>> Can Geoff provide list of IDs considered in his
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 1 Mar 15:12
Picon

Re: host-centric draft


On 2004-02-25, at 18.06, Erik Nordmark wrote:

>> So the question is: can we detect the actual reachability using probes
>> fast enough that we don't feel we also need to look in the routing
>> tables? If end-to-end is 30 seconds while routing table is 30
>> microseconds, then sure, I agree that the latter is useful. If
>> end-to-end is 3 seconds, maybe having to wait this long some of the
>> time is better than importing all this BGP complexity. If it's 300
>> milliseconds I'm sure it is.
>
> That's on the benefit side, but also have too look at the cost side
> in terms of scaling.
> If all hosts perform e2e probing of all the local/peer locator pairs
> this might add up to a lot of packets; might be more than the amount of
> data packets that are exchanged in some cases (imagine hosts being 
> sensors
> which only send a data packet every 30 seconds and now you add probing 
> 4 or
> so local/peer locator pairs!).
>
> If we care about *site* (and not *host*) multihoming one could try to
> have hosts share the information they learn from probing with their
> neighboring hosts. But that leads more or less to reinventing
> a routing protocol.

Or piggybacking on one of the existing ones?

Best regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 1 Mar 15:16
Picon

Re: host-centric draft


On 2004-02-25, at 18.43, Iljitsch van Beijnum wrote:

>
>> might be more than the amount of
>> data packets that are exchanged in some cases (imagine hosts being 
>> sensors
>> which only send a data packet every 30 seconds and now you add 
>> probing 4 or
>> so local/peer locator pairs!).
>
> That's why I think we should only perform reachability checks when we 
> already know or at least have a strong suspicion that something is 
> wrong.
>
> One possible exception is session establishment: it might be useful to 
> try several setup attempts in parallel, as the one that completes the 
> fastest is probably also the one that offers best peformance during 
> the session.
>
Don't this open up for a new DDoS? Interrupt the transport on both 
sides, or at a (or multiple) site exit router, enough to cause a storm 
of setup attempts?

Best regards,

kurtis -
Permalink | Reply | 12 comments |
headers
Noel Chiappa | 1 Mar 20:28
Picon
Gravatar

Re: draft-savola-multi6-asn-pi-01.txt

    > From: Brian E Carpenter <brc <at> zurich.ibm.com>

    >> If people want a namespace which *doesn't* have those properties,
    >> because they find those properties *inconvenient*, then they can get
    >> off their tailbones and add one.

    > As a matter of fact, this is today's practice. The trouble is, that in
    > order to preserve a rational and uniform *internal* addressing plan, it
    > is achieved by using NAT at each ISP access point.

In light of my immediately preceeding comment, this seems to me to be an
obvious sign that we have too few namespaces *in the current system*.

    > The tricky bit is to achieve the same effect without NAT and without
    > horrendous address administration busy-work.

Were such another namespace (e.g of host ID's) available, so that the
routing-names of these machines would be less "interesting" (and possibly
assigned automatically, e.g. by concatenating an "interface ID" with the
routing-name of the physical network they connect to - and yes, I know
there's lots of other needed springs and gears, like getting those addresses
into something like the DNS), do you think we would not see this focus on the
routing-names?

In other words, is the situation you describe (where people have one
addressing scheme internally, and another externally, with NAT to map between
them) caused precisely by having too few name-spaces - or would the same
thing happen even if we also have an additional namespace of host identifiers?

If the latter, that's something I'd like to understand - because clearly,
(Continue reading)

Permalink | Reply | 501 comments |

Gmane