Subject: [Mip4] draft-gundavelli-mip4-multiple-tunnel-support-00 (Was: Re: IPv4 MCoA Draft)

From: Antti Mäkelä <[email-masked]>
Date: Tue, 16 Dec 2008 11:34:53 +0200

Sri Gundavelli <[email-masked]> wrote:
> Hi Antti,
>
> Thanks for your comments, appreciate it. If you can post this to
> the ML, that will be great. We can discuss on the list. Please

 Posted with this :) As everyone on the list can see, we exchanged some 
comments off-list and I hope from the indentation marks it's still clear who 
has stated what.

> see inline  ..
> On Fri, 12 Dec 2008, Antti Mäkelä wrote:
>
>> Not quite :)
>>
>> Anyway, comments on the draft:
>>
>> I like including info on the interface charasteristics. I'd probably
>> add some sort of latency/jitter coefficient (Although If-type might
>> cover that already). Point being that you probably don't want to
>> policy route e.g. VoIP traffic over a low-latency link.
> The idea was expose basic interface characterstics. If type and
> the bandwidth are specified, pretty much the home agent can derive
> the pipe size and the general latency characterstics.

  I of course meant "avoid VoIP on high-latency link". But ok, if this 
information is more or less included in the link type then sounds good.

>> Also, not sure if you want to have if-BW defined tied to a specific
>> unit (kilobytes). Maybe just consider setting it as a metric value
>> instead to the vein of OSPF (with configurable base rate, defaulting
>> to something like Gigabit Ethernet = 1). Would maybe make it more
>> future-proof.
> We thought about this, generally routing protocols have a default
> metric for most types of links. So, the home agent can still use the
> type and the BW and derive the metric. Offcourse, the other option is
> explicit notification.
>
>> Another parameter I'd maybe add would be "priority". Perhaps a
>> granularity of few bits would suffice (in current form, maybe take
>> last six bits from 6th octet). Idea here would be that you might not
>> want to do load-balancing between ALL links all the time, suppose
>> that you have e.g. an LTE connection that is metered. Thus you want
>> to treat that only as backup, even if other interface
>> characteristics could find some use for the link.
>> So...all interfaces with same priority would be considered/eligible
>> for load balancing, but if all of these were down then you'd go to
>> the next class of interfaces. This would be workable even in
>> scenario where you have two links and one is meant to be dedicated
>> for backup purposes - you are already "pre-registered" and the
>> tunnel is up, so it's just a matter of routing packets that way if
>> the other tunnel goes down.
>> This might also alleviate Qins concerns about power consuption and
>> keeping multiple interfaces up at same time. Just do the initial
>> signaling via the backup and then bulk-re-register for additional
>> ones via the normal link
> Ok. Makes lot of sense. We have this supported in IOS, but in a
> slightly different way. We allow all the interfaces on the mobile
> router to tag them with a specific priority group. The mobile router
> will treat all interfaces in a specific priority group as equal and
> will stick with
> the group. If all the interfaces in a specific high priority group are
> not available, we move to the next group and register with all
> interfaces. The home agent will see the tunnels only to interfaces of
> the same group, without it getting exposed this logic.

  Yeah - in fact, this idea came to me from the IOS version :) , I was 
wondering why it was missing. Anyway, in this case you'd also have the 
option to register the low-priority interfaces - you just wouldn't route any 
traffic to them, and the HA would also be aware of the priorities. These 
priority levels would of course be local to the HoA.
  This would also allow the HA and Mobile Node/Router and possible middlebox 
negotiate priorities (possibly allowing for traffic steering), e.g. mobile 
node can request some sort of priority scheme and HA might either accept 
that as-is or override with their own policy.

