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

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 1 Nov 2003 14:14:19 +0100

On 31 okt 2003, at 14:38, marcelo bagnulo wrote:

>>> The problem is that to detect that there is no route to a certain, 
>>> all
>>> the alternative routes with increasing AS path are tried, which is
>>> inherently slow.

>> Only if there are no alternatives. If there are, the path for those is
>> probably not that long so they show up pretty quickly. Only when the
>> last/only path goes down you'll see the following problem:

> Ok, but this is the case that we care, right?
> From ISPA prespective, there is no longer a route to the destiantion, 
> so the
> multi-homed site detects that and tries the alternative ISP (ISPB).
> So the case that we care is the reconvergence of BGP within the portin 
> of
> the network where a route to the destiantion address no longer exist

No, fortunately it works a bit better than that. Consider:

    ISP A
   /  |  \
X    |    Y
   \  |  /
    ISP B

If X gets transit from both A and B, both A and B will always see the 
path to X over the other. (This is required because if X didn't get 
transit from B but only from A, B would _have_ to reach X over A.) So 
B's routing table would show:

prefix         next hop  as path
10.11.12.0/24  x         x
                a         a x

If the direct connection to X now disappears, B's routing table shows:

prefix         next hop  as path
10.11.12.0/24  a         a x

This happens within seconds of the BGP session between X and B going 
down.

BGP only propagates the best path, so before the outage Y would see:

prefix         next hop  as path
10.11.12.0/24  a         a x
                b         b x

and after:

prefix         next hop  as path
10.11.12.0/24  a         a x
                b         b a x

> Anyway, i guess that the reconvergence time is only part of the 
> problem.
> Another part of the problem is the time required to detect the outage. 
> Only
> this factor would render the solution inacceptable for many 
> applications.

Agree. Fortunately work is underway in this area so hopefully this will 
get better in the future.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 4 Nov 2003 20:37:37 +0100

On torsdag, okt 30, 2003, at 15:56 Europe/Stockholm, marcelo bagnulo 
wrote:

> Kurtis wrote:
>
>> Isn't this simply expectation management? The reason we changed the
>> requirements into goals was because the items in the document where
>> either contradictory; we realized that we couldn't get it all so make
>> it all requirements wasn't an option; and we couldn't decide on what
>> issues where needed more than others; ?
>>
>
> Well i am not sure this the case of session survivability, at least 
> right
> now. I mean, i don't think that providing transport session 
> survivability is
> contradictory with another of the requirements, it is just that 
> providing it
> is expensive.

So we are back to what is the definition of "having survived"? How long 
is reasonable before a session times out? This has been discussed in 
several other discussions such as site-local as well. There is no easy 
answer.

>> I think that connection survivability is a nice to have,
>
> IMHO is more than that. It is the main problem that we have.
> I mean, all other aspects of multihoming are simpler to solve than 
> this one
> i guess.

Again. Depends on the timeout value.

> The preservation of established sessions is the only requirements that 
> its
> support imposes modifications of both sites of the communication. this
> implies that hosts *outside* the multihomed site will need to be 
> upgraded in
> order to support this feature of the multi-homing solution. This is 
> IMHO a
> great effort with a really important cost. This cost is justified only 
> if it
> is an important feature, i guess.

Agreed. Note that "nice to have" is not the same as "shouldn't have". I 
agree that it is a really important criteria, but it's not THE criteria.

> If session preservation is a nce to have feature, we could just don't
> provide it and provide a multi-homing solution that only imposes
> modifications to the multi-homed site.

We could. But if we can, we should address it. I am trying introduce a 
gray scale here...

> So the approach that is proposed would be:
> The general M6 layer provides a general service, for instance based in
> current bgp response times

Ok, that is a good definition of my gray scale..:-)

> Also, the M6 accepts hints from modified ULP that have more demanding
> requirements. This would enable that if an ULP is capable of detecting
> outages more quickly than the generic M6 layer it can signal it to the 
> M6
> layer so that it can react somehow

Ok, I am still worried over this hints thing...

>> More, if there is also a rerouting event causing
>> distribution of bad news, and perhaps a new set of locators, or the
>> signaling to move to new locators, this might trigger a "race-like"
>> condition, depending in what order the priorities are set and in which
>> order they arrive where, and then actually making the case worse - no?
>
> I guess that we should try to see if it is possible to design a 
> solution
> that a avoids that.

Oh, I think it is. I just think we need to keep that in mind.

>>
>> "restoration" time is due to these X factors, they can be influenced 
>> by
>> this - but they are not an issue per se for the multi6 layer.
>
> Yes, but IMHO we should define those potential hints and also define 
> the
> interaction among them. Do you agree?

Yes. But I am not convinced that is where we should start.

- - kurtis -