Subject: RE: [nemo] review of the nemo basic spec

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Dec 2003 18:15:34 -0000

Hi Jari:

Thanks for the review :) We need to dig into your work but here is a
beginning of answer (and IMHO we'll have to open issues and propose text
for most of your points)
> 
>           o  Why is there support for so many alternative ways to
> 	    deliver route information? Note that due to the current
> 	    security mechanisms, static config of routes would
> 	    probably be sufficient. Or stick with just the prefix
> 	    option, and don't support the static and routing protocol
> 	    variants.
> 

Actually there's nothing much about static but it's a configuration that
has many advantages. One is the implicit authorization, another is the
minimum control traffic linked to movements.
So I strongly push to keep that option. 

We can not easily prevent the configuration of a routing protocol
between the MR and Home if that's what the customer wants, but how that
is done is mostly out of scope. 

As of the variants of the prefix options, I tried to defend them and at
this point it's a matter of consensus. It's a small piece of code for a
small value anyway. What we want to keep for sure is the ability to use
a Home Address from the mobile network.

> 
>           o  Probably makes sense to have just one moboption.
> 
> 	 o  It is unclear to me why the MR needs to behave as a
> 	    (limited form of a) router on the home link, and whether
there are
> 	    any implications of this.

If Home is not using static routes and a MR deregisters, then the routes
to its prefixes are removed. When at home, the MR has to inject those
routes in the local IGP by itself or they just do not exist. At least
one implication is the routing protocol activity (and the temporary
disruptions) of the Home IGP, associated with MRs registrations and
deregistrations. 

> 
>           o  A related issue is in which order do the various
> 	    things take place? When do you decide you are
> 	    in the home network and can act as a router,
> 	    and when do you join various router-related
> 	    multicast addresses, for instance?
> 

Yes, that would be the assumption. I understand that you suggest adding
more text about that phase, correct?

>           o  Some error cases are missing.
> 
>           o  It probably makes sense to be more explicit about
> 	    the relationship of this document to MIPv6. Does
> 	    a MR have to support everything in MIPV6, or just
> 	    some parts? Or say at least that you MUST support
> 	    everything...

Right. In basic mode, the MR does not need to support to be a CN, and RO
with a CN, since it is not expected to be the end point of most
conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments
anyone?

> 
> 	 o  I'd like understand loop detection better. Or
> 	    at least why its not required.
> 

You mean packets flying back and forth over MRHA? I believe we should
have text to prevent a HA from putting a packet back on a same MRHA
tunnel, which is a classical behavior.

>           o  I don't like the fact that MIPv6 HAs can accept
> 	    and R=1 registration and no one notices anything.
> 	    An approach that uses moboptions, even in the
> 	    response, would probably work smoother.
> 

Could you please elaborate?

>           o  Something unclear with regards to Status value
> 	    treatment in Sections 5.3 and 5.4, perhaps
> 	    related to the above issue.
> 
>        Management: My main concern are the IPRs. A lot of people I
have
>        talked with have worried about the NEMO IPRs, particularly the
>        ones that Cisco claims to have. If I remember correctly, the
>        Nokia IPRs are also free only for public domain implementations
>        which isn't good. We need to decide whether this work should go
>        forward given this situation, unless some better license
>        conditions can be provided. If I had a choice I would rather
>        change the design, if that would help to avoid the existing
>        IPRs.
> 
>        Editorial: The document is well written, but in some cases you
>        could have formulated it in a simpler way. A number of
>        suggestions below. The structure of the document is good.
> 
> --Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 23:33:05 +0200

> is done is mostly out of scope. 

You may be right, but then again describing the routing protocol
behaviour in the basic spec will lead to a number of MUSTs or SHOULDs,
or at least MAYs. We could avoid that, even if someone does that
on their own, or if you develop a NEMO Dynamic Routing Extension
later.

> a Home Address from the mobile network.

That I agree with.