>>  Also, I'd probably split the interface charasteristics to a separate
>> extension from the "bulk registration" functionality, with a
>> separate "If charasteristics extension" (consisting of if-type, bw
>> and maybe jitter/latency) and separate bulk registration (with
>> binding-id's and the two flags). The if charasteristics, after all,
>> might be usable by themselves. Also, If characteristincs info might
>> be something that can also be filled in by e.g. the foreign agent
>> (or some other middlebox!), which might have more information on the
>> network capabilities.  For example in the case where you might have
>> a high-bandwidth access link (say, 802.11n) but the actual uplink
>> from the access point is much slower...
>>
>> So put bulk-re-registration stuff to different extension from if
>> charasteristics.
>>
>
> This is a good input. Probably we need to move these registration
> preferences from the interface characterstics and to the RRQ/RRP.
>
>
>> Also, I'm not sure if I understand these two and their use cases
>> properly:
>>
>> ----
>>      Bulk Re-registration Flag (B)
>>
>>         This flag, if set to a value of 1, is to notify the home
>>         agent to consider this request as a request to update all of
>>         the mobile node's bindings, upon accepting this specific
>>         request. This flag MUST NOT be set to a value of 1, if the
>>         value of the Registration Overwrite Flag (O) flag is set to
>> a value of 1.
>>
>>     Registration Overwrite (O)
>>
>>         This flag, if set to a value of 1, is to notify the home
>>         agent that upon accepting this request, it should replace
>>         all of the mobile node's existing bindings with this
>>         binding.  This flag MUST NOT be set to a value of 1, if the
>>         value of the Bulk Re- registration Flag (B) is set to a
>>         value of 1.  This flag MUST be set to a value of 0, in
>> de-registration requests. ----
>>
>> Constraints are that only one can be set at same time. Fine..but I'm
>> not sure I understand the rest of when these are supposed to be set.
>> Is the B meant for case where you simply want to do the periodic
>> re-registration (toi avoid timeout?), and O for the case where you
>> want to stop being multi-homed and only work traffic on a single
>> link?
>>
>
> Yes, (B) flag is primarily an optimization during re-registrations. I
> nothing changed on the mobile router, just one registration will
> refresh all bindings for that mobile router.
>
>
>
>> I'd appreciate some sort of signaling diagram on how these flags are
>> up/down in the cases of
>>  - Initial registration
>>  - Periodic re-registration (does the re-registration message need
>> to go through all links or is this the portion where
>> "bulk-reregistration" comes in?)
>>  - One interface doing a handover to different CoA
>>  - Deregistration
>>
>
> Sure. Will add this.
>
>
>> Anyway, here's what comes to my mind from this initially.
>>
>> Also, I haven't read draft-ietf-monami6-multiplecoa-10.txt - have
>> you modeled this after the MIP6 one (it's an informative reference,
>> yet not referenced from the draft at all)?
>>
>
> There is no relation to the v6 draft, I just wanted to highlight the
> fact that there is similar work done in the MIP6 space.
>
>
> Regards
> Sri

-- 
- Antti Mäkelä | Senior Network Architect | +358 2040 21613 -
- Broadband Services / TeliaSonera Corporation - 

--
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: Tue, 16 Dec 2008 12:15:15 -0800 (PST)

Hi Antti,

Thanks for the review comments. Inline ...

On Tue, 16 Dec 2008, Antti Mäkelä wrote:

> wondering why it was missing. Anyway, in this case you'd also have the option 
> to register the low-priority interfaces - you just wouldn't route any traffic 
> to them, and the HA would also be aware of the priorities. These priority 
> levels would of course be local to the HoA.
> node can request some sort of priority scheme and HA might either accept that 
> as-is or override with their own policy.
>

This is supported. The logic of what interface to register is local
to the mobile router and is not exposed to the home agent. Home agent
sees only the active registered interfaces (all of them belong to
one group), so no protocol extensions needed. But, offcourse, to your
point that the mobile can register all high and low prio interfaces,
but the low prio will be not used, is another approach, but since
the home agent is not at the best place to quickly determine what
interfaces come up and go, its better we keep this local to the mobile.

Thanks
Sri