Subject: [mobile-ip] host routes in the fast mipv6 draft

From: Michael Thomas <[email-masked]>
Date: Mon, 14 May 2001 09:53:29 -0700 (PDT)

I notice that there is provision for installation
of host routes in ARnew if there is a problem with
the IP address the MN wants to use. Two comments:

1) This should not be host route specific since
   there's now provision for moving prefixes

2) I don't see how this can work as stated. Since
   there's no communication with the intermediate
   routers before the join point, MN's traffic
   will go to ARold first. That implies that there
   would need to be route to MN on ARold as well
   as ARnew. If that's what was intended, it
   should be clarified.  Also: it seems a little
   vague on when the route should be deleted,
   and how the two routers would synchronize.

   I generally question where this requirement
   came from. It seems like it toes the micro
   mobility IRTF line pretty strongly. Would
   there be much harm from just omitting this?
   It doesn't seem to be part of the central
   mission of FMIP.

	   Mike

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 May 2001 06:29:05 -0400

Mike,

Just to clarify one thing...

In MIPv6 tunnels from Home Agents or oldARs terminate at the MN because the
address used to terminate the tunnel is the MN's current COA derived from
the prefix of the router the MN is currently attached to (=> the attendant
router already has a route for the COA towards the wireless interface)

In the Fast-MIPv6 draft we also allow the oldAR to forward packets to the MN
when its newCOA is still ambiguous. To do this the oldAR needs to send
packets to the MN's oldCOA  but this address belongs to the oldAR itself so
it needs to be encapsulated to another address. In the absence of a valid
newCOA for the MN we encapsulate the packets using the newAR's address for
tunnel termination. Tunneled packets will go to the newAR where they will be
decapsulated. Now note that the inside header's Destination Address is
oldCOA and that is why a host route is needed at the newAR...

Any better?

George

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 2:02 AM
To: [email-masked]
Subject: RE: [mobile-ip] host routes in the fast mipv6 draft

>  > GT> I think you are missing something here...The host route is used
when 
the
>  > MN needs to use its oldCOA at the newAR. In this case the oldAR needs
to
>  > tunnel packets with destination oldCOA to the newAR. The host route
(for
>  > oldCOA) is not to be installed anywhere but the newAR...The newAR needs
a
>  > route in its routing table pointing towards its wireless interface for
the
>  > MN so when packets get tunneled to it (from oldAR), the newAR is able
to
>  > delivere them to the MN over the air rather than send them back to the
>  > oldAR...
>  > NOTE: This has nothing to do with micromobility (and/or any of its
>  > denominations)
> 
>  > I this clearer?
> 
>    Nope, I'm really confused now :-)
> 
>    Did you actually mean a tunnel between ARold
>    and ARnew? I didn't see that anywhere. The
>    normal forward tunnel is between ARold and MN,
>    afterall. 
> 
>    In either case, however, ARold needs
>    to place the route in its database as well as
>    ARnew. Otherwise, it will keep routing the
>    packets out the old (wireless) interface as
>    normal, which is obviously not what you'd want.

Whether packets destined to oldCoA are tunneled to newCoA or newAR, there
needs 
to be a state on oldAR. Something like "send all packets destined to oldCoA 
through tunnel100". In one case tunnel100's end point will be newCoA, in
other 
newAR.

>    I think this is what you're trying to say
>    above, but you should probably make it clear
>    about the side effect on ARold as well.

This is the usual thing that happens with "forwarding from previous care-of 
address".

> 	     Mike

alper

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 16 May 2001 09:11:33 -0500

James,

Is there some RFC that defines host route in this manner? My definition
would have been a route entry in a route table of a router for a single IP
address.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 4:24 PM
To: [email-masked]
Subject: RE: [mobile-ip] host routes in the fast mipv6 draft

Mike & Alper,

>Alper Yegin writes:
needs 

other 
> > newAR.
>
>Alper,
>
>Understand that I wasn't on the design team, so
>I'm looking at this sort of like an outside reader
>would look at it. I didn't see where/how the
>tunnel would be terminated on ARnew in the draft.
>Did I miss something? This would be new
>functionality in ipv6 since it sounds like it's
>mimicing v4 FA functionality.
>

The draft is very unclear about how and when tunnels are set up. 
The term "host route" is used to refer to a tunnel being set up.
I've actually never heard the term host route used in this fashion.
Typically, a host route means "even though the dest address doesn't
match the subnet structure topologically, route the packet this way." 
With a tunnel, the dest address will always be topologically correct.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 16 May 2001 09:09:01 -0700 (PDT)

Glenn,

Not that I know of. I'm taking the definition from Radia Perlman's
"Interconnections" second edition.

		jak
		
>From: "Glenn Morrow" <[email-masked]>
>Date: Wed, 16 May 2001 09:11:33 -0500
>
>James,
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 17 May 2001 12:27:47 -0700 (PDT)

Mike,

(sorry for late response.)

We have the following mentions of this tunnel.

Section 2:

...
   If the new care-of-address is rejected by the new access router, the
   old access router sets up a temporary tunnel to forward packets
   destined for the mobile to the old care-of-address which will be
   temporarily hosted on the new access router. 

  ...
   
   If no valid new care-of-address is determined, the new access router
   will record the old care-of-address, de-tunnel the packets received
   in the tunnel from the old access router and deliver them to the
   mobile node.

