Subject: RE: [nemo] Editorial comments from Jari Arkko

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

> 
> >>       Prefix Table
> >>
> >>               It is a list of a Mobile Network Prefixes indexed
> >>               by the Home Address of a Mobile Router.  The prefix
table
> >>               is managed by the Home Agent and is used by the Home
Agent
> >>               to determine which Mobile Network Prefixes are owned
> >>               a particular Mobile Router.  This is an optional data
> >>               structure.
> >>
> >> JARI: Really? Why is it optional? Sounds mandatory to me...
> >
> >
> > well, there could be scenarios where the mobile routers are not
> > expected to misbehave. and there could be other ways for verifying
> > this. so we left it optional. I dont mind making it mandatory.
> 
> That would make sense. Imho all nemo-based products
> should support this function.

Yes, and it's very abstract. It can be implemented as a set of static
routes.

> 
> >>    A Mobile Network is a network segment or subnet which can move
> >>    and attach to arbitrary points in the Internet.  A Mobile
Network
> >>    does not allow any transit traffic and can only be accessed via
> >>    specific gateways called Mobile Routers that manage its
movement.
> >>
> >> JARI: The above is a bit unclear. I think you mean that the
> >>       nodes behind the MR can't access the internet directly, they
> >>       have to go through the MR and the HA.
> >
> >
> > actually no. it means traffic to the Mobile Network can reach
> > the Mobile Network only through mobile routers. it also says
> > mobile networks are not transit networks. always stub networks.
> 
> I'm still having some difficulty with the transit network
> part. I looked up one definition of a transit network from RFC
> 1584, which talks about the number of attached routers. However,
> in the nested nemo case you could actually have several attached
> routers, hidden inside tunnels. And would you allow multiple
> MRs per Mobile Network or not? I think not, because then you
> would appear like a transit network, according to the
> RFC 1584 definition. OTOH, I'm not sure why such a limitation
> would be necessary in the technical sense.
> 
> Is it allowed for an MR to have two home agents, home addresses,
> and network prefixes? Is there any case where the Mobile Network
> would become a transit network in such a situation?

Jari:

This is entering the multihoming discussion, again out of scope. We
tried to define formats that would allow for it. But we do not detail
how that works. Like RO, multihoming in Nemo has multiple faces (see
http://www.ietf.org/internet-drafts/draft-charbon-nemo-multihoming-evalu
ation-00.txt)

> 
> How about this:
> 
>     A Mobile Network is a network segment or subnet which can move
>     and attach to arbitrary points in the Internet.  A Mobile Network
>     can only be accessed via specific gateways called Mobile Routers
>     that manage its movement. Mobile Networks have (always exactly)|
>     (at least) one Mobile Router serving them.
> 
> >> JARI: Question: is the prefix for a MR always unique? This seems
unclear.
> >>       Can other MRs have the same prefix, can the HA have the same
> >>       prefix as the MR?
> >>
> >
> > more than one MR can be assigned a prefix. one can imagine having
> > two routers for the same mobile network. the HA will probably not
> > have the same prefix as the MR.
> 
> Ok.
> 
> >> JARI: Come to think of it, both the MR and the HA must know the
> >>       assigned prefixes beforehand in any case, so I wonder if we
> >>       need to communicate the prefixes at all?!? Can you cite an
> >>       example where the HA would give a prefix to the MR without
> >>       knowing it belongs to it? Or is the idea to prepare for the
> >>       eventual bootstrapping support in MIPv6?
> >
> >
> > well, we still havent figured out how to do prefix delegation
> > to a mobile router. there is a draft by Ralph Droms on extending
> > DHCPv6 prefix delegation for NEMO. not a WG draft yet.
> >
> > and there is this scenario, where the mobile router is delegated
> > more than prefix, but it could decide to setup forwarding for just
> > one prefix instead of all prefixes. this cant be dont without
> > carrying prefix information in the Binding Update.
> 
> If this is the case, perhaps you could remove the static alternative
> then? My concern is mainly the number of alternatives. I'd rather
> have less alternatives, even if the BUs would carry a few more bytes
> in some cases...
> 

Halt! If there's only one thing left, in my mind it's static. The way I
see the original question is more like: why do we need explicit if the
HA has the prefix table anyway for authorization purposes? For the lack
of a better one, my answer is that the authorization may be more global
or turned off by policy.

Having more then one mode opens for different deployments. MRs do not
have to support them all, only the HAs do (we definitely should write
our own version of the MIPv6 8.4 and 8.5 chapters). And static comes
free with the HA. So why remove it?

> >>
> >> JARI: This is only a drawback if the routes would be reachable
somewhere
> >>       else. Given the desire to keep the Internet routing pretty
> >>       stable, I would argue that we shouldn't be moving routes all
> >>       over the place. Hence it would be sufficient if the routes
> >>       were on one place only.
> >
> >
> > well, its a drawback in the sense, the Home Agent has routing table
> > entries even though the mobile router is currently dormant or just
> > disconnected.
> 
> Its additional state yes, but packets destined to the prefix will
> be dropped on the floor in any case.

This is why I like static :)

> 
> >> JARI: What happens in the statically configured route case if R=0?
> >>       Reading on...
> >
> >
> > there are two static cases.
> >
> > 1. implicit mode
> > 2. dynamic routing protocol updates
> >
> > which one are you referring to?
> 
> Either one.
> 

I have trouble to call 2. static... For 1., the spec says not to install
forwarding, but on the other hand it's already installed and can hardly
be removed (should we send an alert and ask the operator to
reconfigure?). So I'm not sure of the value of r=0 in implicit mode. We
discussed that already and I'm still not convinced. 
> 
> I think the key question here is whether running the routing
> protocol makes a difference in the end. Is it used to avoid
> sending useless packets to the MR? Most likely such traffic
> would be minimal, given that there would be no response from
> the networks that are currently disconnected. Or is it used
> to make some real routing changes, such as switching the
> traffic from one HA site to another one? If yes, this needs
> to be supported.
> 
> Like I said above, I'm primarily concerned about the number
> of alternatives and that's why I'm trying to see if we really
> have a true need for all three, i.e. static, BU, and routing
> protocol alternatives.
> 
The routing protocol thing could be considered out of scope. Once the
MRHA tunnel is established, any manual tunnel can be used to carry IPv4,
multicast, or an IGP back home. Do we have to explicitly say all this?
Maybe we could move it to "usages"?

Pascal

---

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

> Maybe we could move it to "usages"?

That would work for me. I like modular specifications ;-)

--Jari

---

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

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 14:53:03 -0800

> Maybe we could move it to "usages"?

Pascal,

the usages document is not the answer to everything. you are
suggesting using the usages document for everything that is
thrown out of the basic spec. :)

you have to keep in midn that it is targeted at informational.

infact as you say, running a routing protocol over the
bi-directional tunnel is not very different from say running
DHCP prefix delegation over the tunnel. it is just some
traffic. but in this case, traffic which affects routing
tables on the Home Agent and the mobile router. we need to
say how it interacts with sending routing information through
the binding updates. so, I think it should stay in the basic
spec.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 14:53:03 -0800

Pascal,

Vijay