Subject: Re: addition of TLV to locator ID or locator ID set
From: Paul Jakma <[email-masked]>
To: Erik Nordmark <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, shim6-wg <[email-masked]>
Date: Fri, 30 Sep 2005 21:16:37 +0100 (IST)

On Thu, 29 Sep 2005, Erik Nordmark wrote:

> How does the host get an IPv6 address assigned that has the right 
> low-order bits so that the HBA stuff on the remote shim/proxy can 
> prove (using HBA) to the peer that it owns the IPv6 address hence 
> is allowed to redirect it?

I don't know. I'm not terribly familiar with HBA. Marcelo seems to 
think it's possible.

BTW, one question, is HBA a requirement for shim6?

Other possibilities include simply securing the side-band shim6 
protocol (using, eg, anonymous IPSec) and disallowing any 
locator<->ULID (do i have the jargon correct?) state changes to occur 
other than through the secured side-band.

Then you wouldn't need to try stuff security state into an address.

> destination locators to be changed). Thus if the shim proxy wants 
> to handle this, it needs to first do a 1:1 IPv6 NAT where the proxy 
> has created the HBA/CGA addresses for the host.

It'd have to be a 1:1 NAT yes.

> One could envision having DHCPv6 be shim aware so that when the 
> hosts asks DHCP for an address, the DHCP server would interact with 
> the shim proxy so that the addresses are from a HBA or CGA set. In 
> that case one wouldn't need the 1:1 IPv6 NAT in the shim proxy.

Hmm, possible I guess.

>   Erik

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Liar, n.:
 	A lawyer with a roving commission.
 		-- Ambrose Bierce, "The Devil's Dictionary"

Delivery-date: Fri, 30 Sep 2005 09:32:11 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: source address rewriting and shim6 proxies
Date: Fri, 30 Sep 2005 11:32:03 +0200
To: Erik Nordmark <[email-masked]>

El 29/09/2005, a las 20:28, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>> what difficulties am i missing?
>
> The first one is that we don't know what problem we are trying to=20
> solve with shim proxies.

:-)
as you stated it in the previous message, there are at least two=20
flavors of proxies:
one would not require shim support form the the host (support legacy=20
hosts) and the other one would require some support from the hosts=20
(i.e. it would require hosts to support part of the shim)

one reason for the first type of proxies would be to enable shim=20
functionalities in legacy hosts
The reasons that i can see for the second type of proxies would be that:
- it would offload the exit path selection to the routing system, which=20=

is more similar to the current paradigm. In this case, the exit path=20
selection process would benefit from routing information available in=20
the routing system of the  multihomed site. In particular, exit path=20
failures would be directly detected by the routing system. Moreover, it=20=

would enable the performance of some type of traffic engineering based=20=

in the the configuration of the route selection in the routing system,=20=

again more similar to current paradigm.
- it would provide ingress filtering compatibility, leaving source=20
address dependent routing just as a mechanism to support legacy hosts=20
(internal and external). so even if there is still a need for something=20=

like source address dependent routing, the upgraded nodes won't need=20
it.

>  It could be enabling legacy IPv6 hosts behind a proxy (this is what=20=

> Paul is suggesting as far as I understand), or it could be having shim=20=

> aware hosts offload some functionality to a shim proxy.
>
> The issues with the two are quite different. So which one are we=20
> trying to solve?
>
> Your comments were related to the second problem:
>
>> I am not sure i can see any difficulty with this... I mean in current=20=

>> multihomed site scenario, where the prefixes are quite stable and=20
>> they change because of renumbering events associated to changes in=20
>> the ISPs, the coordination of the prefix set perceived by the host=20
>> and the prefix used by the routers seems feasible to me... In more=20
>> dynamic scenarios, this may be require further analysis.
>
> But this might be problematic if you have shim6 hosts with different=20=

> capabilities. For instance, a smallish host is today allowed to not=20
> configure IPv6 addresses for all the prefixes announced on its links,=20=

> which it might do to save on memory (think small battery operated=20
> devices).
>
> Having the routers be configured to rewrite to any of the site's=20
> prefixes would then mean that the peer would see packets with a source=20=