Although it's implicitely mentioned here, we can do a better job and explicitely 
talk about tunnel end points. And yes, I understand you are an outside reader, 
and your comments are very welcome. It would be hard for us tho catch this kind 
of improvements.

alper

---

From: kempf <[email-masked]>
Date: Thu, 17 May 2001 19:09:19 -0700 (PDT)

Alper,

As I mentioned in my reply to Raj about the timing, I think newAR needs
to arrange a reverse tunnel back to oldAR, otherwise, the real time
stream may stall because the mobile's packets may not get out. If
they have the oldCoA as the dest addr, they will not be topologically
correct at oldAR and so oldAR may drop them if egress filtering is on.

Also, if there is a forward and reverse tunnel from oldAR to newAR, I'm
curious why MN needs to do a BU/BACK back to oldAR? The mobile will
be getting its packets, why should oldAR have to know, except to break
down the tunnel, and it could be informed by newAR just as soon as
the Neighbor Advert is received. This would save one round trip
over the air for the mobile.

		jak

>Date: Thu, 17 May 2001 12:34:29 -0700 (PDT)
>From: Alper Yegin <[email-masked]>
>Content-MD5: TnmDYGQknEZ2w/+jW+QlUQ==
>List-Owner: <mailto:[email-masked]>
>
>Jim,
>
>That shouldn't be the case. As George explained out earlier, host routes are 
>created on the newAR, to point to MN's oldCoA. They are not used on oldAR, or 
>for tunnels. If you can point us where draft says or implies so, we can fix it.
>
>alper
>
>

---

From: kempf <[email-masked]>
Date: Thu, 17 May 2001 19:12:35 -0700 (PDT)

>I don't see how this can possibly work unless the
>route is also installed on ARold. Otherwise it
>forward it out the wireless interface as usual.
>
>As I've said before, I'm sort of worried about how
>this interacts with other routing protocols, and
>especially how it converges when the routes are
>deleted. What would happen, for example, if the
>host route were propogated by OSPF while the
>tunnel was up?
>

I have to agree with Mike here. I don't see the need 
for a host route if there's a tunnel set up.

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 18 May 2001 18:09:44 -0700 (PDT)

Jim,

> curious why MN needs to do a BU/BACK back to oldAR? 

Which BU/Back is this? This is not the F-BU/F-Back that was exchanged before 
this tunnel gets created. ??

> The mobile will

alper

alper

---

From: kempf <[email-masked]>
Date: Fri, 18 May 2001 17:29:37 -0700 (PDT)

Alper,

>this tunnel gets created. ??

The F-BU/F-BACK can occur either before or after the L2 handover. If
the tunnel isn't created until the F-BU/F-BACK is exchanged, there
is no point in creating it. I thought the point of the tunnel was
so that MN can use old CoA until the F-BU/F-BACK completes. But since
MN already knows is new CoA (via the RtAdv), and since it can send
and receive packets using its old CoA via a bidirectional tunnel
through old AR, what is the point of the F-BU/F-BACK? 

		jak

---

From: Alper Yegin <[email-masked]>
Date: Tue, 22 May 2001 10:52:30 -0700 (PDT)

Jim,

> so that MN can use old CoA until the F-BU/F-BACK completes. But since

Basically this tunnel accomplishes "forwarding from previous care-of address". 
It's not created until oldAR receives a F-BU, and a HACK. Depending on whether 
newCoA is valid or not, this tunnel's end point becomes either newAR or newCoA.

Through this tunnel, packets destined to oldCoA are either shuttled to newAR or 
MN at its new point of attachment. In the former case, newAR needs to have a 
host route to deliver packets to MN.

> through old AR, what is the point of the F-BU/F-BACK? 

Until F-BU is received by oldAR, there's no tunnel. Only if MN doesn't receive 
F-BACK, then it sends another F-BU after attaching to new link. Otherwise, F-BU 
is sent to oldAR while MN is still attached to old link.

I hope this clarifies...

alper

alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 22 May 2001 11:01:05 -0700 (PDT)

Mike,

>  > This must be preventable. Otherwise same OSPF might also propogate the host 
>  > routes (for home addresses) on the Home Agent.
> 
>    This is why I'm worried about this feature of the
>    FMIP draft altogether as I don't get the impression
>    that the ideas are fully baked. You say that it
>    must be prevented, but in fact, if it were propogated

I'm trying to point out that the potential problem you are saying is not 
specific to FMIP. If there's such a problem, it'll also hit base Mobile IPv6, as 
there are host routes on the Home Agent for each mobile node that's away from 
home (pointing to respective tunnels).

>    it would produce least cost routing, and bypass 
>    ARold altogether. Under normal circumstances,
>    that would be a Good Thing. 
>  
>    Also: I generally think that this is going
>    into the same design territory that got moved
>    into the IRTF for the micro mobility work. I
>    think there's more at stake here than meets
>    the eye.

Are you saying this becase there is one (oldCoA -> tunnel) and sometimes two 
(oldCoA -> newlink) host routes? Note that these are "temporary" host routes 
used to establish forwarding from previous care-of address.

alper