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

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.
> >>          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?
> 
> 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: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 13:11:32 +0200

> Are you suggesting to remove chapter 7 and say nothing?

That would be one alternative yes. I think the draft
has too many options at the moment. (Another alternative
would be not have the static config option, that would
also reduce the number of options. But I see there is
some discussion about this already ...)

> presents itself at ND level.

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.

> comes home in extended mode, it may present itself in either way (NA or

Well, you could arrange for the MR to always use NEMO, even
when at home. Or forbid it to ever come home ;-)

> but I suspect there'd be more information such as MTU, bandwidth, and

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

> comply with MIPv6 as for the reqs on 8.1, 8.3 and MAY comply with 8.2.

Sounds ok.

> But I'm afraid that we need to extend 8.4 (for route setup) and to

Extensions are fine too.

> revisit 8.5 (to limit to MRHA tunnel, which is the requirement for

Probably ok too.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 13:11:32 +0200

Sounds ok.

Extensions are fine too.

Probably ok too.

--Jari

---

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

Pascal Thubert (pthubert) wrote:
> "routers" discussions in the v6WG list.

I would suggest keep that thread where it started.

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

I think there could be some confusion when using NINO in a MIMO device.

Alex

---

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

Alex

---

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

Jari Arkko wrote:
> That would be one alternative yes. I think the draft has too many 
> options at the moment. (Another alternative would be not have the 
> static config option, that would also reduce the number of options. 
> But I see there is some discussion about this already ...)

The first alternative sounds reasonable to me.  Keep both the implicit
and explicit network modes, and enhance the routing protocol section
over MRHA in an additional document.

Alex

---

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

Alex

---

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

>> But I'm afraid that we need to extend 8.4 (for route setup) and to

Extensions in new documents are even better, such as the base document 
stays short and digestible by the IESG.

Alex

---

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

Alex

---

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

> over MRHA in an additional document.

Alex, if there is a technical issue which needs a lot of text to
resolve, then maybe, yes. otherwise, I disagree.

Vijay

---

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

Vijay