Subject: RE: [nemo] Soliciting comments on draft-ietf-nemo-v4-base-00.txt

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 27 Mar 2006 11:03:00 -0800

as Terry said, not all concepts in MIPv4 need
to be carried over to NEMOv4. 

> The draft makes no attempt to incorporate Foreign Agents into the
> solution. Why is that? I think it would be trivial to add FA 
> support for
> mobile routing and avoid the MR HoA to HA tunnel when FAs are 
> used. The
> tunnel is a good idea when we are dealing with RFC3344 FAs 
> but there is
> no reason not to get rid of it when the FA knows about mobile routing.
> The draft also does not discuss agent advertisements for HA 
> and FA which
> can be used to let the MN know whether Mobile Routing is supported or
> not.

the FA needs to be aware of the mobile network.
which means changes to how the FA works. it is
probably best if it is written up in a separate
spec.

Vijay

> 
> Please see more comments inline. Between other things, I am 
> making some
> suggestions about the way you use error codes which you 
> should consider.
> 
> Regards
> George
> 
> -----------------------------------------------------------------
> 
> 3.  Requirements
> 
> ....
>    o  The Mobile Network should be supported using Foreign Agents that
>       are compliant to RFC 3344 without any changes.
> 
> 
> GT> While it is important to be able to work with RFC3344 
> FAs, we should
> also have extensions to FAs that make this better.
> ...
> 
> 4.2.  Mobile Network Acknowledgement Extension
> 
>    ...  A Registration
>    Reply may have either or both Implicit Mode Acknowledgement or
>    Explicit Mode Acknowledgement extensions. 
> 
> 
> GT> The last "or" should be "and" I think?
> 
> ..
> 5.  Mobile Router Operation
> 
>   ...
> 
>    o  Set up default route via this tunnel or roaming interface when
>       registered with or without reverse tunneling, respectively
> 
> GT> What is a roaming interface?? I think I know what you mean but is
> roaming interface a well defined term?
> 
> GT> This section I think should also say something about what 
> the Mobile
> Router is supposed to do if it receives an explicit mobile network ack
> extension for a prefix that it did not explicitly ask for i.e., it
> should make the prefix available to the mobile network, route packets
> for it etc etc.
> 
> 5.1.  Error Processing
> 
> ..
> 
>    If the value of the Code field in the Registration Reply is set to
>    HA_MOBNET_UNSUPPORTED or HA_MOBNET_DISALLOWED, then the 
> Mobile Router
>    MUST stop sending Registration Requests with any Mobile Network
>    Prefix extensions to that Home Agent.
> 
> GT> How would an HA that does not support Mobile networks know to send
> the HA_MOBNET_UNSUPPORTED error code??? You in fact have solved this
> problem later by saying that if the HA does not include a 
> mobile network
> ack extension the MN should assume that the HA does not support mobile
> networks. 
> 
> GT> Also, why don't you just use the code in the mobile network ack
> extension to indicate mobile network specific errors and use 
> an existing
> code in the registration reply header? I think this would 
> make backwards
> compatibility easier. 
> 
> ...
> 
> 6.3.  Mobile Network Prefix Registration
> 
> ...
>    
>   If the check fails or
>    if the Mobile Router is not authorized for using any of those
>    prefixes, the Home Agent MUST reject the registration request with
>    Mobile Network Acknowledgement Extension code MOBNET_UNAUTHORIZED.
> 
> GT> This may be an optimization but since you have code fields in the
> mobile network ack extension, why can't you reject the specific prefix
> that was not allowed and accept everything else?
> 
>    On the other hand, if check passes for every requested 
> Mobile Network
>    Prefix, the Home Agent MUST attempt to set up forwarding 
> for all the
>    Mobile Network Prefixes included in the registration request.  If
>    forwarding set up fails for any of the prefixes, the Home 
> Agent MUST
>    reject the registration request with Mobile Network Acknowledgement
>    Extension code MOBNET_FWDING_SETUP_FAILED. 
> 
> GT> Could you clarify what problem you are trying to solve with this?
> Why would forwarding fail???
> 
> 
> 7.  Data Forwarding Operation
> 
>    For traffic to the nodes in the Mobile Network, the Home Agent MUST
>    perform double tunneling of the packet, if the Mobile Router had
>    registered with a Foreign Agent care-of-address.  
> 
> GT> As I already said IMO this is not acceptable and there is 
> no reason
> why the FAs can not support mobile network and avoid the additional
> tunnel.
> 
> ...
> 
> 9.  Security Considerations
> ...
>    All registration requests and replies MUST be authenticated by the
>    MN-HA Authentication Extension as specified in ([RFC3344]).  
> 
> 
> GT> Why are you changing what the RFC3344 requires? The RFC 
> requires an
> authorization enabling extensions of which MN-HA auth is only one. I
> think this should be kept as is.
> -------------------------------------------------------
> 
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 31 Mar 2006 07:38:45 -0800

Alex,

Thanks, you have been very accommodating....somewhat uncommon in the
IETF these days :-)

Some more inline...

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, March 31, 2006 10:12 AM
To: Tsirtsis, George
Cc: [email-masked]
Subject: Re: [nemo] Soliciting comments on
draft-ietf-nemo-v4-base-00.txt

...

>>> GT> This section I think should also say something about what the
>>> Mobile Router is supposed to do if it receives an explicit mobile
>>>  network ack extension for a prefix that it did not explicitly
>>> ask for i.e., it should make the prefix available to the mobile
>>> network, route packets for it etc etc.
>> You mean it "shouldn't" instead of "should"?
>> 
>> New text proposed, in section 5 "Mobile Router Operation":
>> 
>> As per RFC3344, when the Mobile Node sends a Registration Request 
>> it saves the following information: -  the link-layer address of
>> the foreign agent to which the Registration Request was sent, if 
>> applicable, -  the IP destination address of the Registration 
>> Request, -  the care-of address used in the registration, -  the 
>> Identification value sent in the registration, -  the originally 
>> requested Lifetime, and -  the remaining Lifetime of the pending 
>> registration.
>> 
>> Additionally, when the Mobile Node acts as a Mobile Router it 
>> should also save: -  the Mobile Network Prefix(es) it counts using
>> if registration successful. -  the respective prefix length(s).
>> 
>> In section 5.1 "Error Processing"
>> 
>> It is possible that the Mobile Router receives a Registration Reply
>>  containing prefixes for which it did not send a Registration 
>> Request. (The Mobile Router can check this with the help of
>> information it saved prior to sending this Registration Request.)
>> In such case the Mobile Router SHOULD...
>> 
> 
> [GT>] SHOULD...what? I am missing what you are trying to say here.

I thought you suggest and have an idea about what should the MR do when
it receives a prefix in the RegRep for which it didn't send a RegReq. I
think the MR shouldn't do anything.

[GT>] Hmmm, sorry I might be confused. Doing nothing (i.e., ignoring
them) makes sense if the  Mobile Network Extension Acks indicates they
are in "explicit" mode. I thought that in "implicit" mode the MR will
send a normal RFC3344 RREQ and it will received a RREP with one or more
prefixes indicated in Mobile Network Extension Acks, with Code field set
to "implicit mode". 
If I understood this correctly then the MR must do something, no? It
basically needs to treat these prefixes as if it requested them in
"explicit" mode.