Subject: [nemo] RE: Issue 10

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Aug 2003 08:04:24 +0100

Hi Vijay :)

Yes it globally makes a lot of sense. A few comments in line:

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: jeudi 31 juillet 2003 20:50
> To: Pascal Thubert (pthubert); [email-masked]
> Subject: Issue 10
> 
> hi Pascal and all,
> 
> I want to see if we can close issue 10.
> 
> Binding Ack status 143 is supposed to be used when the
> HA cant figure out which MNP belongs to the MR in the
> implicit mode. it is every essential to have this error
> status because we dont want the MR assuming that the HA
> has set up forwarding for the MNP when it actually didnt.
> it doesnt matter which mechanism (Prefix Table being one)
> is used by the HA in the implicit mode.
> 

Agreed, with restrictions below below

> status code 143 is not supposed to be used when an IGP
> is being run over the MR-HA tunnel. when an IGP is being
> used, the HA just waits for the routing protocol updates
> from the MR and does not attempt to create any routes if
> the BU did not contain any prefix information.
> 

Yes, that's the key. I would agree with the 143 if it was sure between
HA and MR that they are talking about implicit, the real one, as opposed
to static or IGP. That would be the only reason at this time to have an
implicit bit in the BU/BA, so that the HA can answer 143 if it is
expected to have MNP information in a Nemo specific config that we
usually refer to as prefix table, and can not find it.

So I'd say it's either (NO 143) or (143 AND implicit bit). What do you
think?

> there are basically three different mechanisms by which
> the MR propagates routes to the HA.
> 

(you do not seem to like them, but they are definitely in the picture)
0. static routes. The routes to the MNP is preinstalled and resident in
the HA(s), independently of the binding update or IGP activity between
the HA and the MR.

> 1. explicit mode. the Binding Update contains the prefix
>    information in the mobility options (Mobile Network
>    Prefix option or Mobile Network Prefix Length option)
> 
> 2. implicit mode. the HA figures out the MNP through
>    mechanisms not defined in the draft. a pre-configured
>    Prefix Table is one such mechanism that you can use.
>    a static route configuration (manually added) is
>    another one.
> 
> 3. IGP over the MR-HA tunnel.
> 
> I dont want to mix up (3) with (2). I would like to keep
> the IGP part separate from the rest of the specification.
> I am not too sure we have taken care of all the issues
> related to running an IGP over the tunnel.
> 
> does this make sense?
> 

Sure does. How about my comments ;) ?

Pascal

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 05 Aug 2003 10:51:27 -0700

> So I'd say it's either (NO 143) or (143 AND implicit bit). What do you

you are hung up on the prefix table. :) forget it for the 
moment. implicit mode was supposed to cover every mechanism 
under which the HA is in control of adding/activating/maintaining 
routes to the mobile network. if this is not clear in the 
spec, lets correct the text. the MR has control only in the 
two explicit modes and when an IGP is being run over the 
MR-HA tunnel.

FWIW, I dislike any mode where the MR is not in control. 
but that doesnt matter.

implicit mode includes static routes. it includes prefix
table. it includes any proprietary mechanism that you 
implement on the HA. it is internal to the HA and there 
is no interoperability problem. 

but if the HA for some reason is not able to setup 
forwarding to the mobile network in the implicit mode, 
then we need a Binding Ack status to indicate this. 

we can change 143 to mean "forwarding setup failed".

if we cant agree on this, I would suggest removing implicit
mode with static routes from the spec and writing up a short
separate spec on how to do it. we already have too many 
mechanisms/modes in the spec. I am not sure the IESG is 
going to like these many different mechanisms of doing the
same thing.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 05 Aug 2003 10:51:27 -0700

Vijay