Subject: [nemo] Draft Agenda and CFP

From: Thierry Ernst <[email-masked]>
Date: Mon, 12 Jul 2004 18:47:38 +0900

Dear all,

The San Diego meeting is fast approaching. The NEMO WG is scheduled on
Monday 2nd August.

>---------- Drafty Draft Agenda 

During that meeting, we will
definitely speak about:
- status of the WG and WG documents
- WG charter and WG direction
- Results of WG Last Call for draft-ietf-nemo-terminology
- Results of WG Last Call for draft-ietf-nemo-equirements 
- Multihoming Problem Statement (draft-ietf-nemo-multihoming)

Other topics on which we wish to have contributions:
- MIB for NEMO Basic Support
- Securiry Threat Analysis
- Analysis of the Solution Space for Route Optimization
- Prefix Delegation for Mobile Networks
- NEMO Home Network models (draft-ietf-nemo-home-network-models-00)

>----------- Call for Participation

If you intend to request a slot for a topic related with the above
listed topic, or to add an item, please send your request to both chairs
by July 20th. Requests must be justified and will be accepted based the
priorities of the WG and time allowed during our slot.

>----------- Submitted Drafts 

Also, if you have submitted a new draft since last meeting, or intend to
submit one before the deadline, please inform TJ and myself so that we
can list all the ACTIVE drafts in the reading list. 

Note that I've seen a couple of drafts passing on the IETF-Announce
Mailing List, but these drafts were usually not announced on the NEMO
ML. According to the new secretariat policy, it's now the responsability
of the author to send a note to the NEMO ML.

Regards,
NEMO Chairs.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 19 Jul 2004 12:27:28 +0200

Hi Thierry, T.J.,

> - Results of WG Last Call for draft-ietf-nemo-terminology

When did the last call ended?

i couldn't find it in the archives...

i sent some comments a while ago, but i didn't receive any answer

You can find them at:
http://www1.ietf.org/mail-archive/web/nemo/current/msg00910.html

regards, marcelo

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Fri, 23 Jul 2004 10:04:36 +0900

Dear all,

We have submitted an updated draft.

 http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo-multihome-fixed-network-01.txt

 Abstract
 
     Multi-homing technology improves the availability of host and
     network connectivity. Since the node and network behavior of
     mobile networking and fixed networking are different, the
     different architecture has been discussed and proposed. This
     document proposes the common architecture both for mobile and
     fixed networking environment, using the mobile IP and NEMO. The
     proposed architecture only requires a modification of the mobile
     IP and NEMO so that multiple-CoA can be used. In addition,
     multiple HAs which are located in different place, are required
     for redundancy.

It is nice if we can have a presentation solot for the draft.
We have sent a request to WG chairs.

We appreciate any comments, questions or suggestions.

Regards,

Nobuo Ogashiwa

At Mon, 12 Jul 2004 18:47:38 +0900,

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Jul 2004 12:08:31 +0200

Hi Nobuo,

some comments about this draft

First of all, i am not sure i understand if this work really belongs to  
this working group...
I mean the tittle is:  Multi-homing for small scale fixed network Using  
Mobile IP and NEMO

this is also stated in section 1- Motivation when it is stated that:

     Therefore, we propose a multi-homing
     architecture using the mobile IP and NEMO for small-scale fixed
     network.

Along the rest of the document the focus is to the fixed network case,  
like for instance in section 1.3, it is explicitly stated that the nemo  
protocol will be used in fixed networks

So this solution is for "fixed" network, not for nemo, right? it uses  
the nemo basic support protocol but it is not a solution for a  
multihomed nemo, right?

If this is so, i don't thing this draft belongs to this wg

Second, this draft presents two scenarios:
- First with a single HA. In this case, the single HA (and its site) is  
single point of failure, so the fault tolerance gaol is not fulfill
- Second the case with multiple HA geographically distributed. In order  
to work, this requires that each HA announces the multihomed network  
prefix to the interdomain routing, which clearly beats the scalability  
goal.
So i fail to understand the benefit of this solution w.r.t. announcing  
the prefix through multiple ISPs by the endsite in terms of scalability

