Subject: [Mip4] Draft Agenda Posted

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 11 Mar 2010 11:55:49 -0500

A draft agenda for Anaheim is available here:

http://www.ietf.org/proceedings/10mar/agenda/mip4.txt

There is still space available.  If there is a topic you'd
like to discuss, please send e-mail to me and Henrik ASAP.

-Pete

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Mar 2010 11:35:30 +0100

> http://www.ietf.org/proceedings/10mar/agenda/mip4.txt

Hi, thanks for the agenda.

I would like to email discuss about the multiple-tunnel-support draft.

http://tools.ietf.org/html/draft-gundavelli-mip4-multiple-tunnel-support-01

I agree with the idea in this draft, and represents a very useful and 
realworld case for Mobile Router support of multiple interfaces: a 
client PDA at 11Mbps is strongly limited by the MR's 1Mbps cell egress 
interface.  In this sense, multiple egress cell interfaces may be the 
only way to improve the situation offered by a e.g. vehicular MR to the 
numerous client end users.

I also consider the topic difficult to address for several reasons, some
already mentioned in various discussions:
(1) we risk getting into QoS and load balancing issues, without which
     the solution is pointless,
(2) we risk designing a solution which doesn't solve the inherent
     problem of multiple addresses on a single host (be it mobile or not
     mobile),
(3) we risk non-interoperable solutions due to the singularity of the
     affiliated authorship of this draft, sorry for saying that too
     direct, I could not find a better formulation :-)
(4) we know not about the IPR status.  This is very important in order
     to be able to agree or not on its advancement.

Here are specific points in the draft which are unclear:

The pictures show several MIP Tunnels ending into a single Home Agent
interface (presumably interface, not link) - but a typical IP-in-IP
tunnel can not have several "remote" addresses per a single "local"
address.  What kind of tunnel do you plan to use?

> The mobile node registers to the home agent through each of the
> available roaming interfaces.  As part of the registration, the
> mobile node identifies the interface through which the specific
> registration is setup.

How does the MN identify that interface?  I don't see a specific field
e.g. "eth0" in the Multiple Tunnel Request Extension.  I believe there
isn't one in RegReq either.

Does it identify the interface with an IP address?  With the Home
Address?  So there are several Home Addresses, one per interface, i.e.
one per CoA?

> However, the available bandwidth on any single interface or the
> connected link is still quite low and is not sufficient either for a
> mobile router to support large mobile networks with many users or
> even for a mobile node to be able to run multimedia or other high
> bandwidth consuming applications.

I agree.  Moreover, not only the apps on MN (LFN) are high bandwidth but
also apps on the MR.  An application on MR should not be aware that
there are multiple egress interfaces, as it is not aware it runs Mobile
IP.  This app should not be modified to support either MIP nor multiple
interfaces.

In this sense this app should only use a typical IP src address, i.e.
its Home Address.  But which is _the_ Home Address when there are
several interfaces, several tunnels?  Several interfaces can't use a
single IP address (unless they're Ethernet: bonding, more; for
point-to-point this doesn't work, because no link-layer addresses).
Several tunnels can't use same "local" IP address.

We risk coming down to the typical (non mobility) problem of using
multiple addresses per a host.

> These multiple paths can be used for load balancing the mobile nodes
> traffic across all those tunnels based on various traffic policies.
> The specifics on the definition of these traffic policies, or how
> they are negotiated is outside the scope of this document and future
> work can offer such dynamic negotiation capability.

Hmm... there are 2 things here.

I agree we should not get into defining the traffic policy.  I.e. the 
draft should not specify a policy like "distribute traffic 50-50 when 2 
interfaces and 25-25-25-25 when 4 interfaces".

But I believe we should indicate a clear idea about the tool and 
protocol used to realize this load balancing.  I.e. we should say 
whether we use e.g. RSVP and the iproute tool.  This tool is so 
important because without it the entire MIP extension multiple tunnell 
won't work.  There exist many tools out there, some relying on changing 
the addresses on the fly, which won't work with MIP and the tunnels you 
supposedly(?) propose to do.

Other comments:
> Interface Bandwidth (If-BW)
>
> This 16-bit unsigned integer is used for conveying the available
> bandwidth of the interface associated with this request.  The
> bandwidth is specified in kilo-bytes, fractions are to be rounded to
> the nearest integer.

I disagree with this encoding or its description.  Is it on seconds?  It
doesn't say.  Does it cover _very_ slow links too?  Is it symmetric
download/upload?  Etc.

Finally, security considerations... of course the security of all this 
is weakened when a single HoA is used with several CoAs (instead of one 
HoA per CoA).

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 16 Mar 2010 20:07:18 -0800

Hi Alex:

Thanks for the review. Please see inline.

> numerous client end users.

Ok. Thanks for supporting this work.

>      the solution is pointless,

One pending action on my end is adding support for flow policies, as
discussed in the WG when I presented this previously. So, with the flow
policy support, we have clear semantics on both home agent and the mobile
router to make the forwarding decisions.

>      direct, I could not find a better formulation :-)

