Subject: RE: [nemo] Multiple Egress vs multihoming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 May 2003 13:15:28 +0100

Hi Julien

Note that I tweaked my language from 'multiple careOf' to 'multiple
registrations' for the same prefix. For instance it may happen that a MR
registers a same prefix with the same CareOf to 2 different HAs. It
seems to me that the key is that a registration for a prefix has a
unique ID as in Ryuji's draft.

> >
> > Tarzan: One MR building and registering (to same HA) several CareOf
in
> > order to maintain connectivity while moving is a MH(x=0)
> 
>  Excuse-me that is MH? [Just for my information]

Sorry! MultiHoming

> 
> > The Tarzan problem is the introduction of multiple CareOfs
registered in
> > parallel. This breaks the MIP paradigm. Whether they are on a single
or
> > multiple interfaces of the MR may not ne important, but I expect
that
> > they'll be on different access routers. Anyway, this introduces the
load
> > balancing / high availability problem in both directions. I
understand
> > that FMIP has already studied this some. Maybe we can start from
there.
> 
>  Let's go for comments:
> 
>   The case:
> 
>                        _____
>        _    p      _  |     |
>       |_|-|<-_  |-|_|-|     |-|        _
>        _  |-|_|=|     |_____| |  _  |-|_|
>       |_|-|     |             |-|_|-|
>                                     |
> 
>       MNNs   MR   AR  Internet  AR    HA
> 
>   I think it a very classic multi-interface problem.
> 
>  Solution requirements:
> 
>   If you want to use the two interfaces at the same time:
> 
>     o Allow several tunnels between a MR and a HA.
>     o Allow binding of Multiple CoAs for the same MN-Prefix.
>     o Identify the CoAs in the Prefix-BU.
>       Explanations for this requirement:
> 
>         At a time on the HA you have:
> 
>          HA Nemo Binding cache:
>             Prefix1/length -> CoA1.
>             Prefix1/length -> CoA2.
> 
>         And then you receive a Prefix-BU from the same MR:
>            Prefix1/length -> CoA3.
> 
>          Which CoA has changed the CoA1 or the CoA2 ?
> 
>   If you use just one interface a the same time:
> 
>     o Nothing, just switch the interface when one goes down.
> 
>    But take care in this case the mobile router it's not a
>    Multihomed Mobile Router with this behavior according to:
> 
>    ,----[ draft-ernst-nemo-terminology-01.txt ]
>    | Multihomed Mobile Router
>    |
>    | A MR is multihomed when it has simultaneously more than one
>    |                                ^^^^^^^^^^^^^^
>    | active connection to the Internet, that is when it is either:
>    |
>    | [...]
>    |
>    `----
> 
>    And so remember the R.12 requirements:
> 
>    ,----[ draft-ietf-nemo-requirements-01.txt ]
>    |    R12: The solution MUST function for multihomed MR [...]
>    `----
> 
>  Configuration good for:
> 
>   o Keep Connectivity Transparently
> 
>     Reasons:
>      o Don't not change anything for the MNNs.
> 
>   o Load-Balancing & Policy
> 
>     Outbound traffic:
>      o The MR choose between the two CoAs.
> 
>     Inbound traffic:
>      o The HA choose between the two MR's CoAs.
> 
>     So the Prefix-BU should carry some preference for each CoA.
> 
>  Clear case for me and you. That's fine.

Right :)

> 
> > JetSet: one MR that registers its prefix to Paris and New York at
the
> > same time in order to optimize routing is a MH(x=1)
> >
> > The JetSet is the case where the multiple CareOfs are not registered
to
> > the same HA. The HAs may be far away from each other. The JetSet
problem
> > is the collaboration of the HAs in order to accept multiple
> > registrations, and the selection by the MR of the best via-HA to the
> > correspondent. Correlated problem is to get the packets onto the
active
> > tuunels on the HA side. This is the problem for which I pointed out
that
> > a dynamic routing over the MRHA is needed, including for me whatever
> > causes the MNP prefix to be injected in the Home AS routing protocol
> > while the MR is registered.
> 
>  The case:
> 
>                                  AR    HA2
>                                   _  |
>                                |-|_|-|  _
>                         _____  |     |-|_|
>         _    p      _  |     |-|
>        |_|-|<-_  |-|_|-|     |
>         _  |-|_|-|     |_____|-|        _
>        |_|-|     |             |  _  |-|_|
>                                |-|_|-|
>                                      |
>        MNNs  MR    AR  Internet  AR    HA1
> 
>  Solution requirements:
> 
>   o Maybe nothing.
> 

Well, there's something. The HAs have to talk together and with the rest
of their area. So the 'static' case does not work anymore. 

>  Configuration used for:
> 
>   o HA redundancy
> 
>   o Kind of Routing Optimization
> 
>   o Load-Balancing & Policy
> 
>     Outbound traffic:
>      o The MR choose between the two HAs. [priority]
> 
>     Inbound traffic:
>      <maybe-far-away-from-nemo>
> 
>       o Prefix-BU should carry some priority in the Prefix-BU for each
>         HA, and thus the HAs announce the prefix in IGP with metric
>         depending on this priority.
> 
>      </maybe-far-away-from-nemo>
> 

