Re: revision of architecture draft is now published

marcelo bagnulo braun <[email protected]>
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>
Hi Geoff,

El 02/07/2004, a las 7:26, Geoff Huston escribió:

> [...]

> although my concerns about traffic engineering remain.
>
> I recognise that its in the RFC3582 goal set, but I still have the 
> concern that "The consideration here appears to be that hosts need 
> much more information at hand if they are to make locator address 
> selection decisions based on some form of metric of relative load 
> currently being imposed on select components of a number of end-to end 
> network paths, and it raises the entire issue of Traffic Engineering 
> being a network function independent of host function or an outcome of 
> host interaction with the network, and if the host is to interact with 
> the network how is this interaction to be signalled?"

Ok, i agree with your point here.

perhaps we have a terminology problem here....

My intention about the TE capabilities of a mh are much more modest 
than selecting paths according to the current load. I think that a 
multihoming solution should allow the site to express some sort of 
preferences about which path to use, both for incoming and outgoing 
traffic . I think that this capability is present in current IPv4 
multihoming solution, and similar capabilities should be provided by 
the IPv6 multihomig solution.

I think that this is a reasonable goal, and that we should analyze 
different alternatives (if any) to provide it. Perhaps we end up 
concluding that the TE capabilities of the IPv6 multihoming solution 
are very limited (and that they will not match current IPv4 multihoming 
TE capabilities), but i think that this should be conclusion after 
analysing the possibilities and the tradeoffs, hence my opinion that 
this should be part of the analysis.

Regards, marcelo


>
> regards,
>
>   Geoff
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.