> locator which was not setup as part of the context.
>
right
as i see it, this capability should be optional. I mean, hosts should=20
be able to prevent rewriting (this probably needs a don't rewrite bit=20
as well :-(
So, small devices as you mention may just prefer to do all their shim=20
processing themselves.

> Even if you want to ignore small (battery operated) IPv6 devices, you=20=

> have similar issues when the set of prefixes change; the border=20
> routers notion of the prefixes to use will be out of synch with what=20=

> any particular host in the site knows as the prefixes.
>

ok, as is see it the problem occurs when there is a new prefix=20
available in the exit router that the hosts is not aware of, right?
In this case, the router would stuff a prefix that is not in the=20
locator set for the shim session and packets would be discarded.

I think that this may be an issue depending on the considered scenario.
For instance, if you are considering a traditional site i.e. a SOHO or=20=

big organization network, i guess this would be acceptable. I mean, in=20=

this case, the prefix changes when there is a renumbering event=20
(because of changes in the ISP prefixes) This is a managed event and=20
the addition and removal of prefixes is a managed event. So i guess=20
that easily we could assume that the new prefix will be first notified=20=

to the hosts and then configured in the exit routers.

However, in more unstable scenarios, like those related to mobility,=20
this may be an issue. I mean, if we are considering a mobile network=20
that changes the prefixes very dinamically, then maybe it is not=20
possible to assume that the hosts will be aware of the prefix before=20
that the router use it (in particular, because in a mobility scenario,=20=

the new prefix may be the only available prefix) However, i am not sure=20=

if this would be much of an issue because in this case, we have other=20
tools to deal with this (such as the nemo protocol)

> One way to handle this is to have the receiver, instead of looking up=20=

> the context based on <source locator, destination locator, context=20
> tag>,
> only use <destination locator, context tag> for the lookup. That way=20=

> if the border routers put in a source locator that the source host=20
> isn't aware of, the packets still get accepted by the destination.
>

but this would mean that you would be accepting packets with any source=20=

address? wouldn't be some serious security issues there?

regards, marcelo

> But as I said, I don't think this is the problem that folks are trying=20=

> to solve with the external shim.
>
>    Erik
>

Delivery-date: Thu, 29 Sep 2005 18:28:34 +0000
Date: Thu, 29 Sep 2005 11:28:49 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: source address rewriting and shim6 proxies

marcelo bagnulo braun wrote:
> what difficulties am i missing?

The first one is that we don't know what problem we are trying to solve 
with shim proxies. It could be enabling legacy IPv6 hosts behind a proxy 
(this is what Paul is suggesting as far as I understand), or it could be 
having shim aware hosts offload some functionality to a shim proxy.

The issues with the two are quite different. So which one are we trying 
to solve?

Your comments were related to the second problem:

> I am not sure i can see any difficulty with this... I mean in current 
> multihomed site scenario, where the prefixes are quite stable and they 
> change because of renumbering events associated to changes in the ISPs, 
> the coordination of the prefix set perceived by the host and the prefix 
> used by the routers seems feasible to me... In more dynamic scenarios, 
> this may be require further analysis.

But this might be problematic if you have shim6 hosts with different 
capabilities. For instance, a smallish host is today allowed to not 
configure IPv6 addresses for all the prefixes announced on its links, 
which it might do to save on memory (think small battery operated devices).

Having the routers be configured to rewrite to any of the site's 
prefixes would then mean that the peer would see packets with a source 
locator which was not setup as part of the context.

Even if you want to ignore small (battery operated) IPv6 devices, you 
have similar issues when the set of prefixes change; the border routers 
notion of the prefixes to use will be out of synch with what any 
particular host in the site knows as the prefixes.

One way to handle this is to have the receiver, instead of looking up 
the context based on <source locator, destination locator, context tag>,
only use <destination locator, context tag> for the lookup. That way if 
the border routers put in a source locator that the source host isn't 
aware of, the packets still get accepted by the destination.

But as I said, I don't think this is the problem that folks are trying 
to solve with the external shim.

    Erik

Delivery-date: Thu, 29 Sep 2005 17:59:02 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: source address rewriting and shim6 proxies
Date: Thu, 29 Sep 2005 19:59:44 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

nice summary
some comments below...

El 28/09/2005, a las 21:08, Erik Nordmark escribi=F3:

> Paul Jakma wrote:
>> On Tue, 27 Sep 2005, Brian E Carpenter wrote:
>>> Shim6 is not 8+8; the address changes take place in the end system.
>> There is not as yet any technical reason why this should be so. And=20=

>> if shim6 is to work with ULP's like UDP, then there isn't any good=20
>> technical reason why the connection between ULP and the shim must be=20=

>> on the same host.
>> If a technical reason comes along to restrict shim6 to having to be=20=

>> on same host, fine. If it doesn't, no reason to be arbitrary.
>
> There are technical reasons that make this hard relating to the=20
> interaction of the shim, the way things are secured with HBA/CGA, and=20=

> IPv6 address assignment.
>
> But we could actually talk about two different things in this space:
> 1. A shim aware host sitting in a site and the host defers "source=20
> address selection" to the border routers.
>
> 2. A legacy IPv6 host in a site and there is some shim6 proxy=20
> mechanism in the site that provides shim6 capabilities on behalf of=20
> the unmodified host.
>
> I and Tony Li explored the former a bit and one way to do such border=20=

> router rewriting is in the NOID draft (which is probably expired by=20
> now).
>
> A couple of difficulties came up with border router rewriting:
> 1. It is far from clear that there is a well-defined border router=20
> between a site and the Internet. Take a Univerisity and ask three=20
> people where the border router is and see if they have the same idea:
>  - the network admin for one of the departments
>  - the central IT organization
>  - the ISP
>
> 2. Blind border router rewriting (just replace the top N bits of the=20=

> source address) assumes the host is configured with an IPv6 address in=20=

> each prefix that the border routers know about, and is capable of
> "proving" that this is one of its locators. ("proving" using whatever=20=

> means a shim solution uses to prevent attackers from redirecting your=20=

> packets somewhere else). Thus there has to be some coordination=20
> between the allowable rewriting by the border router and the hosts;=20
> worst-case this implies rewriting rules on a per-host granularity.
>
> 3. Folks have raised privacy concerns around shim6 (for small sites)=20=

> if a host is using the same low-order 64 bits on all paths, and desire=20=

> that different bit patterns be used for different prefixes. Such a=20
> requirement would conflict with blind rewriting by the border routers.
> The WG could of course decide which of such conflicting requirements=20=

> one wants to handle and which one to skip.
>

The shim scheme currently proposed could perhaps accommodate something=20=

to support this flavor of proxy that you are analyzing here with some=20
of the restrictions that you mention.

Suppose that we keep the shim protocol (whatever that is, but=20
essentially a protocol with the e2e capabilities to establish a shim=20
session, exchange a verify a locator set)

Suppose that we impose the additional restriction that he lower 64 bits=20=

must be the same for the different prefixes available in the host.=20
(this can be easily done with HBA and CGAs) (this would imply as you=20
mention that we loose privacy features indeed)

Suppose that we mark data packets belonging to established shim=20
sessions, so that border routers can distinguish packets that can be=20
rewritten (the shim bit)

Now, all these can be easily accomplished with current view of the shim=20=

protocol

Once that the shim session is established, it doesn't matter who=20
actually selects the prefix included in the source address i.e. it can=20=

be selected by the source host or it can be selected/changed by any=20
device on-path, as long as the prefix used is included in the prefix=20
set negotiated for the particular shim session

I guess that the potential difficulty here is how the perceived prefix=20=

sets are coordinated between the host and the exit routers.
I guess that the host needs to be aware of all the prefixes available,=20=

since he is the one that is providing the security for the association=20=

between them. So, the host needs to be know all the potential prefixes.=20=

If a border router uses a prefix that the host is not aware of, then=20
this will be perceived as an attack and the packet discarded.

The routers don't need to know all the prefixes, just the one that they=20=

will stuff in the source address of the shim marked packets.

I am not sure i can see any difficulty with this... I mean in current=20
multihomed site scenario, where the prefixes are quite stable and they=20=

change because of renumbering events associated to changes in the ISPs,=20=

the coordination of the prefix set perceived by the host and the prefix=20=

used by the routers seems feasible to me... In more dynamic scenarios,=20=

this may be require further analysis.

As i see it, we could support source address prefix renumbering by exit=20=

routers with current shim approach. the key for this would be to let=20
security be handled by the shim hosts and not by the exit routers (i=20
guess this is why this case is much more easy to approach that the proy=20=

case). the price would be privacy, since all iids for a host would be=20
the same (supporting different iids would be quite more complex, since=20=

we would need to inform the exit routers about the available=20
addresses...)

Of course, in this scenario, ingress filtering compatibility would be=20
provided by rewriting of the source address, but only for the packets=20
marked as shim packets. Failures would be handled different now, since=20=

the hosts would no longer have the capability of selecting the exit=20
path (since the source address would be rewritten, instead of=20
accommodating the path to the selected source address). I mean, the=20
assumption that changing the source address would result in a change of=20=

exit path would be broken, so alternative mechanisms for selecting the=20=

exit path would be needed. This of course could be handled by the=20
routing system i.e. injecting bgp information in the multihomed site

this approach would look more like current multihoming, i guess, since=20=

exit path selection is performed by the routing system

what difficulties am i missing?

regards, marcelo

> There are actually two approaches that can avoid the above issues, but=20=

> as usual there is no free lunch.
> A. (I think Paul Francis suggested something like this a while back)=20=

> Add an option to every data packet which indicates the allowed=20
> alternative source addresses. Thus the host says "I'm sending this=20
> with source address A1, but it's OK if a border router rewrites the=20
> source address to be one of A2, A3, or A4".
>
>  This would make every packet header bigger.
>
> B. Put a hook in the RFC 3484 address selection mechanism to ask a=20
> site-wide oracle for advise on which <source, destination> addresses=20=

> to prefer. This presumably only handles things when a new connection=20=

> is setup thus can't deal with dynamic changes. Doing it for every=20
> (short-lived) connection might imply a lot of overhead and high load=20=

> on the oracle.
>
> If you were thinking about the legacy IPv6 hosts and shim6 proxies,=20
> then there was some discussion on the mailing list (shim6 or multi6?)=20=

> a while back. I can try to restate things on that front if there is=20
> interest.
>
>    Erik
>

Delivery-date: Thu, 29 Sep 2005 17:58:10 +0000
Date: Thu, 29 Sep 2005 10:58:15 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, Spencer Dawkins <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:

> Both of the above interfaces are (obviously) easily encapsulated in IP 
> (hey, in the latter case you'll already have a full IP packet buffered). 
> In which case there won't be any deep technical barrier to just spitting 
> the packet out to another host (eg your normal gateway) and letting it 
> to do the shimming.

Paul,

How does the host get an IPv6 address assigned that has the right 
low-order bits so that the HBA stuff on the remote shim/proxy can prove 
(using HBA) to the peer that it owns the IPv6 address hence is allowed 
to redirect it?

> There ought be no more impact on end-end connectivity than is implied by 
> end-host shimming (which AFAIK has "full two-way end-end connectivity" 
> as its goal.).

The difference is that when the shim is in the end host, we also have 
the end host do IPv6 address assignment based on HBA (which effects the 
bottom 64 bits of the address.)

If we have the hosts just do stateless address autoconfiguration (RFC 
2462) or temporary addresses (RFC 3041), then the shim can *not* use HBA 
or CGA to tell the peer to switch locators for the host. (But it can 
presumably handle the remote end asking the destination locators to be 
changed). Thus if the shim proxy wants to handle this, it needs to first 
do a 1:1 IPv6 NAT where the proxy has created the HBA/CGA addresses for 
the host.

One could envision having DHCPv6 be shim aware so that when the hosts 
asks DHCP for an address, the DHCP server would interact with the shim 
proxy so that the addresses are from a HBA or CGA set. In that case one 
wouldn't need the 1:1 IPv6 NAT in the shim proxy.

    Erik

Delivery-date: Thu, 29 Sep 2005 16:32:22 +0000
Cc: Spencer Dawkins <[email-masked]>, shim6-wg <[email-masked]>
From: Tony Li <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Thu, 29 Sep 2005 09:31:38 -0700
To: Brian E Carpenter <[email-masked]>

> The reason I think shim6 is intrinsically much more deployable than  
> 8+8
> is that it doesn't force *any* change on ULPs.

Sorry, I'm not buying this.  Whether you change 1 module or 10,  
you're talking about a kernel swap.  From a 'deployability'  
perspective, they are the same.

> What has to be deployed is a new IPv6 stack. One host at a time.
> We know how to do that. It will take years, but it will happen,
> due to routine operating system upgrades. And there are no
> discontinuities of service - just progressive growth in the fraction
> of sessions that can benefit from shim6.
>
> Yes, it is a big change to the stack, but it's *only* the stack.

Changing the ULPs doesn't make this significantly harder.  Yes, you  
have to have a careful transition, but this is not rocket science.

Tony

Delivery-date: Thu, 29 Sep 2005 13:25:03 +0000
Date: Thu, 29 Sep 2005 14:24:37 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
cc: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>, Spencer Dawkins <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Thu, 29 Sep 2005, Jason Schiller ([email-masked]) wrote:

> You can leave the shimming function on the end hosts and insert an
> additional shim  by intermediate routers such as Paul Jakma suggets.

I was envisaging that the 'shimmed' hosts (ie the ones using shimmed 
prefixes, the shimming being done by some intermediary router(s)) 
would be completely unaware and even potentially using non-shim6 
capable IPv6 stacks.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"I found out why my car was humming.  It had forgotten the words."

Delivery-date: Thu, 29 Sep 2005 13:18:46 +0000
Date: Thu, 29 Sep 2005 09:18:25 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
To: Brian E Carpenter <[email-masked]>
Cc: shim6-wg <[email-masked]>, Paul Jakma <[email-masked]>, Spencer Dawkins <[email-masked]>

Brian,

I'm certainly not opposed to your suggestion.  In fact it makes the shim6
more like site multihoming and less like host multihoming and probably
removes one big operator concern that they don't want to manage the
network level traffic engineering on every host.

I think I would like to be more clear on your approach.

>
> Exactly - that's what I mean by using a policy mechanism - have the site
> boundary routers distribute address selection policy. That is orthogonal
> to the shim and we probably need it anyway, for exit router selection.

One interpretation is to configure the inbound link preferences on all
border routers.  There would be some protocol to signal these preferences
to all local hosts.  When a host is acting as a destination, it would have
to signal its inbound link preference (that was learned from the border
routers) to the source host who is sorting the locators.  

Having site boundry routers that are local to the source instructing the
source host how to order the destination locators will only work if we
de-aggragate the IPv6 routing.  Without de-aggragation, the site boundry
routers that are local to the source will lack the needed state to make a
correct choice.

It is possible to have the site boundry routers that are local to the
destination instruct the source how to order the dstination locators.

You can also take the approach of moving the shim function to the border
routers.

You can leave the shimming function on the end hosts and allow
intermediate routers the ability add or change information in the shim

You can leave the shimming function on the end hosts and insert an
additional shim  by intermediate routers such as Paul Jakma suggets.

___Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Americas' Network Engineering                              [email-masked]
UUNET, an MCI brand                                 [email-masked]

Keeping the spirit of UUNET engineering alive!

On Thu, 29 Sep 2005, Brian E Carpenter wrote:

> Date: Thu, 29 Sep 2005 13:07:17 +0200
> From: Brian E Carpenter <[email-masked]>
> To: [email-masked]
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> See below... this piece of the conversation accidentally went
> off-list.
> 
> Jason Schiller ([email-masked]) wrote:
> > Brian,
> > 
> > Feel free to drop this to the list.
> > 
> > ___Jason
> > ==========================================================================
> > Jason Schiller                                               (703)886.6648
> > Senior Internet Network Engineer                         fax:(703)886.0512
> > Americas' Network Engineering                              [email-masked]
> > UUNET, an MCI brand                                 [email-masked]
> > 
> > Keeping the spirit of UUNET engineering alive!
> > 
> > On Fri, 23 Sep 2005, Brian E Carpenter wrote:
> > 
> > 
> >>Date: Fri, 23 Sep 2005 08:39:57 +0200
> >>From: Brian E Carpenter <[email-masked]>
> >>To: "Jason Schiller ([email-masked])" <[email-masked]>
> >>Subject: Re: addition of TLV to locator ID or locator ID set
> >>
> >>I see that I accidentally dropped the list from my message -
> >>that wasn't intentional. Is it OK if I reply to you on the list?
> >>
> >>     Brian
> >>
> >>Jason Schiller ([email-masked]) wrote:
> >>
> >>>Brian,
> >>>
> >>>This certainly is an important point that I have thought about.
> >>>
> >>>The point I have been trying to make is that this trafic engineering
> >>>functionality is needed.  It seems that people are not interesting in this
> >>>problem partly because they feel it doesn't impact the protocol.
> >>>
> >>>So I am attempting to break through by approaching the problem of getting
> >>>traffic engineering functionality into shim6 not as an opperational
> >>>requirment, but from the oppsite direction of protocol changes which are
> >>>needed to support this.
> >>>
> >>>You point out an interesting mis-match.  The problem is that the current
> >>>traffic engineering in IPv4 is done at the network level.  Shim6 is
> >>>between two end hosts.  Shim6 is not site multihoming, it is host
> >>>multihoming.
> >>>
> >>>How do you add network wide traffic engineering preferences to the host to
> >>>host shim6 solution?
> >>>
> >>>It seems to me there are three approaches:
> >>>1. Some how get the source end system to sort the locators in the correct
> >>>order by giving it additional information and having it do forwarding
> >>>plane measurements.
> 
> I think this asks too much of the hosts. We've always tried to avoid
> the hosts requiring real routing knowledge, as a matter of principle.
> 
> >>>
> >>>2. Let the end systems choose what ever locator and allow the routers to
> >>>record locator set information.  Allow routers to recognize a destination
> >>>address as one out of the locator set, and replace it with a different
> >>>destination address if there is a different locator which is better (or
> >>>at least forward towards a different address if a different locator is
> >>>better).
> 
> I have concerns about this. It takes us straight back to 8+8
> and all the resultant concerns. (As I already said, if this is viewed
> as part of a network stack offload, it could work, but that's not
> what you are describing here.)
> 
> >>>
> >>>3. Let the routers reach into the locator set exchange and add additional
> >>>information or modify the locator set exchange in some way.
> 
> Exactly - that's what I mean by using a policy mechanism - have the site
> boundary routers distribute address selection policy. That is orthogonal
> to the shim and we probably need it anyway, for exit router selection.
> 
> >>>
> >>>Mangeling packets on the fly by routers seems a bit scary.  I think that
> >>>this sort of a solution was intorduced early on and has been rejected.
> 
> Exactly.
> 
> >>>
> >>>
> >>>But you are right, adding traffic engineering capabilites to the end hosts
> >>>does creates three interesting problems. 
> >>>
> >>>1. Configured in the right place
> >>>
> >>>It is not clear to me that the folks who operate the Internet facing
> >>>routers also own the configuration of the end systems.   Even if they do,
> >>>its likely that they would rather administrate the traffic engineering
> >>>policy on a few Internet facing routers than on every end host in the
> >>>network.  And what about end-user who think they know better about what
> >>>link they want to use, will they be able to over ride the network wide
> >>>preferences?
> 
> That is indeed part of the discussion of a policy mechanism - who wins
> when policies conflict?
> 
> >>>
> >>>So If this needs to be administrated at the network level, are we talking
> >>>about deploying a TE server, or adding functionality to routers so that
> >>>they can instruct end systems on what the network wide in bound traffic
> >>>engineer preference is?  This seems like an awful lot of complexity, and
> >>>what security concerns does this bring up?
> 
> Yes, there's complexity, which is a worry, and a reason to separate this
> conceptually from the basic shim logic. And it would have to be immune to
> active attack.
> 
> >>>
> >>>2. Shortest exit out bound 
> >>>
> >>>Today in IPv4 if two routes are equal, the BGP tie breaker is IGP distance
> >>>to the exit point of the network.  Operators will often tweak IGP metrics
> >>>to slightly modify out-bound traffic loading charastics.  If the source is
> >>>choosing destination A over destination B and the source has no IGP
> >>>information to base this decesion on, then this functionality is lost.
> 
> Right. So the policy mechanism needs at least that much power.
> 
> >>>
> >>>3. Transit AS traffic engineering
> >>>
> >>>Transit ASes lack useful traffic engineering for transit traffic.
> >>>
> >>>In the diagram below take that the source AS is sending traffic to the
> >>>destination AS. 
> >>>
> >>>Assume that in the IPv4 world the destination is using the default BGP
> >>>configuration (not setting any MED, local pref, etc).  Also assume that
> >>>the destination is advertising a /24 which appears in the global routing
> >>>table as a /24.
> >>>
> >>>In this case the source can choose to send the traffic to transit AS1 or
> >>>transit AS2.  If the traffic reaches If the traffic reaches AS1, then AS1
> >>>can choose to send the traffic via AS3 or AS4.  This can be based and exit
> >>>cost to AS3 and AS4 or based on some policy such that AS3 is a peer and
> >>>AS4 is a transit provider. 
> >>>
> >>>AS1 can choose to distance some of the routes or all of the routes behind
> >>>AS3.  AS1 can choose to make some of the entrance points closer or farther
> >>>to AS3 as compaired to AS4.
> >>>  
> >>>
> >>>
> >>>           ---AS1-----AS3---
> >>>          /      \   /      \
> >>>         /        \ /        \locator 3
> >>>source AS          X         dest AS
> >>>         \        / \        /locator 4
> >>>          \      /   \      /
> >>>           ---AS2-----AS4---
> >>>
> >>>
> >>>In the case of shim6, the source chooses to build the IP packet with a
> >>>source of either locator 3 or locator 4.  When the traffic reaches AS1,
> >>>there is no choice.  AS1 only knows that locator 3 is behind AS3 and
> >>>locator 4 is behind AS4.  AS1 has no mapping to know that it can
> >>>substitute locator 3 for locator 4.  
> >>>
> >>>So if traffic with a destination of locator 3 then AS1 must always deliver
> >>>traffic to AS3.
> >>>
> >>>AS1 has no ability to distance some of the customers of AS3 without
> >>>distancing all of the customers of AS3 since they all share the same
> >>>aggrgate, and the more specifics are not in the global routing table.
> >>>
> >>>AS1 has no ability to compair IGP metrics between the exit point to AS3
> >>>and the exit point to AS4 as it does not know that locator 3 and locator 4
> >>>are the same host.
> 
> That's certainly correct. I would tend to say it's a feature rather than
> a bug that the intermediate AS doesn't know that two locators refer to the
> same host - it's not due to shim6. As far as I can see it can happen today
> in IPv4 if someone cares to set it up that way. So I have nothing to
> offer here...
> >>>
> >>>
> >>>Personally at the moment, I am more concerned with getting people to agree
> >>>that the functionality needs to be supported.  This is the first
> >>>step.  Then we can argue about the best way to support it.
> 
> Yes, and I do see the need.
> 
>     Brian
> 
> >>>
> >>>___Jason  
> >>>
> >>>==========================================================================
> >>>Jason Schiller                                               (703)886.6648
> >>>Senior Internet Network Engineer                         fax:(703)886.0512
> >>>Americas' Network Engineering                              [email-masked]
> >>>UUNET, an MCI brand                                 [email-masked]
> >>>
> >>>Keeping the spirit of UUNET engineering alive!
> >>>
> >>>On Thu, 22 Sep 2005, Brian E Carpenter wrote:
> >>>
> >>>
> >>>
> >>>>Date: Thu, 22 Sep 2005 14:16:05 +0200
> >>>>From: Brian E Carpenter <[email-masked]>
> >>>>To: "Jason Schiller ([email-masked])" <[email-masked]>
> >>>>Subject: Re: addition of TLV to locator ID or locator ID set
> >>>>
> >>>>Jason Schiller ([email-masked]) wrote:
> >>>>
> >>>>
> >>>>>Summary:  support for an additional TLV is required in order to allow for
> >>>>>a destination (sink) to signal to a source which links should be utilized
> >>>>>to carry traffic inbound to the destination (sink).
> >>>>>
> >>>>
> >>>>Jason, I understand your goal here and it is very reasonable.
> >>>>
> >>>>However, I would like to ask whether this policy-like information should be
> >>>>signalled in-band with the locator set (which is host to host) or
> >>>>whether it should be signalled out of band as a policy mechanism, and in
> >>>>that case signalled site to site. I'm assuming that the real requirement
> >>>>is to apply site to site preferences.
> >>>>
> >>>>   Brian
> >>>>
> >>>
> >>>
> >>>
> > 
> 
> 

Delivery-date: Thu, 29 Sep 2005 12:49:28 +0000
Date: Thu, 29 Sep 2005 13:48:40 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Brian E Carpenter <[email-masked]>
cc: Spencer Dawkins <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Thu, 29 Sep 2005, Brian E Carpenter wrote:

> The reason I think shim6 is intrinsically much more deployable than 
> 8+8 is that it doesn't force *any* change on ULPs. They can go on 
> using the current socket API for a hundred years if they want to.

If shim6 specifically is not to require changes in ULPs:

 	|     ULP   |
 	|-----------|
 	|<interface>|
         |-----------|
         |   shim6   |

Then that means the interface will be either:

- The hosts normal interface between ULP and IP

or

- Network driver interface (so <interface> would actually incorporate
   the hosts IP output layer)

The latter is quite possible given it is intended to have IPSec AH 
and ESP sit above Shim6.

Both of the above interfaces are (obviously) easily encapsulated in 
IP (hey, in the latter case you'll already have a full IP packet 
buffered). In which case there won't be any deep technical barrier to 
just spitting the packet out to another host (eg your normal gateway) 
and letting it to do the shimming.

In which the only thing required to have intermediary shimming (as a 
subset case of normal end-host shim6) really would be to ensure your 
addressing scheme allows for a static 1:1 mapping.

Everything else would be normal shim6, except the hosts would be 
unaware of the shim remapping. Think of the intermediary as being 
exactly like a shim6 host that happens to have a whole /64 allocated 
to it ;).

There ought be no more impact on end-end connectivity than is implied 
by end-host shimming (which AFAIK has "full two-way end-end 
connectivity" as its goal.).

> What has to be deployed is a new IPv6 stack. One host at a time. We 
> know how to do that. It will take years, but it will happen, due to 
> routine operating system upgrades. And there are no discontinuities 
> of service - just progressive growth in the fraction of sessions 
> that can benefit from shim6.
>
> Yes, it is a big change to the stack, but it's *only* the stack.

Intermediary shimming would require an even smaller subset of stacks 
to be upgraded, even more deployable.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
In any world menu, Canada must be considered the vichyssoise of nations --
it's cold, half-French, and difficult to stir.
 		-- Stuart Keate

Delivery-date: Thu, 29 Sep 2005 11:19:55 +0000
Date: Thu, 29 Sep 2005 13:19:41 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Spencer Dawkins <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Spencer Dawkins wrote:
>> On Sep 28, 2005, at 11:28 AM, Iljitsch van Beijnum wrote:
>>
>>> But isn't there still the huge deployability problem caused by  
>>> having to make upper layers and/or apps ignore the upper 64 bits in  
>>> many places and make the lower 64 bits globally unique?
> 
> 
>> There's a huge deployability problem with getting shim6 into the  
>> hosts too.
>>
>> Tony
> 
> 
> I guess we're saying that huge=host IP implementations < huge=host IP 
> implementations plus transports plus applications, but I take Tony's 
> point that we are talking about relatively huge changes in either case :-)
> 
> Spencer

The reason I think shim6 is intrinsically much more deployable than 8+8
is that it doesn't force *any* change on ULPs. They can go on using
the current socket API for a hundred years if they want to.

What has to be deployed is a new IPv6 stack. One host at a time.
We know how to do that. It will take years, but it will happen,
due to routine operating system upgrades. And there are no
discontinuities of service - just progressive growth in the fraction
of sessions that can benefit from shim6.

Yes, it is a big change to the stack, but it's *only* the stack.

(I don't mean there won't also be changes in TE... but they are
not required for shim6 to be deployed and to support failover.)

    Brian

Delivery-date: Thu, 29 Sep 2005 11:08:27 +0000
Date: Thu, 29 Sep 2005 13:07:17 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Re: addition of TLV to locator ID or locator ID set

See below... this piece of the conversation accidentally went
off-list.

Jason Schiller ([email-masked]) wrote:
> Brian,
> 
> Feel free to drop this to the list.
> 
> ___Jason
> ==========================================================================
> Jason Schiller                                               (703)886.6648
> Senior Internet Network Engineer                         fax:(703)886.0512
> Americas' Network Engineering                              [email-masked]
> UUNET, an MCI brand                                 [email-masked]
> 
> Keeping the spirit of UUNET engineering alive!
> 
> On Fri, 23 Sep 2005, Brian E Carpenter wrote:
> 
> 
>>Date: Fri, 23 Sep 2005 08:39:57 +0200
>>From: Brian E Carpenter <[email-masked]>
>>To: "Jason Schiller ([email-masked])" <[email-masked]>
>>Subject: Re: addition of TLV to locator ID or locator ID set
>>
>>I see that I accidentally dropped the list from my message -
>>that wasn't intentional. Is it OK if I reply to you on the list?
>>
>>     Brian
>>
>>Jason Schiller ([email-masked]) wrote:
>>
>>>Brian,
>>>
>>>This certainly is an important point that I have thought about.
>>>
>>>The point I have been trying to make is that this trafic engineering
>>>functionality is needed.  It seems that people are not interesting in this
>>>problem partly because they feel it doesn't impact the protocol.
>>>
>>>So I am attempting to break through by approaching the problem of getting
>>>traffic engineering functionality into shim6 not as an opperational
>>>requirment, but from the oppsite direction of protocol changes which are
>>>needed to support this.
>>>
>>>You point out an interesting mis-match.  The problem is that the current
>>>traffic engineering in IPv4 is done at the network level.  Shim6 is
>>>between two end hosts.  Shim6 is not site multihoming, it is host
>>>multihoming.
>>>
>>>How do you add network wide traffic engineering preferences to the host to
>>>host shim6 solution?
>>>
>>>It seems to me there are three approaches:
>>>1. Some how get the source end system to sort the locators in the correct
>>>order by giving it additional information and having it do forwarding
>>>plane measurements.

I think this asks too much of the hosts. We've always tried to avoid
the hosts requiring real routing knowledge, as a matter of principle.

>>>
>>>2. Let the end systems choose what ever locator and allow the routers to
>>>record locator set information.  Allow routers to recognize a destination
>>>address as one out of the locator set, and replace it with a different
>>>destination address if there is a different locator which is better (or
>>>at least forward towards a different address if a different locator is
>>>better).

I have concerns about this. It takes us straight back to 8+8
and all the resultant concerns. (As I already said, if this is viewed
as part of a network stack offload, it could work, but that's not
what you are describing here.)

>>>
>>>3. Let the routers reach into the locator set exchange and add additional
>>>information or modify the locator set exchange in some way.

Exactly - that's what I mean by using a policy mechanism - have the site
boundary routers distribute address selection policy. That is orthogonal
to the shim and we probably need it anyway, for exit router selection.

>>>
>>>Mangeling packets on the fly by routers seems a bit scary.  I think that
>>>this sort of a solution was intorduced early on and has been rejected.

Exactly.

>>>
>>>
>>>But you are right, adding traffic engineering capabilites to the end hosts
>>>does creates three interesting problems. 
>>>
>>>1. Configured in the right place
>>>
>>>It is not clear to me that the folks who operate the Internet facing
>>>routers also own the configuration of the end systems.   Even if they do,
>>>its likely that they would rather administrate the traffic engineering
>>>policy on a few Internet facing routers than on every end host in the
>>>network.  And what about end-user who think they know better about what
>>>link they want to use, will they be able to over ride the network wide
>>>preferences?

That is indeed part of the discussion of a policy mechanism - who wins
when policies conflict?

>>>
>>>So If this needs to be administrated at the network level, are we talking
>>>about deploying a TE server, or adding functionality to routers so that
>>>they can instruct end systems on what the network wide in bound traffic
>>>engineer preference is?  This seems like an awful lot of complexity, and
>>>what security concerns does this bring up?

Yes, there's complexity, which is a worry, and a reason to separate this
conceptually from the basic shim logic. And it would have to be immune to
active attack.

>>>
>>>2. Shortest exit out bound 
>>>
>>>Today in IPv4 if two routes are equal, the BGP tie breaker is IGP distance
>>>to the exit point of the network.  Operators will often tweak IGP metrics
>>>to slightly modify out-bound traffic loading charastics.  If the source is
>>>choosing destination A over destination B and the source has no IGP
>>>information to base this decesion on, then this functionality is lost.

Right. So the policy mechanism needs at least that much power.

>>>
>>>3. Transit AS traffic engineering
>>>
>>>Transit ASes lack useful traffic engineering for transit traffic.
>>>
>>>In the diagram below take that the source AS is sending traffic to the
>>>destination AS. 
>>>
>>>Assume that in the IPv4 world the destination is using the default BGP
>>>configuration (not setting any MED, local pref, etc).  Also assume that
>>>the destination is advertising a /24 which appears in the global routing
>>>table as a /24.
>>>
>>>In this case the source can choose to send the traffic to transit AS1 or
>>>transit AS2.  If the traffic reaches If the traffic reaches AS1, then AS1
>>>can choose to send the traffic via AS3 or AS4.  This can be based and exit
>>>cost to AS3 and AS4 or based on some policy such that AS3 is a peer and
>>>AS4 is a transit provider. 
>>>
>>>AS1 can choose to distance some of the routes or all of the routes behind
>>>AS3.  AS1 can choose to make some of the entrance points closer or farther
>>>to AS3 as compaired to AS4.
>>>  
>>>
>>>
>>>           ---AS1-----AS3---
>>>          /      \   /      \
>>>         /        \ /        \locator 3
>>>source AS          X         dest AS
>>>         \        / \        /locator 4
>>>          \      /   \      /
>>>           ---AS2-----AS4---
>>>
>>>
>>>In the case of shim6, the source chooses to build the IP packet with a
>>>source of either locator 3 or locator 4.  When the traffic reaches AS1,
>>>there is no choice.  AS1 only knows that locator 3 is behind AS3 and
>>>locator 4 is behind AS4.  AS1 has no mapping to know that it can
>>>substitute locator 3 for locator 4.  
>>>
>>>So if traffic with a destination of locator 3 then AS1 must always deliver
>>>traffic to AS3.
>>>
>>>AS1 has no ability to distance some of the customers of AS3 without
>>>distancing all of the customers of AS3 since they all share the same
>>>aggrgate, and the more specifics are not in the global routing table.
>>>
>>>AS1 has no ability to compair IGP metrics between the exit point to AS3
>>>and the exit point to AS4 as it does not know that locator 3 and locator 4
>>>are the same host.

That's certainly correct. I would tend to say it's a feature rather than
a bug that the intermediate AS doesn't know that two locators refer to the
same host - it's not due to shim6. As far as I can see it can happen today
in IPv4 if someone cares to set it up that way. So I have nothing to
offer here...
>>>
>>>
>>>Personally at the moment, I am more concerned with getting people to agree
>>>that the functionality needs to be supported.  This is the first
>>>step.  Then we can argue about the best way to support it.

Yes, and I do see the need.

    Brian

>>>
>>>___Jason  
>>>
>>>==========================================================================
>>>Jason Schiller                                               (703)886.6648
>>>Senior Internet Network Engineer                         fax:(703)886.0512
>>>Americas' Network Engineering                              [email-masked]
>>>UUNET, an MCI brand                                 [email-masked]
>>>
>>>Keeping the spirit of UUNET engineering alive!
>>>
>>>On Thu, 22 Sep 2005, Brian E Carpenter wrote:
>>>
>>>
>>>
>>>>Date: Thu, 22 Sep 2005 14:16:05 +0200
>>>>From: Brian E Carpenter <[email-masked]>
>>>>To: "Jason Schiller ([email-masked])" <[email-masked]>
>>>>Subject: Re: addition of TLV to locator ID or locator ID set
>>>>
>>>>Jason Schiller ([email-masked]) wrote:
>>>>
>>>>
>>>>>Summary:  support for an additional TLV is required in order to allow for
>>>>>a destination (sink) to signal to a source which links should be utilized
>>>>>to carry traffic inbound to the destination (sink).
>>>>>
>>>>
>>>>Jason, I understand your goal here and it is very reasonable.
>>>>
>>>>However, I would like to ask whether this policy-like information should be
>>>>signalled in-band with the locator set (which is host to host) or
>>>>whether it should be signalled out of band as a policy mechanism, and in
>>>>that case signalled site to site. I'm assuming that the real requirement
>>>>is to apply site to site preferences.
>>>>
>>>>   Brian
>>>>
>>>
>>>
>>>
> 

Delivery-date: Wed, 28 Sep 2005 22:09:31 +0000
From: "Spencer Dawkins" <[email-masked]>
To: "shim6-wg" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Thu, 29 Sep 2005 06:09:06 +0800

> On Sep 28, 2005, at 11:28 AM, Iljitsch van Beijnum wrote:
>
>> But isn't there still the huge deployability problem caused by  having to 
>> make upper layers and/or apps ignore the upper 64 bits in  many places 
>> and make the lower 64 bits globally unique?

> There's a huge deployability problem with getting shim6 into the  hosts 
> too.
>
> Tony

I guess we're saying that huge=host IP implementations < huge=host IP 
implementations plus transports plus applications, but I take Tony's point 
that we are talking about relatively huge changes in either case :-)

Spencer 

Envelope-to: [email-masked]
Delivery-date: Wed, 28 Sep 2005 21:35:21 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: delay as a metric, aggregation 
Date: Wed, 28 Sep 2005 23:34:45 +0200

 In your previous mail you wrote:

   Well, I've never seen real clients do requests of type ANY.

=> with a lot of RR types it can be a good strategy...

   Also, how does this work with regard to caching? Does a caching
   server know it has all the records so it doesn't have to bother the
   authoritative server?

=> at least the cache has all or no RR of a given type. With DNSSEC
it can know all the types for the name so even I don't believe
caches are so smart they can/shall be.
   
   > PS: BTW all infos which don't depend on where is the guy asking for
   > will ultimately finish in the DNS...
   
   :-)

