Subject: [nemo] merged multihoming draft

From: Eun Kyoung Paik <[email-masked]>
Date: Mon, 23 Feb 2004 00:46:18 +0900

Hi all,

As the result of last IETF meeting, we merged three of
multihoming related drafts into one.

http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt 

Your comments on this draft are welcome.

Regards,
Eun Kyoung

---

From: Chan-Wah NG <[email-masked]>
Date: Mon, 23 Feb 2004 10:44:53 +0800

> Your comments on this draft are welcome.

Thank you, Eun-Kyoung.  

Like to take this opportunity to describe more on the changes to this
draft.

Firstly, Eun-Kyoung's problem statement draft is merged to this draft,
so she won't be releasing an update of her draft.

Secondly, we decided to combine effort with people working on
multihoming issues in Mobile IPv6.  For this purpose, we released
draft-multihoming-generic-goals-and-benefits-00.txt.  This draft
contains general description of multihoming, and listed the benefits of
multihoming.  draft-ng-nemo-multihoming-issues-04.txt uses this generic
draft as a baseline, and discusses the NEMO specific issues.

Thirdly, we tried to shorten the draft.  Well, we managed to shorten the
main text of the draft, by moving some sections to the appendix.  We
felt that it is not necessary to list 3 different approaches to the
taxonomy, and the WG largely is comfortable with the {w,x,y} (now called
{x,y,z}) approach.

Our next task is to focus on the scenario that is relevant to NEMO, and
hopefully the next release of this draft will be a WG document.

As always, comments and bashing of this drafts are always welcomed.

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Mon, 23 Feb 2004 10:44:53 +0800

Thank you, Eun-Kyoung.  

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 23 Feb 2004 15:33:05 +0900

Dear all,

By the way, the generic draft Goals and Benefits of Multihoming" has
been badly referenced into draft
draft-ng-nemo-multihoming-issues-03.txt. Reference 6 should read:

   [6]  Ernst, T., "Goals and Benefits of Multihoming",
        draft-multihoming-generic-goals-and-benefits-00 (work in progress), 
        February 2004.

I recommend people interested in the multihoming discussion to read this
draft as it will serve as a basement to motivate the needs and benefits
for multihoming in NEMO. The draft lists a number of scenarios.  Some
scenarios apply to fixed nodes, while other apply to mobile nodes, or
fixed nodes in mobile networks, but usually all scenarios could apply to
either cases.  This is the reason why the document has not been
submitted to a particular WG.

As a result of this generic draft, all non NEMO-issues are expected to
be moved out of draft-ng-nemo-multihoming-issues; some non NEMO-specific
paragraphs may remain but will be removed as we improve both documents. 

Thierry.

On Mon, 23 Feb 2004 10:44:53 +0800

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 23 Feb 2004 15:33:05 +0900

Dear all,

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 23 Feb 2004 15:38:20 +0900

Dear all again,

> hopefully the next release of this draft will be a WG document.

Another point: I would like to raise this to the attention of the
working group. Now than multihoming drafts have been merged, we would
like to decide if the document as it is now corresponds to the needs of
the NEMO WG. If yes, it should become a WG document as we have said
in Minneapolis. 

We also expect feedback from the WG concerning the structure and content
of the document:
- any specific section you may consider useless
- any specific section you may consider missing
- etc.

Thank you,
Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 23 Feb 2004 15:38:20 +0900

Dear all again,

Thank you,
Thierry.

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 24 Feb 2004 13:16:03 +0100

Hi Thierry,

> the NEMO WG. If yes, it should become a WG document as we have said

IMO this I-D should be made a WG doc.

I have a comment on chapter 5:

>    o  (N,1,N) Mobile Network
> 
>       The (N,1,N) mobile network has multiple active egress mobile
>       routers registering to the same home-agent, and advertising
>       multiple prefixes. If a mobile router is advertising more than one
>       prefix, we have the same problem as (1,1,N) as in how to register
>       more than one NEMO-prefix to the same home-agent.
> 
>       On the other hand, if each mobile router take cares of a separate
>       (and only one) NEMO-prefix, then there should not be any
>       NEMO-specific problem.

