Subject: [nemo] Multihoming Issues To be Presented Wednesday

From: Chan-Wah NG <[email-masked]>
Date: Tue, 09 Nov 2004 22:26:11 +0800

Hello All,

During the Multihoming slot on Wednesday afternoon, we will be polling
the room to check what are the problems listed in the draft that the WG
feels should be worked on, either by some other WG, or by the NEMO WG if
the problem is is directly related to the NEMO Charter.

So, it would be much more productive if folks would come prepared (that
is, read the draft, esp section 4).

Thanks,

/rgds
/cwng

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 09 Nov 2004 11:45:47 -0800

> the problem is is directly related to the NEMO Charter.

I'd be curious what folks think is the relationship between Nemo 
specific multihoming and the work being done in the MULTI6 WG.
It seems like the latter would could be layered on top of Nemo basic 
support and provide e2e redundant paths.

    Erik

---

From: Christophe Janneteau <[email-masked]>
Date: Wed, 10 Nov 2004 05:10:08 +0100

Hi Chan-Wah, and co-authors,

Thanks for the updated draft-ietf-nemo-multihoming-issues-01.txt. I find 
the classification useful. Here are some comments:

In section 2.1  (1,1,1): Single MR, Single HA, Single MNP
---------------------------------------------------------

The terminology draft (5.2) defines a multihomed MR as:

   "a router is
    multihomed when it has several IPv6 addresses to choose between, i.e.
    in the following cases when the MR is either:

       multi-prefixed: multiple prefixes are advertised on the link(s) a
       MR's egress interface is attached to, or.

       multi-interfaced: the MR has multiple egress interfaces to choose
       between, on the same link or not."

While section 2 of multihoming draft defines a multihomed MR as:

   "the MR may be multihomed if either (i) multiple
    prefixes are advertised on the home link, (ii) multiple prefixes are
    advertised on the visited link, or (iii) the MR is equipped with
    multiple interfaces.  In such a case, the MR would have a combination
    of Home Address / Care-of Address pairs."

==> The two defition differs. There may be a need to update the 
terminology draft to cover (i) as well.

In addition 2.1 reads:

   "A bi-directional tunnel may be established between each pair of Home
    Address / Care-of address if the MR is itself multihomed."

This sentence is confusing in the case multiple prefixes are advertised 
on the visited link but only one is advertised on the home link. Indeed:
    - MR would be multihomed according to the definition, and has 
multiple CoAs, but
    - only 1 tunnel can be established at a time, between the unique HoA 
and the selected CoA; because NEMO/MIP does not allow multiple CoAs to 
be associated with a same HoA AFAIK.

==> Sentence could be replaced with "A bi-directional tunnel may be 
established for each Home Address of the MR if multiple prefixes are 
advertised one the MR's home link."

In 2.7  (n,n,1): Multiple MRs, Multiple HAs, Single MNP
--------------------------------------------------------
    " No assumptions are made on whether or not the HAs
    belongs to the same administrative domain.  However, the MRs
    advertises the same MNP."

==> How can HAs from different administrative domains advertise routes 
to the same MNP? Seems to me that the only possible scenario is the one 
where all HAs are in the same domain. This is ackwonledged in 4.6 and 
4.11 but there may be a need for a ref to these sections in 2.7, to 
avoid mislead the reader.

In 3.1:
--------

For case "z=N:  Multihomed mobile networks with multiple MNPs":

    "Example: a car with a prefix taken from home (personal traffic
          transit on this prefix and is paid by the owner) and one that
          belongs to the car manufacturer (maintenance traffic is paid by
          the car-manufacturer).  This will typically be a (1,1,n)."

==> In general I assume car manufacturer and personal ISP would be 
different administrative domains, hence with different HAs. So the 
example seems more like an (1,n,n) to me.

In 4.7 MR Synchronization
---------------------------
    "In the (n,*,n) case, a MR relaying the advertisement of the MNP
       from another failed MR."

==> Do we really want that? Would it not be better to just let the 
addresses die?

In 4.12 Nested Mobile Networks
-------------------------------
"As such, a solution to prevent an infinite loop must be provided."
==> An infinite loop of what? Motivation is unclear IMHO.