=> funny?

Thanks

[email-masked]

Delivery-date: Wed, 28 Sep 2005 21:24:21 +0000
Cc: shim6-wg <[email-masked]>
From: Tony Li <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Wed, 28 Sep 2005 14:23:39 -0700
To: Iljitsch van Beijnum <[email-masked]>

There's a huge deployability problem with getting shim6 into the  
hosts too.

Tony

On Sep 28, 2005, at 11:28 AM, Iljitsch van Beijnum wrote:

> On 28-sep-2005, at 20:04, Tony Li wrote:
>
>
>>>> Shim6 is not 8+8; the address changes take place in the end system.
>>>>
>
>
>>> There is not as yet any technical reason why this should be so.
>>>
>
>
>> No, but there's a whopper of a political reason.
>>
>
>
>> If we've either misread the politics or the playing field has  
>> shifted and 8+8 is now a politically tractable solution, we should  
>> definitely explore it.  It is, architecturally, a much cleaner  
>> solution.
>>
>
> But isn't there still the huge deployability problem caused by  
> having to make upper layers and/or apps ignore the upper 64 bits in  
> many places and make the lower 64 bits globally unique?
>

Delivery-date: Wed, 28 Sep 2005 19:43:17 +0000
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Thu, 29 Sep 2005 03:42:54 +0800

> None of this imply that the policy need to be load dependent, thus I think 
> we can avoid Spencer's concern about oscillation (that are valid concerns 
> any time the path selection is a function of some measured 
> characteristic.)

Good!

And just to be clear, my concern was only about load-dependent policy; I 
thought adding the TLV was a *good* idea, but apparently spent too many 
years in TSV and just focused on one small part of the posting :-)

Thanks,

Spencer 

Delivery-date: Wed, 28 Sep 2005 19:09:38 +0000
Date: Wed, 28 Sep 2005 12:08:58 -0700
From: Erik Nordmark <[email-masked]>
To: Paul Jakma <[email-masked]>
CC: Brian E Carpenter <[email-masked]>, "Jason Schiller ([email-masked])" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: source address rewriting and shim6 proxies

Paul Jakma wrote:
> On Tue, 27 Sep 2005, Brian E Carpenter wrote:
> 
>> Shim6 is not 8+8; the address changes take place in the end system.
> 
> 
> There is not as yet any technical reason why this should be so. And if 
> shim6 is to work with ULP's like UDP, then there isn't any good 
> technical reason why the connection between ULP and the shim must be on 
> the same host.
> 
> If a technical reason comes along to restrict shim6 to having to be on 
> same host, fine. If it doesn't, no reason to be arbitrary.

There are technical reasons that make this hard relating to the 
interaction of the shim, the way things are secured with HBA/CGA, and 
IPv6 address assignment.

But we could actually talk about two different things in this space:
1. A shim aware host sitting in a site and the host defers "source 
address selection" to the border routers.

2. A legacy IPv6 host in a site and there is some shim6 proxy mechanism 
in the site that provides shim6 capabilities on behalf of the unmodified 
host.

I and Tony Li explored the former a bit and one way to do such border 
router rewriting is in the NOID draft (which is probably expired by now).

A couple of difficulties came up with border router rewriting:
1. It is far from clear that there is a well-defined border router 
between a site and the Internet. Take a Univerisity and ask three people 
where the border router is and see if they have the same idea:
  - the network admin for one of the departments
  - the central IT organization
  - the ISP

2. Blind border router rewriting (just replace the top N bits of the 
source address) assumes the host is configured with an IPv6 address in 
each prefix that the border routers know about, and is capable of
"proving" that this is one of its locators. ("proving" using whatever 
means a shim solution uses to prevent attackers from redirecting your 
packets somewhere else). Thus there has to be some coordination between 
the allowable rewriting by the border router and the hosts; worst-case 
this implies rewriting rules on a per-host granularity.

3. Folks have raised privacy concerns around shim6 (for small sites) if 
a host is using the same low-order 64 bits on all paths, and desire that 
different bit patterns be used for different prefixes. Such a 
requirement would conflict with blind rewriting by the border routers.
The WG could of course decide which of such conflicting requirements one 
wants to handle and which one to skip.

There are actually two approaches that can avoid the above issues, but 
as usual there is no free lunch.
A. (I think Paul Francis suggested something like this a while back) Add 
an option to every data packet which indicates the allowed alternative 
source addresses. Thus the host says "I'm sending this with source 
address A1, but it's OK if a border router rewrites the source address 
to be one of A2, A3, or A4".

  This would make every packet header bigger.

B. Put a hook in the RFC 3484 address selection mechanism to ask a 
site-wide oracle for advise on which <source, destination> addresses to 
prefer. This presumably only handles things when a new connection is 
setup thus can't deal with dynamic changes. Doing it for every 
(short-lived) connection might imply a lot of overhead and high load on 
the oracle.

If you were thinking about the legacy IPv6 hosts and shim6 proxies, then 
there was some discussion on the mailing list (shim6 or multi6?) a while 
back. I can try to restate things on that front if there is interest.

    Erik

Delivery-date: Wed, 28 Sep 2005 18:56:33 +0000
Date: Wed, 28 Sep 2005 11:56:16 -0700
From: Erik Nordmark <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: [email-masked]
Subject: Re: addition of TLV to locator ID or locator ID set

Brian E Carpenter wrote:

> Jason, I understand your goal here and it is very reasonable.
> 
> However, I would like to ask whether this policy-like information should be
> signalled in-band with the locator set (which is host to host) or
> whether it should be signalled out of band as a policy mechanism, and in
> that case signalled site to site. I'm assuming that the real requirement
> is to apply site to site preferences.

I'm not Jason but ...

I'm not sure the big picture is in scope for the WG, but it makes sense 
to think about the big picture a bit, and whether there is need/utility 
in a shim6 piece.

For sites that have significant traffic concentration (e.g., 
www.examle.com being involved in 99% of the traffic for the example.com 
site), then I can see how the combination of SRV records (with priority 
and weight) and some similar mechanism in the shim6 control protocol can 
provide significant control of the traffic.
But it requires that the priority/weight be configured not only in the 
DNS server but also be fed to the shim on the host.

Even for a site with less traffic concentration to one or a few hosts, 
this would be beneficial. But one would need to manually configure each 
of the hosts with the priority/weight type things.
  - Perhaps automating this configuration (DHCP?) would be worth-while?
  - Perhaps source address selection should take the priority/weight type
    thing into account so that outgoing connections follow the intent of
    the policy?

None of this imply that the policy need to be load dependent, thus I 
think we can avoid Spencer's concern about oscillation (that are valid 
concerns any time the path selection is a function of some measured 
characteristic.)

    Erik

Delivery-date: Wed, 28 Sep 2005 18:29:17 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Wed, 28 Sep 2005 20:28:08 +0200
To: Tony Li <[email-masked]>

On 28-sep-2005, at 20:04, Tony Li wrote:

>>> Shim6 is not 8+8; the address changes take place in the end system.

>> There is not as yet any technical reason why this should be so.

> No, but there's a whopper of a political reason.

> If we've either misread the politics or the playing field has  
> shifted and 8+8 is now a politically tractable solution, we should  
> definitely explore it.  It is, architecturally, a much cleaner  
> solution.

But isn't there still the huge deployability problem caused by having  
to make upper layers and/or apps ignore the upper 64 bits in many  
places and make the lower 64 bits globally unique?

Delivery-date: Wed, 28 Sep 2005 18:05:47 +0000
Cc: Brian E Carpenter <[email-masked]>, "Jason Schiller ([email-masked])" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
From: Tony Li <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Wed, 28 Sep 2005 11:04:54 -0700
To: Paul Jakma <[email-masked]>

>> Shim6 is not 8+8; the address changes take place in the end system.
>>
>
> There is not as yet any technical reason why this should be so.

No, but there's a whopper of a political reason.

If we've either misread the politics or the playing field has shifted  
and 8+8 is now a politically tractable solution, we should definitely  
explore it.  It is, architecturally, a much cleaner solution.

Tony

Delivery-date: Wed, 28 Sep 2005 15:33:57 +0000
Subject: Re: delay as a metric, aggregation
From: Cedric de Launois <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Wed, 28 Sep 2005 17:39:07 +0200

Le mercredi 28 septembre 2005 � 16:40 +0200, Iljitsch van Beijnum a
�crit :
> On 28-sep-2005, at 14:48, Cedric de Launois wrote:
> 
> > I elaborated a solution some months ago to estimate delays associated
> > with a couple of src-dst prefixes. I proposed to associate synthetic
> > coordinates to a prefix. The euclidean distance between two  
> > coordinates
> > aims to predict the delay between the prefixes. The synthetic
> > coordinates are computed in a very scalable way by using an algorithm
> > taken from the p2p litterature.
> 
> Yes, I remember your paper and our discussion in Brussels.
> 
> I don't remember off the top of my head whether your system had  
> significant downsides or what those are, but do you feel it's so good  
> that it negates the need for actual measurements?

Actual measurements are still performed of course, but only for
computing the synthetic coordinates, and with a limited number of nodes.
This number is constant, and does not increase with the total number of
nodes using the coordinates.

Here is an example :

Site A has prefixes P1 and P2,
       with coordinates (15, 25) and (21, 30) respectively

Site B has prefixes P3 and P4,
       with coordinates (5, 12) and (2, 16) respectively

Site A has four possible prefix pairs to join Site B. To know which
prefix pair yields to the lowest delay path, it follows these steps :

- Site A queries the DNS for prefixes and coordinates of Site B
- Site A receives P3 with coord (5, 12) and P4 with coord (2, 16)
- Site A computes locally the euclidean distances between the
  coordinates of its own prefixes and the coordinates of the prefixes
  of Site B :

  P1->P3 :   || (15, 25) - (5, 12) || = 16.4 ms
  P2->P3 :   || (21, 30) - (5, 12) || = 24.1 ms
  P1->P4 :   || (15, 25) - (2, 16) || = 15.8 ms  <-- best
  P2->P4 :   || (21, 30) - (2, 16) || = 23.6 ms

- Site A selects the best prefix pair according to the delay predicted
  by the coordinates, i.e. (P1, P4) here, with a predicted delay of
  15.8ms.

Notes :
- 2-D euclidean coordinates are used here. In practice, this can be
  any coordinate system
- A single DNS request can be used to retrieve prefixes AND coordinates,
  as Francis pointed out. The overload is low, especially if we take  
  care that the coordinates do not change often (and thus can be heavily
  cached)
- The system is fully distributed, no infrastructure needed
- coordinates are assigned to a prefix, but can also be assigned to a
  particular host when a better precision is needed

The challenge is to compute good enough coordinates. But there is
abundant literature from the P2P world on how to do that. I personnally
used in my simulations an improved version of the Vivaldi algorithm.
This was sufficient to avoid all really bad paths.

Cedric

Delivery-date: Wed, 28 Sep 2005 15:04:53 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: delay as a metric, aggregation 
Date: Wed, 28 Sep 2005 17:04:39 +0200
To: Francis Dupont <[email-masked]>

On 28-sep-2005, at 16:54, Francis Dupont wrote:

>>    The downside of a new RR is that the number of DNS queries is  
>> slowly
>>    exploding here... It used to be just A, now both A and AAAA, in  
>> the
>>    future probably also SRV, and so on.

> => note this should only make a larger packet (and DNSSEC will be
> more efficient for this :-), not a larger number of packets. Of  
> course,
> I assume type ANY in requests and/or good additional section in  
> replies.

Well, I've never seen real clients do requests of type ANY. Also, how  
does this work with regard to caching? Does a caching server know it  
has all the records so it doesn't have to bother the authoritative  
server?

> PS: BTW all infos which don't depend on where is the guy asking for
> will ultimately finish in the DNS...

:-)

Envelope-to: [email-masked]
Delivery-date: Wed, 28 Sep 2005 14:55:00 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Cedric de Launois <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: delay as a metric, aggregation 
Date: Wed, 28 Sep 2005 16:54:25 +0200

 In your previous mail you wrote:

   Getting the info to the client is probably the most challenging part.  
   The downside of a new RR is that the number of DNS queries is slowly  
   exploding here... It used to be just A, now both A and AAAA, in the  
   future probably also SRV, and so on.
   
=> note this should only make a larger packet (and DNSSEC will be
more efficient for this :-), not a larger number of packets. Of course,
I assume type ANY in requests and/or good additional section in replies.

Thanks

[email-masked]

PS: BTW all infos which don't depend on where is the guy asking for
will ultimately finish in the DNS...

Delivery-date: Wed, 28 Sep 2005 14:41:09 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: delay as a metric, aggregation
Date: Wed, 28 Sep 2005 16:40:41 +0200
To: Cedric de Launois <[email-masked]>

On 28-sep-2005, at 14:48, Cedric de Launois wrote:

> I elaborated a solution some months ago to estimate delays associated
> with a couple of src-dst prefixes. I proposed to associate synthetic
> coordinates to a prefix. The euclidean distance between two  
> coordinates
> aims to predict the delay between the prefixes. The synthetic
> coordinates are computed in a very scalable way by using an algorithm
> taken from the p2p litterature.

Yes, I remember your paper and our discussion in Brussels.

I don't remember off the top of my head whether your system had  
significant downsides or what those are, but do you feel it's so good  
that it negates the need for actual measurements?

A hybrid system where there are measurements for big hubs and  
computed estimates for smaller sites could also make sense.

> The coordinates of a prefix can be stored in the DNS, using a new
> resource record :

Getting the info to the client is probably the most challenging part.  
The downside of a new RR is that the number of DNS queries is slowly  
exploding here... It used to be just A, now both A and AAAA, in the  
future probably also SRV, and so on.

Iljitsch

Delivery-date: Wed, 28 Sep 2005 14:15:17 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Wed, 28 Sep 2005 16:14:45 +0200
To: Brian E Carpenter <[email-masked]>

On 28-sep-2005, at 15:01, Brian E Carpenter wrote:

> Agreed. But I don't think you can look on it as an intermediate  
> system,
> unknown to the host, which was the basis of 8+8. It will be more like
> an offload processor, with the stack split above the shim.

Although implementing the shim in a proxy / middlebox / offload  
processor is useful in its own right, having a different box (such as  
a regular router) rewrite source addresses may yet be possible, and  
if it is, it solves most of our ingress filtering problems in a very  
nice way.

I think I posted this to the list, but maybe I didn't so here goes.  
One of the ways to do demultiplexing would be for the shim to insert  
a header. If we manage to make it possible to do demux on JUST this  
header, then rewriting the source address field is of no consequence  
to the correspondent.

Delivery-date: Wed, 28 Sep 2005 13:01:35 +0000
Date: Wed, 28 Sep 2005 15:01:11 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Paul Jakma <[email-masked]>
CC: "Jason Schiller ([email-masked])" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:
> On Tue, 27 Sep 2005, Brian E Carpenter wrote:
> 
>> Shim6 is not 8+8; the address changes take place in the end system.
> 
> 
> There is not as yet any technical reason why this should be so. And if 
> shim6 is to work with ULP's like UDP, then there isn't any good 
> technical reason why the connection between ULP and the shim must be on 
> the same host.
> 
> If a technical reason comes along to restrict shim6 to having to be on 
> same host, fine. If it doesn't, no reason to be arbitrary.

Agreed. But I don't think you can look on it as an intermediate system,
unknown to the host, which was the basis of 8+8. It will be more like
an offload processor, with the stack split above the shim.

    Brian

Delivery-date: Wed, 28 Sep 2005 12:43:06 +0000
Subject: Re: delay as a metric, aggregation
From: Cedric de Launois <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Wed, 28 Sep 2005 14:48:08 +0200

Le mercredi 28 septembre 2005 � 12:27 +0200, Iljitsch van Beijnum a
�crit :
> I've been thinking about the virtues and challenges of using delay as  
> a metric for shim load balancing.
> [...]
> Thougts?

I elaborated a solution some months ago to estimate delays associated
with a couple of src-dst prefixes. I proposed to associate synthetic
coordinates to a prefix. The euclidean distance between two coordinates
aims to predict the delay between the prefixes. The synthetic
coordinates are computed in a very scalable way by using an algorithm
taken from the p2p litterature. No global infrastructure is needed, and
our simulations show that the delay estimation is sufficient to avoid
almost all really high delay paths. Moreover, the computation of the
coordinates is very cheap.

More details in 

http://www.info.ucl.ac.be/~delaunoi/networking05/delaunois-svivaldi-full.pdf

The coordinates of a prefix can be stored in the DNS, using a new
resource record :

http://www.info.ucl.ac.be/~delaunoi/ietf/draft-de-launois-dnsext-sloc-rr-00.txt

Cedric

Delivery-date: Wed, 28 Sep 2005 11:29:38 +0000
Date: Wed, 28 Sep 2005 12:28:15 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Brian E Carpenter <[email-masked]>
cc: "Jason Schiller ([email-masked])" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Tue, 27 Sep 2005, Brian E Carpenter wrote:

> Shim6 is not 8+8; the address changes take place in the end system.

There is not as yet any technical reason why this should be so. And 
if shim6 is to work with ULP's like UDP, then there isn't any good 
technical reason why the connection between ULP and the shim must be 
on the same host.

If a technical reason comes along to restrict shim6 to having to be 
on same host, fine. If it doesn't, no reason to be arbitrary.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The less a statesman amounts to, the more he loves the flag.
 		-- Kin Hubbard

Delivery-date: Wed, 28 Sep 2005 10:28:26 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: delay as a metric, aggregation
Date: Wed, 28 Sep 2005 12:27:16 +0200

I've been thinking about the virtues and challenges of using delay as  
a metric for shim load balancing.

My first thought was that delay is immaterial: other considerations,  
such as bandwidth, load and packet loss are more important. But  
that's not entirely true: in today's high speed networks, delay is  
almost entirely the result of distance, and using a longer path  
through the network when a shorter path is available wastes  
resources, everything else being equal.

Also, some protocols deteriorate as delay increases, and even  
standard file transfer is hampered by delay because even though most  
OSes implement RFC 1323 most default settings are such that there is  
no benefit, and most file transfer applications fail to override  
these defaults.

So it makes sense to optimize for low delay if this can be done  
reasonably. Now obviously one way to accomplish this is to measure  
the delay for different address pairs. However, this has the enormous  
downside that there needs to be a lot of measuring and the shim will  
be activated much more often.

While (SOHO) end-users may still suffer clogged access links these  
days, this is a rare condition for most hosting farms. And at 100 Mbps 
+ any queuing delays are insignificant compared to common speed of  
light delays. So a lot of delay information can be aggregated at the  
AS level: rather than measure the delay towards service X, I can  
measure the delay towards beacon servers located at X's ISPs Y and Z.  
The loss of information caused by the aggregation is more than offset  
by the reduction in the numbers of measurements required, especially  
if X has a way to point to the Y and Z beacon servers before the  
session starts, for instance, through the DNS.

The initially measured delay to/from the beacon server can also serve  
as a base level to compare the actual delay of the communication  
session with: as long as the session delay is a certain number of  
milliseconds longer than the beacon delay, the optimum performance is  
realized and there is no need to explore alternatives. However, when  
the session delay deteriorates it may be useful to explore  
alternative paths.

Since the delay toward a beacon is mostly determined by the distance,  
there is no need to measure it before each session: the measurements  
can be cached for some time.

Thougts?

Delivery-date: Wed, 28 Sep 2005 06:19:04 +0000
Date: Tue, 27 Sep 2005 19:44:42 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Re: addition of TLV to locator ID or locator ID set

