Subject: [nemo] RE: splitting moving networks (was: DND test)

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 24 Mar 2004 21:30:22 -0500

> I think that, first, moving networks in the NEMO sense have a rigid 
 > structure, they just don't separate components from one 
 > another, a basic 
 > definition.

=> Disagree. Where is this definition made? It would be 
a big mistake to make this assumption IMHO. How can 
you say that a moving network will never be divided?
If I have a PAN with 4 devices and one day I left 
2 at home and took 2 with me to work, you're saying 
that this is not _meant_ to work?

 > 
 > I think second that the NEMO context has a kind of support of 
 > "splitting" which is in fact called "nesting" and which is 
 > supported by 
 > a good understanding about how it works.  A PAN can enter a train 
 > entering a ferry and all works; all works also whenever the 
 > PAN gets off 
 > the train (splitting?) and into the ferry, or when the train 
 > gets off 
 > and the PAN back or similar.

=> This is very different from what we're discussing, 
nesting is fine.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 01:33:40 -0500

> I do understand the issue. Sorry if I repeat myself, but I 
 > would like to
 > try to propose the following actions.
 > 
 > a. May I suggest Vijay to add an issue in his list (although 
 > the spec.
 > is in IESG hands) ?
 > 
 > b. I support open and un-ambiguous standard. So:
 > 
 > b1. I would oppose to add in the NEMO Basic Support spec. sentences
 > such like:
 > - 2 MRs do not share the same prefix
 > - NEMO cannot spit
 > - etc
 > 
 > b2. To solve ambiguousness, I would rather just say in the top of the
 > document (a kind of disclaimer) than there is no warranty that NEMO
 > Basic Support works with configurations other than a single NEMO-link
 > attached to the Internet via one MR, i.e.:
 > 
 > - multihomed mobile networks (8 cases, as identified by the 
 > multihomong
 >   problem statement, including multiple MRs)
 > 
 > - nested mobile networks [although it's assumed it would, but test
 >   remains to be done - we will do it in our lab very soon]
 > 
 > - split mobile networks
 > 
 > and that necessary fixes may be done later.
 > 
 > 
 > So, everyone is aware that checks remains to be done, and that
 > additional specs. may be needed for specific configuration [e.g. a
 > multihoming usage doc), at least in the informational track. 
 > Does this
 > makes sense for everyone ?

=> That's fine with me.

 > 
 > I concur to what Hesham says. Nested is when a sub-NEMO gets into a
 > parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO
 > and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated
 > prefix get split in 2 separate entities.

=> Agreed.

Thanks,
Hesham

 > Thierry

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 08:21:25 -0000

> that this is not _meant_ to work?
Yes, Hesham, exactly. It's a configuration error. It should be 2
networks. But then, they should not share an ingress link, ever. It's
either load balancing in an atomic (rigid) configuration or a totally
separated configuration. What you're asking for is just too difficult
with the current technology, and it's not just Nemo. 

Actually, we are very careful not to expose LFNs to other mobile
networks when we do our tests, because that breaks everything. And this
has to do with the way the LFNs we are using handle address
autoconfiguration and SAS. I agree we should doc the results of this.
Our (Nemo) policy is to write an informative usage draft that gives the
status of the cans and can'ts, and that status may evolve with the
overall technology...

You kinda convinced me that we should start the multihoming usage draft
ASAP :)

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 08:30:04 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Soliman Hesham
> Sent: jeudi 25 mars 2004 07:34
> To: Thierry Ernst; nemo
> Subject: RE: [nemo] RE: splitting moving networks (was: DND test)
> 
> 
Cool :)

>  > prefix get split in 2 separate entities.
Yes. Not that this split nemo thing is not different from a multilink
subnet. Which ends up being resolved using host routes...

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 08:30:04 -0000

Soliman Hesham
Cool :)

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 05:56:20 -0500

> networks. But then, they should not share an ingress link, ever. 

=> You're trying to get users to understand nemo I think!
It won't work. People should go away with whatever devices
they want and things should just work. This scenario is based
on real life it's not a configuration error.

   It's
 > with the current technology, and it's not just Nemo. 

