Re: revision of architecture draft is now published

[Geoff Huston <gih@telstra.net>]

At 09:19 PM 2/07/2004, marcelo bagnulo braun wrote:
> 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.

I've no problem with the goal as a theoretical objective. My comment is in 
looking at the information available to a host that would be used as the 
basis of a preference decision. To be of any practical use this preference 
would be based on some level of information about the current state of the 
network paths (available capacity, latency, [QoS stuff]) and at this point 
we appear to be reentering the QoS routing realm with the added issue of 
host / network interaction.

However I suppose that the question here is that given that some 
considerations about TE should be included in the document, what text is 
appropriate here that notes the goal, but references the large body of work 
that has been undertaken already on QoS and TE?

Suggestions are, obviously, solicited!

thanks,

  Geoff