I meant to send this to the list and accidentally
sent it only to Jason some days ago:

Jason Schiller ([email-masked]) wrote:
> Summary:  support for an additional TLV is required in order to allow for
> a destination (sink) to signal to a source which links should be utilized
> to carry traffic inbound to the destination (sink).
> 

Jason, I understand your goal here and it is very reasonable.

However, I would like to ask whether this policy-like information should be
signalled in-band with the locator set (which is host to host) or
whether it should be signalled out of band as a policy mechanism, and in
that case signalled site to site. I'm assuming that the real requirement
is to apply site to site preferences.

    Brian

Delivery-date: Wed, 28 Sep 2005 06:18:34 +0000
Date: Tue, 27 Sep 2005 19:52:24 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Paul Jakma <[email-masked]>
CC: "Jason Schiller ([email-masked])" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Paul Jakma wrote:
> On Thu, 22 Sep 2005, Jason Schiller ([email-masked]) wrote:
> 
>> We can certainly move the shim function from the host to some network 
>> level device; router, traffic engineering server, etc...
>>
>> The problem is that the current traffic engineering in IPv4 is done at 
>> the network level based on lots of routing state.  Shim6 is between 
>> two end hosts with no routing state.  Shim6 is not site multihoming, 
>> it is host multihoming.
> 
> 
> I, for one, would be very disappointed if shim6 is formulated in such a 
> way as to preclude 'shimming' by intermediaries on behalf of one or more 
> networks.

Shim6 is not 8+8; the address changes take place in the end system.
What can be done at site boundaries is policy distribution that
affects how the end systems execute the address changes. That's
why I just suggested that Jason's TLV exchange should be out of
band.

     Brian

Delivery-date: Wed, 28 Sep 2005 06:18:04 +0000
Date: Tue, 27 Sep 2005 19:49:47 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Spencer Dawkins <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Spencer Dawkins wrote:
> Hi, Jason,
> 
>>
>> Some TLVs may also rely on a forwarding component in order to sort the
>> locator IDs.  I wanted somethin analogous to the current BGP "best" path.
>> Since end hosts lack routing state, there will need to be another 
>> mechinism
>> to determine shortest path leveraging the forwarding plane.  One 
>> method is
>> to measure the latency in the forwarding path.  This seems that this 
>> solution
>> should be closely aligned to forwarding path failure detection problem 
>> space.
> 
> 
> Are we talking about basing path selection on current latency (I thought 
> I understood, later in this thread, RTT latency)?
> 
> I would be concerned about what frequency you are measuring this over, 
> and how often you think path selection based on RTT might change.
> 
> There's a lot of protocols that have had to add dampening to avoid 
> oscillation, and I'm hoping Shim6 won't be defined so that it changes 
> preferred paths very often, because it's too easy to have multiple 
> senders all figure out that destination B is the high-performance 
> destination - until all the other senders start using destination B, so 
> now destination C is the right answer, and then...

I don't think this is part of shim6 at all. It's a way shim6 might
be managed or tuned - and of course you're correct that a tuning
system that results in the "dancing in your own shadow" form
of oscillation would be a Very Bad Thing, but that is outside
shim6 itself.

     Brian
> 
> My apologies if I misunderstood what was being proposed.
> 
> Spencer
> 

Delivery-date: Tue, 27 Sep 2005 22:01:22 +0000
Date: Tue, 27 Sep 2005 14:59:57 -0700
From: Erik Nordmark <[email-masked]>
To: shim6 <[email-masked]>
Subject: draft-ietf-shim6-proto-00.txt 

I've submitted this draft today. Presumably it shows up in the I-D 
directory soon.

Hopefully the draft can be used to throw darts at in Amsterdam :-)

    Erik

Delivery-date: Sun, 25 Sep 2005 22:10:12 +0000
Date: Sun, 25 Sep 2005 15:08:43 -0700
From: David Meyer <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: IPv6 Multi-homing BOF at NANOG 35

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 25, 2005 at 06:48:25PM +0200, Iljitsch van Beijnum wrote:
> On 23-sep-2005, at 17:06, David Meyer wrote:
>=20
> >    The IAB has proposed the below BOF for the upcoming NANOG
>=20
> That's nice, but...
>=20
> >The purpose of this BOF for the IAB is to solicit operator
> >feedback on the progress and direction of IPv6 multi-homing work,
> >particularly as discussed in the IETF, and to help the IAB
> >determine if there is meaningful work that it can do or can
> >signal to the appropriate IETF WGs to address any problem(s) that
> >may be perceived with the current direction.
>=20
> NANOG =3D network operators in the sense of ISPs and the like. The =20
> solution that the shim6 is working on does NOT apply to this =20
> demographic.

	Understand your concern. However, as you know there are
	many network operators who do have an interest. There
	are also many enterprise folks who attend NANOG, and they
	also have expressed interest/opinions.

> Not long ago, there was heavy opposition on the NANOG list against =20
> unique local addresses in IPv6, which is also something that doesn't =20
> impact ISPs. I seem to remember there were also NANOGers argueing for =20
> keeping AS numbers 16 bits, but I can't find these posts, so maybe =20
> I'm misremembering.
>=20
> I urge the discussion leaders to make it painfully clear to which =20
> types of users the shim6 solution space applies and to which type of =20
> users it doesn't.

	Well taken, and yes, the shim6 context will be clearly
	laid out.=20

> >Minimally, notes
> >of the session will be posted for those unable to attend the
> >discussion in person.
>=20
> NANOG meetings tend to have streaming video. That would be nice for =20
> this BOF too.

	Good suggestion. I'm not sure what the standard NANOG BOF
	gets in terms of A/V, but I will ask the NANOG
	PC/engineering support staff what is available.

	Thanks again for the comments,

	Dave

=09

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline

--9amGYk9869ThD9tj--

Delivery-date: Sun, 25 Sep 2005 16:50:07 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: IPv6 Multi-homing BOF at NANOG 35
Date: Sun, 25 Sep 2005 18:48:25 +0200
To: David Meyer <[email-masked]>

On 23-sep-2005, at 17:06, David Meyer wrote:

>     The IAB has proposed the below BOF for the upcoming NANOG

That's nice, but...

> The purpose of this BOF for the IAB is to solicit operator
> feedback on the progress and direction of IPv6 multi-homing work,
> particularly as discussed in the IETF, and to help the IAB
> determine if there is meaningful work that it can do or can
> signal to the appropriate IETF WGs to address any problem(s) that
> may be perceived with the current direction.

NANOG = network operators in the sense of ISPs and the like. The  
solution that the shim6 is working on does NOT apply to this  
demographic.

Not long ago, there was heavy opposition on the NANOG list against  
unique local addresses in IPv6, which is also something that doesn't  
impact ISPs. I seem to remember there were also NANOGers argueing for  
keeping AS numbers 16 bits, but I can't find these posts, so maybe  
I'm misremembering.

I urge the discussion leaders to make it painfully clear to which  
types of users the shim6 solution space applies and to which type of  
users it doesn't.

> Minimally, notes
> of the session will be posted for those unable to attend the
> discussion in person.

NANOG meetings tend to have streaming video. That would be nice for  
this BOF too.

Delivery-date: Sun, 25 Sep 2005 11:13:18 +0000
From: "Spencer Dawkins" <[email-masked]>
To: "shim6-wg" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Sun, 25 Sep 2005 19:11:49 +0800

Hi, Jason,

>
> Some TLVs may also rely on a forwarding component in order to sort the
> locator IDs.  I wanted somethin analogous to the current BGP "best" path.
> Since end hosts lack routing state, there will need to be another 
> mechinism
> to determine shortest path leveraging the forwarding plane.  One method is
> to measure the latency in the forwarding path.  This seems that this 
> solution
> should be closely aligned to forwarding path failure detection problem 
> space.

Are we talking about basing path selection on current latency (I thought I 
understood, later in this thread, RTT latency)?

I would be concerned about what frequency you are measuring this over, and 
how often you think path selection based on RTT might change.

There's a lot of protocols that have had to add dampening to avoid 
oscillation, and I'm hoping Shim6 won't be defined so that it changes 
preferred paths very often, because it's too easy to have multiple senders 
all figure out that destination B is the high-performance destination - 
until all the other senders start using destination B, so now destination C 
is the right answer, and then...

My apologies if I misunderstood what was being proposed.

Spencer 

Delivery-date: Fri, 23 Sep 2005 23:35:42 +0000
Date: Fri, 23 Sep 2005 16:35:54 -0700
From: Erik Nordmark <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Jason Schiller ([email-masked]) wrote:

> However, if one of the links to destination B is getting over loaded, then
> destination B will want to migrate some traffic away from what most people
> are seeing as the lowest latency link.  

But this could be done by B adjusting some preference (e.g. a weight) 
instead of trying to pad something like a latency. For instance, if it 
turns out that the applications care more about throughput than latency, 
then inflating the latency number might not have the desired effect.

Of course, for host B to be able to send anything, it needs to somehow 
discover that the border routers sees overload on one link but not the 
other; I think this is another desirable feature of a signaling 
mechanism from the border routers (we talked earlier on the mailing list 
about the border routers being able to influence the source address 
selection). I view these as potentially useful optimizations; I'm not 
sure we should have shim6 depend on the existence of some such new 
communication mechanism from the border routers to the hosts.

> I'm not married to the concept of using a TLV if there is a better
> approach that is equally flexible.  I proposed TLV as it seems very
> flexible, can be used to carry multiple sets of values that can allows for
> a complex nested sorting, and doesn't seem like a re-invention of the
> wheel.  

Multiple sets of values assume something about how the peer will 
interpret the values. If what A cares about is to tell B to prefer some 
other locators when sending to A, I think we can handle that by just 
allowing A to send updated preferences for its locators to B.
Once we agree on such a capability, then we can discuss what the actions 
should be on B's side (immediately switch vs. something else).

> The question here is what are the solution spaces for path failure
> detection, and do any of them fit nicely with trying to determin some sort
> of forwarding plane measured "best" path.  

Presumably a notion of "best" path is dynamic. If it can't be detected 
dynamically by A or B, then we have another case where the border 
routers need to tell the hosts in their site. But it isn't clear to me 
how a signal about the paths can avoid having to effectively tell all 
the hosts about all the paths. I think the hosts should only need 
information about the destinations/paths they are using, which seems a 
bit challenging in this context.

    Erik

Delivery-date: Fri, 23 Sep 2005 15:06:55 +0000
Date: Fri, 23 Sep 2005 08:06:09 -0700
From: David Meyer <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: IPv6 Multi-homing BOF at NANOG 35

--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Folks,

	The IAB has proposed the below BOF for the upcoming NANOG
	(please see http://www.nanog.org for information on
	NANOG). As mentioned in the description (see below), the
	purpose of the BOF is for the IAB to solicit operator
	feedback on the progress and direction of IETF IPv6
	multi-homing work, and to help the IAB determine if there
	is meaningful work that it can do (or can signal to the
	appropriate IETF working group(s)) to address any issues
	that may be perceived with the current direction.     =20

	Please let us know if you have any questions or comments,
	and watch the NANOG pages in the upcoming days for the
	NANOG agenda.=20

	Thanks, and hope to see you there.

	Dave (for the IAB)

=09
--

IAB IPv6 Multi-Homing BOF

With the advent of the growing and wide-spread deployment of
IPv6, many familiar operational issues have arisen. Among the
current IPv6 "hot topics" are RIR policy (including the HD ratio
discussion) and site multi-homing. This BOF proposal focuses on
the multi-homing issue, since multi-homing is one of the
significant drivers of the growth and dynamic properties of
Default Free Zone (DFZ). In particular, there is concern that
that the amount of multi-homing will grow beyond the
organizations who use it today in the IPv4 Internet and that=20
new mechanisms will be required to to handle that growth.=20

The current direction that the IETF is taking is being defined by
the shim6 working group. Briefly, shim6 seeks to find a mechanism
which provides most the functional benefits of multi-homing while
still allowing reasonable scalability of the DFZ. Note that=20
multi-homing under shim6 differs from multi-homing under IPv4
since in IPv4 case, multi-homing is accomplished (in most cases)
by injecting a provider-independent (PI) prefix into the DFZ.
This approach has the property that it scales in the number of
multi-homed sites; each multi-homed site requires an unique entry
in the DFZ. shim6 differs from the IPv4 approach in that it does
not require an entry in the DFZ per multi-homed site.=20

The purpose of this BOF for the IAB is to solicit operator
feedback on the progress and direction of IPv6 multi-homing work,
particularly as discussed in the IETF, and to help the IAB
determine if there is meaningful work that it can do or can
signal to the appropriate IETF WGs to address any problem(s) that
may be perceived with the current direction.   Minimally, notes
of the session will be posted for those unable to attend the
discussion in person.

=09

--OgqxwSJOaUobr8KG
Content-Type: application/pgp-signature
Content-Disposition: inline

--OgqxwSJOaUobr8KG--

Delivery-date: Fri, 23 Sep 2005 09:19:33 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Fwd: I-D ACTION:draft-huitema-shim6-ingress-filtering-00.txt 
Date: Fri, 23 Sep 2005 11:19:24 +0200

Hi,

We would like to submit the following draft for consideration to the  
working group.

The goal of this document is to provide ingress filtering compatibility  
for multihomed sites, fitting in the charter in the item described as:

    In addition to the network layer shim solution, the shim6 WG is
    specifically chartered to work on:

    o Solutions for site exit router selection that work when each ISP
    uses ingress filtering, i.e. when the chosen site exit needs to
    be related to the source address chosen by the host. This site
    exit router selection and the associated address selection
    process should work whether or not the peer site supports
    the shim6 protocol.

In particular, the approach proposed in the draft provides support for  
legacy hosts (within and outside the the multihomed site) allowing this  
legacy hosts to be able to properly communicate without being affected  
by the availability of multiple prefixes/ISPs in the site, as required  
in RFC 3582:

    The solution should not destroy IPv6 connectivity for a legacy host
    implementing RFC 3513 [4] , RFC 2460 [1] , RFC 3493 [5], and other
    basic IPv6 specifications current in April 2003.  That is to say, if
    a host can work in a single-homed site, it should still be able to
    work in a multihomed site, even if it cannot benefit from site-
    multihoming.

    It would be compatible with this goal for such a host to lose
    connectivity if a site lost connectivity to one transit provider,
    despite the fact that other transit provider connections were still
    operational.

So, we would like to know if the working group would be willing to take  
on this document and continue with this approach.

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 23 de septiembre de 2005 00:50:01 GMT+02:00
> Para: [email-masked]
> Asunto: I-D ACTION:draft-huitema-shim6-ingress-filtering-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: Ingress filtering compatibility for IPv6 multihomed sites
> 	Author(s)	: C. Huitema, et al.
> 	Filename	: draft-huitema-shim6-ingress-filtering-00.txt
> 	Pages		: 17
> 	Date		: 2005-9-22
> 	
>    The note presents a set of mechanisms to provide ingress filtering
>    compatibility for legacy hosts in IPv6 multihomed sites.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-huitema-shim6-ingress- 
> filtering-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of  
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-huitema-shim6-ingress-filtering-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-huitema-shim6-ingress-filtering-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Fri, 23 Sep 2005 02:18:44 +0000
Date: Fri, 23 Sep 2005 03:17:02 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Jason Schiller <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--299119927-1728172797-1127441822=:3483
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 23 Sep 2005, Iljitsch van Beijnum wrote:

> Do people really buy lines just to use them as backups? I never 
> understood this.

Yep people do, for cost reasons. It's all about the €'s. :)

Eg because the backup was negotiated with a low fixed rental cost in 
return for really high per-MB cost (comparatively at least: maybe 
your 'primary' line you just got exceptionally good rates on). So you 
try avoid using that line, hence it's effectively a backup. Cost can 
also lead to strange things like preferring one line up until some 
quota of traffic is reached and then preferring another, within some 
arbitrary billing period.

Indeed, I'd say cost is as significant a reason for multihoming as 
redundancy is (perhaps even more so, imle).

Shim6 has to be malleable to policy routing (the easiest way to 
achieve this probably is to provide for shimming to be done at an 
'edge' device rather than at each host). If it is not malleable in 
this way it will, I suspect, weigh against shim6.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
We all live under the same sky, but we don't all have the same horizon.
 		-- Dr. Konrad Adenauer
--299119927-1728172797-1127441822=:3483--

Delivery-date: Fri, 23 Sep 2005 01:30:36 +0000
Date: Fri, 23 Sep 2005 02:29:39 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Thu, 22 Sep 2005, Jason Schiller ([email-masked]) wrote:

> We can certainly move the shim function from the host to some 
> network level device; router, traffic engineering server, etc...
>
> The problem is that the current traffic engineering in IPv4 is done 
> at the network level based on lots of routing state.  Shim6 is 
> between two end hosts with no routing state.  Shim6 is not site 
> multihoming, it is host multihoming.

I, for one, would be very disappointed if shim6 is formulated in such 
a way as to preclude 'shimming' by intermediaries on behalf of one or 
more networks.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Life is too important to take seriously."
 		-- Corky Siegel

Delivery-date: Fri, 23 Sep 2005 01:29:25 +0000
Date: Fri, 23 Sep 2005 02:27:44 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Jason Schiller <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Mail-Copies-To: [email-masked]

On Thu, 22 Sep 2005, Iljitsch van Beijnum wrote:

> I still don't know what you mean here. These days, 85% of the 
> internet is reachable over either two or three hops. So "best" is 
> largely meaningless here.

The general "depth" of the internet may be short in terms of AS hop 
length, that does not mean each AS is equal in terms of actual 
path-length. That one AS path difference might be the difference 
between:

     A_
     | \
     |  Tier-1
     |   |
     Y   X
      \ /
       B

Where A and B are, say, in the same country, both peered with Y, a 
national-level ISP, B also gets transit from national-ISP X, A also 
of some large multinational service provider. Tier-1 however does not 
peer locally, cause that country is just too small for it to be worth 
it, so X-Tier1-A actually goes way out of the way to LINX or AMSIX 
and back.

That's not an uncommon scenario in my country: none of the big 
operators are interested in peering locally. There can be a fairly 
big difference between 2 and 3 AS hop counts - the difference between 
staying reasonably local and going the scenic route via London or 
Amsterdam and incurring a good bit extra latency[1].

> Also note that in BGP we only get to use the "best" path, while the 
> shim allows using different paths in quick succession or at the 
> same time.

This isn't quite true, various BGP implementations are able to 
construct ECMP routes in their Local-RIB and use multiple best paths 
(bit of a nasty hack though). BGP may well acquire better support for 
ECMP in future.

> Testing a large number of paths is exactly the situation we're 
> desperately trying to avoid.

Hmm, well you know my opinion on this.

I really don't think solving routing problems should be within remit 
of this group, other than ensuring shim6 plays nice with routing.

1. Significantly less though than is implied by interleaved DSL, the 
common access technology here, but that's not relevant to other more 
efficient access technologies.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Just because your doctor has a name for your condition doesn't mean he
knows what it is.

Delivery-date: Thu, 22 Sep 2005 22:47:56 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Fri, 23 Sep 2005 00:47:22 +0200
To: Jason Schiller ([email-masked]) <[email-masked]>

On 22-sep-2005, at 23:23, Jason Schiller ([email-masked]) wrote:

>> These days, 85% of the internet is reachable over either two or  
>> three hops. So "best" is largely meaningless here.

> I'm not sure I agree that shortest AS path is mostly uselees  
> because most
> of the Internet is only a few ASes away.  I think generally people  
> still
> think its better to transit two ASes instead of three.

What I meant is that there is a group of people for which 85% of the  
world is 2 ASes away and a group for which 85% is 3 ASes away.

Five years ago or so you could do some traffic engineering with path  
prepending, these days it's largely useless because the AS hierarchy  
is so flat.

> BGP has many mechinisms to alter the loading of links.  By default  
> you get
> shortest AS path in bound.  You can get primary back-up using local  
> pref
> to different up stream ISPs,

Do people really buy lines just to use them as backups? I never  
understood this.

> you can get primary back up whith a single upstream using MED,

You can still do that with the shim in effect.

> our you can load share by splitting your announcements
> across you links.

Yuck, you should never announce more specifics for this.

>   You can have complex cases that combine these.

Tell me about it...

[...]

> How do you recreate this type of traffic delivery with shim6 (this is
> just one example)?

I'm not sure, trying to find something for my headache...

Don't forget that you can still have BGP to manage your outgoing  
traffic distribution if that is what you want. Also, with the TLV  
mechanisms in the shim and assuming SRV records are used, static  
balancing and primary/backup arrangements should work well.