=> I know it's not working today, but it can be made to work.
I've also stated countless times that it's not nemo specific.
It doesn't mean it's not solveable...

 > networks when we do our tests, because that breaks 
 > everything. 

=> Good luck ;) Tell that to a user: Your CD player can't 
access the Internet reliably when your phone and laptop are
both connected....

 > You kinda convinced me that we should start the multihoming 

=> I hope the useage draft considers real useage scenarios
and is not limited to ships, planes ...etc. 

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 12:53:17 -0000

> Pascal Thubert (pthubert) wrote:
It's
> Pascal, I did not see any specific requirement from Hesham about how
the
> moving network actually splits; it's just "I leave two devices at home
> and take two with me".  That is not enough.  If one really wants to
see
> how NEMO would work in this too-high-level scenario, and depict the
> BU/BAck message exchanges and the tunnels, then one should be a little
> bit more detailed on how the network actually splits.
> 
> I've tried to interpret more on what Hesham meant, drawed some
diagrams
>   here that respect the split net Hesham's scenario and I think NEMO
> Base Protocol works.  But I'm not sure exactly what Hesham meant
exactly.
> 
> So, Hesham, could you please be more explicit on exactly you see that
> split  moving network scenario?  Where are the home agents?  Does your
> house host a home link?  Are all devices LFN's or can they be MH's?
> What moves and in what order.
> 
General Agreement here... Seems that Hesham wants a multilink subnet to
work by magic. Like you, I wish to see use cases, maybe in the
multihoming draft. There is a lack of crispness in all this. 

I agree that Nemo basic support does not guarantee any multihoming
scenario to work. Also that Nemo basic support voluntarily does not put
in place any artifact that would prevent them in the future when the
necessary technology is in place. I believe that's what it was meant to
do.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 14:02:41 -0000

>  > work by magic.
> => Just to be sure I'm not being misquoted here....
> This has _nothing_ to do with the scenarios I mentioned.
> I don't know what you call multilink subnet but that term,
> to me, refers to something like the ND proxy that implements
> something similar to a spanning tree on L2/2.5.
> If that's what you mean I have no idea how you concluded
> it from my scenario.
Well, I concluded that because you have a link with a number of devices
on it, and 2 MRs. And then, you split the link, one MR stays, one MR
goes, some LFNs stay and some LFNs go. The subnet has been split over 2
links. 
This can be resolved in a number of way, including host routes at the
HA. But this is out of scope for nemo basic. The link and every node
that has a fixed address on it stick together. 

>    Like you, I wish to see use cases, maybe in the
> => The scenarios draft can help. The basic idea is to
> that a network containing more than one MR, providing
> access to the Internet, could be split (one MR goes
> away with or without other MNNs/LFNs). After the split,
> communication should be possible in both "halves". Note that
> I haven't placed any requirements on connection survival or
> failure detection...etc
> 
I'm not sure we considered that level of complexity already. Seems to me
it's a new scenario to add and which validity has to be debated, for
example based on practical use cases.

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 05:56:20 -0500

It's

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 09:08:18 -0500

> HA. 

=> This is one way, yes. But this is not good for LFNs, 
unless the signalling is done by the MR only, in which 
case the MR needs to keep track of nodes on its link.
That solution is probably a bit too complex.

 > example based on practical use cases.

=> Agreed. The keyword is "practical".

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 08:18:32 -0500

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 14:02:41 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 09:08:18 -0500

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 09:14:03 -0500

Alex, 

I was giving a scenario that purposely eliminates 
irrelevant information to focus on the key issue. 

 > Hesham, please just say how many MR's exactly (instead of 
 > "more than one
 > MR") 

=> It doesn't matter for my scenario. If you need
a number 2 is fine.

    and how many and what kinds of interfaces. 

=> Doesn't matter what kinds of interfaces, cellular/WLAN
pick one.

    Please say 
 > "with other
 > LFN's" instead of "with or without other MNN's/LFN's".  

=> The MR can move with an LFN (or more), with an MNN (or more),
or a mix of both.

 >  > => The scenarios draft can help.

=> We need a multihoming scenarios draft, I think
there is a number of people working on it. I don't 
know if it's published yet. But this :