We have George and Hesham on this draft as agreed up on the WG meet. I could
not add them by the last posting day for this IETF, as I did not complete
the draft merger and hence largely posted the previous version. But, the
updated draft should reflect non-cisco authors on the draft, if we now go
with affiliations.

>      to be able to agree or not on its advancement.

I would not comment on any IPR issues. But, I've not seen any new
declarations on this work.

> address.  What kind of tunnel do you plan to use?

All the supported encaps, GRE, IP-in-IP and MIP-UDP modes, as per RFC-3344,
and RFC-3519 will be supported. I will work on the illustrations to clarify
this.

> isn't one in RegReq either.
There is a binding identifier field, that identifies the interface index.

> Address?  So there are several Home Addresses, one per interface, i.e.

Its an identifier that uniquely identifies the physical interface. The CoA
address is registered any ways as part of the binding. When you say home
address per interface ? Can you please clarify ?

> IP.  This app should not be modified to support either MIP nor multiple

Agree. Applications should not be aware of the tunnel paths. They should be
bound to the HoA, the flow policies will ensure there is a routing path for
that flow.
  
> Several tunnels can't use same "local" IP address.

In the MIP implementation we have, we typically bind the hoA to a virtual
interface. The source address selection rules on the host will use the HoA
for the applications.

> multiple addresses per a host.

We have the HoA to which apps are bound and then we have flow policies that
take the traffic over a specific path.

> interfaces and 25-25-25-25 when 4 interfaces".

We discussed this, the consensus as read by the chairs was to integrate
George's work on flow policies and have support for that.

> supposedly(?) propose to do.

These comments should be addresses in the new draft. Sorry, for making you
read a older version. Let me complete the updated draft and post it.

> doesn't say.  Does it cover _very_ slow links too?  Is it symmetric

Ok. Let me put the new options and you can comment.
 