> disruptions) of the Home IGP, associated with MRs registrations and

Ok. The IGP route argument is compelling.

The implications I was afraid of were related to a host
becoming a router depending on movement detection results.
I don't have any specific case where this would fail, I
just worried about it.

> more text about that phase, correct?

Yes.

> conversations. But IMHO, a Nemo HA should fully support MIPv6. Comments

Specification-wise it would be easiest to just require full
support. Functionality-wise RO might not be necessary, if the
MR is not sending any packets itself. OTOH RO support is not
a very big burden.

> tunnel, which is a classical behavior.

Here's what I'm thinking:

Step 1.
         MR1 -> MR2 -> MR3 ---> Fixed Network ---> HA

Step 2.
                           _---> Fixed Network ---> HA
                          /
   +---> MR1 -> MR2 -> MR3 ---+
   |                          |
   +--------------------------+

Step 3.

   +---> MR1 -> MR2 -> MR3 ---+
   |                          |
   +--------------------------+

That is, an MR3 is attached to a fixed network and communicates
with its HA. There are nested MRs, MR1 and MR2. Now, MR3 sees MR1
advertising access with a better signal strenght, and thinks
incorrectly that it would be a good idea to attach to it. So
it decides to attach to MR1 instead. However, MR3 keeps its old
attachment running until it has completed the attachment to MR1;
this implies the BU it sends via MR1 gets routed back to itself
in a tunnel, and actually gets to the home agent via the
still operational fixed attachment. But after the BA comes back,
MR3 detaches itself from the fixed network. As a result, we
have a loop and no connectivity. Now try to send a data packet.

I would like to understand why this is not a problem.
I'm sure I'm missing something obvious.

> Could you please elaborate?

I'm referring to the first paragraph of Section 7.
Remember that according to MIPv6 base spec, unknown
flags are ignored, as are unknown moboptions. One good
way past this is to send one moboption and expect another
one back as an ack that the receiver understood what you
requested; then you know the HA supports NEMO. Alternatively,
you can track a flag value on the Binding Ack. If it comes
back as zero, HA did not support NEMO.

In nemo, you do neither. Instead you have added a new flag
in DHAAD. That is useful, but I would also handle the BU/BA
in a way that the mobile router becomes certain the home
agent understood what it was being asked to do.

Does this help explain my issue about the current nemo R=1
usage?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 23:33:05 +0200

That I agree with.

Yes.

Step 1.

Step 2.

Step 3.

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Dec 2003 15:03:17 -0800

>> a Home Address from the mobile network.

there is an ongoing discussion on removing the explicit prefix
length mode. it is issue 20 at 
http://people.nokia.net/vijayd/nemo/issues.html.
IMO, we can remove this mode, since the explicit network mode
can used to do whatever you want to do with the explicit prefix
length mode.

> 
>>>          o  Probably makes sense to have just one moboption
>>>

the idea is let the mobile router on its home link behave as it
would if it were a fixed router. turning on/off this behavior
very much depends on movement detection. I dont see any issue
currently though.

>> more text about that phase, correct?

I will add some text.

>>>          o  Some error cases are missing.

??

> MR is not sending any packets itself. OTOH RO support is not

it depends on the specific scenario. if a cell phone is a mobile
router (which provides connectivity to a laptop and an MP3 device),
then it is likely to be a mobile node most of the time. maybe we
should should all of MIPv6 (?)

> Here's what I'm thinking:

filed this as issue 24 at http://people.nokia.net/vijayd/nemo/issues.html

> Does this help explain my issue about the current nemo R=1

this was discussed earlier. Issues 15 and 16 capture the
discussion. the first solution to support inter-working with
MIPv6 Home Agents was to add a new binding ack status which
says forwarding was setup. MIPv6 Home Agents would return
just 0. the second suggestion was to add a flag in the binding
ack which would be set to 1 if the Home Agents sets up
forwarding for the mobile network. MIPv6 Home Agent would not
set this flag. neither of this will work because, the Mobile
Router now has to repeatedly try other Home Agents until it
gets an indication from a Home Agent that it has set up
forwarding. the mobile router also has to deregister with the
MIPv6 Home Agent before trying another Home Agent.