Yes

> > Shinkansen: A train with one prefix, one careof per MR and 2 MRs,
which
> > is a MH(y=0).
> >
> > Shinkansen is about the high availability of a prefix being
registered
> > by 2 different MRs. The problem is to make that transparent to the
MNNs,
> > so that if the MRHA tunnel of one MR fails, the MNNs traffic move to
the
> > other MR. Note that if we have both routers registering the same
prefix
> > at the same time, this is an x case too. But the second MR can be in
hot
> > standby, in which case this is not a x case.
> 
>  The case:
> 
>              MR2
> 
>              p
>             <-_  |
>         _  |-|_|-|  _____
>        |_|-|     |-|     |
>         _  |       |     |-|        _
>        |_|-|  _  |-|_____| |  _  |-|_|
>            |-|_|-|         |-|_|-|
>             <-   |               |
>              p
> 
>        MNNs  MR1   Internet  AR    HA
> 
>  Solution requirements:
> 
>   o Allow binding of Multiple CoAs for the same MN-Prefix.
> 
>  Configuration used for:
> 
>   o Keep Connectivity Transparently
> 
>     Reasons:
>      o The Default Router Selection [RFC 2461, Section 6.3.6] ]is
>        implemented in all IPv6 Node.  So if a router is crunched by
>        godzilla the MNNs take the other transparently.
> 

That may be slow... And how do you restore a fair share when the crushed
router comes back from the dead? 