Regards, marcelo

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Sat, 24 Jul 2004 00:28:38 +0900

Dear Marcelo,

Please read inline comments.

At Fri, 23 Jul 2004 12:08:31 +0200,
> If this is so, i don't thing this draft belongs to this wg

I think that our architecture is an one of application of the NEMO. 
The draft describes requirements to the NEMO and solutions for
practical deployment of the NEMO from the viewpoint of one of NEMO application.
I mean, I think that the value of our draft is just like 
value of scenarios docments.

Secondly, the one of purposes of our architecture is redundancy.
The draft is focusing a fixed network, however,
the solution can be applyed to both fixed and mobile network.

Moreover, changing upstream ISP keeping network connectivity in case of
fixed network is just like movement of a network.
I think this is a kind of network mobility and is an one of important
application of NEMO.

These are why I think this draft belongs to the NEMO wg.

> single point of failure, so the fault tolerance gaol is not fulfill

Yes. Right.

> the prefix through multiple ISPs by the endsite in terms of scalability

I don't know why you think "which clearly beats the scalability goal",
and I'm not sure what kind of scalability you are describing above line.
As we mentioned in the draft, mobile network prefixes can be aggregated
when advartisement. Therefore, there is no problem with a scalability of
number of route entries.

Sorry if I miss understand what you attempt to point out.
It would be nice if you point out lack of description or unclear
description in the draft.

Regards,

Nobuo Ogashiwa

>
>
> Regards, marcelo
>
>
> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi♭:
>
> >
> > Dear all,
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Jul 2004 18:20:02 +0200

> description in the draft.

ok, perhaps i am misunderstanding something here... are you assuming 
that the HA belongs to the ISP network or to the end site? when there 
are multiple HAs, are you assuming that they belong to the the same 
ISP, to different ISPs or to the end site?

regards, marcelo

>>>> Also, if you have submitted a new draft since last meeting, or 
>>>> intend
>>>> to

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Sat, 24 Jul 2004 02:44:12 +0900

Dear Marcelo, 

> that the HA belongs to the ISP network or to the end site? when there 

We are assuming that the HA belongs to the ISP network.

> ISP, to different ISPs or to the end site?

Basically, We are assuming that HAs belong to different ISPs 
when there are multiple HAs.
However, you can also set up multiple HAs in same ISP.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Jul 2004 11:28:29 +0200

> when there are multiple HAs.

Ok, this means that the nemo has multiple NEMo prefixes, one per each  
HA i.e. one per ISP, right?
The other option would be that multiple ISP have to be injecting the  
same prefix, which option are you considering here?

Regards, marcelo

>>>>> http://www.ietf.org/internet-drafts/draft-nagami-mip6-nemo- 
>>>>> multihome-
>>>>> fixed-network-01.txt
>>>>>
>>>>>  Abstract
>>>>>
>>>>>> The San Diego meeting is fast approaching. The NEMO WG is  
>>>>>> scheduled
>>>>>> on
>>>>>> Monday 2nd August.
>>>>>>
>>>>>> by July 20th. Requests must be justified and will be accepted  
>>>>>> based
>>>>>> the
>>>>>> submit one before the deadline, please inform TJ and myself so  
>>>>>> that
>>>>>> we

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Mon, 26 Jul 2004 23:06:48 +0900

Dear Marcelo,

At Mon, 26 Jul 2004 11:28:29 +0200,
> same prefix, which option are you considering here?

Our assumption is the latter option.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Jul 2004 16:53:15 +0200

> Our assumption is the latter option.

Ok, then who does the prefix belongs to? to ISP1 or to ISP2?

moreover, what is the length of the prefix being injected?

