Subject: [Mip4] Comments for draft-gundavelli-mip4-multiple-tunnel-support-00.txt

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 5 Jan 2009 09:00:01 +0800

Hi Sri,

I read your draft Multiple Tunnel Support for Mobile IPv4.
I think it is a very useful draft since multihoming is essential in any
mobility protocol. 

This is an interesting work in MIPv4 but nevertheless, I have some
questions.

In page[4], only bulk re-registration is defined. Furthermore, in the
draft bulk registration is not supported. Is there any reason for this?
Or do you plan to have bulk registration support in future revisions.
MONAMI6  MCoA draft has support for bulk registration and why is this
not supported in your draft?

Figure 1 in page 5 shows multiple interfaced MN making simultaneous
attachment with and without using FA. Is the assumption such that the MN
uses co-located care-of address when there is no FA present and uses FA
care-of address when there is a FA present? Just a clarification
question...

It is mentioned in page 5 that the MIPv4 multiple CoA support informs
the HA the type of interface and capacity and so on. What is the need
for this? Current Monami6 MCoA draft which handles multiple CoA
registration does not have this information. Do you think this
information is useful for the network to set flow polices? It leads me
to another question that in any case, the available capacity in the
access network can be monitored by the network entities and informed to
HA and why should the MN send these information?

The term "throughput capacity" in page 5 is not very clear. Is it the
used bandwidth per MN or the available spare bandwidth? I think it would
be better if more clarity is given to this term. My understanding is the
spare bandwidth. If it is the spare bandwidth then again, another
question is how the MN gets such information. This is very much access
technology specific. 

A small typo in page 5,
"The throughput capacity of each of these tunnels is dependent on
      the access technology over which the mobile node is attached.  The
      mobile node notifies the interface properties for each attached
      interface and the home agent can user this as a metric for it
      traffic policies."
 the home agent can use this as a metric for it....

In page 7 the length field is mentioned to have length 6 octets. Is it
10 octets or 6 octets?

BID was defined in terminology section and it is again repeated in page
7. Possibly, such double definition can be removed. Again, it is
mentioned in page 7 that the BID can be an interface index assigned by
the operating system. Is this a preferred way of creating BID and
moreover if there are multiple BIDs per interface then what is the way
of generating the BIDs. In that case, it should not be tied to
interface...Correct me if I am wrong.

It is mentioned in page 7, that in deregistration request, the 'O' flag
must be set to 0. What is the reason for this? My understanding is that
deregistration has a special trigger to remove the bindings and what is
the reason for such setting of the 'O' flag.

In mobile node operation section, the first two bullets mentions about
MN returning home. It is not very clear the methods disclosed in the
first two bullets. Is there any difference between the first two
bullets. Perhaps more clarity in the text is useful.

Also, it is mentioned that simultaneously at home and away is not
supported in section 5.1. Again is there any reason and do you plan to
incorporate this simultaneously at home and away in the future revision.
I think this scenario is essential considering some deployments in 3GPP.
Even in the home network domain, such a scenario can exist due to
different mobility management mechanisms to handle different interfaces.

In "mobile node in foreign network" section in page 9, the first bullet
is a "SHOULD". Why is this so?  If the mobile node cannot see home
prefix then it is in foreign link. Then it is a MUST. Am I right to say
that?

What is the reason for this configuration parameter "Enable Multiple
Tunnel Support". Is it a static variable or dynamic. 

In page 9, there is a small typo error it should be "sought for".
o  If the value of the configuration variable,
      EnableMultipleTunnelSupport is set to a value of 1, then the
      mobile node SHOULD register a care-of address for each of those
      interfaces, by sending a Registration Request.  Each of the
      requests sent MUST contain the care-of address of the respective
      interface and the Multiple Tunnel Request extension reflecting the
      interface properties.  The mobile node MUST ensure that the
      Registration Request is routed through the specific interface for
      which the registration is sough for.

In page 9, in one before the last bullet it says that the MN 'SHOULD"
create a tunnel. I thought once it receives a positive ack, it MUST
create a tunnel.

In section 5.2 it is mentioned that the FA "should" check the
configuration variable. I think it should be MUST because it has a
Enable MultipleSupport variable enabled.