As I remember Erik once said to me in an earlier NEMO discussion: we 
don't want to go down the second alternative. MRs should not advertise 
different prefixes to the same link - they must advertise the same 
prefix set (or otherwise be coordinated and able to route traffic on 
behalf of each other). For an MNN, each MR is a just default router and 
all default routers must be able to route all traffic. We don't want to 
put such requirements on the MNNs to map each prefix to a specific exit 
router and remembering to use the correct source address when sending to 
a specific default router.

Such a general host behaviour may be required for multihoming to work in 
IPv6 some day, but we have not reached that point yet.

/Mattias

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 24 Feb 2004 13:16:03 +0100

Hi Thierry,

/Mattias

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 25 Feb 2004 14:34:39 +0900

Hi Mattias,

> IMO this I-D should be made a WG doc.

With the content as is ?

> IPv6 some day, but we have not reached that point yet.

IMHO, it depends on what scenarios we consider useful or not (this is
unfortunately still an open question). Then, based on the conclusion of
what scenerios are useful, we may prioritize the work if one particular
scenario is cumbersome to handle. But I wouldn't decide not to allow  a
scenario just based on the fact it may be difficult to handle. The
question is "will people want such kind of configuration". My personal
opinion is that they would, and as such we shouldn't disallow it.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 25 Feb 2004 14:34:39 +0900

Hi Mattias,

With the content as is ?

Thierry.

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 25 Feb 2004 14:35:41 +0800

Hello Mattias

> IMO this I-D should be made a WG doc.

Thank you for supporting this ;)

> a specific default router.

Alternatively, the routers can silently re-distribute these packets
among themselves, thus shifting the burden of any requirements to the
mobile routers instead.

> IPv6 some day, but we have not reached that point yet.

I am more towards agreeing with Thierry on this.  We would have to
determine the requirements based on the benefits it brings.  If the
benefits is great enough, then we shall strive to solve the problem.

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 25 Feb 2004 14:35:41 +0800

Hello Mattias

/rgds
/cwng

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 25 Feb 2004 10:26:59 +0100

>>IMO this I-D should be made a WG doc.

Why not? What do others think? We need a doc about MH for NEMO.

> opinion is that they would, and as such we shouldn't disallow it.

Thierry, Chan-Wah [I answer you both here],

It is a question on what entities should carry out the dirty work. 
Either the MRs or the MNNs.

To me it is important that legacy IPv6 hosts can still get connectivity 
in a moving network without having to implement new proposals such as 
draft-huitema-multi6-hosts-xx.

So what is most important: to support standard IPv6 hosts or to simplify 
the MR? It seems like in order to simplify the MR we are proposing to 
introduce a NEMO scenario that was considered "broken" in the IPv6 WG 
earlier. All routers on a link are equal, from the host's point of view! 
The ND model builds on that. I agree that we have arguments both in NEMO 
and in multi6 to question that model, but we do we want to change that 
model just to allow a variant of a scenario?

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 25 Feb 2004 10:26:59 +0100

/Mattias

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 25 Feb 2004 12:47:03 +0100

> Either the MRs or the MNNs.

Perhaps in the case of multiple prefixes, the dirty work has to be carried
by the Home Network Site Exit routers?

> draft-huitema-multi6-hosts-xx.

Fully agree with the first statement.
But Host centric (draft-huitema-multi6-hosts) approach allows exactly this
for multihomed network.

That is, that a regular IPv6 host is connected to the multihomed network and
still works properly.
Clearly, there some benefits, like preserving established communications
through outages, that it will not be able to obtain, but at least it will
work fine and its operation won't be disturbed because of multihoming.

> the MR?

I fully agree that standard IPv6 have to keep on working properly.
Perhaps they won't obtain all the multihoming benefits, though

> It seems like in order to simplify the MR we are proposing to

Well, again this IMHO is generic to multihoming and not specific to nemo.
I guess that if a hosts has to be updated to obtain full multihoming
benefits in a fixed network, it would be reasonable that it also has to be
updated in order to obtain multihoming benefits in nemo.

Regards, marcelo

> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has been
> sent to you in error, please notify the sender by replying to
> this transmission and delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and
> we only send and receive e-mails on the basis that we are not
> liable for any such corruption, interception, amendment,
> tampering or viruses or any consequences thereof.
>
>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 25 Feb 2004 12:47:03 +0100

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 25 Feb 2004 12:47:03 +0100