http://www.mobilenetworks.org/nemo/drafts/draft-multihoming-generic-goals-and
-benefits-00.txt

is a start.

Hesham

 > 
 > Which scenarios draft?  Which of these:
 > 
 > http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-req
uirements-02.txt
http://www.mobilenetworks.org/nemo/drafts/draft-ietf-nemo-terminology-01.txt
http://www.mobilenetworks.org/nemo/drafts/draft-lach-nemo-experiments-overdri
ve-01.txt
http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-01.tx
t
http://www.mobilenetworks.org/nemo/drafts/draft-charbon-nemo-multihoming-eval
uation-00.txt

Or is it a new draft that has not yet been published?

Alex

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 05:51:08 -0500

Alex, you seem to be responding to me, I didn't write
this. Although I agree with Thierry's description.

Hesham

 > From: Alexandru Petrescu [mailto:[email-masked]]
 > Sent: Thursday, March 25, 2004 4:14 AM
 > To: Soliman Hesham
 > Cc: Thierry Ernst; nemo
 > Subject: Re: [nemo] RE: splitting moving networks (was: DND test)
 > 
 > 
 > Soliman Hesham wrote and cited T.E.:
 > >> Nested is when a sub-NEMO gets into a parent-NEMO; the 
 > sub-NEMO has
 > >>  not the same prefix has the parent-NEMO and doesnt' get
 > >> renumbered.
 > 
 > Nestedness also happens when MH visits a moving network; it's also 
 > important to stress that the respective MR's or MH's do 
 > _not_ have the 
 > same home link.
 > 
 > Whenever there's nested encapsulation to HA (i.e. at least 
 > two tunnels
 > encapsulated) then there's moving networks nestedness.
 > 
 > >> Split-NEMO is the opposite: an aggregated prefix get split in 2 
 > >> separate entities.
 > 
 > I really do not understand this high-level definition of an 
 > aggregated
 > prefix that splits in two separate entities; does it separate in two
 > separated "sub-prefixes"?  What is a detailed example of 
 > such a split?
 > 
 > Alex
 > 
 >

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 25 Mar 2004 21:20:32 -0500

> I think in this configuration all works fine from the NEMO 
 > standpoint. 
 > I think the potential problem may lie in how LFN's configure 
 > different 
 > default routes; this can be done at least manually and I 
 > think that how 
 > this is done is outside the scope of NEMO.

=> Yes.

 > 
 > So, what do you think, am I missing something?  Is anything from the 
 > NEMO Base Support that forbids this kind of split moving networks 
 > configuration to work properly?

=> There is only one scenario where this configuration
doesn't work, if MR1 and MR2 are assigned the same MNP.
This is what I've been trying to clarify in the draft. 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 26 Mar 2004 00:03:29 -0500

> > Just assume it; it's like assuming that there will always 
 > be a cable on
 > > which to communicate; if there's no such cable then there's no
 > > communication possible at all.
 > 
 > Here I agree with Hesham. Even if you prevent it in the spec, people
 > will do it, because those who will set up the configuration 
 > may not be
 > network administrators (i.e. usual people).
 > 
 > So, it's safe to either: 
 > 1. provide solutions or hints how to do it 
 > 
 > 2. say that there is no warranty the spec will work in other 
 > cases than
 > single MR with single NEMO-link.
 > 
 > 1. is too complex to address in NEMO Basic Support, so I 
 > prefer 2. Other
 > specs will fix specific cases. 
 > 
 > About stating in the spec something like, "no, you MUST NOT 
 > do it", this
 > is simply a moot statement because it will happen anyway.

=> I completely agree. 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 26 Mar 2004 00:03:29 -0500

=> I completely agree. 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 26 Mar 2004 05:07:11 -0500

> Soliman Hesham wrote:
 > >> So, what do you think, am I missing something?  Is anything from 
 > >> the NEMO Base Support that forbids this kind of split moving 
 > >> networks configuration to work properly?
 > > 
 > doesn't work, 
 > > if MR1 and MR2 are assigned the same MNP. This is what I've been 
 > > trying to clarify in the draft.
 > 
 > First, why would one assign the same MNP to MR1 and MR2?  For failure
 > avoidance of HA?  In that case better use two MNP's.