In section 5.2 it is mentioned that a MN connected to a single FA using
multiple interfaces. Is there a single tunnel for both interfaces or
multiple tunnels? Moreover, it is better to introduce this scenario once
supported configuration section is described. This is just a simple
suggestion.

In section 5.3 in HA operation, it is mentioned that MIPv4 RFC already
has multiple bindings support. It is not very clear from the text how
that is different from this multiple CoA address support disclosed in
this draft. Perhaps it is better to clearly distinguish the difference.
Sorry I haven't read the MIPv4 RFC in detail and was not very clear....

There is no clear differentiation between figure 4 and figure 5. What is
the difference? How is the registration done? It would be beneficial to
show how the multiple CoA support is achieved in such scenarios. This is
a useful scenario and is used in some SDOs. For example in Figure 4, it
seems single tunnel, so will the FA send all interface parameters in a
single registration and so on needs to be explained. This will be useful
for deployments.

These are some of my comments.
Thanks.

BR,
Mohana

--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 5 Jan 2009 15:14:07 -0800 (PST)

Hi Mohana,

Thanks for the review. Please see inline.

> not supported in your draft?

Support for bulk registration is within the scope of re-registration.
We want the registration message for a given CoA to be sent through
the same access network to which the given interface is attached. This
will ensure, it will work even in the presence of NAT and when supporting
RFC-3519. If we allow this for initial registration, that request will
go through only one specific path, which we dont want. So, the spec
allows bulk reg only for reregs, when nothing changes on the MN.

> HA and why should the MN send these information?

Access type is an important parameter for enabling any traffic policies.
The home agent cannot always monitor the characterstics of the access
network, specially in a unmanaged network, or for client-based mobility.
In the mobile router deployments for which this is more useful, the
home network will have no clue about access networks to which the
mobile router is attached. Registering the access type, will provide
the link characterstics to the home network. It knows about each of
tunnel paths and how it is tied to the air link on the mobile.

> question is how the MN gets such information. This is very much access

Ok. Will clarify this.

> the home agent can use this as a metric for it....

Ok.

> In page 7 the length field is mentioned to have length 6 octets. Is it

Thanks. It should be 10, excluding Type and Length fields.

> interface...Correct me if I am wrong.

Ok. Will fix it.

> the reason for such setting of the 'O' flag.

Since, for dereg all bindings are removed, the 'O' flag has little
purpose in that case and hence such restrction.

> bullets. Perhaps more clarity in the text is useful.

Ok

> prefix then it is in foreign link. Then it is a MUST. Am I right to say

The support for multiple interfaces/tunnels, requires some additional
clarity on when a mobile can be considered its at home. Sure, if the
home prefix is not seen, ie. if none of the interfaces are attached
to the home link. Will clarify.

> Tunnel Support". Is it a static variable or dynamic.

Its a knob to turn off the feature. Its a protocol config variable.

>      which the registration is sough for.

Ok

> create a tunnel. I thought once it receives a positive ack, it MUST

Ok.

> Enable MultipleSupport variable enabled.

Ok

> supported configuration section is described. This is just a simple

There is only tunnel on the network side, if the FA-COA is the same.
Will clarify.

> Sorry I haven't read the MIPv4 RFC in detail and was not very clear....

There is simultaneous binding support, where every packet is sent on
all tunnels. Its different from that sense.

> the difference? How is the registration done? It would be beneficial to

There is a tunnel for each CoA, so the difference is 2 tunnels vs 1 
tunnel.

> These are some of my comments.

Thanks for the review.

Regards
Sri

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 6 Jan 2009 11:04:34 +0800

Hi Sri,

Thanks for reply. Please see in-line.