Hi Mattias,

> a specific default router.

Well, i wouldn't say that the MNN have to select the appropriate prefix in
order to send to a specific default router, but IMHO it is clear that in
order to deal with ingress filtering, the prefix included in the source
address will have to match with the selected ISP (if not the packet is
discarded)
So, IMHO not a specific prefix per default router but a prefix per isp.

One possible way to match a prefix with an isp could be to use a different
default route, but i don't really think that would be a good option, since
it would impose several restrictions on the topology, but this is still  on
discussion i guess.

So, i agree that a different prefix per default router doesn't seems
appealing for now at least, but something that allows to match a prefix with
an exit isp is required.

I have an additional question about this draft:

Why do you consider that a mobile network that has several prefixes is
multihomed.
I mean, i would say that a natural case for this is that the Home network is
multihomed, but not really the Mobile Network.
In this case, i guess that there is nothing NEMO specific, only that general
multi6 solutions have to be supported.

Am i missing something? ( i haven't been around for long, so i have missed
previous discussions on this topic)

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 25 Feb 2004 12:47:03 +0100

Hi Mattias,

Regards, marcelo

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 25 Feb 2004 15:43:33 +0100

Hi Marcelo,

> by the Home Network Site Exit routers?

Oh yes. I was thinking of scenario N,N,N where all MRs are very independent.

> work fine and its operation won't be disturbed because of multihoming.

Yes, that is a requirement. But the NEMO-MH here tries to take the 
requirements a step further than what multi6 does. If the MNN sends its 
traffic to the wrong default router/MR it will be dropped due to ingress 
filtering policies when checking the source address.

At least draft-huitema-multi6-hosts doesn't require legacy IPv6 hosts to 
have to send to the correct default router, because the sites are often 
arranged so that the hosts are not on the same link as the site exit 
routers. An intermediate router can inspect the source address and send 
it off to the right site exit router. If there is no intermediate 
router, then at least the site exit routers cooperate.

And this is not even a matter of multihoming to survive outages. The MNN 
won't be able to communicate unless it by luck selects the correct 
source address for the DR it has chosen.

> updated in order to obtain multihoming benefits in nemo.

As far as I know nobody will build a fixed network that is broken, 
meaning that router R1 advertises P1 only and R2 advertises P2 only and 
they only forward traffic using the respectively derived addresses. But 
this seems to me what we're suggesting for NEMO to do. And I don't 
support that idea.

IMHO this NEMO scenario breaks the ND model and general MH approaches 
don't do that.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 25 Feb 2004 15:43:33 +0100

Hi Marcelo,

/Mattias

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 25 Feb 2004 19:56:01 +0100

> filtering policies when checking the source address.

Well, i don't see any need for that. Moreover, i think this imposes
important requirements to the topology of the mobile network, I mean, if you
associate a prefix to a default router, you basically have to have two
different disjoint paths to each one of the prefix, i guess, without any
common router.
so i guess i agree with you, i don't think that a prefix should be linked to
a default router.
I would consider to work in the general case, where a default router can
handle all the prefixes.

> it off to the right site exit router.

that is one of the options.
The other option is that the host itsef knows about which exit router to
use.
The other option is what you mention next, i.e. cooperation between exit
routers.

> If there is no intermediate

This is also the case in any multihomed network, mobile or fixed, since
iwhen there are multiple prefixes available, it has to select the one that
matches with the ISP through which the packet will be carried.

that is why i was asking why do you think that the multiple prefix case has
something NEMO specific.

I would say that fixed multihoming solutions should deal with this case,
just as any other part of the Home Network, (which is actually the
multihomed network in this case, not the mobile network, as far as i can
see)

> this seems to me what we're suggesting for NEMO to do. And I don't

i agree with your pov (i think)

But a similar problems remain in multihomed networks in general which is
related to ingress filtering and how to select the apropriate source address
when the hosts have multiple addresses. But again, this is not NEMO
specific, as far as i can see.

regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 25 Feb 2004 19:56:01 +0100

regards, marcelo

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 26 Feb 2004 10:47:38 +0800

Hello Marcelo,

> Why do you consider that a mobile network that has several prefixes is