=> Pascal put the case for this scenario, have another
look at the thread from the beginning (about a week
ago). I'm not sure it's needed.

 > 
 > Second, even if one assigns only one MNP to both MR1 and MR2 in the
 > figure in the preceding email, then one would still assign different
 > Home Addresses on MR1 and MR2 respectively; and I think at that point
 > everything still works fine from the NEMO perspective: it's just that
 > there are two BC entries and two routing table entries.

=> No no, the network is split you don't know where
to forward LFN1's traffic, to MR1 or MR2?

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 26 Mar 2004 10:47:10 -0000

> ago). I'm not sure it's needed.

Yes, I think a whole length of the initial discussion was that we had
different scenarii in mind.

My scenario was based on the train model that Erik proposed on the list
a looong time ago, and that I called shinkansen (for that reason) in the
multihoming discussion. Basically, a mobile Network has 2 MRs for high
availability and load balancing purposes. 

It took some time for me to figure out that Hesham was on a different
line of thought. I recognized the situation buy remembering a discussion
in Yokohama where he mentioned an ingress link being shared by 2
unrelated MRs (like MRs opportunistically using a fixed AP as an ingress
link). 

This really was not my model -because of the variety of problems
involved, not because of use case validity, though-. I see such a
support as very far fetched, maybe like a ultimate goal. But there's a
long long way to go to get there, as I see every day in my lab.

If a LFN as a chance to see a second MR, it may (and does often) decide
to use it. When the second MR goes, the LFN is disrupted. The LFNs we
have at hand have no clever NUD or SAS. They can not easily do their own
DNA. And anyway all sessions started with an address from an MR that's
gone would be lost even if they did. 

Nemo aims at keeping LFNs sessions active while the MR moves. As of
today this means that the MR moves together with all the LFNS that use
an address from that MR's MNP. Having a second MR on the same MNP / same
ingress link is nothing new. But all the LFNs move with that second MR
for the same reasons. This implies that the whole system moves together.
This is not a use case. This is not a goal. This is the limitation of
today's overall technology.  

Nemo does not specify anything one way or the other. If we want a
walkman to use either a personal router, a car router or a home router,
you make the walkman a mobile node. This does not depend on whether the
car router is mobile and the home router is not. This has to do with the
fact that the walkman changes its point of attachment.

In conclusion, Nemo provides today with the mobility of a system. I used
the word atomic several times for some reasons. If you want to divide
the system into subsystems, each subsystem needs to handle its own
mobility. So we'll end up with many, small and nested subsystems, maybe
more then we may imagine initially. 

 * This is why supporting loopless nesting is critical *

Some time from now, I'd not be too surprised if:

* My Home network (I mean the IP network in my house) is a Nemo Home
network for all my mobile toys

* And it is a mobile network as well from my ISP standpoint, mostly for
management purposes.

Thus the mobile Home model in the home usage draft...

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 26 Mar 2004 10:47:10 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 26 Mar 2004 21:26:58 -0500

> It might be useful for vehicle's moving network. 
 > 
 > Even if we prohibit the single prefix assignment to multiple MRs as
 > you said, we still need to confirm whether each MNP is 
 > surely assigned
 > to single MR or not.  But how?  

=> Not sure what you mean, the current spec does that.

 > Do you think we can just treat this as configuration errors and do
 > nothing for this?

=> I'm not sure what you refer to by "this" above.

 > 
 > I think it is much easier to verify whether a mobile network is not
 > split or not. HA can ask to one of MR whether the other is onlink
 > or not (ex. check ND cache). If not, HA can reject BUs from both MRs.
 > Of course, there isn't such operation in the basic nemo though.

=> On the surface this seems easy but not if you consider
the corner cases, MR reboot, link failures....etc.
I don't think it's that easy actually.

 > 
 > If NEMO can detect the split mobile network and prohibit the
 > split mobile network, there is no problem for the same MNP
 > configuration.