I can see several possibilities here:
- a /48 for each multihomed site (of course if you have two multihomed 
customers that use the same two ISPs and they both have obtained its 
prefix from the same ISP and they have obtained aggregatable prefixes, 
you can aggregate those two prefixes into one, but i am not sure how 
likely this situation would be). Now if you inject a /48 (or a /47), 
you are basically doing current IPv4 multihoming solution with its 
scalability limitations
- a /32. At this case i can think of a couple of possibilities:
  The /32 belong to one of the ISPs. This case doesn't makes much 
business sense imho, since this would mean that the ISP that is 
announcing the prefix but does not owns the prefix will receive all the 
traffic for that prefix even the traffic addressed to no multihomed 
customers.
  The other option i can think of is that there is a special /32 
assigned to the clients multihomed with these two ISPs. Now this is 
pretty old idea, suggested by Rekhter and Li in one of the CIDR RFCs 
(if i remember correctly). The problem with this is that you need an 
important amount of /32 (more exactly the number of combinations of 2 
of all providers available, and then all the combinations of three and 
so on). The other question that i have in this context, i fail to 
understand what do you need nemo or mip6 for doing this in any case... 
(so i guess i still don't understand you proposal : -(

regards, marcelo

>>>>>>>> listed topic, or to add an item, please send your request to 
>>>>>>>> both
>>>>>>>> chairs

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Tue, 27 Jul 2004 01:14:30 +0900

Dear Marcelo,

At Mon, 26 Jul 2004 16:53:15 +0200,
> Ok, then who does the prefix belongs to? to ISP1 or to ISP2?

I would like to make sure the assumptions of your questions before
answer all questions.

ISP1 and ISP2 you are talking about are directly connected to the MR?
If so, the answer of the above question is neither ISP1 nor ISP2.
In our assumption, ISPs directly connected to the MR don't need to 
assign prefixes but need to assign just care-of addresses.
Yet another organization which manages the HAs assign the mobile 
network prefixes.
HAs might be geographically arranged into several ISPs,
however the prefix which are advertised from HAs are differ from the
ISP's one.

Sorry if the description in the draft made any confusion.
Would you mind to point out lines that is hard to understand?

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Jul 2004 18:31:00 +0200

> ISP1 and ISP2 you are talking about are directly connected to the MR?

No, i was asking about the isps that host the HAs
(I mean i am considering the scenario where you have multiple HAs in 
different ISPs)

> however the prefix which are advertised from HAs are differ from the

Ok, but the nemo prefix must be extracted from some prefix (which is 
the prefix that announces the HA). My question is who does this prefix 
belongs to?

Regards, marcelo

>>>>>>>>>      fixed networking environment, using the mobile IP and 
>>>>>>>>> NEMO.
>>>>>>>>> The
>>>>>>>>>> Mailing List, but these drafts were usually not announced on 
>>>>>>>>>> the
>>>>>>>>>> NEMO

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Tue, 27 Jul 2004 10:38:46 +0900

Dear Marcelo,

At Mon, 26 Jul 2004 18:31:00 +0200,
> (I mean i am considering the scenario where you have multiple HAs in 

Ok.

> the prefix that announces the HA). My question is who does this prefix 

We think there are two cases.

case 1) the prefix belongs to ISP1 or ISP2

In this case, ISP1 has a large address block.
Aggregatable nemo prefixes are extracted from this large 
address block as a part of this address block.
ISP1 and ISP2 contract to each other.
Under the contract, ISP1 setup a HA into the ISP2's network 
and ISP2 advertise the aggregatable nemo prefix extracted 
from ISP1's address block.

I think you are assuming this case. right?

case 2) the prefix belongs to the yet another service provider (xSP)

In this case, the xSP has an address block just for multihoming service.
The xSP contract to the ISP1 and the ISP2. 
Under the contract, xSP setup HAs into ISP1 and ISP2's network, and
the xSP's address block is advertised from the ISP1 and ISP2.

We are assuming this case.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Jul 2004 13:15:33 +0200

> We are assuming this case.

Ok.
Then the ISP1 and ISP2 announce the complete block of the xSP i.e. a 
/32 or they just announce the /48 that corresponds to the nemo that is 
multihomed?