In this case, it is not the mobile network that is multihomed, but the
MNN is multihomed.  And MR shouldn't prevent it (as per
draft-ietf-nemo-requirements)

> multi6 solutions have to be supported.

In a fixed network, as you or Mattias mentioned in an earlier post, no
administrator would be crazy enough to build a network, configured it
with multiple prefixes but have each router handles only one prefix and
discards packets with source addresses from the other prefixes.

In NEMO, this scenario becomes possible.  Consider two NEMOs coming
together, or a NEMO with two MRs, each subscribing to services from
different ISPs.

It may not be NEMO-specific, depending on your interpretation of
"NEMO-specific".  But IMHO its clear that NEMO make the problem more
"real".

The draft's objective to raise the readers' awareness to this kind of
problems.  Having done that, if the WG feels that it is worthwhile to
solve it here, we then discuss how to solve it.  If the WG feels that
this is better left until a candidate solution emerged from multi6, we
mention this is the document, and points interested implementors to
consider the solutions coming out of the multi6 group.

Does this make sense?

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 26 Feb 2004 10:47:38 +0800

Hello Marcelo,

Does this make sense?

/rgds
/cwng

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 26 Feb 2004 10:47:13 +0100

> multihomed network in this case, not the mobile network, as far as i can

Yes, sorry, for case N,1,N I fully agree. It is the home network that is 
multihomed and it will ultimately have to deal with this. The MRs can 
get away with their behaviour.

>    o  (N,N,N) Mobile Network
> 
>       The (N,N,N) mobile network has multiple mobile routers,
>       registering to multiple home-agents and advertising prefixes.
>       This may be a case of multiple non-multihomed network superimposed
>       together, i.e. each mobile router take cares of one prefix, and
>       register to separate home agents.

It is the N, N, N (alternative 1, see above) that I've drifted into. 
This is the case where NEMO introduces more requirements on hosts than 
what ND does.

Look at this case from the MNN's point of view. It hears two routers 
(MRs) advertising themselves as capable of routing all traffic (i.e. 
stating that they are default routers). To follow the example in 
draft-huitema-multi6-hosts section 3.3 we have MNN as X with two 
addresses A:X and B:X. It wants to communicate with Y both available at 
C:Y and D:Y. If X can't be allowed to establish a communication between 
any of the four combinations {ax-cy, bx-cy, ax-dy, bx-dy} then something 
is seriously wrong with the configuration of the network. As far as X 
goes it MUST NOT have to know that site-exit router R-A only accepts 
packets with source address with prefix A. Why is a default router 
claiming that it can route all traffic only to drop some of it the next 
minute?

None of the cases that I've seen in IPv6 and multi6 claim that X must 
select the correct default router in order to communicate. Yes, the 
packet must have the right source address to be carried over the ISP's 
network, but that is something the routers have to deal with. Yes, ISP B 
may be "better" in some sense (and sometimes routers only route on 
destination addresses, which is bad in this case), but unless X knows 
that, how can it know what source address to use for its default traffic?

To me it is a serious mistake by a router to claim it is a default 
router if it really isn't. Until the hosts get more information about 
ISP preferences and ingress filtering policies, the router must deal 
with this mess.

So, yes, to answer your question: NEMO case N,N,N introduces a (broken) 
network configuration previously unknown to/unsupported by IPv6 and multi6.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 26 Feb 2004 10:47:13 +0100

/Mattias

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 26 Feb 2004 17:44:36 +0900

> a specific default router.