so modifying DHAAD was the right solution. the mobile router
should not have attempted registration with a Home Agent that
does not support mobile routers.

IMO, a flag in the binding ack is just extra specification and
extra code for something that shouldnt have happened. what do
you think?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Dec 2003 15:03:17 -0800

I will add some text.

??

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 01:09:12 +0200

> this was discussed earlier. Issues 15 and 16 capture the

I need to take a look at that, right now its too late (1 am)
here for that ;-)

> extra code for something that shouldnt have happened. what do

I think I agree that modifying DHAAD was a good thing to
do. WHat I am less sure about is whether that is sufficient.
One thing is that I'd rather not do DHAAD at all, if I can avoid
it. The second thing is making the decision of what you support
local. The HA that responds to a BU certainly knows what
it supports; another home agent might not know, for sure,
what the other home agents support. Or at least there could
be config errors in it. In conclusion, while I agree that
DHAAD support is good, it may be necessary to make the
BU/BA protocol itself robust enough to survive even
mistakes or old information in DHAAD. Does that make
sense?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 01:09:12 +0200

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 00:04:11 -0800

> it. 

okay. apart from DHAAD and manual configuration, how else is
the mobile router assigned a Home Agent?

> The second thing is making the decision of what you support

I am not disagreeing with this. a flag in the binding ack which
says the Home Agent has setup forwarding for the mobile network
will do what you want. the question I have, is this extra
specification worth it for what I consider a corner case (a
configuration error)?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 00:04:11 -0800

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 19:27:26 -0800

hi Jari,

>>> more text about that phase, correct?

here is some text for this. I added a new section.

5.8. Returning Home

    When the Mobile Router realizes it has returned to its home link
    through movement detection mechanisms, it MUST de-register with
    its Home Agent.  The Mobile Router MUST implement and follow the
    returning home procedure defined for a mobile node in [1].  In
    addition, the Mobile Router MAY start behaving as a router on its
    egress interface.  In particular,

     -  The Mobile Router MAY send router advertisements on its egress
        interfaces.  But the router lifetime SHOULD be set to 0, so that
        hosts on the home link do not pick the Mobile Router as the
        default router.

     -  The Mobile Router MAY join the All Routers multicast group on the
        home link.

     -  The Mobile Router MAY send routing protocol messages on its
        egress interface if it is configured to run a dynamic routing
        protocol.

comments?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 19:27:26 -0800

hi Jari,

5.8. Returning Home

comments?

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 19:28:07 -0800

>        hosts on the home link do not pick the Mobile Router as the

I'm missing something.. Why would the MR put out RAs on the egress 
interface? I can see why it would put them out on the ingress interface, 
and use a routing protocol on the egress interface to advertise the 
mobile network.. but what would the RA contain?

tj

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 19:28:07 -0800

tj

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 19:38:42 -0800

> mobile network.. but what would the RA contain?

a router by its nature sends out router advertisements. there is
no spec prohibiting it from sending out router advertisements on
any of its interfaces. the NEMO basic spec restricts the mobile
router to not send router advertisements on its egress interface
when it is attached to a visited link. when it returns to a home
link, we are saying it MAY start sending again.

but we have to prevent hosts on the home link from configuring
the mobile router as a default router. so we say the router
lifetime SHOULD be set to 0.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 19:38:42 -0800

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 19:36:09 -0800

OK.. can you give me an example of when any MR, ever, would get any 
benefit by sending RAs on its egress interface? If not, the text there 
should probably point out this fact, or just say..don't send them.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 19:36:09 -0800

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 19:52:16 -0800

> should probably point out this fact, or just say..don't send them.