The only thing that the shim will NOT give you is a way to prefer  
shorter paths over longer ones.

> I beleive shim6 needs to support something analogous to the current  
> IPv4
> traffic engineering.  Many content providers have expressed that they
> currently offer no content because they require multihoming and  
> traffic
> engineering.

I don't forsee too many problems for outgoing traffic: you basically  
retain current mechanisms (as long as you take "read only" feeds to  
manage your outgoing traffic there are no BGP scaling problems).  
Incoming could be a bit harder, but that's hard today as well. If  
applications start using SRV records this shouldn't be too much of a  
problem. Letting the shim pick up the slack isn't great because of  
the additional overhead, and also because only a small number of  
hosts may implement it, especially at first. (Most people are single  
homed after all.)

> How do you add network wide traffic engineering preferences to the  
> host to
> host shim6 solution?

> It seems to me there are three approaches:
> 1. Some how get the source end system to sort the locators in the  
> correct
> order by giving it additional information and having it do forwarding
> plane measurements.

How would that work? Looking at delay works in some cases, but not in  
others. If I'm in Seattle and I have a cheap, fat link to Chicago and  
a smaller backup link to Palo Alto, I'm not going to be happy when  
half the US + asia pacific is going to send its traffic over my  
smaller link because the delay is better.

> 2. Let the end systems choose what ever locator and allow the  
> routers to
> record locator set information.  Allow routers to recognize a  
> destination
> address as one out of the locator set, and replace it with a different
> destination address if there is a different locator which is better  
> (or
> at least forward towards a different address if a different locator is
> better).

How would the routers know that another choice is better?

> Mangeling packets on the fly by routers seems a bit scary.

Just a bit?

In the long run, this will hopefully be moot as it should be possible  
to change TCP such that it (in cooperation with the shim) uses more  
than one path, and either picks the best one or continues to use  
several concurrently. With an extensible TLV mechanism we should be  
in reasonable shape to begin with, so I'm not too worried, although  
traffic engineering is of course something we need to keep an eye on.

Delivery-date: Thu, 22 Sep 2005 21:24:08 +0000
Date: Thu, 22 Sep 2005 17:23:08 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
To: Iljitsch van Beijnum <[email-masked]>
Cc: Jason Schiller <[email-masked]>, shim6-wg <[email-masked]>

On Thu, 22 Sep 2005, Iljitsch van Beijnum wrote:

> Date: Thu, 22 Sep 2005 19:15:09 +0200
> From: Iljitsch van Beijnum <[email-masked]>
> To: Jason Schiller <[email-masked]>
> Cc: shim6-wg <[email-masked]>
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> On 22-sep-2005, at 18:14, Jason Schiller ([email-masked]) wrote:
> 
> > I think the biggest problem is doing something analogous to current  
> > IPv4
> > BGP "best" path.
> 
> I still don't know what you mean here. These days, 85% of the  
> internet is reachable over either two or three hops. So "best" is  
> largely meaningless here.

I'm not sure I agree that shortest AS path is mostly uselees because most
of the Internet is only a few ASes away.  I think generally people still
think its better to transit two ASes instead of three.

> 
> Also note that in BGP we only get to use the "best" path, while the  
> shim allows using different paths in quick succession or at the same  
> time.

BGP has many mechinisms to alter the loading of links.  By default you get
shortest AS path in bound.  You can get primary back-up using local pref
to different up stream ISPs, you can get primary back up whith a single
upstream using MED, our you can load share by splitting your announcements
across you links.  You can have complex cases that combine these.

You could imagine a customer with links to two ISPs say ISP1 and ISP2,
where best path is used inbound and outbound between the customer
and both upstream ISPs.  Also imagine the connection to ISP1 consists of a
pair of primary links and a pair of backup links while the links to ISP2
consist of a pair of primary links.

In this case the customer could announce the same IP block across all
links.  The primary bundle to ISP1 would have a MED of 0.  The secondary
bundle to ISP1 would have a MED of 10.  The announcement to ISP2 would
have a MED of 0.

Sources closer to ISP1 will send traffic to the customer via
ISP1.  Sources closer to ISP2 will send traffic to ISP2.  

If all the links between the customer and ISP1 fail traffic will roll over
to ISP2.  Likewise if both links between ISP2 and the customer fail,
traffic will roll over to ISP1.

ISP1 will load traffic using round robin across the two primary
links.  ISP1 will only use the secondary links if both primary links
fail.  If both primary links to ISP1 fail the ISP1 will round robin across
the two secondary links.  

ISP2 will round robin across its two links.  

In the other direction, the customer would learn full routes across all
links.  The primary link from ISP1 would have MED set to 0 (or left
default), the secondary link from ISP1 would have a MED set to 10.  The
announcement from ISP2 whould have a MED of 0 (default).

Outbound, destinations closer to ISP1 will be delivered across ISP1,
destinations closer to ISP2 will be delivered via ISP2.  Equal distant
destinations will use shortest exit.  Equal distant destinations where the
source is closer to the link to ISP1 will use ISP1.  Equal distant 
destinations where the source is closer to the link to ISP2 will use ISP2.

If all of the links to one of the ISPs goes down the traffic will rool to
the other ISP.

Traffic sent to ISP1 will round robin across the primary links.  The
secondary links to ISP1 will only be used if both primary links to ISP1
fail.  If the secondary links to ISP1 are used then they will be round
robin across the links.  

Traffic sent to ISP2 will round robin across both links to ISP2.

How do you recreate this type of traffic delivery with shim6 (this is
just one example)?

> 
> > At a glance this seems to have all of the

> > same problems that path failure detection has, with some additional
> > problems thrown in because you may have to test multiple paths to  
> > make a
> > compairson instead of only one.
> 
> Testing a large number of paths is exactly the situation we're  
> desperately trying to avoid. _Especially_ when there is no failure in  
> the first place. That's also the reason why the current assumption is  
> that we don't start rewriting addresses until there is a failure.  
> However, if there is a good case for doing this, we can reconsider.  
> But in this case, it becomes even more important that we don't add  
> overhead to packets.

I beleive shim6 needs to support something analogous to the current IPv4
traffic engineering.  Many content providers have expressed that they
currently offer no content because they require multihoming and traffic
engineering.

> 
> An interesting option would be for a large service to publish  
> addresses for intermediate boxes in the DNS. When these intermediate  
> boxes then receive a TCP SYN, they first try to set up shim state  
> toward the _real_ addresses for the service (at which time  
> sophisticated load balancing decisions can be made) and then the  
> initiator repeats the SYN.

We can certainly move the shim function from the host to some network
level device; router, traffic engineering server, etc...

The problem is that the current traffic engineering in IPv4 is done at the
network level based on lots of routing state.  Shim6 is between two end
hosts with no routing state.  Shim6 is not site multihoming, it is host
multihoming.

How do you add network wide traffic engineering preferences to the host to
host shim6 solution?

It seems to me there are three approaches:
1. Some how get the source end system to sort the locators in the correct
order by giving it additional information and having it do forwarding
plane measurements.

2. Let the end systems choose what ever locator and allow the routers to
record locator set information.  Allow routers to recognize a destination
address as one out of the locator set, and replace it with a different
destination address if there is a different locator which is better (or
at least forward towards a different address if a different locator is
better).

3. Let the routers reach into the locator set exchange and add additional
information or modify the locator set exchange in some way.

Mangeling packets on the fly by routers seems a bit scary.  I think that
this sort of a solution was intorduced early on and has been rejected.  I
beleive the same is true for moving the shim functionality to the routers,
and for providing partial "on-demand" routing tables to end hosts was also
considered and rejected.

> 
> (PS. I'm glad I left UUNET before they started handing out @mci.com  
> email addresses...)
> 

The problem is that of a trade off, if you reduce the routing state, and
what equal functionality then you trade routing state for forward plane
detection.  Thats not a good or bad thing, its a fact of life.  If the
decesion is to not solve the prolem in the routing state, then you have to
solve it in the forwarding plane.

___Jason

Delivery-date: Thu, 22 Sep 2005 17:15:54 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Thu, 22 Sep 2005 19:15:09 +0200
To: Jason Schiller ([email-masked]) <[email-masked]>

On 22-sep-2005, at 18:14, Jason Schiller ([email-masked]) wrote:

> I think the biggest problem is doing something analogous to current  
> IPv4
> BGP "best" path.

I still don't know what you mean here. These days, 85% of the  
internet is reachable over either two or three hops. So "best" is  
largely meaningless here.

Also note that in BGP we only get to use the "best" path, while the  
shim allows using different paths in quick succession or at the same  
time.

> At a glance this seems to have all of the
> same problems that path failure detection has, with some additional
> problems thrown in because you may have to test multiple paths to  
> make a
> compairson instead of only one.

Testing a large number of paths is exactly the situation we're  
desperately trying to avoid. _Especially_ when there is no failure in  
the first place. That's also the reason why the current assumption is  
that we don't start rewriting addresses until there is a failure.  
However, if there is a good case for doing this, we can reconsider.  
But in this case, it becomes even more important that we don't add  
overhead to packets.

An interesting option would be for a large service to publish  
addresses for intermediate boxes in the DNS. When these intermediate  
boxes then receive a TCP SYN, they first try to set up shim state  
toward the _real_ addresses for the service (at which time  
sophisticated load balancing decisions can be made) and then the  
initiator repeats the SYN.

(PS. I'm glad I left UUNET before they started handing out @mci.com  
email addresses...)

Delivery-date: Thu, 22 Sep 2005 16:15:26 +0000
Date: Thu, 22 Sep 2005 12:14:47 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
To: Erik Nordmark <[email-masked]>
Cc: "Jason Schiller ([email-masked])" <[email-masked]>, shim6-wg <[email-masked]>

Erik,

I think we are in complete agreemnt here.  

I want to try and clarify the latancy idea.

> Sure.
> But they might not need to be passed around. When A and B communicate,
> then A can determine the rtt to B (and the ULP such as TCP already does
> this).
> So there might not be much added benefit for A to tell B which latency
> it has observed.

I was thinking that source A could measure rtt to destination B who has
specified that use lowest latency as the locator sorting method.

The destination B would not send any rtt measurement information to A.  
The source A would not send any rtt measurement information to B.

However, if one of the links to destination B is getting over loaded, then
destination B will want to migrate some traffic away from what most people
are seeing as the lowest latency link.  

The idea is to posion the over utilized link by sending an additive value
that the source should use when determining the over all locator
sorting.  So the source will measure rtt and add (and/or subtract
depending  on how the value for this TLV type is defined) a bias
value.  In this case a TLV type of "lowest latency" and a value of the
bias will be the only information sent from destination b to source a.

The default bias value for TLV type lowest latency should be 0.

(I think I may have mis-understood an eariler question TLVs being passed
around.  Some how I was thining this question was asking if latency
information would be flooded across the forwarding path something like
the way IS-IS TLVs sent.  Sorry if this created some confusion.)

> I think in either case we can leave the door open for additional
> information. But we need to think a bit about the criteria for what
> information makes sense passing from A to B.

I completely agree.  I guess my first goal is to see if this approach
seems acceptable.  Then we can try to figure out what types of
functionality is needed and what types of information will support them
initially.  

Some hard thinking needs to be done on what information should be shared
between A and B, and I was not committed to doing it if the general
approach is not accepted.  At the same time I felt like I needed to give
some sort of example to illustrate the concept.

I'm not married to the concept of using a TLV if there is a better
approach that is equally flexible.  I proposed TLV as it seems very
flexible, can be used to carry multiple sets of values that can allows for
a complex nested sorting, and doesn't seem like a re-invention of the
wheel.  

I think the biggest problem is doing something analogous to current IPv4
BGP "best" path.  Since hosts lack routing state, this will need to be
done in the forwarding plane.  At a glance this seems to have all of the
same problems that path failure detection has, with some additional
problems thrown in because you may have to test multiple paths to make a
compairson instead of only one.

The question here is what are the solution spaces for path failure
detection, and do any of them fit nicely with trying to determin some sort
of forwarding plane measured "best" path.  

___Jason 

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Americas' Network Engineering                              [email-masked]
UUNET, an MCI brand                                 [email-masked]

On Wed, 21 Sep 2005, Erik Nordmark wrote:

> Date: Wed, 21 Sep 2005 17:55:09 -0700
> From: Erik Nordmark <[email-masked]>
> To: "Jason Schiller ([email-masked])" <[email-masked]>
> Cc: shim6-wg <[email-masked]>
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> Jason Schiller ([email-masked]) wrote:
> 
> > Also depends on the pain involved in changing DNS (I don't have any
> > insight into this)
> 
> Getting wide-spread SRV records would take some time.
> First of all, the significant applications must try to look them up (so 
> that when the web browser looks for www.example.com, it looks for SRV 
> records at _http._tcp.www.example.com first, and if none found, it looks 
> for AAAA/A records for www.example.com).
> I don't know if there are already applications/systems that look for SRV 
> records.
> 
> When we have that, then the DNS admins for the sites need to put the SRV 
> records in their DNS servers.
> 
> But there isn't any protocol change needed to the DNS.
> 
> 
> 
> >>Do you see latency as being a TLV being passed around, or merely 
> >>something that one of the endpoints can take into account when selecting 
> >>the locator to use?
> >>
> > 
> > 
> > I for see all these preference exhcanges only being shared between the
> > destination and the source.  
> 
> Sure.
> But they might not need to be passed around. When A and B communicate, 
> then A can determine the rtt to B (and the ULP such as TCP already does 
> this).
> So there might not be much added benefit for A to tell B which latency 
> it has observed.
> 
> > I think this works, but I'm not sure it will cover all cases and has
> > flexibility for future growth.
> 
> I think in either case we can leave the door open for additional 
> information. But we need to think a bit about the criteria for what 
> information makes sense passing from A to B.
> 
> > With the different TLV types, additional types can easily be added so long
> > as you can define how to treat when the new type collides with the
> > pre-existing types at a give set level.  
> > 
> > Say in the future you want to add another type to consider packet
> > loss.  In this case you simply add another TLV type and define its
> > values.  In addtion you have to clarifiy what to do when a source signals
> > to ues the lowest latency and the lowest packet loss for all
> > links.  Clearly one has to take precedence over the other.
> 
> I don't see a problem with the principle of having this type of 
> extensibility. But I don't yet understand, as for latency, whether a 
> packet loss metric would be something that A can measure and keep track 
> of for its own purpose only, vs. A also being able to pass that metric 
> to its peer B.
> 
>     Erik
> 

Delivery-date: Thu, 22 Sep 2005 08:51:26 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about draft-ietf-shim6-arch-00.txt
Date: Thu, 22 Sep 2005 10:51:28 +0200

Hi,

I know this draft is waiting for the solution to be more mature, but i 
would like to make some comments about some issues that may be 
interesting to address in later versions of this draft

Section 2.  Summary of Shim6

it is stated that

    The intention of this approach is to minimise the amount of change
    required to support dynamic locator agility in the protocol stack,
    and support dynamic locator agility as a negotiated endpoint-to-
    endpoint capability.  An application can initiate a session with a
    remote host by using an entirely conventional lookup of the host's
    domain name in the DNS, and open up a session with the remote
    endpoint using one of its addresses as the destination address.  The
    application can continue to exchange packets with this remote host
    for the duration of the session by continuing to use this destination
    address.  If the local host subsequently opens up a new session with
    the same remote host, the same destination address may be used, or if
    the local host passes a reference to a third party as a referral, the
    same destination address may be used.  In terms of semantics and
    functionality this represented no change to the use of addresses as
    endpoint identifiers in the IPv6 architecture.

I think that after this paragraph and before the next one, it should be 
stated somehow that the shim association is established using some form 
of signaling handshake.
I mean, in this paragraph it is stated that the communication is 
established as a regular IP communication and in the next paragraph it 
is described bow the shim processes the packets, changing the 
identifiers per locators and the other way round. I think that it would 
be clarifying to state that at some point in time, some heuristics 
(TBD) trigger the establishment of the shim association, so that the 
ongoing application session can benefit from the multihoming 
capabilities. This results in the shim handshake performance and the 
creation in each of the endpoints of the necessary shim state and so 
on.

The next paragraph states that:

    Shim6 operates as a per-host header address mapping function.

I am not sure what do you mean by per-host here...
I think that one of the issues along the document is that a per 
host-pair granularity of the shim state is assumed. I think this is not 
so, and that the shim state granularity would be per ULID-pair. IMHO 
this is a consequence of the design choice that any address can be used 
as ULID. Because of that, any application can select any of the 
available addresses to be used as ULIDs for a communication. This 
results that two communications between the same pair of endpoints can 
use different ULIDs and this would imply having two different shim 
associations and their respective shim state. The difficulty with this 
point is even more clear at the last section, so i will comment more on 
this later.

Then the paragraph continues with

    When
    the Shim6 locator mapping function is activated for a remote endpoint
    packets passed from the IP endpoint sub-layer to the shim sub-layer
    have the packet's headers source and destination addresses rewritten
    with the currently selected locator pair.  Incoming packets passed
    from the IP Routing sub-layer undergo a similar lookup using the
    locator pair.