=> I find this logic a bit skewed actually. Of course if 
you start with shared MNPs then it follows that if we can
prevent splitting then everything is ok. There is only 
a small problem: you can't prevent splitting. 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 27 Mar 2004 00:41:39 -0500

> Prefix table. Yes, your are right.
 > I am not sure the use of prefix table guarantee the 1MNP-1MR all the
 > case. 
 > 
 > When MR has multiple egress interfaces and register each CoA with
 > respective HoA, HA can not distinguish between the case when one MNP
 > assigned to two MRs and the case of one MNP to multihomed MR. 

=> Of course.

 > When each MR registers to different HAs, we need to verify whether
 > prefix table of each HA is consistent or not. 

=> No we don't need to do that, they're two independent 
entries.

 > the case when HA detects there are multiple MRs for the same MNP.

=> As I stated before, I think it's cleaner to have 
different MNPs for MRs. If that's the decision, then
of course we can treat this case as an error just like
MIP treats multiple MNs with the same HoA as an error. 

 > I don't see any problem here.
 > 
 > HA does not have the binding for the MR that reboot or lost 
 > connectivity.

=> If the MR registered for an hour how is 
the binding removed?

 > Only when HA has multiple bindings for the same MR, it checks the
 > split network with registered MRs. 

=> When it checks and one MR doesn't answer what happens?
I've already stated these points before. You can find 
them in earlier emails.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 27 Mar 2004 03:00:22 -0500

>  For some purposes, the consistency *would* be preferable. 
 > If we want some
 >  fault tolerance, multiple HAs and replication (or 
 > consistency) can be helpful.
 >  And this consistency problem can be solved by the HAHA protocol. 
 >  So, we don't need to close the possibility.

=> There is no inconsistency here to address.
I think there is a lot of confusion about multihoming
actually. I intend to put my thoughts in a draft to
avoid repetition.

 >  IMO, multiple MRs can have the same MNP for the fault tolerance.
 >  That's one of the purpose of multihomed mobile networks, and
 >  that can be also the decision.

=> You're mixing a solution with a requirement. Start by
putting requirements then we can discuss solutions THEN
we can decide which solution is better. 

 >  The periodic BU can solve this problem. 

=> No it doesn't, perhaps some interaction between
the IGP and the binding cache management function
can be done but this is still handwaving without any 
concrete ideas.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 27 Mar 2004 08:36:54 -0500

> Do you propose to use prefix table as MUST in the basic ?

=> What is the relationship between maintaining two separate
entries in the binding cache and the prefix table being
mandatory? In any case, I do think the prefix table should
be mandatory.

 > OK.
 > They have mechasnim to detect that such as DAD at home link.

=> DAD detects address duplication on the link, which
still applies to the MR's HoA. It does not detect when
two MNs off link are trying to register with the same
HoA. This is detected because every HoA is tied to 
a unique SA. 

 > How to remove binding for reboot MR is not NEMO specific issue. 
 > Mobile IP has same issue.

=> It is nemo specific in the case where we try 
to introduce this new test which doesn't exist
in MIP. The bigger point is what does the HA do
if one MR does not answer the test.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 27 Mar 2004 08:36:54 -0500

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Mar 2004 08:01:35 +0100

> a small problem: you can't prevent splitting.

Hesham: what if the MR goes and the LFN stays? If you can not prevent
the other splitting then you can't prevent that one either.

In LFN there's the word fixed, for fixed relative to the MR. If there
are 2 MRs on the ingress link then the LFN is fixed with regards to the
2 of them. As I said it's an atomic system by definition. The MR, its
LFNs, a second MR is the ingress link is shared between to MRs. So the
MRs are mobile but not related to each other. This case is not broken,
and you can prevent the relative movement... One way is to package the 2
MRs together and call that a high availability MR :) Seems you did not
get much support trying to bar that.

And like I said if there's a split then all nodes that can split from
each other must manage there own mobility. 

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Mar 2004 08:01:35 +0100

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 29 Mar 2004 04:06:24 -0500

> the other splitting then you can't prevent that one either.

=> Correct.

 > 2 of them. 

=> It's fixed but either MR can do the job for it.
What happens when one prefix disappears from a link
today? The nodes onlink just use the other prefix(es).

   As I said it's an atomic system by definition. The MR, its
 > MRs are mobile but not related to each other. This case is 