not for us to prohibit this, TJ. neighbor discovery specs dont
prohibit it. Jim and I had a discussion on this. the discussion
is at http://people.nokia.net/vijayd/nemo/issue21.txt.

maybe you should pose this question on the IPv6 mailing list.
Jim has sent a mail to Hesham to clarify this when RFC 2461
is being revised. it hasnt been discussed on the IPv6 mailing
list, though.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 19:52:16 -0800

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 22:27:06 -0800

> link, we are saying it MAY start sending again.

My understand about router advertisements is that they are used for 
routers to advertise their existence on links they serve, and give 
information about the prefixes they will serve.

The MR does not serve any nodes on the egress interface. Therefore it is 
just like a HOST on that link. The MR should ever, only, advertise 
itself as a router on a link where it acts as a router -- the mobile 
network.

> lifetime SHOULD be set to 0. 

Which is equivalent to not sending router advertisements. After all, 
it's not going to include any prefix options in the RA, is it??

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 22:27:06 -0800

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2003 10:53:00 +0200

I also feel a bit uneasy about sending RAs on the home
link. If the dynamic routing protocol case is included
in basic support draft, then we do have to allow routing
protocols to be run on the home link. But what else?

Unfortunately, the ipv6 routers vs. ROUTERs discussion
did not go in to too much depth on these issues. Start a
new discussion with the specific case of Nemo in mind?
Or did you already discuss the RFC 2461 unclarities wrt
this in some other thread on the ipv6 list, as someone
promised to do in the issue 21 file?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2003 10:53:00 +0200

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Dec 2003 12:30:31 +0100

Jari Arkko wrote:
> I also feel a bit uneasy about sending RAs on the home link.

I feel at ease with MR's sending RA's on the home link, it's just like a
router like others.  Its neighbour routers will be able to lots of
additional things if they know MR is there like a normal fixed router.

I think TJ didn't feel at ease about MR sending RA's on the egress
interface, while on the visited link (not on the home link).

> If the dynamic routing protocol case is included in basic support 
> draft, then we do have to allow routing protocols to be run on the 
> home link.

Routing protocols interactions between routers on the home link don't
involve RA's.

 > But what else?

On the home link, neighbour routers might use the MR's RA's to log 
presence purposes; additionally, if on the home link FR is shutdown for 
whatever reason then MR sending RA's helps an FH on the home link to be 
able to talk to an LFN inside the moving network.  If MR on the home 
link does not send RA's, then this communication is impossible. (FR - 
fixed router, FH - fixed host).

MTU also, if the FR is down, then MR might provide that MTU.  And all 
the other parameters also, except the one saying MR is a default router.

I think this is reason enough to have MR MAY send RA's on the home link.

Similarly, on the visited link, if MR is not allowed to send RA's on the 
egress interface, then, if AR is down, an an MH on that wireless link 
(between MR and AR) will not be able to form a CoA and talk to an LFN 
inside the moving network (by using source address selection).

It is of course of much concern to allow MR to send RA's on the egress 
interface on the wireless interface, because the avertised prefix is a 
prefix valid in the home link (not in the visited domain).  But normally 
RA's are not propagated by routers, so it should be less of a concern.

So I strongly believe MR MAY send RA's on the visited link too (maybe a 
little bit less MAY than the MAY for the home link).

> Unfortunately, the ipv6 routers vs. ROUTERs discussion did not go in 
> to too much depth on these issues.

I doubt the relevance here, but it's a good discussion.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Dec 2003 12:30:31 +0100

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Dec 2003 12:39:53 +0100

T.J. Kniveton wrote:
> The MR does not serve any nodes on the egress interface. Therefore it
>  is just like a HOST on that link. The MR should ever, only, 
> advertise itself as a router on a link where it acts as a router -- 
> the mobile network.

Could MR act as a router on the visited link too?

For example, MR goes visit an AR over a wireless link.  An MH goes visit
that wireless link too.  Now AR is shutdown for whatever reason.

