Subject: [nemo] Comments on draft-charbon-nemo-multihoming-evaluation

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 14:27:08 -0700

a very good and useful draft. thanks. 

I have some comments on the draft.

fault tolerance and policy as two categories makes a lot of
sense. I am not sure about the load sharing support. what
exactly do you gain by sharing load between the two egress
interfaces (assuming the MR has two egress interfaces)? do
you have a concrete example for this? you would always want 
use the high bandwidth link, right?

I strongly disagree with statements like

>       In this case the MR and the HA MUST use the two bi-directional
>       tunnels simultaneously.  

>          Thus the NEMO solution MUST manage network traffic
>          simultaneously through the several connection of a same MR.

it might be an attractive feature to have. but it is not
a MUST feature to have, IMO. especially when I dont see the 
need for it.

section 2.2

> 
>             A MR is multi-homed when it has simultaneously more than one
>             active connection to the Internet, [...]

and 

>             R12: The solution MUST function for multi-homed MR and
>             multi-homed mobile networks as defined in [NEMO-TERMS]).
>             Particularly:
> 
>                R12.1: The solution MUST function for multi-MR mobile
>                networks

does not lead you to

> 
>          Thus the NEMO solution MUST manage network traffic
>          simultaneously through the several connection of a same MR.

I dont know how you arrived at the above statement.

in case (0,1,0)

its a mess if the Home Agents belong to different 
administrative domains. I looked at the reference [11].
towards the end of section 5.1.2 in reference [11], I
see some text which says this kind of multi-homining
is rare. I think you should also say that this is rare
and is out of scope for NEMO. frankly, I think it is 
not worth solving.

in case (1,0,1) and case (1,1,1)

what if both prefixes are advertised by both Mobile 
Routers? is there any difference?

for both these cases, you have assumed that each Mobile
Router will advertise a different prefix (which is good
makes things simpler). but is this a valid assumption?

> 10. Conclusions
> 
>    In this draft, we explore the level of Multi-homing support available
>    in the NEMO Basic proposed solution with respect to Multi-homing
>    requirements, the main goal being:
> 
>    "Do not prevent Multi-homing configurations/benefits by the using of
>    NEMO Basic Support."
> 
>    and this goal is mainly respected.  

good to know that.

> However, based on our analysis,
>    we propose some improvements.

arent these improvements best handled by separate 
specifications?

> 
>    o Preference & Priority:
> 
>       Theses two informations permit to manage the sharing/the policy of
>       the Inbound traffic to the Mobile Network through several CoAs
>       and/or several HAs.
> 
>       Theses information could be added to the Prefix-BU, and the
>       proposed solution specify a field/an sub-option to permit some
>       implementation to provide this benefit; or specify in the next
>       release of NEMO protocol.
> 
>    o Multiple CoAs for the same MNP:
> 
>       The proposed solution doesn't have to specify anything one this
>       subject, just to support it.  But a paragraph on this purpose can
>       be helpful for implementation's developers.

can you suggest some text? it is not clear to me what you are
looking for. doesnt draft-wakikawa-mobileip-mutliplecoa-01.txt
provide a solution for this?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 16:40:25 -0700

> and is out of scope for NEMO. frankly, I think it is

I want to clarify something. having two Home Agents
in different administrative domains is okay if the MR
uses separate Mobile Network Prefixes with these two
Home Agents. and each prefix should be aggregated under
the respective Home Agents.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Jul 2003 16:40:25 -0700

Vijay

---

From: Julien Charbon <[email-masked]>
Date: Wed, 16 Jul 2003 16:38:34 +0900

Hi Vijay, Hi all,

On Fri, 11 Jul 2003 14:27:08 -0700

> a very good and useful draft. thanks. 

 Thanks to you.

> I dont know how you arrived at the above statement.

 Oups ! My mistake my reasoning should be:

,----[ draft-ietf-nemo-terminology-00, Section 5. ]
|  A MR is multihomed when it has simultaneously more than one active
|    connection to the Internet, that is when it is either:
| 
|    [...]
|
|    - multi-egress-interfaced MR: the MR has simultaneously
|      multiple active egress intefaces on the same link or not
`----

 with

,----[ draft-ietf-nemo-requirements-01, Section 5. ]
|  R12: The solution MUST function for multihomed MR and multihomed
|         mobile networks as defined in [NEMO-TERMS]). Particularly:
|
|     [...]
| 
|     R12.2: The solution MUST function for multi-egress
|            interfaces
`----

 Thus NEMO MUST function with a MR which as simultaneously multiple
active egress intefaces on the same link or not.

 Depending on the meaning of /function/ maybe my sentence is too
oriented Load-Sharing. I will change that.

> and is out of scope for NEMO. frankly, I think it is 

 Yes, you right. I just wanted to answer at the question "Is possible
that theses HAs can be in different AS?".

 Now I will put: "Yes, _BUT_ ..."

 And I will put a paragraph on "aggrated network prefix and multiple HAs",
because it's maybe a better solution.
 
> Routers? is there any difference?

 Yes, if both prefixes are managed by the both router you have the
same behavior than in: Case (0,0,1).

 (1,0,1) and (1,1,1) are interesting because they show how you can
lost the Faul-Tolerance with transparency benefits just by adding a
prefix, and because of Ingress Filtering.

> makes things simpler). but is this a valid assumption?

 Yes, I make this choice because I though about this scenario:

 In a car you have a MR with two egress interfaces: A GPRS and a Wi-Fi,