In A.1.2  Subscriber/Provider Model
-------------------------------------

  "For the S/mP model, the following configurations are likely to be
    deployed:

    o  S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 
MNP"

==> Same comment as for 2.7: 4.6 and 4.11 highlight issues of such 
configurations, which makes them _not_ likely to be deployed IMHO.

In A.2  Problem-Oriented Approach
----------------------------------
    "o  Shinkansen: Single MNP Advertised by MR(s)

       This is the case where one MNP is announced by different MRs.
       This is equivalent to the case of z=n, i.e.  the (1,*,n) mobile
       network."

==> Should be (n,*,1), right?

Christophe.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 Nov 2004 13:28:49 +0100

Hi Erik,

> support and provide e2e redundant paths.

I guess that it depends on the partiuclar nemo multihoming scenario 
that you are considering...

I mean, in multi6 the basic assumption is that there are multiple 
prefixes in the multihomed site and that those are related to one of 
the exits.
I guess that this is true for some of the cases of nemo multihoming but 
not in other cases (for instance imagine a nemo with two MR and a 
single HA, and a single prefix)

So in the case where there are multiple prefixes available and this 
prefixes belong to different HAs then, i guess that the multi6 solution 
would do the trick, but in the other hand, if you have a single prefix 
in the nemo, or when both HAs can route any of the available prefixes 
(for instance they are both connected to the same HA) then i am not 
sure multi6 protocol will be that useful

I guess that there are two main reasosn for the differences between 
multi6 and nemo multihoming i.e.:
- the support for ubiquity (this is well stated in the draft BTW). i 
mean in nemo multihoming, it is very likely that the direct link of the 
nemo is the one that will fail (not becuase of a failure, but because 
different media are available at different moments) so i guess that it 
would make sense to optimize this particular case, and that there will 
be configurations that mistly wnat to obtain this particular feature.
- the need for policing is probably much more significant (Hesham 
brought this up a long time ago AFAICT) if you have the typical example 
of a GPRS and a WLAN connections, it is probably not the same to send 
stuff on either one. Moreover, you probably don't want to fall back all 
your communications to the WLAN if the GPRS connection fails (for 
example) I guess that in the multi6 scenario it is not so common to see 
such big differences in capacity and charging, so the stress in these 
issues is probably very different

I guess that the first step would be to identify the different nemo 
multihoming scenarios and see which one of them are properly served 
with a multi6 solution...

regards, marcelo

>    Erik
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2004 17:46:56 -0800

marcelo bagnulo braun wrote:
> I guess that it depends on the partiuclar nemo multihoming scenario that 
> you are considering...
> 
> prefixes in the multihomed site and that those are related to one of the 
> exits.

Not necessarily "exits", but that there is some likelihood that some
failures would affect the routing to one prefix but not the other.

> not in other cases (for instance imagine a nemo with two MR and a single 
> HA, and a single prefix)

In that case you have limited diversity both between the CN and HA, and
the MR and HA, since they all 1) need to get to a single HA and 2) the
HA has only one address.

> (for instance they are both connected to the same HA) then i am not sure 
> multi6 protocol will be that useful

Yes, I understand one can make a reasonable case for HA-MR redundant 
paths using some MIP/Nemo specific technology.
But that doesn't translate to applying the same mechanism to CN-MR 
redundant paths when Nemo RO is done; in that case I think one should 
just use Multi6.

> be configurations that mistly wnat to obtain this particular feature.

Yes, but when doing RO (to an unmodified MIPv6 CN) you would then loose 
that feature. Thus bidirectional tunneling will have better availability 
that a route optimized path.

> issues is probably very different

And how is this Nemo specific?
With a vanilla IPv4 laptop with WLAN+GPRS I have exactly the same issue.

> multihoming scenarios and see which one of them are properly served with 
> a multi6 solution...

That would make sense.

Thanks,
     Erik

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 11 Nov 2004 11:22:33 +0900

Thanks Christophe, I will fix that and make the drafts consistent.
Thierry.

On Wed, 10 Nov 2004 05:10:08 +0100
Christophe Janneteau <[email-masked]> wrote:

> > Thanks

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 11 Nov 2004 12:23:10 +0900

