[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New I-D Submitted (Re: Newbie Question about addressing impacts)

Hi, all.

Though I guess lots of people on this list almost forgot
about this topic, I submitted 3 new I-Ds about Source Address
Selection issue.

The first one is a brief overview of our proposed model.
In short, in our model, ISPs provide Source Address Selection
Policies as well as Prefix Delegation Info by DHCP.
The consumer edge router receives those policies (from
multiple ISPs) and re-distribute them to end nodes.
End nodes put them into policy table, which leads to
appropriate source address selection.

http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist -00.txt

The second and third draft are new option proposals
for Neighbor Discovery Router Advertisement Message
and DHCPv6. Though I think these drafts should be
posted to other WG, such as IPv6 and DHC, these drafts
have close relationship with site-multihoming, so I
posted here first.

http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address- selection-opt-00.txt
http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address- selection-opt-00.txt

Questions and comments are welcome.

On 2004/08/13, at 20:22, marcelo bagnulo braun wrote:

Hi Brian, Arifumi,

I am not sure that the policy table falls under this particular component, since as i see it, the policy table is more related with locator selection when there are no failures and it is used as a mean to express administrative prefferences.
Anyway, as i understand it, Arifumi is considering mechanisms to distribute RFC3484 policy table, so this is not really related to locator selection, but rather with centralized policy management.
IMHO this will be a requirement, especially as the sites grow bigger, because manually configuring the policy table of each hosts doesn't seems a reasonable approach when there is a considerable number of hosts.
Well, in any case, i can see basically two options to provide automatic configuration of RFC3484 policy table:
- router Advertisement
- dhcp option

the porblem with RA is that the full policy table has to fit in a single RA message, since imho the distribution of the policy table should be atomic (having only part of the policy table configure may cause undesired behaviour), in addition, RA requires the configuration of the policy table in at least one router per link, which may be cumbersome
the problem with dhcp is that you need a dhcp server, but it provides most of the desired features AFAICS

imho, a policy distribution mechanism will be needed at some moment.
We have made a couple of implementations in linux of the two policy table distribution mechanisms, one using dhcp and another one using RA, to see how this work.
If anyone is interested, we can discuss it.

Regards, marcelo

El 12/08/2004, a las 16:26, Brian E Carpenter escribió:

One of the components we have already identified (see the minutes
from San Diego) is

Locator selection after a failure has been detected / Choose new address pair

RFC 3484 policy distribution might be a possible solution
for that component. We aren't chartered to do basic design in
this WG, but it would certainly be good to see proof-of-concept
for this (and every) component.

     Brian


Arifumi Matsumoto wrote: 
Oops, I forgot to send CC to multi6.
--
Hi marcelo,
Well, even if you do a per host locator selection you can still manage policy in a centralized fashion, if we define proper mechanisms to perform policy distribution, for instance a dhcp option for distributing RFC3484 policy table or something similar. However, i don't know how you can enforce policy in a centralized manner when locator selection is performed by the end hosts. 
I believe that such a mechanism for policy distribution
is really important. By making use of the existing RFC3484
framework, IMHO we can develop much manageable multi-home
environment in a simple and easy manner.
Now I'm working on this mechanism to publish a new I-D.
But I'm not sure such kind of topic is appropriate for
this WG or not. I believe this part of the technology should
be necessary for some of the proposals discussed here, though.
--
Arifumi Matsumoto
    Ubiquitous Computing Project
    NTT Information Sharing Platform Laboratories
    E-mail: arifumi@nttv6.net





--
Arifumi Matsumoto
    Ubiquitous Computing Project
    NTT Information Sharing Platform Laboratories
    E-mail: arifumi@nttv6.net