Just one more detail: the fact that multiple prefixes are advertised on
the mobile network's egreess interface doesn't preclude that multiple
NEMO-prefixes will be advertised down the mobile network. So, I guess
there are several interpretations of this case. The sentence starting
with 'since ...' in section 2.6 should be clarified (probably adding
'may be advertised'.

Not allowing to advertise multiple prefixes may be one recommendation,
but then, it means we have to design a protocol to synchronize MRs. On
the other hand, if we allow the advertisement of multiple NEMO-prefixes,
MNNs have to select their source address.

What I said is of course orthogonal with multiple NEMO-prefix
registration with the HA.

> IPv6 some day, but we have not reached that point yet.

Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 26 Feb 2004 18:00:43 +0900

Hi,

> by the Home Network Site Exit routers?

Can we be more specific with 'dirty work' ? 

> updated in order to obtain multihoming benefits in nemo.

Fully agree. 

What is specific to NEMO WG is the ability to register several
NEMO-prefixes with the HA, if we need to.

Obtaining all potential benefits of multihoming is not a NEMO task. It
should be carried on by another WG which doesn't focus on mobility. On
the other hand, our goal is to document the issues; I suspect actions
will have been taken by other WGs based on the conclusions of the NEMO
Multihoming Pb Statement WG document.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 26 Feb 2004 18:05:57 +0900

Hi Marcelo,

This is may be a definition issue ?  I agree that taking the definition
to the words may tell that any host in the Internet is multihomed since
border routers usually are.  I would indeed say that the MRs might be
multihoming, but the MNNs might not be.

I would appreciate if you could read through the multihoming section in
draft-ietf-nemo-terminology and comment on the definition. That would be
helpful for us.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 26 Feb 2004 17:52:59 +0900

Hi Mattias,

> Either the MRs or the MNNs.

It's not the same dirty work. 

On the MR, it's about registering several prefixes, or synchronisation

On the MNN, it's about source address selection. Any host is considered
to implement some source address selection mechanism. Or, is there
anything else dirty to do ?

> model just to allow a variant of a scenario?

I personaly wish to support standard IPv6 hosts. But I've never heard
that advertising multiple prefixes would break the model. Do you have
any reference to a possible decision made by the IPv6 WG to disallow
such scenario ? Any document where this is documented ?

Thierry

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:05 +0100

> NEMO-prefixes will be advertised down the mobile network.

But if you do that, the isp associated with the prefix that you are not
announcing won't be used by the MNN (unless you rewrite the addresses at the
exit or something like this) So you reduce the case to a single homed
network.

[...]

> Not allowing to advertise multiple prefixes may be one recommendation,

I don't think so, see above

> but then, it means we have to design a protocol to synchronize MRs.

I guess that you will need more than that, as stated above.

> On

Yes, like in most of the multihomed site solutions.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:02 +0100

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En nombre de Thierry
> Ernst
> Enviado el: jueves, 26 de febrero de 2004 10:01
> Para: [email-masked]
> CC: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Asunto: Re: [nemo] merged multihoming draft
>
>
>
>
> Hi,
>

Well,a possibility to solve this problem is to create a mesh of tunnels
between the exit router, so that they forward the packet to the exit isp
router that it is connected to the ISP that matches the source address
included in the packet

> Multihoming Pb Statement WG document.

I agree.
I guess that the problem here is to identify which are the NEMO specific
issues that are not present in the general case of a multihomed site.

See my answer to Mattias w.r.t. this

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:04 +0100

> draft-ietf-nemo-requirements)

I don't really agree with this definition, see coments about the terminology
draft

> Does this make sense?

Yes.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:23:57 +0100

Hi Thierry,

> multihoming, but the MNNs might not be.

Yes, agree with you. see my comments below.

> draft-ietf-nemo-terminology and comment on the definition. That would be

Comments about the terminology draft:

Section 3.4: i would include the definition of Mobile router, even if it
would mean to copy it from draft-ietf-seambody-terminology, so that the
draft it is self-contained. I mean, if it is not included, the draft is
harder to read, since you have to check with the other document.

Section 3.5 same comment than 3.4

Section 3.6 same comment than 3.4

Section 3.9 same comment than 3.4

Section 3.11 I think that this definition is confusing (as it was expressed
by the visiting nodes thread recently IMHO) consider the case of a node that
attaches the NEMO using dhcp because it just wants connectivity. This is not
a VMN, it is just a LFN in this context. IMHO, the definition included in
section 2. is much better since it reads:
"  fixed nodes(nodes unable to change their point of attachment
   while maintaining ongoing sessions),"
this is IMHO the appropriate definition of LFN (and it is already included
in the draft :-)

Section 3.12 This definition is also confusing IMHO, since it includes as a
mobile node, a node accessing through dhcp. There is also in Section 2 a
more appropriate definition of mobile node:
"  mobile nodes (nodes able to change their point of attachment while
   maintaining ongoing sessions)."

I would add that a LMN has it HoA that belongs to the MNP

Section 3.13 This is also confusing IMHO. I would use the same definition
proposed above for LMN but changing that the HoA does not belong to the MNP