> the MR and HA, since they all 1) need to get to a single HA and 2) the

This is right, but in mobility environment, what matters is that access
to the fixed network is not reliable, whereas HA is one order of
magnitude more reliable.

> redundant paths when Nemo RO is done; in that case I think one should 

I agree with you (provided we do decide to work on RO ;-). However, for
some of the cases, what would matter the most is the ability to register
multiple CoAs or multiple MNPs with a HA, and in this case MIP/NEMO are
rather good candidates to make it work.

> With a vanilla IPv4 laptop with WLAN+GPRS I have exactly the same issue.

But if MR has multiple egress interfaces, it also has multiple CoAs
which need to be registered with the HA. This is rather NEMO/MIP
specific. May be more MIP than NEMO. That's what I want to talk about
tomorrow in the MIP6 WG (i will speak instead of Nicolas Montavont who
is not here). 

> > multihoming scenarios and see which one of them are properly served with 

I think there is rough consensus on such an approach. I haven't seen
anyone defending the opposite approach.

Thierry.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2004 19:32:45 -0800

> anyone defending the opposite approach.

Looking at *nemo* drafts that talk about multihoming I find one sentence 
mentioning multi6, which is what lead me to think that things are a bit 
too disconnected.

    Erik

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 11 Nov 2004 22:15:17 +0800

Hello Erik, (and Thierry)

Mind if I hop on to the discussion?

> mentioning multi6, which is what lead me to think that things are a bit 

Hmm...  can't interpret from your above sentence whether you feel that
multi6 is mentioned too few or too many times.

I tend to agree that we have not actually sit down and inspect carefully
which problem falls into different working groups domain (multi6, mipv6,
etc).  That will be the one of main item on my plans for -02.  I tend to
agree with Marcelo that we can't simple classify each sub-section of
section 4 as a domain of XXX WG, so most likely there would need to be a
finer grain of partitioning.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 Nov 2004 16:36:31 +0100

El 11/11/2004, a las 4:32, Erik Nordmark escribió:

> Looking at *nemo* drafts that talk about multihoming I find one 
> sentence mentioning multi6, which is what lead me to think that things 
> are a bit too disconnected.
>

yep, but until now, there wasn't remotely clear how a multi6 solution 
would be, so i guess the lack of multi6 reference cannot be blamed.
OTOH, now that we have a hint of how a multi6 solution may be, we can 
move forward into this multi6-nemo integration i guess, so  we should 
do this now that is more possible

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Nov 2004 12:01:17 -0800

> multi6 is mentioned too few or too many times.

It isn't the mention that is needed; it is the work to figure out the 
relationship between Nemo-specific multihoming support and generic 
multi6 support.

    Erik

---

From: Chan-Wah NG <[email-masked]>
Date: Fri, 12 Nov 2004 05:35:29 +0800

> relationship between Nemo-specific multihoming support and generic 

Yep, then we are in agreement here -- that's precisely what I intend to
do for -02.

/rgds
/cwng

---

From: "Eun Kyoung PAIK" <[email-masked]>
Date: Sat, 13 Nov 2004 01:36:01 +0900

Hi Christophe,

Thank you for your comments.
Please see in line comments.
> In section 2.1  (1,1,1): Single MR, Single HA, Single MNP

Actually, the meaning of each definition was the same, e.g. (i) and (ii)
fall into 'multi-prefixed' case since MR's egress interface can attach to
home/visited link.
If readers are confusing, we can re-write them in the same manner.

> be associated with a same HoA AFAIK.

That's why we illustrate it as one of issues in this draft so that we need
a/some solution(s) for it. :-)

> In 2.7  (n,n,1): Multiple MRs, Multiple HAs, Single MNP

Make sense.
Usually, one scenario does not fall into only one configuration.

> In 4.7 MR Synchronization

We think it is one of the benefits of multihoming.

> In 4.12 Nested Mobile Networks

An infinite loop of associating with mobile routers.

> In A.1.2  Subscriber/Provider Model

That's why we move it to the appendix. We want hear from WG and reach a
consensus which scenario is more likely being deployed.

> In A.2  Problem-Oriented Approach

Right. :-)

Regards,
Eun