thanks for your answers,
regards, marcelo

>>>>>>>>>>>      Multi-homing technology improves the availability of 
>>>>>>>>>>> host
>>>>>>>>>>> and
>>>>>>>>>>>      network connectivity. Since the node and network 
>>>>>>>>>>> behavior
>>>>>>>>>>> of
>>>>>>>>>>>      document proposes the common architecture both for 
>>>>>>>>>>> mobile
>>>>>>>>>>> and
>>>>>>>>>>>      proposed architecture only requires a modification of 
>>>>>>>>>>> the
>>>>>>>>>>> mobile

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Tue, 27 Jul 2004 23:48:54 +0900

Dear Marcelo,

At Tue, 27 Jul 2004 13:15:33 +0200,
> /32 or they just announce the /48 that corresponds to the nemo that is 

Basically, our assumption is the former.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Jul 2004 17:02:12 +0200

> Basically, our assumption is the former.

Ok this means that xSP needs to have as many /32 as possible 
combinations of two providers which a site may multihome.
I mean, suppose that in a city there are n ISPs, then there are 
n(n-1)/2 combinations of 2 ISPs which a site can multihome to, right?
Perhaps these are too many /32s?
And i am only considering sites that multihome to 2 isps, you may need 
to consider the case when they multihome to 3, 4,...

Anyway, why do you need nemo or mipv6 to build such a solution?
I mean, imagine that you assign a /32 to each combination of any two 
ISPs in a city, and you assign a /48 of this /32 of each site that 
multihome to those two ISP. All you need now is that these two isps 
announce the /32. You don't need nemo for this AFAICS.

Regards, marcelo