Section 3.17 does the CN support MIPv6 RO or not or it is indifferent?

Section 5.1

If multiaddressed nodes are considered multihomed, then, as you already
noted, all nodes are multihomed, at least in IPv6 because of link local
addresses. IMHO, including multiaddressed nodes as they are into the
multihomed node definition, greatly reduces the meaning of the expression,
since all the nodes are now multihomed, so multihomed node is synonymous of
node, at that is not what we want i guess. We could add an additional
condition, requiring that both addresses are global, but again, both
addresses could belong to the same site (for whatever reason) and this is
not what multihomed means. OTOH, i do understand that a node that has
obtained addresses from different ISP, these addresses may have different
properties, and selecting one or other may imply different services. This is
also true in the case of a mobile node that has the HoA and the CoA, in this
case using one or the other impacts in the characteristics of the packet
flow.
However, i think that the first case, it is a node within a multihomed site
i.e. a multihomed site node, if you wish, and we could define it as this
(Multihomed Network node: a node with multiple addresses, from different
providers) and the second case it is just a mobile node. So, in order to
provide a definition that matches the expected meaning  (at least the
meaning that i expect :-) of a multihomed node, IMHO the multiaddress case
should be omitted.

Section 5.1

delete the multi-sited case, since site locals are being deprecated

Section 5.2

Again, i would not include the multiaddressed case as it is, since it means
that because of the link local case all routers are multihomed and that some
degenerated cases like the ones mentioned above are included as multihomed
MR. So, i would omit this case. However, i would include in the multiple
interfaces case the case of a MR with multiple tunnel interfaces. This is
particularly true IMHO for the multihomed MR, when it has two different HA
and two different tunnels, since it has two different accesses to the
internet, one per HA.

Section 5.3

Here the definitions don't really match, IMHO

I mean it is stated that the NEMO is multihomed if it has more than one
active interface connected to the internet (which i agree)
But then, it states that this happens when the MR is multihomed. The problem
here is that if the MR is simply multiaddresses, it doesn't have multiple
egress interfaces, so both definitions don't match. Again, i would remove
the multiaddressed case as it is currently stated.

Perhaps it would be interesting to include the definition of a
multiconnected NEMO, which is the case that the NEMO has multiple
connections with its home network, but it doesn't have multiple ISPs.

Section 5.4

Same than the multihomed NEMO case, a multihomed MR as stated may not have
multiple active egress interfaces.

Mostly editorial:

Section 3 states that:
"  LFN, VMN and LMN. The distinction is a property of how different
   types of nodes can move in the topology and is necessary to discuss
   issues related to mobility management and access control, but does
   not preclude that mobility should be handled differently."

I don't understand the meaning of the last sentence. I mean, what mobility
are you referring to, to network mobility or to host mobility. If it is the
last,
i don't understand what do you say "preclude", wouldn't have to be changed
to another verb, like "imply"

Section 3.3 s/DEPRECIATED/DEPRECATED
                    ^
Section 3.3 add a " to the second MONET

Section 3.7 NEMO-Prefix (MNP) the acronym doesn't match the meaning. Include
Mobile Network Prefix

Section 3.14 NEMO-enabled (NEMO-node)
                   add   ^ "node"
Section 4.5
s/depreciated/deprecated

Section 5.5

remove the 1 in NEMO-11

Section 6.1

It reads "It could be achieved using Mobile IPv6"

I would rephrase it to "It can be achieved using Mobile IP or other mobility
support mechanism" because in the way that it is stated to me it seems that
perhaps MIPv6 doesn't achieve mobility :-)

Section 6.3

It reads:

"  NEMO Basic Support is a solution to preserve session continuity by
   means of bidirectional tunneling much like what is done using [1] for
   mobile nodes."

[1] also specifies RO for mobile nodes, so i would add a "when RO is not
used" at the end.

Section References

split into Normative references

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:05 +0100

[...]

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:02 +0100

I agree.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:06 +0100

> get away with their behaviour.