At this point, if MR does _not_ send RA's on its egress interface, then
MH is not at all capable of talking to LFN inside MR.  If MR _does_ send
RA on its egress interface, then MH receives it and forms an address,
and uses source address selection, and can talk to LFN (MH does not go
through its HA).

The RA used by MR sent on the visited link has a prefix topologically
correct on the home link (not under the AR).  Only the AR advertises
itself as a default router, but the MR not.

So, if MR could act as a router on the visited link too, then MR might
send some RA's.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Dec 2003 12:39:53 +0100

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Dec 2003 09:47:25 -0800

I see one use for it. a router can attach to a new link and
announce itself through a router advertisement. we dont have
any other message which can do this. not all routers run a
routing protocol.

but we dont have a use for this yet, currently.

but then again, I dont see a reason to prohibit this when the
MR is on the home link.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Dec 2003 09:47:25 -0800

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Dec 2003 10:06:09 -0800

I know James Kempf sent a mail to Hesham asking for this
to be clarified when RFC 2461 is revised.

IMO, there is no technical reason to prohibit it. infact
I see it as a message which can be used by a router to
announce itself on a link when it attaches to its home
link. however there is no use for this currently.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Dec 2003 10:06:09 -0800

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 4 Dec 2003 13:31:02 -0800

> any other message which can do this. not all routers run a

I expect packets coming to the home link would be routed to the MR by 
the HA.

> but then again, I dont see a reason to prohibit this when the

OK.. it just seems like a weird thing to do. :)
>> is just like a HOST on that link. The MR should ever, only, advertise

---

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 4 Dec 2003 13:31:02 -0800

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Dec 2003 14:59:00 +0100

Hi Jari, I would like to better understand the potential loop problem
and eventually the loop detection tool.

Jari Arkko wrote:
> with its HA.

Do you assume that HA only serves MR3?  And that MR1 and MR2 have 
different HA's that are not pictured?

> There are nested MRs, MR1 and MR2. Now, MR3 sees MR1 advertising
> access with a better signal strenght, and thinks incorrectly that it
> would be a good idea to attach to it. So it decides to attach to MR1
> instead. However, MR3 keeps its old attachment running until it has
> completed the attachment to MR1;

Claiming that MR3 keeps its old attachment involves something very 
difficult that touches on multi-homing.  Would it be possible to 
describe the same loop detection problem but without the "keeps its old 
attachment" part?

Also, is it necessary to have _three_ MR's to describe the problem?  I 
think only two MR's would be sufficient to describe the problem.

> this implies the BU it sends via MR1 gets routed back to itself in a
> tunnel, and actually gets to the home agent via the still operational
> fixed attachment.

No.  If MR3 sends a BU when attached to MR1 then it is not capable of 
talking to its HA via the "still operational" fixed attachment.  In 
other words, it is impossible for MR3 to send the BU to MR1 and to still 
talk to its HA (unless it had two egress interfaces).

According to which rule would MR3 (1) send a BU to MR1 but (2) forward
packets coming from MR2 tunnelled towards HA, through AR? (1) and (2)
are entirely different L2 links, MR3 can not be attached to both
simultaneously, unless it has two egress interfaces.

> But after the BA comes back, MR3 detaches itself from the fixed
> network. As a result, we have a loop and no connectivity. Now try to
> send a data packet.> I would like to understand why this is not a
> problem. I'm sure I'm missing something obvious.

I would like to understand better how "loops" could become a problem, 
but w/o involving a MR wireless interface being simultaneously connected 
to two L2 links.  Is it possible?

To me, the loop detection problem as described up to now relates to the
"disconnected operation" problem described in sec B.5 of
draft-petrescu-nemo-mrha-03.txt and raised very early in the BoF by
members; this problem basically says that if the TLMR is not connected
to the infrastructure then communication between LFN's of different MR's
within the nested aggregation is not possible, even if they are
physically linked.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Dec 2003 14:59:00 +0100

Alex