=> It's not broken but it's limited to certain scenarios.
I never claimed it was broken.

 > MRs together and call that a high availability MR :) 

=> You're missing the point. This isn't about 
availability only, on some cases it'll just happen
that 2 MRs appear then one disappear.
Availability is just one aspect.

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by other is 
strictly prohibited.  If you are not the inteded recipient please contact
the sender and delete all copies.
========================================================

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 29 Mar 2004 04:06:24 -0500

=> Correct.

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Mar 2004 10:36:15 +0100

> From: Soliman Hesham [mailto:[email-masked]]
> Sent: lundi 29 mars 2004 11:06
> To: Pascal Thubert (pthubert); Ryuji Wakikawa
> Cc: [email-masked]; [email-masked];
[email-masked]
> today? The nodes onlink just use the other prefix(es).

Is that so?  In fact:

1) Connections are lost (HIP, where art thou?)

2) it takes quite some time for hosts to NUD their default GW, if they
ever do. In the lab, we basically unplug and replug the interfaces to
clean up the hosts when such a thing happens. There are a lot of
DNA/NUD/MIP RA-interval based solutions proposed but if you talk about
today, it's pretty slow.

My point is that while I agree with a ultimate goal that I seem to
understand from all this, we do not have the overall technology to do
it. And I believe that the Nemo spec is OK in the context. 

> I never claimed it was broken.
Cool. 

> Availability is just one aspect.
Yes, I believe you're right about corner cases. Splitting them in 2
sets:
Set a: multi6/IPv6 problems (connections broken, slow NUD on default GW)
Set b: new problems induced by Nemo.

Since the Nemo MR looks like a standard GW to the LFNs, the only thing I
can see in set b is against the DND test as I proposed it. But I see
nothing specific about the nemo spec?

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Mar 2004 10:36:15 +0100

[email-masked]

Is that so?  In fact:

Cool. 

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 29 Mar 2004 04:50:53 -0500

> 1) Connections are lost (HIP, where art thou?)

=> And? Is there a requirement to maintain connectivity
in this particular case? This will happen regardless
of the solution you use. 

 > DNA/NUD/MIP RA-interval based solutions proposed but if you 

=> Sigh. I'm trying to focus this discussion on 2 things:
  - The validity of the scenario
  - Requirements.

We already discussed that there are various problems
to be solved. For the split case, problems exist anyway
regardless of the number of prefixes. They're just _different_
problems. Now, regardless of how many problems exist, it seems
unproductive to say : "This is too hard, discard those scenarios".
This statement doesn't provide alternatives. This might be ok
if we think the scenario is not real or not worth solving.
But we didn't even discuss this, so .....

 > it. 

=> I know that! It's not the point. 

  And I believe that the Nemo spec is OK in the context. 

=> The nemo spec shouldn't attempt to solve the split
case. My original comment on the nemo spec is that it's 
vague and doesn't state the limitations of the current
solution. This was already addressed by Thierry's comment
to add a disclaimer that multihoming is not guaranteed
to work.

 > Set b: new problems induced by Nemo.

=> Agreed on a high level. We might want to split them
further later.

 > can see in set b is against the DND test as I proposed it. 

=> Sorry I can't parse this.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 29 Mar 2004 04:50:53 -0500

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Mar 2004 11:03:27 +0100

> => Sorry I can't parse this.

In the case of an atomic system with 2 MRs sharing an ingress link and
one MNP with a bunch of LFNs. Is that a problem that is specific to Nemo
in the case where one MR dies? I mean as opposed to the same config but
the routers are fixed? I think not.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Mar 2004 11:03:27 +0100

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 29 Mar 2004 05:22:42 -0500

> the routers are fixed? 

=> If you constrain the config to routers that are fixed
w.r.t each other then No. Our argument is basically that 
you can't generalise this scenario and assume that it is 
the case for all mobile networks IMO.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 29 Mar 2004 05:22:42 -0500

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 25 Mar 2004 12:53:17 -0000

It's
the
see
diagrams
exactly.

Pascal