>>>>>> announcing the prefix but does not owns the prefix will receive 
>>>>>> all
>>>>>> the
>>>>>> important amount of /32 (more exactly the number of combinations 
>>>>>> of
>>>>>> 2
>>>>>>>>>>>>>      different architecture has been discussed and 
>>>>>>>>>>>>> proposed.
>>>>>>>>>>>>> This
>>>>>>>>>>>>>> If you intend to request a slot for a topic related with 
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> above
>>>>>>>>>>>>>> Also, if you have submitted a new draft since last 
>>>>>>>>>>>>>> meeting,
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> intend
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> submit one before the deadline, please inform TJ and 
>>>>>>>>>>>>>> myself
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> we

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Wed, 28 Jul 2004 00:55:16 +0900

At Tue, 27 Jul 2004 17:02:12 +0200,
> n(n-1)/2 combinations of 2 ISPs which a site can multihome to, right?

No. In this case, the xSP needs to have a exactry one /32 prefix.

If xSP contract to ISP-A, ISP-B, ISP-C then three HAs(HA-A, HA-B, HA-C)
are setup into those three ISP's network.

On the other hand if a multihomed user (user1) has multiple links connected to
ISP-X and ISP-Y, and the user1 contract to the xSP, then
the user1 uses a nemo prefix as mobile network prefix, which is extracted 
from xSP's address block, and the user1 receive traffic via HA-A, HA-B, HA-C.
In this case, the number of tunnels is 6 because the user1 has 
two direct connection to ISP-X and ISP-y and user1 can use three HAs, 
HA-A, HA-B and HA-C.

If another user (user2) contract to ISP-S, ISP-T, ISP-U for direct connection,
and contract to xSP for tunnel connection, then user2 also uses
a nemo prefix extracted from xSP's address block and receive packets via 
HA-A, HA-B, HA-C.
In this case, the number of tunnels is 9.

I mean, regardless of number of directly connected links,
every multihomed users contract to the xSP can use every HAs 
which are setup by the xSP, 
and every ISPs contract to the xSP have to advertise a same address block.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Jul 2004 18:10:37 +0200

> and every ISPs contract to the xSP have to advertise a same address  

i used the wrong terminology, sorry
The point was not about ISPs that are connected to the end site, but  
about ISPs where the XSP places HA into.

So the point is, using the new terminology

xSP needs to have as many /32 as possible
combinations of two providers which a multihomed site can have HAs  
placed into
I mean, suppose that in a city there are n ISPs that can host HAs, then  
there are
n(n-1)/2 combinations of 2 ISPs which a multihomed site can place its  
HAs
So you need n(n-1)/2 prefixes assigned for this solution, right?

regards, marcelo

>>>>>>>> (if i remember correctly). The problem with this is that you  
>>>>>>>> need
>>>>>>>> an
>>>>>>>> of all providers available, and then all the combinations of  
>>>>>>>> three
>>>>>>>> and
>>>>>>>>>>>>>>>      mobile networking and fixed networking are  
>>>>>>>>>>>>>>> different,
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>      multiple HAs which are located in different place,  
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> required
>>>>>>>>>>>>>>>      for redundancy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> listed topic, or to add an item, please send your  
>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>> chairs
>>>>>>>>>>>>>>>> Mailing List, but these drafts were usually not  
>>>>>>>>>>>>>>>> announced
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> NEMO
>>>>>>>>>>>>>>>> ML. According to the new secretariat policy, it's now  
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> responsability

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Wed, 28 Jul 2004 02:23:57 +0900

Dear Marcelo,

At Tue, 27 Jul 2004 18:10:37 +0200,
> about ISPs where the XSP places HA into.

Ok. I get your point about the terminology.

But, still I don't know why you think xSP needs many /32 prefixes.
The conceptual topology in our solution is just like full meshed 
VPN connections between every HAs and every users (MRs), 
those HAs act as border gateway routers of xSP, which advertise 
a same prefix.
Note that every MRs are connected to every HAs so 
the number of virtual links is number of HAs x number of MRs.

I mean, I think the conceptual topology of xSP consists of multiple HAs,
multiple MRs, full meshed virtual links between HAs and MRs, 
and subnetworks under MRs, which have nemo prefix.
And also I think that hosting HAs equals to peering, 
and prefixes of subnetworks are aggregated into 
a single /32 prefix then advertised from each HAs to peer ISPs.
In other word, every HAs of xSP advertise same /32 prefix to peer ISPs.
So I think that, regardless of the number of HAs, xSP doesn't need
to have many /32 prefixes.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 28 Jul 2004 11:41:06 +0200

> to have many /32 prefixes.

I am concerned about two issues here:

- First, the number of /32 required

Suppose that we have two multihomed sites mhsite1 and mhsite2

The mhsite1 has HA1 placed in ISP1 and HA2 placed in ISP2.
mhsite1 obtains multihoming services from XSP1, so mhsite1 obtains a 
Pref1:mhstie1::/48 from a prefix Pref1::/32
In order to make this work, ISP1 and ISP2 have to announce a route to 
Pref1::/32 through BGP,
agree?

Now we consider mhsite2.
mhsite2 has HA3 placed in ISP2 and HA4 placed in ISP3
mhsite2 obtains multihoming services from xSP also, the question now 
is: is it possible for mhsite2 to obtain a /48 form Pref1::/32?
Suppose that mhsite2 obtains the prefix Pref1:mhstie2::/48
In order to obtain traffic from its both ISP, both ISP2 and ISP3 have 
to announce Pref1::/32, right?

this would mean that ISP1, ISP2 and ISP3 will be announcing a route to 
Pref1::/32 through BGP, right?
This means that eventually ISP1 will carry traffic directed to mhsite1 
right?
This doesn't make any business sense AFAICS, i mean mhsite1 is not 
paying money to ISP1, so why ISP1 would carry traffic for mhsite1?

- The second point that i am concerned about is what do you need nemo 
at all for building this solution?

I mean suppose that mhsite is connected to ISP1 and ISP2, suppose that 
there is a Pref::/32 assigned to the multihomed users of those two 
ISPs, then all you need is that:
   - mhsite obtains addresses form Pref::/32, i.e Pref:mhsite::/48
   - ISP1 and ISP2 announce Pref::/32 through BGP

AFAICS, you obtain the same solution without having to deal with HAs 
nor nemo, what i am missing?

regards, marcelo

>>>>>>>>>> customers that use the same two ISPs and they both have 
>>>>>>>>>> obtained
>>>>>>>>>> its
>>>>>>>>>> you can aggregate those two prefixes into one, but i am not 
>>>>>>>>>> sure
>>>>>>>>>> how
>>>>>>>>>> assigned to the clients multihomed with these two ISPs. Now 
>>>>>>>>>> this
>>>>>>>>>> is
>>>>>>>>>> pretty old idea, suggested by Rekhter and Li in one of the 
>>>>>>>>>> CIDR
>>>>>>>>>> RFCs

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 28 Jul 2004 12:38:06 +0200

oops, i made a typo below...

> This means that eventually ISP1 will carry traffic directed to mhsite1 
                                                                 ^^^^^^^^
Should be mhsite2 instead of mhsite1, sorry for that.

> paying money to ISP1, so why ISP1 would carry traffic for mhsite1?
                                                      ^^^^^^^^

Should be mhsite2 here too

regards, marcelo

>>>>>>>>>>> likely this situation would be). Now if you inject a /48 (or 
>>>>>>>>>>> a
>>>>>>>>>>> /47),
>>>>>>>>>>> you are basically doing current IPv4 multihoming solution 
>>>>>>>>>>> with
>>>>>>>>>>> its
>>>>>>>>>>> scalability limitations
>>>>>>>>>>> so on). The other question that i have in this context, i 
>>>>>>>>>>> fail
>>>>>>>>>>> to
>>>>>>>>>>> understand what do you need nemo or mip6 for doing this in 
>>>>>>>>>>> any
>>>>>>>>>>> case...
>>>>>>>>>>>>>>>>>>      proposed architecture only requires a 
>>>>>>>>>>>>>>>>>> modification
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> mobile
>>>>>>>>>>>>>>>>>>> The San Diego meeting is fast approaching. The NEMO 
>>>>>>>>>>>>>>>>>>> WG
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> scheduled
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> Monday 2nd August.
>>>>>>>>>>>>>>>>>>>

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Wed, 28 Jul 2004 22:09:56 +0900

