RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> >             +----+
> >         ----|ISPA|_             +----+
> >        /    +----+ \_+------+  _|ISPC|_
> >  +----+              |      |_/ +----+ \__+----+
> >  | mh1|             _|      |            _| mh2|
> >  +----+     +----+_/ |      |_          / +----+
> >        \____|ISPB|   +------+ \_+----+_/
> >             +----+              |ISPD|
> >                                 +----+
> >

[...]

> >
> > Now, suppose that mh2 also obtains a hint that something is wrong (this
> > could be because TCP at mh2 timeout or because packets start
>
> > arriving with a different source address (this last case cannot
> > be guaranteed because it depends on the internal routing in mh1)).
>
> > So, mh2 shim layer start using an alternative destination address,
> > so it switches from PA:mh1 to PB:mh1. However, this does not solve
> > the problem, since packets addressed to PB:: are also routed through
ISPC.
> > The problem here is that TCP detects the problem but it has no means to
> > communicate the problem to the mh2's routing system, who still
> > believes that a route through ISPC is still available.
>
> I thought you expressed concern about potential destructive interference
> between the endpoints trying different locators and the routing system
> finding a new path. But in the above example I don't find such destructive
> interference.
> (Sure, the worst case performance might not be better than the worst case
> routing convergence time, but that is a different topic.)
>

Well, i think that the ULP hint mechanism is not working for this particular
case, so i would say that a different interaction than letting the ULP hints
set the destination locator and the routing system to determine the source
locator is needed.
In this case we may detect some desturctive interference
IMHO, we should try to define a ULP hints mechanism that properly uses all
hints and that improves the routing system response time.


> So do you see any destructive interference?
>
> If not folks can work separately on the multi6 rehoming and improving the
> convergence time as well as information (such as churn rate) in BGP.
>
> > This could be achieved with source address based routing.. the
> problem here
>
> Source address based routing seems like a fair amount of added
> complications; impacts the hardware/firmware in the routers and what else?
> It might be easier to work on BGP convergence time.
>

Well, i am not really agree with the evolution of the reasoning here.
Let me see if i do a brief summary:
- In order to provide ULP established session, we propose a solution that
implies the modification of all the hosts in the IPv6 Internet. IMHO, it's
ok
- However, if we base our solution only in BGP recovery features, the
solution won't be usefull to preserve the established sessions of a number
of applications.
- One option to address this concern is to use keepalives, but a general
solution based in keepalives exchanges seems inefficient and expensive. IMHO
agree
- Since every ULP has different needs we can use ULP hints to detect if
something is wrong. IMHO good
- Now the problem is that the host cannot force the routing system when it
detects a problem based in the ULP hint
- A proposed solution is to use source address based routing
- But now you say that it would be better to work in BGP convergence, which
is clearly out of the scope of the wg
The result is that the solution than will not provide ULP session
surviavility for a number of cases.
Is this the evolution of the discussion?
If so, i don't agree with the last steps.
IMHO we will propose an expensive solution and it should better provide good
capabilities and this inlcudes the preservation of the ULP sessions.
I don't think it is a good approach to tell that someone else will solve the
BGP convergence problem, so that we will just wait for that.
I think that the ULP hint approach has possibilties and we should try to
work it out, if it is not source address based routing, it may a routing hea
der or something else.
So my proposal is let's try to solve the problem above.
What do you think?


> > (Another hint can be the reception of ICMP error messages.)
>
> I'm concerned about the threats in that case since the host has no way
> to assertain whether the ICMP error was generated by a router in the path
> or some off-path spoofer.
>

Agree, however, this could be a low priority hint perhaps?

Regards, marcelo

>   Erik
>
>