So why don't we just split these two different cases:

  there are four different situations to be considered of NEMO with multiple
  prefixes, according to the draft:
  (sorry that i dont use the (x,y,z) notation, i am still getting used to
it)
  Multiple prefixes with single home address and single MR
  Multiple prefixes with multiple home address and single MR
  Multiple prefixes with single home address and multiple MR
  Multiple prefixes with multiple home address and multiple MR

  IMHO, the first case and the third case are not about a multihomed NEMO
  but about a multihomed Home network
  I agree that the second and the fourth case can be about a multihomed nemo

> claiming that it can route all traffic only to drop some of it the next

Well, this is the site exit issue, decribedin the draft and it is common to
all multihomed sites that have multiple prefixes. This is not specific to
NEMO

> select the correct default router in order to communicate.

Well, i would state it otherwise.
IMHO it is important that any multihoming solution supports "legacy" hosts
that don't implement new mechanisms.
So, i agree with you, and again this is common to any multihomed site

However, some optimizations may require that the host selects the apropriate
exit router or the apropriate prefix in order to reach a certain
destiantion, but these must be only optimizations, and they must preclude
the normal operation of legacy hosts.

> Yes, the

As mentioned, legacy host has to be supported in a multihoming solution, see
RFC 3582

"3.2.3.  Impact on Hosts

   The solution should not destroy IPv6 connectivity for a legacy host
   implementing RFC 3513 [3], RFC 2460 [4], 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."

> ISP preferences and ingress filtering policies, the router must deal

I fully agree with you

> network configuration previously unknown to/unsupported by IPv6

Here is where we disagree :-)

This is exactly the same situation than in any multihomed site that
announces multiple prefixes.
A multihoming solution has to provide a solution for this, fulfilling the
requirement to honor legacy hosts as you require.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:04 +0100

Yes.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:24:06 +0100

"3.2.3.  Impact on Hosts

I fully agree with you

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 29 Feb 2004 01:23:57 +0100

Hi Thierry,

Section 5.1

Section 5.1

Section 5.2

Section 5.3

Section 5.4

Mostly editorial:

Section 3 states that:

Section 5.5

remove the 1 in NEMO-11

Section 6.1

Section 6.3

It reads:

Section References

---

From: "S. Felix Wu" <[email-masked]>
Date: Sun, 29 Feb 2004 00:01:40 -0800

The merged draft is a very good step to comsolidate various
interests in multi-homing NEMO. Thanks very much.

After reading the draft, I have one comment regarding:

 > 2.4 (1,N,N): Single MR, Multiple HAs, Multiple Prefixes
 >
 >   The (1,n,n) mobile network has only one mobile router.  However, the
 >   mobile router advertises more than one NEMO-prefix, and also
 >   associates to multiple home agents at the same time, possibly one
 >   home agent per home address.  No assumptions is made on whether or
 >   not the home agents belongs to the same administrative domain.

and,

 > 5. Evaluation of Basic NEMO Solution
 > ....
 >   o  (1,N,N) Mobile Network
 >      The (1,N,N) mobile network has one mobile router registering to
 >      multiple home agents multiple NEMO-prefixes.The same question of
 >      whether the same home-address can be simultaneously registered to
 >      multiple home agents.

It seems to me that, from the above segments of text in the draft,
it is not clear whether different prefixes under the (1,N,N) and
maybe (N,N,N) cases should be registered to different HAs.

My concern is that this capability seems to me a key motivation to
have multi-homing. I.e., when one of the N HA's is down, any CN in
the public Internet, can still access the MN via other HAs.

But, of course, we will get our routing table larger and larger...

I heard a proposal (I forgot the source) that each MNN will have
multiple IP addresses (so it will have one address in each prefix
in this particular multihoming NEMO), and it is the responsibility
of the CN to decide "which IP address to use to communicate with
the MNN". Assuming that the CNN will be able to use DNS-like or
other host identities to find out this multi-address binding.
(may this is from the Multi6 working group).

Certainly, under this proposal, we don't need to register different
prefixes to different HAs. But, otherwise, it seems to me that this
feature is very useful.

-Felix
-- 
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu                           [email-masked]
Associate Professor                      http://www.cs.ucdavis.edu/~wu
Computer Science Department                     office: 1-530-754-7070
University of California at Davis               fax:    1-530-752-4767
----------------------------------------------------------------------

---

From: "S. Felix Wu" <[email-masked]>
Date: Sun, 29 Feb 2004 00:01:40 -0800

and,

-Felix