Dear Marcelo,

At Wed, 28 Jul 2004 12:38:06 +0200,
> > In order to make this work, ISP1 and ISP2 have to announce a route to 

In our assumption, the organization that has HAs and place HAs in ISP
is not multihomed site but xSP.  Multihomed sites aquire a right to
use HAs when contract to the xSP.

> Should be mhsite2 here too

As I mentioned above, in our assumption, the organization that has HAs
and place HAs in ISP is not multihomed site but xSP.  I mean, mhsite2
and mhsite1 use same HAs, and every ISPs that host HAs announce a same
route through BGP.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 28 Jul 2004 15:40:23 +0200

> and mhsite1 use same HAs, and every ISPs that host HAs announce a same

Which implies that an ISP hosting a HA may end up carrying traffic for  
non customers site, which imho makes no business sense.

In addition, i still don't see what does the nemo protocol is needed

But i guess that your proposal is more clear for me now.

Thanks for your answers,
regards, marcelo

>>>>>>>>>>>>> prefix from the same ISP and they have obtained  
>>>>>>>>>>>>> aggregatable
>>>>>>>>>>>>> prefixes,
>>>>>>>>>>>>>   The /32 belong to one of the ISPs. This case doesn't  
>>>>>>>>>>>>> makes
>>>>>>>>>>>>> much
>>>>>>>>>>>>> business sense imho, since this would mean that the ISP  
>>>>>>>>>>>>> that
>>>>>>>>>>>>> is
>>>>>>>>>>>>>   The other option i can think of is that there is a  
>>>>>>>>>>>>> special
>>>>>>>>>>>>> /32
>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-nagami- 
>>>>>>>>>>>>>>>>>>>> mip6-
>>>>>>>>>>>>>>>>>>>> nemo-
>>>>>>>>>>>>>>>>>>>> multihome-
>>>>>>>>>>>>>>>>>>>> fixed-network-01.txt
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  Abstract
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      fixed networking environment, using the mobile  
>>>>>>>>>>>>>>>>>>>> IP
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> NEMO.
>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>>      IP and NEMO so that multiple-CoA can be used.  
>>>>>>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>>> addition,
>>>>>>>>>>>>>>>>>>>> It is nice if we can have a presentation solot for  
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> draft.
>>>>>>>>>>>>>>>>>>>>> by July 20th. Requests must be justified and will  
>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> accepted
>>>>>>>>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> Note that I've seen a couple of drafts passing on  
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> IETF-Announce

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Thu, 29 Jul 2004 00:42:33 +0900

