Re: about draft-nagami-mip6-nemo-multihome-fixed-network-01 (was Re: [nemo] Draft Agenda and CFP

[marcelo bagnulo braun <[e-mail]>]

>>
>> Which implies that an ISP hosting a HA may end up carrying traffic for
>> 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.
>

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

>
>> 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.

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

>
>
>
> Regards,
>
> Nobuo Ogashiwa
>
>
>
>> But i guess that your proposal is more clear for me now.
>>
>> Thanks for your answers,
>> regards, marcelo
>>
>>>
>>> Regards,
>>>
>>> Nobuo Ogashiwa
>>>
>>>
>>>>
>>>> regards, marcelo
>>>>
>>>>> - 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
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Nobuo Ogashiwa
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Nobuo Ogashiwa
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Nobuo Ogashiwa
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> thanks for your answers,
>>>>>>>>>>> regards, marcelo
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Nobuo Ogashiwa
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, marcelo
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nobuo Ogashiwa
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards, marcelo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> However, you can also set up multiple HAs in same ISP.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards, marcelo
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nobuo Ogashiwa
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regards, marcelo
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> El 23/07/2004, a las 3:04, Nobuo OGASHIWA escribi♭:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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,
>>>>>>>>>>>>>>>>>>>>>> Thierry Ernst wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>