> is weakened when a single HoA is used with several CoAs (instead of one

When we have one 1:1 mapping between a HoA and a CoA, we always had a
floating CoA. Now, when we have 1:n relation, I do not know where you see
the security gap.

Thanks again for your time on this draft. Appreciate it. Let me post the
revised draft and we go from there.

Sri

> Alex
> 
> --
> 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: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Mar 2010 16:31:15 +0100

Hi Sri and thank you for the reply.

I am interested in continuing the discussion on this and progress the
document.

However I am not sure about the way to progress.

For the moment I will stay technical with respect to your draft.

Le 17/03/2010 05:07, Sri Gundavelli a écrit :
> On 3/16/10 2:35 AM, "Alexandru
> Petrescu"<[email-masked]> wrote:
>
>>  client PDA at 11Mbps is strongly limited by the MR's 1Mbps cell
>> egress interface.  In this sense, multiple egress cell interfaces
>> may be the only way to improve the situation offered by a e.g.
>> vehicular MR to the numerous client end users.
>>
>
>> I also consider the topic difficult to address for several
>> reasons, some already mentioned in various discussions: (1) we risk
>> getting into QoS and load balancing issues, without which the
>> solution is pointless,
>
>  discussed in the WG when I presented this previously. So, with the
> flow policy support, we have clear semantics on both home agent and
> the mobile router to make the forwarding decisions.

Do we want to reproduce the IPv6 work here? (MEXT flow drafts).  Or
could we do otherwise?

Why do we need to exchange policy information in the first place?  If we
do why isn't COPS sufficient (or other policy exchnage existing protocol).

Why exchanging policies if we don't know yet how they're implemented?

[...]

>> (4) we know not about the IPR status.  This is very important in
>> order to be able to agree or not on its advancement.
>>
>

Hmmm, I am interested to learn whether there's any IPR declaration on
this work.

>> The pictures show several MIP Tunnels ending into a single Home
>> Agent interface (presumably interface, not link) - but a typical
>> IP-in-IP tunnel can not have several "remote" addresses per a
>> single "local" address.  What kind of tunnel do you plan to use?
>>
>
> All the supported encaps, GRE, IP-in-IP and MIP-UDP modes, as per
> RFC-3344, and RFC-3519 will be supported. I will work on the
> illustrations to clarify this.

WEll, IP-in-IP wouldn't work ok in the setting I am trying.  Only GRE
does in the way I need it.  That doesn't mean I am happy with the situation.

I could contribute illustration when or if needed.

>> How does the MN identify that interface?  I don't see a specific
>> field e.g. "eth0" in the Multiple Tunnel Request Extension.  I
>> believe there isn't one in RegReq either.
>>

Ok and what if there's no Mobile IP thus no binding?

In certain deployments of vehicular networks multiple tunnels could be
used on EVDO (e.g.) w/o Mobile and then use Mobile IP only when handing
over from EVDO (e.g.) to WiFi.

In this case one needs multiple tunnel interfaces over EVDO but doesn't
need Mobile IP, hence no binding ID.

>> Address?  So there are several Home Addresses, one per interface,
>> i.e. one per CoA?
>>
>
> Its an identifier that uniquely identifies the physical interface.
> The CoA address is registered any ways as part of the binding. When
> you say home address per interface ? Can you please clarify ?

WEll, the way I understand the current draft proposal is that Mobile IP
could be extended to have several CoAs for one RegReq.  However, the
draft is not clear whether or not there are several HoAs - i.e. as many
as interfaces.

In implementation it's very easy to have several Mobile IP tunnels each
with a pair HoA-CoA, each address distinct.

On the contrary it's hard to have a unique same Home Address on several
EVDO interfaces, with Mobile IP.

This is why I don't understand the draft: do you assume a single Home
Address per MR with several EVDO interfaces?

>>> connected link is still quite low and is not sufficient either
>>> for a mobile router to support large mobile networks with many
>>> users or even for a mobile node to be able to run multimedia or
>>> other high bandwidth consuming applications.
>>
>> I agree.  Moreover, not only the apps on MN (LFN) are high
>> bandwidth but also apps on the MR.  An application on MR should
>> not be aware that there are multiple egress interfaces, as it is
>> not aware it runs Mobile IP.  This app should not be modified to
>> support either MIP nor multiple interfaces.
>>
>
> Agree. Applications should not be aware of the tunnel paths. They
> should be bound to the HoA, the flow policies will ensure there is a
> routing path for that flow.

WEll I am interested in the proper setting of the routing path but I
don't yet see the need for flow policies.

>> In this sense this app should only use a typical IP src address,
>> i.e. its Home Address.  But which is _the_ Home Address when there
>> are several interfaces, several tunnels?  Several interfaces can't
>> use a single IP address (unless they're Ethernet: bonding, more;
>> for point-to-point this doesn't work, because no link-layer
>> addresses). Several tunnels can't use same "local" IP address.
>>
>
> In the MIP implementation we have, we typically bind the hoA to a
> virtual interface.

Ok, I guess you add it, and not bind in the sense of MIP.

WE too use a virtual interface with the single HoA on it.  We call this
the "default" interface because it's the default route for applications,
which is good.

But do you also use virtual intefaces for the tunnels?

We found that's hard to use virtual interfaces of type IP-IP, but easy
to use GRE.  DEspite this easiness it's not a happy situation to be in,
because of (1) IPR aspects and (2) GRE is not the default implementation
of Mobile IP.

This is one aspect of a problem we'd like to solve.

> The source address selection rules on the host will use the HoA for
> the applications.

YEs, we rely on that too.  We set the default route through that virtual
interface being configured with a unique HoA.

Finally:

DEfault route configured on MR: what is your default route on MR?
towards the virtual interface holding the HoA?  Or towards one of the
EVDO interfaces?  If towards the virtual interface then do you have
specific routes (host-based, /32, etc.) configured on MR to reach the
HA?  How many addresses does HA have?  How many real interfaces?  If yes
then this could be spelled in the draft it's very helpful to implementer.

If your default route points to the virtual interface having the HoA,
and if the HA has a single interface and a single address, and if you
use a specific route configured on MR to reach the HA address then
obviously MR  will use a single interface to send packets, despite the
fact HA distributes traffic going towards MR and MR receives packets on
multiple paths.

I do not agree to solve this problem by simply invoking flow policies
which we don't know what they are.

Alex

> We have the HoA to which apps are bound and then we have flow
> policies that take the traffic over a specific path.
>
>
>
>>> These multiple paths can be used for load balancing the mobile
>>> nodes traffic across all those tunnels based on various traffic
>>> policies. The specifics on the definition of these traffic
>>> policies, or how they are negotiated is outside the scope of
>>> this document and future work can offer such dynamic negotiation
>>>  capability.
>>
>> I agree we should not get into defining the traffic policy.  I.e.
>> the draft should not specify a policy like "distribute traffic
>> 50-50 when 2 interfaces and 25-25-25-25 when 4 interfaces".
>>
>
> We discussed this, the consensus as read by the chairs was to
> integrate George's work on flow policies and have support for that.
>
>
>
>> important because without it the entire MIP extension multiple
>> tunnell won't work.  There exist many tools out there, some
>> relying on changing the addresses on the fly, which won't work with
>> MIP and the tunnels you supposedly(?) propose to do.
>>
>
>
> These comments should be addresses in the new draft. Sorry, for
> making you read a older version. Let me complete the updated draft
> and post it.
>
>
>> Other comments:
>>> bandwidth is specified in kilo-bytes, fractions are to be
>>> rounded to the nearest integer.
>>
>> I disagree with this encoding or its description.  Is it on
>> seconds?  It doesn't say.  Does it cover _very_ slow links too? Is
>> it symmetric download/upload?  Etc.
>>
>
>> Finally, security considerations... of course the security of all
>> this is weakened when a single HoA is used with several CoAs
>> (instead of one HoA per CoA).
>>
>
> floating CoA. Now, when we have 1:n relation, I do not know where you
> see the security gap.
>
> Thanks again for your time on this draft. Appreciate it. Let me post
> the revised draft and we go from there.
>
> Sri
>
>
>> Alex
>>
>> -- 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/
>
>