Subject: RE: [nemo] RE: Issue 6

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Jul 2003 14:05:44 +0100

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: mercredi 23 juillet 2003 19:33
> To: Pascal Thubert (pthubert)
> Cc: Jongkeun Na; Kent Leung (kleung); S. Felix Wu; [email-masked]
> Subject: Re: [nemo] RE: Issue 6
> 
> "Pascal Thubert (pthubert)" wrote:
> >
> > > I disagree. it is always good to have an error message
> > > if something goes wrong. the MR shouldnt assume the HA
> > > has setup forwarding for the Mobile Network, when the
> > > HA actually didnt. the MR has now way of figuring out
> > > whats wrong, if packets from the CN to MNNs are dropped
> > > at the HA.
> >
> > Then you do not want implicit mode at all.
> 
> Pascal,
> 
> please read the text under implicit mode again.
> 
>     Implicit:
> 
>          In this mode, the Mobile Router does not include either a
>          Mobile Network Prefix Option or a Mobile Network Prefix
Length
>          Option in the Binding Update (but it does include the Home
>          Address Option in the Destination Options header, as all
Mobile
>          Hosts do).  The Home Agent can use any mechanism (not defined
>          in this document) to determine the Mobile Network Prefix(es)
>          owned the Mobile Router.  One of the possible mechanisms is
>          where the Home Agent maintains a Pre-configured Prefix Table
>          listing all the Mobile Network prefixes owned by a particular
>          Mobile Router.  This table is keyed on the Home Address of
the
>          Mobile Router.
> 
> it says the Home Agent can use any mechanism. we suggest
> Prefix Table as one of the mechanisms. static routes (as
> you call them) is another mechanism. otherwise static
> routes are not really mentioned anywhere in the spec.

I love this text. Never asked to change it :) Just pointed out that we
may find useful to differentiate implicit source (static route, prefix
table and routing protocol over MRHA, the latter opening to unauthorized
cases) by maybe a more precise naming?

> 
> > Because even if the HA has
> > some prefixes listed for that MR in its prefix table, the may not be
> > correct, or complete. Unless the HA lists the prefixes it knows of
in
> > the B-Ack. Again I'm talking about the real implicit, the one with
> > prefix table, as opposed to static routes or IGP over MRHA.
> >
> > Consequence, if you want full checking, you need implicit, plus the
list
> > of accepted prefixes in the B-Ack if not all.
> >
> > In the latter case, (IGP over MRHA) the HA can not know at B-Ack
time
> > whether it will ever get the right routes,
> 
> it doesnt have to. all it needs to do is lookup local
> configuration to figure out if it is running a IGP
> with the mobile rputer. if the HA realizes it is not
> running an IGP, neither there is any information in
> the prefix table, then it sends 143 status code in
> the Binding Update if the MR sends a Binding Update
> using implicit mode.
> 

You do not know if both ends are configured correctly and whether the
exchange will work??? So a lot of bother for little value.

Again, you need explicit to make sure of full agreement. And there's
still room for a config error that would forget a prefix in the BU
depending on the implementation. 

So code 143 is a lot of effort for no big result. I'm still for removing
that small text...

> Vijay
> 
> > or whether the MR will try
> > anything. So the code 143 is straight infeasible.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Jul 2003 10:32:45 -0700

I created a new issue 10 because we have digressed
from the original issue 6. please lookup
http://people.nokia.net/vijayd/nemo/issues.html for 
the current list of issues.

> cases) by maybe a more precise naming?

I am not sure. I want to keep the IGP over MR-HA tunnel
separate from the rest of specification. I am not too
sure that we have taken care of all the issues related 
to running IGP over the tunnel. if later there are any 
problems with it, it would be easy to deal with it. if
you notice, running IGP over the MR-HA tunnel is 
described in section 8 and is not mentioned anywhere 
else in the draft. I think it is sensible to keep it 
that way.

> exchange will work??? 

agree, you can never be sure about that.

> So a lot of bother for little value.

??? since we can never be sure if things at both end
are configured correctly, we need an explicit error
status in the Binding Ack (in the implicit mode) so 
that the MR does not assume everything is fine at the 
HA, when the HA couldnt actually figure out the prefix 
corresponding to the MR.

> So code 143 is a lot of effort for no big result. 

could be. but I think it shouldnt be removed.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Jul 2003 10:32:45 -0700

Vijay