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

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 24 Mar 2006 22:11:50 -0800

Hi,

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.

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: "Davis, Terry L" <[email-masked]>
Date: Mon, 27 Mar 2006 07:28:53 -0800

George

Not all of believe that carrying forward the HA concepts from mobile IP
to NEMO is the right thing to do!

I remain unconvinced that any technology based on HA concepts will ever
fully service the needs of the global aviation and maritime industries.
HA works nicely in relatively small geographic areas where latency is
not a problem, but it does not appear to be adequate for large globally
mobile platforms.

Take care
Terry

> -----Original Message-----
> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Friday, March 24, 2006 10:12 PM
> To: Alexandru Petrescu; [email-masked]
> Subject: RE: [nemo] Soliciting comments on
draft-ietf-nemo-v4-base-00.txt

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Mar 2006 16:37:34 +0200

George, thanks for the valuable comments.  Let me separate the FA
discussion in a different thread.  Basically, co-authors and myself 
would be supportive for an additional NEMOv4-aware FA document, but 
separated from the current spec.  We tried to keep the current spec 
simple and essential, keeping the opportunity open for FA enhancements.

Tsirtsis, George wrote:
> solution. Why is that?

In an initial un-published version of the document we've extensively
treated some FA enhancements for NEMOv4.  That included some new options
and messaging.  But we wanted to keep the base spec simpler.

> 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.

Eliminating the MN-side tunnel by using FA support would be indeed an
advantage.  But in terms of spec size it will certainly be a lengthening
factor.

> 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.

Indeed, it doesn't.  Co-authors and myself think FA would be a valuable
feature to add, but as a separate document, especially knowing that
during the last meeting it was stated that the current document is ready
for IESG.

If you're interested in writing an FA NEMOv4 document I'd be supportive.
  If you need I can send the initial FA text we had.  Reviewing back and
forth can happen.

> 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. ...

Ok.

> 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.

It can.  But the base initial step should be that the MN should do it.
Would you agree.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Mar 2006 20:36:18 +0200

> GT> The last "or" should be "and" I think?

Would a clearer reformulation:

   A Registration Reply may contain any non-zero number of Explicit Mode
   and Implicit Mode Acknowledgements sub-types. Both sub-types can be
   present in a single Registration Reply.

work?  Any other?

> roaming interface a well defined term?

Right... No, "roaming interface" is not defined anywhere.

RFC3753 "Mobility Related Terminology" does define "egress interface". 
"Egress interface" is used by RFC3963 NEMOv6 with the same same meaning 
as in this draft.

However, "egress interface" is (1) a term largely used in contexts other 
than mobility and (2) confusing.  In current speech the meaning of 
"egress" depends largely on some particular topology.  With some 
sketches just turn the page 180 degrees, or the point of view, and 
"egress" becomes "ingress".  What's "egress" for me is "ingress" for my 
ISP.  "Roaming interface" can't be confused this way.

I do agree with the textual definition in the terminology RFC and with 
its use in RFC3963 NEMOv6, but less with using text "egress".

So I was thinking "roaming interface" may be fine.  Or otherwise "mobile 
  interface"?

Would it be ok substituting "egress interface" for "roaming interface" 
in this draft?  Any other term for this interface?

> should make the prefix available to the mobile network, route packets

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...

> ack extension the MN should assume that the HA does not support mobile

HA_MOBNET_UNSUPPORTED for HAs that today support MRs and tomorrow no and 
after tomorrow again yes?

HA_MOBNET_UNSUPPORTED for migration?  Somebody may implement a 
pre-production HA that doesn't "yet" support MRs and then on day D 
switch to a full implementation, thus easing informing the remote MN it 
could become an MR?

Or do you propose eliminating HA_MOBNET_UNSUPPORTED altogether?

> code in the registration reply header?

We use error codes both in the RegRep _and_ in the Mobile Network Ack 
extension to offer finer control to HA and MR.

The error codes in RegRep are high-level, like "NEMO not supported" or 
"this HA can't allow this MR's Home Address be a MR".  The ones in the 
extension are specific to particular Mobile Network Prefixes and their 
faults.

> I think this would make backwards compatibility easier.

How?

Error codes in the RegRep header are defined as extensible (start from 
127 and above or so).  A legacy non-NEMO MN not understanding some error 
code there would just drop it or so.

> that was not allowed and accept everything else?

For saving error code space in the regrep header?

For finer per-prefix control?

Probably one way would be to have one error code in the regrep header 
saying "see below there is some error with some prefix" and below it 
have extensions each specifying which prefix is successful and which not 
and how.

Is this what you mean?

> Why would forwarding fail???

No disk space, not enough virtual memory at HA, etc.

When HA receives a request to setup forwarding it usually creates new 
data structures for that particular prefix.  If not enough space then 
setting up forwarding may fail, no?

Calling a ioctl SIOCADDRT to set up a new route to a potentially 
"virtual" interface may fail for a number of additional reasons, like no 
right metric ("1" should be fine), no more "virtual" interface space 
(number of possible virtual interfaces is defined at boot time) and more 
I believe.

Do you think this option is not needed?

> think this should be kept as is.

Ok, what text in rfc3344 says that the Mobile-Home Authentication 
Extension is only one possibility and others are possible?  I think it's 
the only possibility.  Is the alternativity opening you're talking about 
the choices around MD5?

But I do agree we should have a NEMOv4 Security Considerations section 
very similar and sourced from the rfc3344.  We tried to do just that.

The HA ingress filtering text may be improved to express it as 
"additional" rules to the ones in rfc3344.

Alex