The locator pair is not enough imho and a demux tag is needed

    The packet header is rewritten with the mapped
    endpoint identifier pair is there is an active mapping entry.  This
    functionality is indicated in Figure 2.  Here the endpoint identities
    are referred to as Upper Layer Identifiers (ULIDs), and the packet
    header addresses are referred to as Locators (L).  The Shim6 element
    contains a context state, associating a ULID pair (in this case the
    pair [ULID(A),ULID(B)]

and a context tag i guess

    with a set of locators for A and a set of
    locators for B. The shim elements are synchronised such that

then in section 4.  Functional Decomposition

4.1  Establishing Session State

...
          In
          this case the selected source address, as seen by the upper
          level protocol stack element is the ULID of the stored state
          associated with the destination ULID.  Otherwise the selected
          source address is a selected IP address from the set of
          addresses associated with the particular host interface that
          will be used to send the packet, as happens in a conventional
          IPv6 protocol stack.

I would add "following the rules defined in RFC 3484"

Later on...

          The local host to performs a name-to-address
          DNS lookup to obtain a set of locators (recorded in the DNS
          using AAAA resource records).  The host then performs a
          selection from this set of locators

I would add "following the rules defined in RFC 3484"

          and uses the selected
          address as the identification of the remote host.

later on...

       Does the identity protocol element need to create a mapping from
       the upper level protocol's local and remote identity tokens into
       an identity token that identifies the session?  If so, then is
       this translation performed before or after the initial session
       packet exchange handshake?

This is an interesting question...
I think that the demux tag or context tag would serve as a name for the 
association... depending on whether the the context tag is unique or is 
unique within those two ULIDs or two nodes, it maybe part of a name for 
the session.
I mean, if the demux tag is unique, imho this is a name for the 
session, while if what is unique is the ULIDs, context tag, then it is 
part of the name of the session. In any case, imho the context tag 
plays a role in here.

later on...

          The session initiator determines the ability of the remote end
          to support the Shim6 protocol via explicit negotiation.  The
          Shim6 protocol will continue to operate in a conventional mode
          if the capability negotiation fails for Shim6 support.  The
          nature of the communication exchange to determine the
          capability to use Shim6 support is not described in [ID.SHIM6].

this is described to some detail in the ID.FUNC reference.

then...

          The initial choice of source and destination locators matches
          the initial choice of upper level identifiers, namely the
          initial addresses used as the upper level identifiers.  The
          remote address is obtained using conventional DNS lookup.

I would state that the DNS returns a list of locators and the node 
selects one of them using RFC3484 (i mean, since in the following 
phrase it is specified that RFC3484 is used for selecting the source 
address, i guess this should be here too)

          The
          local address is based on an address selection from the
          addresses associated with the outbound interface, using the
          procedure described in [RFC3484].

Then In section 4.2...

       The Shim6 documentation covers a number of options, but does not
       provide definitive answers to this question.  The [ID.FAIL] notes
       four approaches: namely positive feedback from the upper level
       sessions,

i would say "lack of positive feedback from the upper level sessions"

       negative feedback from the upper level sessions,
       explicit reachability tests

i would say "failure of explicit reachability tests"

       and ICMP error messages.
       From the discussion in this draft it appears that negative
       feedback from upper layer transport sessions in the form of ACK
       timeouts is the preferred locator change trigger mechanism.

funny how things change, but my current understanding is that people 
would prefer lack of positive feedback, rather than negative feedback 
(i guess this is why the completion of this doc should be left for when 
the work is almost finnish i guess :-)

Later on...

    What triggers can be used to indicate the direction of the failed
    path in order to trigger the appropriate locator repair function?

       The [ID.FAIL] description does not provide a description of
       detection of the failed path.  The Shim6 approach attempts to
       treat path failure as a failure of the locator pair, rather than
       failure of a single locator, so the direction of the failure is
       not necessarily critical information in the search for a new
       functional pair.

I think that this changes with different failure detection mechanisms. 
I mean with FBD, the direction that failed is determined by the nature 
of the mechanism (i.e. the failure is always in the incoming direction 
of the node that detects the failure)
An issue that i think that is relevant and it is related to this is the 
relationship between which endpoint detects the failure and which 
endpoint has to do something to repair it. I mean, in FBD, a node 
detects a failure in its incoming path, so the one that needs to do 
something to repair it is the peer. So, in this case, we need in 
addition, a reliable mechanism to communicate the existence of a 
failure from the peer that has detected the failure to the peer that 
can do something to repair it.

Later on in section 4.3...

    Must a change of an egress site exit router be accompanied by a
    change in source and / or destination locators?

       This appears to be an area for further study.  The situation is
       not explicitly addressed in the Shim6 documentation.

I think that while this is an area for further study, as mentioned 
here, it is clear that for now, the design of the shim assumes that a 
change in the locator pair used implies a change in parts of the path 
used, so that changing the locator pair may result in using an 
alternative working path.
I think that it is good to note that this assumption relies in very 
different mechanisms for the source and the destination addresses. For 
destination address, this assumption is based on the usage of PA 
addresses, so changing the destination address would result in changing 
the ingress ISP to the destination. In the case of the source address, 
this assumption is based in that the ingress filtering compatibility 
must be provided somehow, which implies that a packet with a source 
address of a given ISP will be forwarded through that ISP (to guarantee 
ingress filtering compatibility), so that changing the source address 
results in changing the exit isp.
So, i agree that the actual mechanisms are not defined yet, but i would 
say that the shim is assuming that some mechanisms will be i place to 
make sure that changing the src/dst address would result in different 
exit/ingress paths

Later on in section 4.4...

       The preconditions necessary is that there has been a successful
       establishment of packets between the two hosts, Shim6 capabilities
       have been successfully negotiated and locator sets have been
       exchanged, and there is an explicit trigger for a locator change
       that has been generated by an active transport session.  IN
       addition reception of a packet where the locator par is a member
       of the locator set for this host pair implies a remotely-triggered
       locator change.

I am not sure this so straight forward. I mean, how would this 
behaviour affect the case of unidirectional path availability. I mean, 
consider the case where only two different unidirectional paths are 
available (so that packets in one direction must carry different 
locators that packets in the other direction). If this behaviour is 
used, then this communication would fail, since peers would always be 
changing of locator pair, upon the reception of a packet from the other 
end having a different locator pair

Then...

    How can the locator change be confirmed by both ends?

I think i don't understand this question...

       The approach proposed here is by using a return reachability test,
       where a host searches through locator pair selections until it
       receives an explicit acknowledgement of a poll.

But the reachability exchange is not used to confirm that both nodes 
can use a give locator pair, but to confirm that packets sent by one 
peer are received by the other. I mean, we are considering the 
possibility that the different endpoints use different locator pairs in 
the different directions of the communication... but perhaps i am 
missing something

In Section 5.

    It may also be useful to allow the upper level protocol to explicitly
    indicate that any form of L3 functionality should not be applied to
    this session.  The implication of this functionality is that incoming
    packets need to provide some form of positive indication that the
    incoming locator pair should be mapped to an equivalent ULID pair,
    while packets without this indication should be processed in a
    conventional fashion with any Shim6 packet header mapping.  The Shim6
    documentation suggests that some form of explicit tagging should be
    performed in the IPv6 Flow Id field, but further details have not
    been provided.

I think that there are, at least, three different issues addressed here:
- first we have the context tag issue i.e. the need for a context tag 
that allows to demux shim packets having the same locators but 
belonging to different shim contexts
- second we have "the shim bit" which is a bit to differentiate shim 
data packets from non-shim data packets. this is not clear that is 
needed (my understanding is that this is basically needed when we want 
to be able to detect context loss). The possibility for this is to use  
a virtual bit defining new extension headers values
- third, the need to have some packets or some communications not to 
use the shim or parts of the shim. For this, i think that, if we want 
that two apps use the same address pair and one uses the shim and the 
other don't, then we may need the shim bit...

But in any case, i think that these are three different issues that may 
be good to explicitly differentiate.

Later on...

    The potential use of unreachable ULIDs as the initial choice of ULIDs
    and the consequent requirement to undertake a reachable locator
    search, capability negotiation and establishment of a Shim6 mapping
    state is mentioned in the Shim6 documents, but at a relatively
    abstract level.  This requires further consideration in terms of the
    potential failures, and the appropriate signalling to be passed back
    to the ULP in such cases.

I think that an issue that is somehow related with this and that it may 
be interesting to discuss, is what happens when the initial address 
that is supposed to be used as ULID and as locator for initial packets 
is unreachable. We have so far discussed two possibilities for dealing 
with this: let the application retry, or let the shim deal with this 
(this last thing is what would be needed if we want to support ULAs as 
ULIDs)

later on...

    The issue of ambiguity of demultiplexing may require further
    consideration.  If there are multiple AAAA resource records in the
    DNS, or the resource records change over the lifetime of active
    communication, it is possible to have multiple Shim6 states set up
    for the same remote host, with distinct ULIDs for the remote host.

Well, as i understand this can happen for other reasons than changes in 
the DNS records. As i mentioned earlier, imho this can happen simply 
because the different apps running between two nodes choose different 
address pairs as ULIDs for a given communication. In this case, we 
would end up having multiple shim sessions between the same two hosts, 
each one with different ULIDs pairs.
The underlying point here imho is that the shim session granularity 
would be per ULID pair rather than per host pair.

    An incoming packet with a given locator pair will, according to the
    Shim6 documentation, need to use the locator pair as a lookup key

I guess that the locator pair is not enough in this scenario to work as 
a key. I guess that the context tag is also needed in this.

    into the Shim6 state information to establish the associated ULID
    pair.  In the case of multiple active ULIDs for the same remote host
    this lookup will result in multiple ULIDs.

    The treatment of trigger conditions for locator change also requires
    further consideration.  As noted in [ID.ARCH], different upper level
    transports may have different sensitivity requirements to locator
    triggers.  When the mapping is performed on a host-by-host basis

Imho mapping would be in a ULID pair basis, rather than in host basis. 
This won't solve this particular issue, but anyway...

In addition, perhaps a comment about possible ways for detecting the 
loss of shim state by one of the peers may be relevant here....

Editorial

Section: Notes

    The document provides am architectural description of the
    approach, using the framework described in the multi-homing
    architecture document.

s/am/an

Section 2.  Summary of Shim6

    The shim layer provider a set of associations
    between endpoint identity pairs and locator sets.

s/provider/provides

Section 2.

    The packet header is rewritten with the mapped
    endpoint identifier pair is there is an active mapping entry.
                             ^^
s/is/if

Section 2.

    At this level of the protocol stack there is no information to
    indicate wither this packet is a single datagram, or the start of an
    extended packet exchange with a remote entity.

s/wither/whether

Section 4.4.

    IN addition reception of a packet where the locator par is a member

s/IN/In

Section 5

    The signalling interface between the Shim6 and the upper layers pf
    the protocol stack requires further consideration.

s/pf/of

References

    [ID.FAIL]  Arkko, J., "", Work in progress: Internet
               Drafts draft-arkko-multi6dt-failure-detection-00.txt,
               January 2005.

The tittle is missing

Regards, marcelo

Delivery-date: Thu, 22 Sep 2005 03:47:07 +0000
Date: Thu, 22 Sep 2005 13:45:27 +1000
To: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group

We'll press on with the planned Saturday and Sunday dates for this meeting,
at the Hotel Krasnapolsky in Amsterdam, as per the original notice.

regards,

   Geoff

At 11:54 PM 20/09/2005, Jari Arkko wrote:
>Was there a conclusion of this thread? Are the dates
>as originally planned or did they get changed?
>
>--Jari
>
>P.S. The IETF SHIM6 WG page does not show up the
>location of the archives.
>
>

Delivery-date: Thu, 22 Sep 2005 00:56:26 +0000
Date: Wed, 21 Sep 2005 17:55:09 -0700
From: Erik Nordmark <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Jason Schiller ([email-masked]) wrote:

> Also depends on the pain involved in changing DNS (I don't have any
> insight into this)

Getting wide-spread SRV records would take some time.
First of all, the significant applications must try to look them up (so 
that when the web browser looks for www.example.com, it looks for SRV 
records at _http._tcp.www.example.com first, and if none found, it looks 
for AAAA/A records for www.example.com).
I don't know if there are already applications/systems that look for SRV 
records.

When we have that, then the DNS admins for the sites need to put the SRV 
records in their DNS servers.

But there isn't any protocol change needed to the DNS.

>>Do you see latency as being a TLV being passed around, or merely 
>>something that one of the endpoints can take into account when selecting 
>>the locator to use?
>>
> 
> 
> I for see all these preference exhcanges only being shared between the
> destination and the source.  

Sure.
But they might not need to be passed around. When A and B communicate, 
then A can determine the rtt to B (and the ULP such as TCP already does 
this).
So there might not be much added benefit for A to tell B which latency 
it has observed.

> I think this works, but I'm not sure it will cover all cases and has
> flexibility for future growth.

I think in either case we can leave the door open for additional 
information. But we need to think a bit about the criteria for what 
information makes sense passing from A to B.

> With the different TLV types, additional types can easily be added so long
> as you can define how to treat when the new type collides with the
> pre-existing types at a give set level.  
> 
> Say in the future you want to add another type to consider packet
> loss.  In this case you simply add another TLV type and define its
> values.  In addtion you have to clarifiy what to do when a source signals
> to ues the lowest latency and the lowest packet loss for all
> links.  Clearly one has to take precedence over the other.

I don't see a problem with the principle of having this type of 
extensibility. But I don't yet understand, as for latency, whether a 
packet loss metric would be something that A can measure and keep track 
of for its own purpose only, vs. A also being able to pass that metric 
to its peer B.

    Erik

Delivery-date: Wed, 21 Sep 2005 23:30:54 +0000
Date: Wed, 21 Sep 2005 19:30:06 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
To: Erik Nordmark <[email-masked]>
Cc: "Jason Schiller ([email-masked])" <[email-masked]>, shim6-wg <[email-masked]>

On Wed, 21 Sep 2005, Erik Nordmark wrote:

> Date: Wed, 21 Sep 2005 16:10:37 -0700
> From: Erik Nordmark <[email-masked]>
> To: "Jason Schiller ([email-masked])" <[email-masked]>
> Cc: shim6-wg <[email-masked]>
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> Jason Schiller ([email-masked]) wrote:
> > Summary:  support for an additional TLV is required in order to allow for
> > a destination (sink) to signal to a source which links should be utilized
> > to carry traffic inbound to the destination (sink).
> 
> Jason,
> 
> I don't see a problem with adding some priority and weight 
> TLV/information to the locators.
> But I wonder if this is supposed to work in the larger scope.
> 
> Take a site with 6 ISPs. This presumably means each of their servers 
> will have 6 AAAA records (one for each prefix).
> Thus the clients out there will lookup www.example.com and get 6 AAAA 
> records in the set (and it is a set; there is no implied order among the 
> records in DNS RRset).
> So the client will try them in an order that example.com can not control 
> (RFC 3484 effects the order presumably).
> 
> Once it has connected using address A5, the client might communicate for 
> a while before it decides to setup the shim context. Thus some packets 
> will flow using A5. When it has setup the context, the client will 
> discover that A1 and A2 has higher priority than A5, using the proposed 
> TLVs/information.
> 
> Should that cause the communication to immediately switch over to A1 or 
> A2, even though A5 is working fine?

I think at the least there needs to be the option to immediately switch
over.

> 
> And what about the fact that the initial communication is done using the 
> information in the DNS, and AAAA records don't have a priority/weight? 
> Should we recommend that applications switch ASAP to using SRV records, 
> so that example.com can express there priority in the SRV records?
> 
> Or would be be sufficient for the long-lived communication (that has 
> setup shim6 state) to switch to the most preferred locators?

I think you are right here, if in gerenal the sessions are long lived,
then the initial packet exhcange prior to the shim6 setup is not a big
deal.  However if a particular network has only short lived sessions this
may be problematic.  I don't know if there are any such networks. 

Also depends on the pain involved in changing DNS (I don't have any
insight into this)
> 
> > Initial TLV scould include:
> > 
> > 1. Link Order -- lower value link order is always used before higher link
> > order
> 
> FWIW The SRV records use the term "priority" for this, so it might make 
> sense to use the same term.
> 
> > 2. Round-robin -- value specified would weight the round-robin.  No value
> > would result in a non-weighted round-robin for all locator IDs in the set.
> 
> > 3. Lowest latency -- paths with lower measured latency will be preferred
> > over paths with higher latency.  A value set will be added or subtracted
> > to the measured value for biasing
> 
> Do you see latency as being a TLV being passed around, or merely 
> something that one of the endpoints can take into account when selecting 
> the locator to use?
> 

I for see all these preference exhcanges only being shared between the
destination and the source.  

> 
> > Take the case where link 1 is an OC-3 and link 2 is a DS-3.  In this
> > case you would want the OC-3 to carry three times more traffic than 
> > the DS-3.  In this case, the destination may want to alter the pre-
> > existing policy (from above) such that link 1 carries 75% of the traffic
> > and link 2 carries only 25% of the traffic.  This can be accomplished
> > by weighting the round-robin.
> > 
> > (1)    -- TLV type = round-robin, Value = 0.75
> > (2)    -- TLV type = round-robin, Value = 0.25
> > (1, 2) -- TLV type = link order, Value = 0
> > (3, 4) -- TLV type = link order, Value = 1
> > (5, 6) -- TLV type = link order, Value = 2
> 
> FWIW the priority/weight combination in the SRV RFC is a bit more 
> general. First you rank things based on the priority value. Within the 
> subset with the same priority value, the weight is taken into account to 
> do a random draw of which to use. Thus in the above example, the 
> secondary locators 3 and 4 can also have weights.
> (1) priority = 0; weight = 75
> (2) priority = 0; weight = 25
> (3) priority = 1; weight = 90
> (4) priority = 1; weight = 10;
> (5) priority = 2; weight = 1;
> (6) priority = 2; weight = 1
> 
> That way, when 1 and 2 fail, there is a 90/10 split between 3 and 4.
> And when they fail, there is a 50/50 split between 5 and 6.
> 
>     Erik
> 

I think this works, but I'm not sure it will cover all cases and has
flexibility for future growth.

With the different TLV types, additional types can easily be added so long
as you can define how to treat when the new type collides with the
pre-existing types at a give set level.  

Say in the future you want to add another type to consider packet
loss.  In this case you simply add another TLV type and define its
values.  In addtion you have to clarifiy what to do when a source signals
to ues the lowest latency and the lowest packet loss for all
links.  Clearly one has to take precedence over the other.

___Jason 

Delivery-date: Wed, 21 Sep 2005 23:14:09 +0000
Date: Wed, 21 Sep 2005 19:13:13 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6-wg <[email-masked]>

On Wed, 21 Sep 2005, Iljitsch van Beijnum wrote:

> Date: Wed, 21 Sep 2005 23:35:33 +0200
> From: Iljitsch van Beijnum <[email-masked]>
> To: Jason Schiller <[email-masked]>
> Cc: shim6-wg <[email-masked]>
> Subject: Re: addition of TLV to locator ID or locator ID set
> 
> On 21-sep-2005, at 21:00, Jason Schiller ([email-masked]) wrote:
> 
> > Summary:  support for an additional TLV is required in order to  
> > allow for
> > a destination (sink) to signal to a source which links should be  
> > utilized
> > to carry traffic inbound to the destination (sink).
> 
> You're of course completely right that something closely resembling  
> this should be part of the shim. Thank you for writing it down  
> explicitly.
> 
> > 3. Lowest latency -- paths with lower measured latency will be  
> > preferred
> > over paths with higher latency.  A value set will be added or  
> > subtracted
> > to the measured value for biasing
> 
> Hmmm...
> 
> I'm not sure we can cook something digestable from the delay, except  
> that if we're first using address pair AX with delay N, and then pair  
> BY has delay M where M is a lot larger than N, it probably makes  
> sense to continue to test CZ and so on, while if M <= N there is no  
> need to search any further.
> 
> > An additional draft will need to be written to define the default
> > locator ID selection process, and how the TLVs will be used to modify
> > locator ID selection.
> 
> Please don't say "locator ID", it sound like "dry wet". We have  
> locators and identifiers, both are addresses and some addresses are  
> both.
> 
> Since at this stage, we're only considering the case where the  
> initial session setup happens in a backward compatible way, the shim  
> has no influence over the selection of the initial address pair. We  
> also presume that it's best to engage the shim only when there is an  
> outage. This means that for most traffic, the traffic distribution  
> depends on regular destination and source address choices like they  
> exist today. That's probably not good enough, though. An obvious  
> mechanism to influence this would be SRV records in the DNS, which  
> would need the same TLVs that you propose for the shim in your  
> message (as far as they're missing from the current SRV specs).

I guess what I was envisioning was at least the option to leverage the
shim, and use different locators as soon as the shim6 handshake is
complete rather then waiting for an outage.  

Initial TCP set up should be backward compatabile, and not being a DNS
guy, I'm not sure how much pain is involved in the SRV DNS
records.  Assuming the amount of DNS pain is large, then we need to
consider what is the impact of of picking the address at random at the
start, and switching over to the "optimum" address after a few packets
have been exchanged.

I guess the question to network operators is if there are networks where a
majority of the sessions are a very short lived.

> 
> > Some TLVs may also rely on a forwarding component in order to sort the
> > locator IDs.  I wanted somethin analogous to the current BGP "best"  
> > path.
> 
> Do you mean "best" by virtue of the BGP path selection algorithm left  
> to its own devices, or "best" after having massaged the values the  
> BGP selection algorithm takes into account?
> 

The concept of "best" that I have is something that provides analogous
functionality to what IPv4 BGP AS path.  The concept is using the most
optimum path which in a loose sense is the shortest path.  If there could
be some sort of latency check then the "best" path can be a function of
the strick latency measurment.  

AS pre-pend in IPv4 BGP allows for making the best path a little less
best.  Tis will cause sources that are very close to the best and second
best path to switch over to the second best path.  Sources close to the
best path but far from the sceond best path will not switch.

Adding a biasing factor for the latency measurement, can allow the source
to make the latency check and add the biasing factor, So in this case the
best path is the one with the best latency plus or minus the bias factor.

Delivery-date: Wed, 21 Sep 2005 23:11:38 +0000
Date: Wed, 21 Sep 2005 16:10:37 -0700
From: Erik Nordmark <[email-masked]>
To: "Jason Schiller ([email-masked])" <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set

Jason Schiller ([email-masked]) wrote:
> Summary:  support for an additional TLV is required in order to allow for
> a destination (sink) to signal to a source which links should be utilized
> to carry traffic inbound to the destination (sink).

Jason,

I don't see a problem with adding some priority and weight 
TLV/information to the locators.
But I wonder if this is supposed to work in the larger scope.

Take a site with 6 ISPs. This presumably means each of their servers 
will have 6 AAAA records (one for each prefix).
Thus the clients out there will lookup www.example.com and get 6 AAAA 
records in the set (and it is a set; there is no implied order among the 
records in DNS RRset).
So the client will try them in an order that example.com can not control 
(RFC 3484 effects the order presumably).

Once it has connected using address A5, the client might communicate for 
a while before it decides to setup the shim context. Thus some packets 
will flow using A5. When it has setup the context, the client will 
discover that A1 and A2 has higher priority than A5, using the proposed 
TLVs/information.

Should that cause the communication to immediately switch over to A1 or 
A2, even though A5 is working fine?

And what about the fact that the initial communication is done using the 
information in the DNS, and AAAA records don't have a priority/weight? 
Should we recommend that applications switch ASAP to using SRV records, 
so that example.com can express there priority in the SRV records?

Or would be be sufficient for the long-lived communication (that has 
setup shim6 state) to switch to the most preferred locators?

> Initial TLV scould include:
> 
> 1. Link Order -- lower value link order is always used before higher link
> order

FWIW The SRV records use the term "priority" for this, so it might make 
sense to use the same term.

> 2. Round-robin -- value specified would weight the round-robin.  No value
> would result in a non-weighted round-robin for all locator IDs in the set.

> 3. Lowest latency -- paths with lower measured latency will be preferred
> over paths with higher latency.  A value set will be added or subtracted
> to the measured value for biasing

Do you see latency as being a TLV being passed around, or merely 
something that one of the endpoints can take into account when selecting 
the locator to use?

> Take the case where link 1 is an OC-3 and link 2 is a DS-3.  In this
> case you would want the OC-3 to carry three times more traffic than 
> the DS-3.  In this case, the destination may want to alter the pre-
> existing policy (from above) such that link 1 carries 75% of the traffic
> and link 2 carries only 25% of the traffic.  This can be accomplished
> by weighting the round-robin.
> 
> (1)    -- TLV type = round-robin, Value = 0.75
> (2)    -- TLV type = round-robin, Value = 0.25
> (1, 2) -- TLV type = link order, Value = 0
> (3, 4) -- TLV type = link order, Value = 1
> (5, 6) -- TLV type = link order, Value = 2

FWIW the priority/weight combination in the SRV RFC is a bit more 
general. First you rank things based on the priority value. Within the 
subset with the same priority value, the weight is taken into account to 
do a random draw of which to use. Thus in the above example, the 
secondary locators 3 and 4 can also have weights.
(1) priority = 0; weight = 75
(2) priority = 0; weight = 25
(3) priority = 1; weight = 90
(4) priority = 1; weight = 10;
(5) priority = 2; weight = 1;
(6) priority = 2; weight = 1

That way, when 1 and 2 fail, there is a 90/10 split between 3 and 4.
And when they fail, there is a 50/50 split between 5 and 6.

    Erik

Delivery-date: Wed, 21 Sep 2005 21:36:43 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: addition of TLV to locator ID or locator ID set
Date: Wed, 21 Sep 2005 23:35:33 +0200
To: Jason Schiller ([email-masked]) <[email-masked]>

On 21-sep-2005, at 21:00, Jason Schiller ([email-masked]) wrote:

> Summary:  support for an additional TLV is required in order to  
> allow for
> a destination (sink) to signal to a source which links should be  
> utilized
> to carry traffic inbound to the destination (sink).

You're of course completely right that something closely resembling  
this should be part of the shim. Thank you for writing it down  
explicitly.

> 3. Lowest latency -- paths with lower measured latency will be  
> preferred
> over paths with higher latency.  A value set will be added or  
> subtracted
> to the measured value for biasing

Hmmm...

I'm not sure we can cook something digestable from the delay, except  
that if we're first using address pair AX with delay N, and then pair  
BY has delay M where M is a lot larger than N, it probably makes  
sense to continue to test CZ and so on, while if M <= N there is no  
need to search any further.

> An additional draft will need to be written to define the default
> locator ID selection process, and how the TLVs will be used to modify
> locator ID selection.

Please don't say "locator ID", it sound like "dry wet". We have  
locators and identifiers, both are addresses and some addresses are  
both.

Since at this stage, we're only considering the case where the  
initial session setup happens in a backward compatible way, the shim  
has no influence over the selection of the initial address pair. We  
also presume that it's best to engage the shim only when there is an  
outage. This means that for most traffic, the traffic distribution  
depends on regular destination and source address choices like they  
exist today. That's probably not good enough, though. An obvious  
mechanism to influence this would be SRV records in the DNS, which  
would need the same TLVs that you propose for the shim in your  
message (as far as they're missing from the current SRV specs).

> Some TLVs may also rely on a forwarding component in order to sort the
> locator IDs.  I wanted somethin analogous to the current BGP "best"  
> path.

Do you mean "best" by virtue of the BGP path selection algorithm left  
to its own devices, or "best" after having massaged the values the  
BGP selection algorithm takes into account?

Delivery-date: Wed, 21 Sep 2005 19:01:58 +0000
Date: Wed, 21 Sep 2005 15:00:59 -0400 (EDT)
From: "Jason Schiller ([email-masked])" <[email-masked]>
Subject: addition of TLV to locator ID or locator ID set
To: shim6-wg <[email-masked]>

Summary:  support for an additional TLV is required in order to allow for
a destination (sink) to signal to a source which links should be utilized
to carry traffic inbound to the destination (sink).

=================================================================

In the current IPv4 multihoming scenario, where de-aggregation is the
mechanism for inter-AS traffic engineering, a destination (sink) can
manipulate the routing announcements to control how traffic is loaded
across all of the inbound links to the destination (sink).

In the shim6 implementation it is up to the source to determine the order
of the locator ID set and choose which locator ID to send the traffic 
to.  The source lacks routing information, and the routing table lacks 
information about the de-aggregates.  

In order to allow the destination (sink) to control how traffic is loaded
across all of the inbound links to the destination, the destination must
send some clues to advise the source on how the locator IDs should be
ordered.

The suggestion is to attach one or more Type Length Values (TLVs) to a 
locator ID or set of locator IDs when two shim6 capable hosts exchange 
the locator ID set.  A TLV similar to IS-IS will be flexible enough to 
allow the destination to specify any type of inbound link preferences.  
The TLV will consist of a type which will specify the sort preference 
type and a value.  

Initial TLV scould include:

1. Link Order -- lower value link order is always used before higher link
order
2. Round-robin -- value specified would weight the round-robin.  No value
would result in a non-weighted round-robin for all locator IDs in the set.
3. Lowest latency -- paths with lower measured latency will be preferred
over paths with higher latency.  A value set will be added or subtracted
to the measured value for biasing

Additional TLVs should be easily added.

Take for example, a destination that has six uplinks (1,2,3,4,5,6).  Each 
link is with a different ISP, and each host has an IP address associated 
with each upstream ISP.  Assume the destination wants the following 
inbound link loading charastics: 
Use links 1 and 2 as primary.
Use links 3 and 4 as secondary only if both links 1 and 2 fail
Use links 5 and 6 as tertiary only if links 1, 2, 3, and 4 all fail

In this case the destination needs to send additional information along
with the locator IDs to indicate that the source should order the set of
locator IDs such that the IP addresses associated with links 1 and 2 be 
used first.  This wil be followed by the set of IP addresses associated 
with links 3 and 4 as second.  Finally the set of IP addresses associated
with links 5 and 6 should be used third.

(1, 2) -- TLV type = link order, Value = 0
(3, 4) -- TLV type = link order, Value = 1
(5, 6) -- TLV type = link order, Value = 2

>From a traffic engineering perspective you may find that a simple
round-robin loading of all the links at a particular level may not
result in the desired utilization on inbound links.  This may be 
from differnt sized flows that are being round-robined or due to 
different sized links.

Take the case where link 1 is an OC-3 and link 2 is a DS-3.  In this
case you would want the OC-3 to carry three times more traffic than 
the DS-3.  In this case, the destination may want to alter the pre-
existing policy (from above) such that link 1 carries 75% of the traffic
and link 2 carries only 25% of the traffic.  This can be accomplished
by weighting the round-robin.

(1)    -- TLV type = round-robin, Value = 0.75
(2)    -- TLV type = round-robin, Value = 0.25
(1, 2) -- TLV type = link order, Value = 0
(3, 4) -- TLV type = link order, Value = 1
(5, 6) -- TLV type = link order, Value = 2

If this general approach seems reasonable, then some text will need to 
be added to the shim6 architecture document to make a place holder for 
the TLV.   

An additional draft will need to be written to define the default 
locator ID selection process, and how the TLVs will be used to modify
locator ID selection.  It should also include the format of the TLVs,
current TLV types, and thier acceptable values, consideration of the 
maximum number of TLVs, and what to do when mutliple conflicting TLVs
and applied a locator ID or locator ID set.

Some TLVs may also rely on a forwarding component in order to sort the 
locator IDs.  I wanted somethin analogous to the current BGP "best" path.
Since end hosts lack routing state, there will need to be another mechinism
to determine shortest path leveraging the forwarding plane.  One method is
to measure the latency in the forwarding path.  This seems that this solution
should be closely aligned to forwarding path failure detection problem space.

Thnaks for your comments,

___Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Americas' Network Engineering                              [email-masked]
UUNET, an MCI brand                                 [email-masked]

Delivery-date: Tue, 20 Sep 2005 13:54:55 +0000
Date: Tue, 20 Sep 2005 16:54:18 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group

Was there a conclusion of this thread? Are the dates
as originally planned or did they get changed?

--Jari

P.S. The IETF SHIM6 WG page does not show up the
location of the archives.

Delivery-date: Tue, 20 Sep 2005 11:26:38 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CUD and FBD
Date: Tue, 20 Sep 2005 13:26:40 +0200
To: Erik Nordmark <[email-masked]>

Hi Erik,

sorry for the delay...

El 14/09/2005, a las 19:54, Erik Nordmark escribi=F3:

> marcelo bagnulo braun wrote:
>
>> In CUD, each node waits for a given time Tu for ULP feedback. If no=20=

>> feedback is received during Tu seconds, then it probes reachability=20=

>> by sending probes. This means that it will send a probe and wait for=20=

>> To for the answer to come back. It will probably send several probes,=20=

>> e.g. m probes. The node will wait for w seconds between each probe.
>> So the time required in FBD would be: n*t seconds
>> And the time required in CUD would be Tu + To + (m-1)w
>
> Presumably To=3Dw,

right, but i think we discussed once the possibility that w being much=20=

smaller than To (i.e. pessimistic approach) in order to have a faster=20
detection/reaction. In any case i agree that for the purpose of the=20
comparison assuming To similar to w makes sense.

>  but to avoid causing congestion, presumably CUD needs to do binary=20
> exponential backoff.

i would like to understand a bit more if this is really needed...
First of all, the gaol of these set of probes is to determine that a=20
failure occurred so that an alternative path is used (i note this, as=20
opposed to other cases, where exponential backoff is used, where the=20
sender just give up sending)
In this case, including an exponential backoff would result in an=20
exponential increased delay/response time, since in every case that an=20=

outage has really occurred, all the exponential backoff process needs=20
to finnish, right?
So using exponential backoff here would result in a worse performance=20
of the shim (additional delay/interruption in the communication)
OTOH, i think that the number m considered will be somehow low (in=20
order of 3 or 4 perhaps?) so, i am not sure that these would result in=20=

much additional congestion (while the exponetial increasing time with 4=20=

iterations may be somehow high, i guess)

>  (NUD doesn't do this, since it assumes that the local link isn't=20
> likely to suffer congestive collapse from only the NUD probes, but for=20=

> the end-to-end path I don't think this assumption holds.)
>
> This raises the question whether the packets generated by FBD needs to=20=

> be concerned about congestion control.
> If we have a simple model of the network where the paths are symmetric=20=

> and traffic volume is symmetric, then one can definitely argue that=20
> FBD does no need this, because at most it sends one packet for every=20=

> received packet. (Only if a packet has been received in the last t=20
> seconds and the ULPs haven't sent anything back, will FBD send a=20
> keepalive.)
>
> But the limit on FBD (of at most sending one packet in response to one=20=

> received packet) means that it exhibits the same behavior as TCP SYNs=20=

> and DNS queries; in those cases the protocols do not apply any=20
> congestion control to the "responder" but does assume that the=20
> "requestor" handles congestion avoidance (by retransmitting using=20
> binary exponential backoff.)
>
> So my take is that FBD doesn't need binary exponential backoff, which=20=

> would be a great benefit.
>

yes that would be my understanding also, BTW i am not sure i understand=20=

how FBD could implement an exponential backoff, since the other end is=20=

expecting a given frequency of incoming packets... implemeting an=20
exponential backoff would imply that packets are generated more and=20
more spaced in time, so the other end would not receive a fixed=20
frequency of incoming packets, right?

>> Now i think that for the comparaison, and if the expected resiliency=20=

>> is to be similar, we could assume that n =3D m (the number of probes =
is=20
>> the same).
>> Also, that Tu will be smaller or similar to t, since Tu is the=20
>> timeout of the application, and t is the default timeout of the shim.
>
> I NUD Tu isn't related to the application/ULP timeout; instead it is a=20=

> protocol constant (which is picked so that with high probability if=20
> there will be ULP positive advice it will arrive in less than Tu=20
> seconds). Basically you want it to be at least Rtt + ack delay (to=20
> handle protocols like TCP that implements delayed acks).

right, that is why i assumed that Tu is smaller than t (Tu is the=20
timeout of the app, which should know better than the shim, which has a=20=

generic (by default) tiemout t)

>
>
> Another thing to look at is whether the timers can be dynamic, or keep=20=

> them static as in NUD. Since shim6 is end-to-end I think it makes=20
> sense to make them dynamic.
> In CUD, when the probes are not supressed, then the probe+response can=20=

> be used by the host to determine the roundtrip time, hence it can be=20=

> the basis for the "w" timeout.
>

agree

> In FBD it is not clear to me what techniques can be used to make "t"=20=

> be a function of the Rtt. Any ideas?
>

interesting question...

i guess that t is not directly affected by the value of the RTT but t=20
is affected by the variations of the RTT.
I mean, if the RTT remains constant, then it doesn't matter if it is 1=20=

ms or 500 ms, because t is the time between probes, so it is only=20
related to the rate at which the sender generates probes. the RTT would=20=

impact the time that it takes the first packet to arrive but not to the=20=

time between packets, right?

However, it the RTT changes during the communication, then the=20
variation in the RTT would be added to the t.

I mean, suppose that the sender is generating probes each t seconds.
Until now, the RTT was fixed.
this means that the receiver is receiving probes each t seconds.

Now, the RTT increases in dRTT, so that it results in RTT+dRTT.
this means that the next packet won't be received in t seconds but in=20
(t+dRTT/2)seconds, right?

So, in order to make the t adaptive, we would need to measure the=20
variations in the RTT... this could be done if the receiver of the=20
probes can feedback the sender of the probes about the variations in=20
the times between received probes... but i am getting the feeling that=20=

this may be too much complexity and i am not sure if it is worthy...

>> - Overhead
>> In CUD, each time there is an idle period, 2 packets are generated,=20=

>> one in each direction.
>
> I don't think that is necessary (assuming ULP advice).
>
> A sends packet to B, and B sends a packet back shortly there after.=20
> Then things go idle.
> This means that the reachability state will move from REACHABLE to=20
> UNKNOWN (RFC 2461 uses a slightly different description).
> If A then goes to send a packet, we can use the DELAY state idea from=20=

> RFC 2461 to avoid sending an immediate probe. As long as B responds=20
> and the ULP on A passes down positive advice, any probe from A to B=20
> can be supressed. Whether B ends up probing A is more difficult to=20
> tell; if B receives packets from A (need multiple packets) that=20
> indicate to the ULP on B that A has received it's ack, then the ULP on=20=

> B can provide positive advice.
>

right, but i was comparing the worse scenario (which for the overhead=20
implies that no ULP feedback is provided, so periodic keepalive tests=20
are required)

> But if there is no positive advice from the ULP, the overhead would be=20=

> 4 packets when the flow restarts (a probe from each direction, which=20=

> each of them being acknowledged). This could be minimized to 3 but=20
> can't do any better to verify that both directions are working.
>

right. However, i we consider the possibility of using packet flow as=20
an indication that the things are working, then this case that you are=20=

presenting would not generate any additional packet since the data=20
packets would serve as an indication that things are working. In this=20
case, the worse case is an ULP that doesn't provides feedback to the=20
shim and that it generates unidirectional flow, in which case the=20
sender has to generate periodic keepalives tests, adding two extra=20
packets.
(but i guess that what we need to discuss first is about the usage of=20
data packets as an indicator that things are working, which i will=20
address below)

>> In FBD, each time there is an idle period, i packet is generated
>
> "i" or "1"??
>

1 (sorry for the typo)

> I think this can actually be zero extra packets, depending on details=20=

> of  the time period FBD uses to "measure" received and transmitted=20
> packets.
>
> A sends a packet to B, and B responds in time period 0. No need to=20
> send extra packets.
> The communication is silent in time period 1,2,3, and 4.
> In time period 5, A sends a packet to B, and B responds. Both ends=20
> have sent and received in time period 5, hence no need to send a=20
> keepalive.
>
> Only if the packet arrives at B at the very end of time period 5 so=20
> that the ULP response is sent by B in time period 6, would FBD cause=20=

> an extra packet. Presumably one can avoid that by having FBD, after an=20=

> idle period, start the new time period when the first packet is=20
> received.
>

i was considering again an unidirectional flow. In this case the=20
receiver would need to generate periodic packets (since it does not=20
generates data packets) right?

>
>> FBD imposes half of the overhead than CUD
>> [Note: As currently defined in the draft, if there is no ULP=20
>> feedback, CUD will periodically generate probes, which would greatly=20=

>> increment the overhead imposed by CUD when the ULP does not provides=20=

>> feedback (e.g. UDP) resulting in an overhead much greater than the=20
>> double of the one of FBD . However, i think that not only ULP=20
>> feedback can be used as an indicator of communication progress, but=20=

>> also the reception of packets could be assumed as an indication of=20
>> progress. In this case, the overhead of CUD would be the double of=20
>> the one in FBD]
>
> FWIW I don't think reception of packets can be an indication in CUD=20
> that the bidirectional path is working.
> If A is transmitting packets to B, and B is acking, but the acks don't=20=

> make it to A, then B will continue to receive (ULP retransmitted)=20
> packets from A for a few minunutes, even though the path from B to A=20=

> is broken.

right, but A won't receive any packets and would start path exploration=20=

procedure.
I mean, in this case, the node detects outages in its incoming path,=20
i.e. A is the one that will detect the outage.

In other words, a necessary condition for a failure is that at least=20
one of the communicating nodes is not receiving packets. this is not a=20=

sufficient condition for a failure, since traffic can be unidirectional=20=

(in which case, the above condition is meet but no outage has occurred)
In the case of unidirectional communications, explicit reachability=20
tests are required in CUD

So, the point is to use use the absence of incoming packets as an=20
indicator that an explicit reachability test is required (in order to=20
differentiate a failure from an unidirectional flow)

In this extended CUD scheme there are three elements in the failure=20
detection:
- ULP feedback
- incoming traffic
- explicit reachability tests

Regards, marcelo

>
>    Erik
>

Delivery-date: Thu, 15 Sep 2005 02:54:00 +0000
Date: Wed, 14 Sep 2005 19:23:45 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: CUD and FBD

Iljitsch van Beijnum wrote:

> Are there links that can't handle a fairly small packet every 3 - 20  
> seconds or so?

My question was really whether having a few billion hosts do this and 
whether that could cause congestive collapse. I don't think it can do 
this any more than TCP always responding to a SYN with a SYN|ACK can 
cause congestive collapse.

CUD on the other hand sends new requests (and needs to retransmit them) 
so I think those retransmissions should follow binary exponential 
backoff to be safe.

   Erik

Delivery-date: Wed, 14 Sep 2005 20:01:22 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CUD and FBD
Date: Wed, 14 Sep 2005 22:00:51 +0200
To: Erik Nordmark <[email-masked]>

On 14-sep-2005, at 19:54, Erik Nordmark wrote:

> This raises the question whether the packets generated by FBD needs  
> to be concerned about congestion control.
> If we have a simple model of the network where the paths are  
> symmetric and traffic volume is symmetric, then one can definitely  
> argue that FBD does no need this, because at most it sends one  
> packet for every received packet. (Only if a packet has been  
> received in the last t seconds and the ULPs haven't sent anything  
> back, will FBD send a keepalive.)

I always imagined that FBD keepalives would adhere to a standard  
interval, which would be dictated by the requirements of the  
application. For instance, if the application wants to rehome within  
15 seconds, FBD keepalives would have to be sent every 10 seconds or  
so (when required) which leaves 5 seconds to do the shim magic when  
ONE FBD keepalive is missed. Or maybe make this every 5 or every 3  
seconds and start action after two or three misses.

It gets easier when the application can survive longer outages.

Are there links that can't handle a fairly small packet every 3 - 20  
seconds or so?

Delivery-date: Wed, 14 Sep 2005 18:05:31 +0000
Date: Wed, 14 Sep 2005 10:54:33 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: CUD and FBD

marcelo bagnulo braun wrote:

> In CUD, each node waits for a given time Tu for ULP feedback. If no 
> feedback is received during Tu seconds, then it probes reachability by 
> sending probes. This means that it will send a probe and wait for To for 
> the answer to come back. It will probably send several probes, e.g. m 
> probes. The node will wait for w seconds between each probe.
> 
> So the time required in FBD would be: n*t seconds
> And the time required in CUD would be Tu + To + (m-1)w

Presumably To=w, but to avoid causing congestion, presumably CUD needs 
to do binary exponential backoff. (NUD doesn't do this, since it assumes 
that the local link isn't likely to suffer congestive collapse from only 
the NUD probes, but for the end-to-end path I don't think this 
assumption holds.)

This raises the question whether the packets generated by FBD needs to 
be concerned about congestion control.
If we have a simple model of the network where the paths are symmetric 
and traffic volume is symmetric, then one can definitely argue that FBD 
does no need this, because at most it sends one packet for every 
received packet. (Only if a packet has been received in the last t 
seconds and the ULPs haven't sent anything back, will FBD send a keepalive.)

But the limit on FBD (of at most sending one packet in response to one 
received packet) means that it exhibits the same behavior as TCP SYNs 
and DNS queries; in those cases the protocols do not apply any 
congestion control to the "responder" but does assume that the 
"requestor" handles congestion avoidance (by retransmitting using binary 
exponential backoff.)

So my take is that FBD doesn't need binary exponential backoff, which 
would be a great benefit.

> Now i think that for the comparaison, and if the expected resiliency is 
> to be similar, we could assume that n = m (the number of probes is the 
> same).
> Also, that Tu will be smaller or similar to t, since Tu is the timeout 
> of the application, and t is the default timeout of the shim.

I NUD Tu isn't related to the application/ULP timeout; instead it is a 
protocol constant (which is picked so that with high probability if 
there will be ULP positive advice it will arrive in less than Tu 
seconds). Basically you want it to be at least Rtt + ack delay (to 
handle protocols like TCP that implements delayed acks).

Another thing to look at is whether the timers can be dynamic, or keep 
them static as in NUD. Since shim6 is end-to-end I think it makes sense 
to make them dynamic.
In CUD, when the probes are not supressed, then the probe+response can 
be used by the host to determine the roundtrip time, hence it can be the 
basis for the "w" timeout.

In FBD it is not clear to me what techniques can be used to make "t" be 
a function of the Rtt. Any ideas?

> - Overhead
> 
> In CUD, each time there is an idle period, 2 packets are generated, one 
> in each direction.

I don't think that is necessary (assuming ULP advice).

A sends packet to B, and B sends a packet back shortly there after. Then 
things go idle.
This means that the reachability state will move from REACHABLE to 
UNKNOWN (RFC 2461 uses a slightly different description).
If A then goes to send a packet, we can use the DELAY state idea from 
RFC 2461 to avoid sending an immediate probe. As long as B responds and 
the ULP on A passes down positive advice, any probe from A to B can be 
supressed. Whether B ends up probing A is more difficult to tell; if B 
receives packets from A (need multiple packets) that indicate to the ULP 
on B that A has received it's ack, then the ULP on B can provide 
positive advice.

But if there is no positive advice from the ULP, the overhead would be 4 
packets when the flow restarts (a probe from each direction, which each 
of them being acknowledged). This could be minimized to 3 but can't do 
any better to verify that both directions are working.

> In FBD, each time there is an idle period, i packet is generated

"i" or "1"??

I think this can actually be zero extra packets, depending on details of 
  the time period FBD uses to "measure" received and transmitted packets.

A sends a packet to B, and B responds in time period 0. No need to send 
extra packets.
The communication is silent in time period 1,2,3, and 4.
In time period 5, A sends a packet to B, and B responds. Both ends have 
sent and received in time period 5, hence no need to send a keepalive.

Only if the packet arrives at B at the very end of time period 5 so that 
the ULP response is sent by B in time period 6, would FBD cause an extra 
packet. Presumably one can avoid that by having FBD, after an idle 
period, start the new time period when the first packet is received.

> FBD imposes half of the overhead than CUD
> 
> [Note: As currently defined in the draft, if there is no ULP feedback, 
> CUD will periodically generate probes, which would greatly increment the 
> overhead imposed by CUD when the ULP does not provides feedback (e.g. 
> UDP) resulting in an overhead much greater than the double of the one of 
> FBD . However, i think that not only ULP feedback can be used as an 
> indicator of communication progress, but also the reception of packets 
> could be assumed as an indication of progress. In this case, the 
> overhead of CUD would be the double of the one in FBD]

FWIW I don't think reception of packets can be an indication in CUD that 
the bidirectional path is working.
If A is transmitting packets to B, and B is acking, but the acks don't 
make it to A, then B will continue to receive (ULP retransmitted) 
packets from A for a few minunutes, even though the path from B to A is 
broken.

    Erik

Delivery-date: Sat, 10 Sep 2005 15:42:22 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Date: Sat, 10 Sep 2005 17:41:29 +0200
To: Francis Dupont <[email-masked]>

On 10-sep-2005, at 16:36, Francis Dupont wrote:

>>    if not, we can ask RIPE for Jabber conferencing.

> => RIPE has already Jabber conferencing...

Yes, but that doesn't mean can automatically use it two days before  
the meeting begins.

But it seems that [email-masked] works right now just like at  
the IETF meetings so we can just use that.

Envelope-to: [email-masked]
Delivery-date: Sat, 10 Sep 2005 14:40:39 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: Geoff Huston <[email-masked]>, shim6 <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Date: Sat, 10 Sep 2005 16:36:54 +0200

 In your previous mail you wrote:

   if not, we can ask RIPE for Jabber conferencing.
   
=> RIPE has already Jabber conferencing...

[email-masked]

Delivery-date: Sat, 10 Sep 2005 11:12:36 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group
Date: Sat, 10 Sep 2005 13:11:15 +0200
To: Geoff Huston <[email-masked]>

On 10-sep-2005, at 2:38, Geoff Huston wrote:

> Nothing p[lanned as yet - no. Obviously we're open to offers of  
> assistance here for this - (such as an icam feed)

If there is bandwidth and the room has an audio setup that I can tap  
into that and bring a camera like I did in Santa Monica.

I'm not sure if it's any fun to watch this stuff for two days, though...

I think the IETF Jabber rooms are available even when there is no  
IETF meeting (can't check right now, jabber.org is down (again)), and  
if not, we can ask RIPE for Jabber conferencing.

Delivery-date: Sat, 10 Sep 2005 01:36:34 +0000
Date: Sat, 10 Sep 2005 10:38:16 +1000
To: David Meyer <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group
Cc: [email-masked], Kurt Erik Lindqvist <[email-masked]>

Nothing p[lanned as yet - no. Obviously we're open to offers of assistance 
here for this - (such as an icam feed)

regards,

     Geoff

At 01:07 AM 10/09/2005, David Meyer wrote:
>         Geoff/Kurtis,
>
>         I'm wondering, for those of use who would rather not (or
>         can't) travel, do you plan to provide any A/V (or other)
>         facilities to enable remote participation?
>
>         Thanks,
>
>         Dave
>

Delivery-date: Fri, 09 Sep 2005 15:08:22 +0000
Date: Fri, 9 Sep 2005 08:07:20 -0700
From: David Meyer <[email-masked]>
To: Geoff Huston <[email-masked]>
Cc: [email-masked], Kurt Erik Lindqvist <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group

--EVF5PPMfhYS0aIcm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

	Geoff/Kurtis,

	I'm wondering, for those of use who would rather not (or
	can't) travel, do you plan to provide any A/V (or other)
	facilities to enable remote participation?

	Thanks,

	Dave

--EVF5PPMfhYS0aIcm
Content-Type: application/pgp-signature
Content-Disposition: inline

--EVF5PPMfhYS0aIcm--

Delivery-date: Fri, 09 Sep 2005 09:16:40 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Date: Fri, 9 Sep 2005 11:16:12 +0200
To: Thomas Narten <[email-masked]>

On 9-sep-2005, at 3:04, Thomas Narten wrote:

> Hmm. For me, the interesting stuff at Ripe are the Wednesday-Friday
> sessions, i.e., the RIPE WG sessions.

> Would it all be possible to move the interim meeting up to
> Sunday-Monday (RIPE doesn't start until 2PM on Monday, so this would
> have minimal impact)?

> Or just have the sessions Monday/Tuesday?

> Would this help/or hurt other peoples intention w.r.t. to the RIPE
> meeting?

Looking at http://www.ripe.net/ripe/meetings/ripe-51/meeting- 
plan.html there are sure lots of "plenary" slots from monday  
afternoon through wednesday morning. It would be good to know what is  
going to happen during those slots before we make decisions.

In the old format where there was "EOF" the first two days I often  
found that the most interesting part of the meeting.

How about making the meeting saturday afternoon - monday morning?  
This allows people who can arrive saturday morning to leave a day  
later, and those who don't arrive until late saturday (or very early  
sunday) only miss half a day.

Delivery-date: Fri, 09 Sep 2005 08:57:51 +0000
Cc: shim6 <[email-masked]>
From: Pekka Nikander <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Date: Fri, 9 Sep 2005 10:57:44 +0200
To: Geoff Huston <[email-masked]>, Kurt Erik Lindqvist <[email-masked]>

> How do others feel - should we shift this to the Sunday and the  
> Monday morning,
> or are you happy with the proposed weekend scheduling?

Sunday-Monday would definitely work better for me.

--Pekka Nikander

Delivery-date: Fri, 09 Sep 2005 08:51:26 +0000
Cc: Kurt Erik Lindqvist <[email-masked]>, [email-masked], Thomas Narten <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Date: Fri, 9 Sep 2005 09:54:51 +0200
To: Geoff Huston <[email-masked]>

I am fine with the weekend and also with sunday-monday.

regards, marcelo

El 09/09/2005, a las 3:39, Geoff Huston escribi=F3:

> I understand your concerns here.
>
> However I note that we just managed to get the meeting announcement in=20=

> within
> the 30 day stipulated advance notice. (apologies about the last minute=20=

> planning!)
>
> How do others feel - should we shift this to the Sunday and the Monday=20=

> morning,
> or are you happy with the proposed weekend scheduling?
>
> Geoff
>
>
> At 11:04 AM 9/09/2005, Thomas Narten wrote:
>> > Interim Meeting Announcement
>> > Working Group: SHIM6 (Site Multi-Homing for IPv6)
>> > Dates: Saturday 8th October, Sunday 9th October 2005
>> > Times: 10:00 am - 5:00 pm
>>
>> Hmm. For me, the interesting stuff at Ripe are the Wednesday-Friday
>> sessions, i.e., the RIPE WG sessions.
>>
>> Would it all be possible to move the interim meeting up to
>> Sunday-Monday (RIPE doesn't start until 2PM on Monday, so this would
>> have minimal impact)?
>>
>> Or just have the sessions Monday/Tuesday?
>>
>> Would this help/or hurt other peoples intention w.r.t. to the RIPE
>> meeting?
>>
>> (Not trying to make trouble, and finding host space is surely
>> complicated, but the idea of having to be there Friday-Friday just
>> isn't very appealing.)
>>
>> Thomas
>
>
>

Delivery-date: Fri, 09 Sep 2005 05:14:33 +0000
Date: Fri, 09 Sep 2005 08:13:50 +0300
From: Jari Arkko <[email-masked]>
To: Thomas Narten <[email-masked]>
CC: Geoff Huston <[email-masked]>,  [email-masked],  Kurt Erik Lindqvist <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group

I'm fine with all the proposed dates, but my preference
is avoiding the weekend.

--Jari

Thomas Narten wrote:

>>Interim Meeting Announcement
>>Working Group: SHIM6 (Site Multi-Homing for IPv6)
>>Dates: Saturday 8th October, Sunday 9th October 2005
>>Times: 10:00 am - 5:00 pm
>>    
>>
>
>Hmm. For me, the interesting stuff at Ripe are the Wednesday-Friday
>sessions, i.e., the RIPE WG sessions.
>
>Would it all be possible to move the interim meeting up to
>Sunday-Monday (RIPE doesn't start until 2PM on Monday, so this would
>have minimal impact)?
>
>Or just have the sessions Monday/Tuesday?
>
>Would this help/or hurt other peoples intention w.r.t. to the RIPE
>meeting?
>
>(Not trying to make trouble, and finding host space is surely
>complicated, but the idea of having to be there Friday-Friday just
>isn't very appealing.)
>
>Thomas
>
>
>
>  
>

Delivery-date: Fri, 09 Sep 2005 01:40:49 +0000
Date: Fri, 09 Sep 2005 11:39:12 +1000
To: Thomas Narten <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Cc: [email-masked], Kurt Erik Lindqvist <[email-masked]>

I understand your concerns here.

However I note that we just managed to get the meeting announcement in within
the 30 day stipulated advance notice. (apologies about the last minute 
planning!)

How do others feel - should we shift this to the Sunday and the Monday morning,
or are you happy with the proposed weekend scheduling?

Geoff

At 11:04 AM 9/09/2005, Thomas Narten wrote:
> > Interim Meeting Announcement
> > Working Group: SHIM6 (Site Multi-Homing for IPv6)
> > Dates: Saturday 8th October, Sunday 9th October 2005
> > Times: 10:00 am - 5:00 pm
>
>Hmm. For me, the interesting stuff at Ripe are the Wednesday-Friday
>sessions, i.e., the RIPE WG sessions.
>
>Would it all be possible to move the interim meeting up to
>Sunday-Monday (RIPE doesn't start until 2PM on Monday, so this would
>have minimal impact)?
>
>Or just have the sessions Monday/Tuesday?
>
>Would this help/or hurt other peoples intention w.r.t. to the RIPE
>meeting?
>
>(Not trying to make trouble, and finding host space is surely
>complicated, but the idea of having to be there Friday-Friday just
>isn't very appealing.)
>
>Thomas

Envelope-to: [email-masked]
Delivery-date: Fri, 09 Sep 2005 01:05:42 +0000
Message-Id: <[email-masked]>
To: Geoff Huston <[email-masked]>
cc: [email-masked], Kurt Erik Lindqvist <[email-masked]>
Subject: Re: Announcement of an Interim Meeting of the Shim6 Working Group 
Date: Thu, 08 Sep 2005 21:04:53 -0400
From: Thomas Narten <[email-masked]>

> Interim Meeting Announcement
> Working Group: SHIM6 (Site Multi-Homing for IPv6)
> Dates: Saturday 8th October, Sunday 9th October 2005
> Times: 10:00 am - 5:00 pm

Hmm. For me, the interesting stuff at Ripe are the Wednesday-Friday
sessions, i.e., the RIPE WG sessions.

Would it all be possible to move the interim meeting up to
Sunday-Monday (RIPE doesn't start until 2PM on Monday, so this would
have minimal impact)?

Or just have the sessions Monday/Tuesday?

Would this help/or hurt other peoples intention w.r.t. to the RIPE
meeting?

(Not trying to make trouble, and finding host space is surely
complicated, but the idea of having to be there Friday-Friday just
isn't very appealing.)

Thomas

Delivery-date: Thu, 08 Sep 2005 18:55:12 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: CUD and FBD
Date: Thu, 8 Sep 2005 20:54:57 +0200
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

I guess that the issue of whether CUD or FBD is more appropriate for 
the shim protocol is still on the table, so i will try to recap the 
aspects that i can think of for making such comparison. Here goes an 
initial list, inspired on what's on the draft and following discussions 
in the list:

- Who detects what?
By this, i mean the capability of each node to to detect exactly in 
which direction of the communication path the failure has occurred.

FBD: Since each node is committed to generate traffic with a given 
frequency, if a node stops receiving traffic, this means a failure in 
the incoming direction of the communication path. So, in FBD only 
failures in the incoming paths are detected. If the failure also 
affects the outgoing direction, this is detected by the other end of 
the communication. The result is that failures are detected by the 
receiver and it knows for sure that  a failure affecting at least the 
incoming path has occurred. The reaction to this failure needs to 
involve for certain the sender node, so, the node that detects the 
outage needs to inform the other end of the failure so the recovery 
procedure can be started.

CUD: The nodes check path availability by performing an explicit 
reachability test. In this case, the detected failure may affect any of 
the directions of the communication. i.e. this mechanism does not 
provides the precise direction that is affected by the failure. This 
means that the node that has detected the failure cannot tell whether 
he should try alternative locator pair itself and/or should try to 
inform the other end about the failure so that it is the other end who 
uses alternative locators.

So, in FBD each node has a clear view about a failure in their incoming 
path, while in CUD, each node can detect a failure but it is not 
certain of which direction is affected.

This difference may not be relevant, depending on which are the 
following steps.
In FBD, the node that has detected the outage needs to inform the other 
end about the failure, in a reliable manner. This may result in 
starting the full path exploration procedure as described in the draft, 
so that the other end starts the procedure itself.
In CUD, the behaviour is likely to be the same, since the node that has 
detected the outage does not knows which direction has failed, so both 
nodes need to perform the full path exploration procedure.
So, i think that the result in both mechanisms is similar.

- Reaction time

Another issue that may be relevant when comparing CUD and FBD is the 
time required by each mechanism for detecting the outage and reacting 
accordingly.

In FBD, each node expects to receive traffic with a minimum frequency 
e.g. at least 1 packet each t seconds. If no packets are received in t 
seconds, this may mean that a failure has occurred or that the packet 
was lost for other reason. So, probably the node will wait for n*t 
seconds without receiving incoming packets until it determines that a 
failure has occurred.

In CUD, each node waits for a given time Tu for ULP feedback. If no 
feedback is received during Tu seconds, then it probes reachability by 
sending probes. This means that it will send a probe and wait for To 
for the answer to come back. It will probably send several probes, e.g. 
m probes. The node will wait for w seconds between each probe.

So the time required in FBD would be: n*t seconds
And the time required in CUD would be Tu + To + (m-1)w
Now i think that for the comparaison, and if the expected resiliency is 
to be similar, we could assume that n = m (the number of probes is the 
same).
Also, that Tu will be smaller or similar to t, since Tu is the timeout 
of the application, and t is the default timeout of the shim.
Probably, To will be smaller or similar to Tu for the same reasons than 
before.
I think that w can be set to a much smaller value that To because the 
purpose of sending multiple packets between intervals of w seconds is 
to avoid assuming a failure because of a punctual packet loss.
So, according to these considerations, i would say that probably CUD 
will be a bit faster, but i guess that the reaction time in both cases 
will be similar.

- Overhead

In CUD, each time there is an idle period, 2 packets are generated, one 
in each direction.
In FBD, each time there is an idle period, i packet is generated

FBD imposes half of the overhead than CUD

[Note: As currently defined in the draft, if there is no ULP feedback, 
CUD will periodically generate probes, which would greatly increment 
the overhead imposed by CUD when the ULP does not provides feedback 
(e.g. UDP) resulting in an overhead much greater than the double of the 
one of FBD . However, i think that not only ULP feedback can be used as 
an indicator of communication progress, but also the reception of 
packets could be assumed as an indication of progress. In this case, 
the overhead of CUD would be the double of the one in FBD]

- ULP interaction

As defined in the draft, CUD requires ULP feedback in order to greatly 
reduce overhead. However, as i mentioned above, i think that a 
workaround can be used to deal with this issue.

IMHO, both mechanisms can benefit from negative ULP feedback in a 
similar way, since CUD wouldn't need to wait for Tu and FBD wouldn't 
have to wait for n*t. Probably, the benefit is much greater in FDB.

So, as far as i can see, both mechanisms behave quite similarly. 
Probably, the main difference is w.r.t. the overhead, where FBD is 
superior.

Delivery-date: Thu, 08 Sep 2005 09:06:38 +0000
Date: Thu, 08 Sep 2005 19:05:22 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Announcement of an Interim Meeting of the Shim6 Working Group
Cc: Kurt Erik Lindqvist <[email-masked]>, [email-masked]

Hi,

Kurtis and I, your co-chairs would like to convene an interim meeting of this
working group on the 8th and 9th October 2005. This interim meeting is not
intended to replace a regular IETF meeting of this working group - we fully
intend to meet at Vancouver in November 2005. However in order
to ensure that we can achieve our charter milestones it is considered necessary
to take some extended time in the interim to consider the details of the
activity and ensure that the various components of the activity work to a
cohesive whole.

Note that this is immediately before the RIPE meeting, at the same venue.

An announcement will be posted to the IETF announce list shortly.

If you intend to come to this meeting please let us know, so that we can
ensure that the room is the right size. Mail to Kurtis at the address
above would be appreciated  if you are coming.

MANY THANKS to the RIPE NCC for being the sponsor of this meeting!

thanks,

   Kurtis & Geoff

====================================

Interim Meeting Announcement

Working Group: SHIM6 (Site Multi-Homing for IPv6)

Dates: Saturday 8th October, Sunday 9th October 2005

Times: 10:00 am - 5:00 pm

Location: Hotel Krasnapolsky, Amsterdam, The Netherlands

Proposed Agenda:

   Proposed Agenda

   1. Review of current status

   2. Presentation by lead authors on working documents:
         Protocol
         Crypto Locators
         Triggers
         Applicability

   3. Issue identification
         Potential areas:
             locator pairing discovery
             locator pairing state maintenance / cache management
             upper level protocol API / signalling
             mobility implications
             packet header format / content
             shim equivalence state behaviour

   4. Functional decomposition

   5. Next steps (deliverables for Vancouver)

   6. AOB

Chairs: Kurtis Lindqvist, Geoff Huston

====================================