BR,
Mohana 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sri Gundavelli
> Sent: Tuesday, January 06, 2009 7:14 AM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: Re: [Mip4] Comments 
> fordraft-gundavelli-mip4-multiple-tunnel-support-00.txt
> 
> Hi Mohana,
> 
> > I think it is a very useful draft since multihoming is essential in 
> > any mobility protocol.
> >
> We want the registration message for a given CoA to be sent 
> through the same access network to which the given interface 
> is attached. This will ensure, it will work even in the 
> presence of NAT and when supporting RFC-3519. If we allow 
> this for initial registration, that request will go through 
> only one specific path, which we dont want. So, the spec 
[Mohana] Ok, Understand. Specially, since this is IPv4 addresses and
highliy likely that NATs will
be present, it may be advisable to avoid bulk registration.

> > attachment with and without using FA. Is the assumption 
> such that the 
> > MN uses co-located care-of address when there is no FA present and 
> > uses FA care-of address when there is a FA present? Just a 
> > clarification question...
> >
> >
> >
> > access network can be monitored by the network entities and 
> informed 
> > to HA and why should the MN send these information?
> >
> 
> The home agent cannot always monitor the characterstics of 
> the access network, specially in a unmanaged network, or for 
> client-based mobility.
> In the mobile router deployments for which this is more 
> useful, the home network will have no clue about access 
> networks to which the mobile router is attached. Registering 
> the access type, will provide the link characterstics to the 
> home network. It knows about each of tunnel paths and how it 
> is tied to the air link on the mobile.
> 
> 
[Mohana] Agree, I was thinking more interms of MN in home network
domain. I agree
in foreign domain, access link specific characetristics cannot be sent
to
the home agent by foreign network entities and such information is
useful. My true feeling is that
this access technology specific information is useful (as you have
mentioned) for home agent to set some traffic policies.   
> > used bandwidth per MN or the available spare bandwidth? I think it 
> > would be better if more clarity is given to this term. My 
> > understanding is the spare bandwidth. If it is the spare bandwidth 
> > then again, another question is how the MN gets such 
> information. This 
> > is very much access technology specific.
> >
> 
> Ok. Will clarify this.
[Mohana] thanks.
> > BID was defined in terminology section and it is again repeated in 
> > page 7. Possibly, such double definition can be removed. 
> Again, it is 
> > It is mentioned in page 7, that in deregistration request, the 'O' 
> > flag must be set to 0. What is the reason for this? My 
> understanding 
> > is that deregistration has a special trigger to remove the bindings 
> > and what is the reason for such setting of the 'O' flag.
> >
> 
> Since, for dereg all bindings are removed, the 'O' flag has 
> little purpose in that case and hence such restrction.

[Mohana] Ok, understand.

> > In "mobile node in foreign network" section in page 9, the first 
> > bullet is a "SHOULD". Why is this so?  If the mobile node 
> cannot see 
> > home prefix then it is in foreign link. Then it is a MUST. 
> Am I right 
> > to say that?
> >
> 
> 
> The support for multiple interfaces/tunnels, requires some 
> additional clarity on when a mobile can be considered its at 
> home. Sure, if the home prefix is not seen, ie. if none of 
> the interfaces are attached to the home link. Will clarify.
> 
> >
[Mohana]Ok, fine...
> > In section 5.2 it is mentioned that a MN connected to a single FA 
> > using multiple interfaces. Is there a single tunnel for both 
> > interfaces or multiple tunnels? Moreover, it is better to introduce 
> > this scenario once supported configuration section is 
> described. This 
> > is just a simple suggestion.
> >
> >
> 
[Mohana] Ok, thanks. This scenario is very interesting.
> There is simultaneous binding support, where every packet is 
> sent on all tunnels. Its different from that sense.

[Mohana] Ok, when I read back can see the difference..
> > There is no clear differentiation between figure 4 and 
> figure 5. What 
> > is the difference? How is the registration done? It would be 
> > beneficial to
> 
> There is a tunnel for each CoA, so the difference is 2 
> tunnels vs 1 tunnel.

[Mohana] Agree, the diagram clearly shows the tunnel separation but
wanted to see more
On protocol operation. Maybe in future revisions you can use this
scenario for more protocol operation....

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 8 Jan 2009 16:26:21 -0800 (PST)

Hi Mohana,

Please see inline ..

> mentioned) for home agent to set some traffic policies.

Yes

> scenario for more protocol operation....

Sure. Will fix it.

>>> These are some of my comments.

Thanks again for the review comments.

Sri