Subject: Summary of work areas

From: "Tony Li" <[email-masked]>
Date: Wed, 12 Nov 2003 12:02:03 -0800

Hi,

To help Elliot out, I'd like for us to start thinking
about our top level work items.  As top level items,
they should, IMHO, be as independent as possible (tho
not wholly independent).  They should not be nested and
they should not be about the details.

Here's a strawman:

Threat analysis
Locator storage & distribution
Mappings between locators, identifiers, and FQDNs
Security solutions
Exit addressing

Additions, modifications?

Tony

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 12 Nov 2003 14:28:17 -0600

Hi Tony,

I think that another issue that should be included is locator selection.

Inside locator selection you have multiple related topics:
First you have to split it in source locator selection and destination
locator selection.
Then other items fit in like:

Locator selection for initial contact
Locator selection during the communication lifetime
Policing
Load sharing

Questions: by exit addressing you mean mechanism to ensure ingress filtering
compatibility?
By security solutions you mean security solutions to preserve established
communications right?
And also by Locator storage & distribution and Mappings between locators,
identifiers, and FQDNs you are also considering this items in the context of
preserving established communications, right?

I mean, if i understand your items correclty, 3 or 4 of the 5 itmes are
focused on preserving established communications, so perhaps an initial top
level item could be preserving established communications?

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Tony Li
> Enviado el: miercoles, 12 de noviembre de 2003 14:02
> Para: [email-masked]
> Asunto: Summary of work areas
>
>
>
> Hi,
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Nov 2003 14:50:48 -0600

My list may be more cross-area than multi6 has a stomach for, although
I've been astonished at the sense of humor of the chairs so far, but I
wonder about these related topics:

- what multihoming switching looks like to applications (especially
whether/how applications might select locators)
- any possibilities for loadsharing
- transport reaction to multihoming switching (or explicitly assume
end-to-end adaptation continues to be the right answer)

Although it's outside my own area, I also wonder about interaction of
multihoming with renumbering.

Spencer

----- Original Message ----- 
From: "Tony Li" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 12, 2003 2:02 PM
Subject: Summary of work areas

Hi,

Here's a strawman:

Threat analysis

Tony

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Nov 2003 12:40:17 +0900

I'd like to add the following items

	analysis on interaction with mobility

	analysis on interaction with IGP

	analysis on interaction with BGP (or any routing protocol
	used beyond the edge of a site)

	expected average and maximum number of locators of a site

	expected maximum (for the lifetime of IPv6) number of
	global routing table entries

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 04:42:47 +0100

Tony,

> Additions, modifications?

Are you saying that these are issues that you would like to see in 
Elliots draft or are you saying that these are issues that we need to 
break out as sub-pieces in general?

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 13 Nov 2003 04:45:32 +0100

Oh, and I think the bootstrap/start-up face that Margaret and others 
brought up is something that should be on the list.

- - kurtis -

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Nov 2003 15:55:43 +0100 (CET)

> Additions, modifications?

As marcelo suggested, adding an item to the list for locator selection
(based on routing feedback, ULP feedback, etc) would make sense to me.
I think this is largely independent of the other work areas, even though the
mechanisms to get feedback from the routing system might be different depending
on other aspects of the total space.

  Erik