Subject: [nemo] review of the nemo basic spec

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2003 19:26:45 +0200

I recently read the Nemo spec and have some questions and comments,
embedded in the document itself:

http://www.arkko.com/publications/mipv6/nemo/nemo_basic_review.txt

For your convenience, I have copied the main questions and
comments below:

       Technical: This is pretty solid work (especially for an -02) but
       I still had the a number of issues with it. Here are the main
       ones:

          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.

	    I understand that these alternatives can be useful in some
	    specific contexts. But reducing them would contribute to a
	    shorter and easier-to-implement spec.

          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.

          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?

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

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

          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.

          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: "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)
> 	    option, and don't support the static and routing protocol

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.

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

> 	    multicast addresses, for instance?

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

> 	    some parts? Or say at least that you MUST support

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?

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

> 	    response, would probably work smoother.

Could you please elaborate?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 09:25:27 -0000

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

Are you suggesting to remove chapter 7 and say nothing?

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

This relates to the "ND model for routers" and the "ROUTERS" vs.
"routers" discussions in the v6WG list. A MR is always and definitely a
router, but we are talking here about the model that its applies when it
presents itself at ND level.

Maybe the ND model is a bit limited. When a MR comes home in aggregated
mode, it presents itself as a Node (NA), but it would be beneficial to
advertise directly the prefixes for its MNPs, as not onlink. When a MR
comes home in extended mode, it may present itself in either way (NA or
RA), both unsatisfying. 

The model I'm missing in ND is the "Network in a Node". For a Node with
a prefix inside it or behind it, or more generally a proxy. A Network in
Node Option (Nino) would help. Maybe it's just a prefix option in a NA,
but I suspect there'd be more information such as MTU, bandwidth, and
other metrics.
> 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.

Being a CN is a piece of work that may be useless and costly for a MR to
implement.
If we go through the requirements, it seems fair to say that MR MUST
comply with MIPv6 as for the reqs on 8.1, 8.3 and MAY comply with 8.2.
But I'm afraid that we need to extend 8.4 (for route setup) and to
revisit 8.5 (to limit to MRHA tunnel, which is the requirement for
basic).

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 09:28:57 -0000

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: mardi 2 décembre 2003 00:09
> To: Vijay Devarapalli
> Cc: Pascal Thubert (pthubert); [email-masked]
> Subject: Re: [nemo] review of the nemo basic spec
> 
> Vijay Devarapalli wrote:
> 
> >> 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?
> >
> >
> > 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 ;-)
> 
> > 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?
> 
> 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?
> 

My point exactly. I agree we need both, since DHAAD is not always wanted. 
Note that for DHAAD, we need also to modify the Router Advertisement Message to add a Nemo bit...

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 10:43:13 -0000

> Sent: mardi 2 décembre 2003 10:29
> To: Pascal Thubert (pthubert)
> Cc: Vijay Devarapalli; [email-masked]
> Pascal Thubert (pthubert) wrote:
> 
> Or a vector of capabilities bits for every HA... ok, maybe
> that's an overkill.
> 
Well I think it's not in the end. This is why we started HAHA. But for Nemo, maybe yes :)

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 12:57:13 -0000

> An MR is a router between its ingress and tunnel interfaces,
> and a host on its attachment interface. When home, MR is a complete
> router. When it is still figuring out whether its at home or not,
> it is a router only on its ingress interface and a host on the
> egress interface.

Technically, since the MR forwards packets across interfaces (including
the egress) it is still a router... We are talking about the ND model
that it uses to present itself at the egress, right? ND was not designed
to represent a node with a subnet in or behind it, a node that does not
wish to be used as a router by other nodes but can receive packets or
bridge them for that particular subnet. We're missing NA for a subnet,
we're missing proxy NA...  

> Well, you could arrange for the MR to always use NEMO, even
> when at home. Or forbid it to ever come home ;-)
> 
The work on proxy ND has already started. ND is being reworked. I think
it's possible to express what we would really like to have for MRs in a
problem statement and see with v6WG whether someone is willing to help.
What do you think?

> If the answer to "is this node a router" is something else than
YES/NO,
> we are now finding out that all the rules in the RFCs based on this
> question are starting to look funny...
> 
> But what to do about that? I don't know yet...
> 
:)

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 12:57:13 -0000

YES/NO,
:)

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 14:58:26 -0000

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: mardi 2 décembre 2003 09:04
> To: Jari Arkko
> > 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)?
> 
If you consider the lifetime of a MR, it may happen that a configuration that is right for some time becomes wrong. For instance if HAs are reassigned for some reasons overtime. I agree with you it's not a critical thing, but my inclination is to add the check.  

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 14:58:26 -0000

Pascal