Dear Marcelo,

At Wed, 28 Jul 2004 15:40:23 +0200,
> non customers site, which imho makes no business sense.

I am assuming that under the contract to ISPs, the xSP pays for 
transit service and hosting.

> In addition, i still don't see what does the nemo protocol is needed

In our architecture, regardless of whether we use the NEMO protocol or
not, a protocol to inform CoA, HoA, BID from MR to HA and a protocol
to synchronize Binding Caches among HAs are required.  The MIP6 and
the NEMO with multiple CoA option and HAHA protocol satisfy our
requirements. So we will use the NEMO protocol.

One of purposes of our architecture is to accomplish redundant connection.
So, keeping connectivity to the Internet, anytime, multihomed user can
switch the ISP to use. (or unfortunatly a ISP goes down) At this time, 
the xSP have to be informed the multihomed user's care-of addresses 
to setup tunnles to the user's MR.

Furthermore, to accomplish redundant connection, HA should not be a
single point of failure. This is why we need HAHA protocol.

Regards,

Nobuo Ogashiwa

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 28 Jul 2004 18:00:53 +0200

> transit service and hosting.

So, you are assuming that the xSP defines where to put the HAs, not the 
multihomed site?

If not, you may end up in a situation where ISP1 has 100 HAs ISP2 has 
300 Has and ISP3 has 3 Has, which may be difficult to solve, i guess

> single point of failure. This is why we need HAHA protocol.

Yes i see that but imho a solution where two ISPs announce the prefix 
reserved for multihomed users of those providers would provide several 
benefits:
- optimized routing
- lower overhead
- less points of failure (you only rely on the ISPs, not in the HAs)
- simplicity
- cheaper (you don't have to pay to the XSP)

Regards, marcelo

>>>>>>> I mean, suppose that in a city there are n ISPs that can host 
>>>>>>> HAs,
>>>>>>> then
>>>>>>> there are
>>>>>>>>> And i am only considering sites that multihome to 2 isps, you 
>>>>>>>>> may
>>>>>>>>> need
>>>>>>>>> I mean, imagine that you assign a /32 to each combination of 
>>>>>>>>> any
>>>>>>>>> two
>>>>>>>>>>>>>>> - a /48 for each multihomed site (of course if you have 
>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>> multihomed
>>>>>>>>>>>>>>>>>>>>>>      document proposes the common architecture 
>>>>>>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> mobile
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> If you intend to request a slot for a topic 
>>>>>>>>>>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> above

---

From: Nobuo OGASHIWA <[email-masked]>
Date: Thu, 29 Jul 2004 10:09:21 +0900

Dear Marcelo,

At Wed, 28 Jul 2004 18:00:53 +0200,
> So, you are assuming that the xSP defines where to put the HAs, not the 

yes.

> - cheaper (you don't have to pay to the XSP)

I think it is good suggestion.  But, one of purposes of our
architecture is to make it possible for multihomed user to control
in-comming traffic. That is, to make it possible for multihomed user
to decide a tunnel to use for specific flow, packet, or application.
To accomplish, a protocol to control HA will be required. We are 
now discussing about such protocols.  Anyway, I think that HA or
something like HA will be required to accomplish the purpose.

Regards,

Nobuo Ogashiwa