>   o Router redundancy
> 
>   o Load-Balancing & Policy
> 
>     Outbound traffic:
> 
>      <sure-far-away-from-nemo>
> 
>      I think a kind of good solution is something like that:
> 
>      ,----[ draft-ietf-ipv6-router-selection-02.txt ]
>      | IPng Working Group
R. Draves
>      | Internet Draft
Microsoft Research
>      | Document: draft-ietf-ipv6-router-selection-02.txt
R. Hinden
>      |
Nokia
>      |
June 10, 2002
>      |
>      |    Default Router Preferences, More-Specific Routes, and Load
Sharing
>      `----
[http://ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt
]
> 
>      </sure-far-away-from-nemo>
> 
>     Inbound traffic:
> 
>      o The HA choose between the two MR CoA's.
> 
>      So the Prefix-BU should carry some preference for each CoA.
> 

Yes, but for the last sentence. I do not see that as different whether
there's one or more MR. This is why it's an x case too if the 2 MRs
register at the same time. And yes, a preference, a metric of some sort,
is a way to approach the x problem.

> > doubleBed: 2 MRs happening to share the same wireless media for
their
> > mobile prefix (Erik's problem) is a MH(y=1)
> >
> > Say MR1 has prefix P1 and HA1, and that MR2 has P2 via HA2.
doubleBed
> > problem is basically to allow traffic with a careOf in P2 to flow
via
> > MR1. This requires MR1 to accept P2 in its ingress filtering
selection.
> > This also requires, if MR2 is down, the HA1 sends traffic for P2
over
> > MRHA1. In other words, MR1 has and advertises P2. Julien's case with
an
> > intermediate router is a good one. For me, this is a case where the
MN
> > is not a stub anymore, and should be ruled out of scope real quick.
> 
>  The case:
> 
>              MR2             AR    HA2
> 
>              p2               _  |
>             <-_  |         |-|_|-|  _
>         _  |-|_|-|  _____  |     |-|_| [Manage p2 only]
>        |_|-|     |-|     |-|
>         _  |       |     |
>        |_|-|  _  |-|_____|-|        _
>            |-|_|-|         |  _  |-|_| [Manage p1 only]
>             <-   |         |-|_|-|
>              p1                  |
> 
>        MNNs  MR1   Internet  AR    HA1
> 
>  Solution requirements:
> 
>   o Manage the Ingress Filtering. [Maybe difficult or too high
requirement].
> 
>  Configuration imposed by:
> 
>   o "2 MRs happening to share the same wireless media for their
>     mobile prefix".
> 
>  These case is maybe out of scope of Nemo.
> [See my write below].
> 
>  I prefer this case which is Doublebed too:
> 
>              MR2
> 
>              p2
>             <-_  |
>         _  |-|_|-|  _____
>        |_|-|     |-|     |
>         _  |       |     |-|        _
>        |_|-|  _  |-|_____| |  _  |-|_|
>            |-|_|-|         |-|_|-|
>             <-   |               |
>              p1
> 
>        MNNs  MR1   Internet  AR    HA
> 
>  And in these case:
> 
>  Configuration used for:
> 
>   o Keep Connectivity Transparently
> 
>   o Router redundancy
> 
>   o Load-Balancing & Policy
> 
>     Outbound traffic:
> 
>      I think a kind of good solution is something like
>      [draft-ietf-ipv6-router-selection-02.txt] as I write above.
> 
>     Inbound traffic:
> 
>      o The HA choose between the two MR CoA's.
> 
>      So the Prefix-BU should carry some preference for each CoA.
> 

Right :) Note that I saw nowhere a text saying that if you see 2 routers
advertising each a different prefix, and if you autoconf'ed an address
for each prefix, SAS should derive the best of the 2 addresses depending
on which router you are using. That is if MR2 is used for destination D,
then source P2::x should be preferred over P1::x. I hope I just missed
it but I think this is central to our problem. 

> > If you see other problems to be solved please update this
discussion. I
> > could also help on the draft if you wish...
> 
>  Examples:
> 
> 
>                         _____
>         _   p1,p2   _  |     |
>        |_|-|<-_  |-|_|-|     |-|        _
>         _  |-|_|=|     |_____| |  _  |-|_| [Manage p1 & p2]
>        |_|-|     |             |-|_|-|
>                                      |
> 
>        MNNs   MR    AR Internet  AR    HA
> 
>  and
> 
>              MR2             AR    HA2
> 
>              p2               _  |
>             <-_  |         |-|_|-|  _
>         _  |-|_|-|  _____  |     |-|_| [Manage p2 only]
>        |_|-|     |-|     |-|
>         _  |       |     |
>        |_|-|  _  |-|_____|-|        _
>            |-|_|-|         |  _  |-|_| [Manage p1 only]
>             <-   |         |-|_|-|
>              p1                  |
> 
>        MNNs  MR1   Internet  AR    HA1
> 
>   Theses cases are Tarzan [Single HA for CoAs of a same Mobile Network
>  Prefix], and DoubleBed [Multiple prefixes advertised to the MNNs].
> 
>  In the first case:
> 
>   All work like for a simple Tarzan case, so you provide "Keep
>  Connectivity Transparently" easily. No problem with the doublebed
>  style. [No Ingress Filtering Rule to change]
> 

Yes, it's just a Tarzan, just with twice as many BUs... Or BUs with more
options.

>  In the second case:
> 
>  [I hope I'll be clear as enough]
>  [I know you [Pascal] understand this problem is just a reminder]
> 
>   What's wrong with "Keep Connectivity Transparently":
> 
>    The MRs announce two different Mobile Network Prefixes. So the
>    MNNs have two global source addresses. The MNNs operates a Source
>    Address Selection [RFC 3484, section 5]. And:
> 
>    Example of lost connection:
> 
>     A MNN select for a connection the source address prefixed by
>     p1. And after a moment the connection to the HA1 is lost.
>     [Godzilla again].
> 
>     Thus the connection is lost. [You can't send the p1 prefixed
>     packets towards the HA2 because the Ingress Filtering]. But new
>     connection are possible using the other source addresses.
> 
>   The problem is the same for a fixed network.
> 
>  Solutions:
> 
>    [Not a real solution]
>   o Do not put different HAs who manage different Network Prefixes for
a
>     same Mobile Network in different domains.
> 
>   o [draft-ng-nemo-multihoming-issues-00,
>      section 3.2.2. Using Alternate Mobile Router]
> 
>   o Modify the Ingress filtering rules.
> 
>  Thus maybe [sometime] make difference between one router with
> multiple CoAs and multiple mobile router can be useful. But I have
> write before you provide a good solution, and these examples are very
> specific.
> 

Or MR2 autoconf'ed an address in PA (though it's on the side of the
standard), advertises that to HA2, which advertises that to the world.
Which is just what we want to avoid by making MRs stubby. 

>  Maybe another example more simple:
> 
>   In this case: [Tarzan]
>                         _____
>         _    p      _  |     |
>        |_|-|<-_  |-|_|-|     |-|        _
>         _  |-|_|=|     |_____| |  _  |-|_|
>        |_|-|     |             |-|_|-|
>                                      |
> 
>        MNNs   MR   AR  Internet  AR    HA
> 
>     Load-Balancing for Inbound traffic "easy" to manage.
> 
>   In this case: [Tarzan too]
> 
>              MR2
> 
>              p
>             <-_  |
>         _  |-|_|-|  _____
>        |_|-|     |-|     |
>         _  |       |     |-|        _
>        |_|-|  _  |-|_____| |  _  |-|_|
>            |-|_|-|         |-|_|-|
>             <-   |               |
>              p
> 
>        MNNs  MR1   Internet  AR    HA
> 
>     Load-Balancing for Inbound traffic "hard" to manage.
> 
> 
>  So the difference are maybe not so visible in the solution level, but
> much more in the deployment / configuration level.
> 
>                      Best regard for the people who read the entire
mail.

Ouf :)

>                                             -- Julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 May 2003 18:29:04 +0200

>> Excuse-me that is MH? [Just for my information]

Overloaded, I use MH sometimes for Mobile Host (not a Mobile Router), or 
for Mobility Header...

Just 2 cents.

Alex
GBU