and because you don't find any provider which provide the both
connections, you have to take a contract in two different. And because
it's two differents ISPs, they delegate you two Mobile Network Prefix.

 And here you have the case (0,1,1), and if connections are too
differents like I don't know,... For example a satelite
bi-directionnal connection [big antenna for a car], and a Infra-Red,
you will need two differents MR. [Because difficult to find a MR
supporting the both connection]. Thus you find case (1,1,1).

 In more general way, ISP tend to propose "all in one" package thus:

  Pack "Internet-in-Car": Connection + MR + HA management.

 Thus you just have to put the MR in your car, link it to car
network, and.. It's ok. But all these comments are IMHO, because I'm
nor a car manufacturer, neither an ISP.

> arent these improvements best handled by separate 

 Hum, What did you think about ? [What kind of separate specifications
I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ?

> provide a solution for this?

 I was rough for keeping a maximum freedom about solution idea,
Wakikawa is one solution, but in mip6, thus maybe it should take a
long time to be accepted. IMHO. I think these points should be sharply
discuss at Vienna today, and after result of comment I will write some
text about solutions. [If NEMO deciced to not include any preference nor
priority field nor Interface ID for NEMO basic, maybe in the next version
of NEMO it will be OK].

 Thanks for these good comments.

                                 Best regards.

                                           -- Julien

---

From: Julien Charbon <[email-masked]>
Date: Wed, 16 Jul 2003 16:38:34 +0900

Hi Vijay, Hi all,

 Thanks to you.

 with

 

                                 Best regards.

                                           -- Julien

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 16 Jul 2003 17:42:41 +0900

> priority field nor Interface ID for NEMO basic, maybe in the next version

I don't think every MIP items takes a long time:-p

I submitted my draft to MIP6 WG, because the requirement is not only
from NEMO, but also from MIP.
I also prefer a common solution for NEMO and MIP.

I am always ready to discuss my draft in NEMO WG.

Our draft can be simply applied to NEMO basic support.
I will update the draft after the meeting. 
I personally got comments from MIP6 folks. 

regards
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 16 Jul 2003 17:42:41 +0900

regards
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jul 2003 11:42:24 -0700

> oriented Load-Sharing. I will change that.

okay. load sharing is a nice feature, but it shouldnt a 
MUST support for NEMO. it should be an optional mechanism.

> because it's maybe a better solution.

cool.

>  Yes, I make this choice because I though about this scenario:

good. I also like this assumption because it makes things
simpler. how about making this a requirement?

> I mean] ? Another Internet-Draft ? draft-ng-nemo-multihoming-issue ?

draft-nemo-multihoming-basic-support. (I even made it a
WG document :). the WG chairs have to decide on it. any 
extensions, improvements, I suggest, should go into this 
draft. the basic suport draft currently is short and 
simple. it would be easy to advance it.

> [If NEMO deciced to not include any preference nor

IMO, NEMO basic support should not include these because
they are specific to multi-homing. I prefer defining new
mobility options for this. you can have a Care-of Address
Preference option, Interface ID option or even a 
Multi-homing option in 
draft-nemo-multihoming-basic-support. I can help you with 
this.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jul 2003 11:42:24 -0700

cool.

Vijay

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 17 Jul 2003 17:17:42 +0900

> MUST support for NEMO. it should be an optional mechanism.

In draft-ietf-nemo-requirements we have:

 R18: The solution SHOULD preserve sessions established through
        another egress interface when one fails [PROPOSED BY EDITOR OF
        THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE
        MAILING LIST]

So far, I put "SHOULD". It may even by "MAY", or requirement could be
removed because it's not a NEMO issue. Thoughts on this are appreciated
to clarify the requirements draft.

> simple. it would be easy to advance it.

The decision doesn't belong to the chairs, but to the WG. Indeed, we
asked if the multihoming analysis should become a WG document: show of
hands is about +30 "YES", none "NO". I agree the basic support draft
should not speak about that  (but make sure it provides room for the
needed extensions, so we should be careful about this).

> draft-nemo-multihoming-basic-support. I can help you with 

This is a good direction, I think.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 17 Jul 2003 17:17:42 +0900

Thierry.

---

From: Chan-Wah Ng <[email-masked]>
Date: 17 Jul 2003 16:59:42 +0800

> to clarify the requirements draft.

I would say ts okay to be a SHOULD or a MAY, but it should remain.  It
may not seems like a NEMO issue, but you must consider that NEMO would
experience this problem more often then other multihomed networks.

But of-course, I may be biased! ;)

> needed extensions, so we should be careful about this).

I thank the WG for accepting it.  I will propose combining
draft-ng-multihoming-issues and draft-charbon-nemo-evaluation into a
single draft-ietf-nemo-multihoming-basic-support.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 17 Jul 2003 16:59:42 +0800

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Jul 2003 10:45:40 -0700

> to clarify the requirements draft.

arent we talking about two different things? I was talking
about load sharing requirement in draft-charbon which said
if the NEMO network has multiple egress interfaces, load
MUST be distributed among the different interfaces. I was
objecting to this MUST. infact I even said this is 
implementation specific.

R18 is about, if one egress interface fails, sessions 
SHOULD be preserved by switching to another interface.

IMHO, both should be a MAY. SHOULD is too strong for these
optional mechanisms.

> needed extensions, so we should be careful about this).

yes. I agree.

> This is a good direction, I think.

great.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Jul 2003 10:45:40 -0700

yes. I agree.

great.

Vijay