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.