[Netext] next steps for netext

[sgundave at cisco.com (Sri Gundavelli)]

Hi Jari,

Thanks for your mail. Sorry for the late reply.
Please see inline.


On Mon, 6 Apr 2009, Jari Arkko wrote:

> Sri,
>
> Thanks for your input. Inline:
>
>>  I've a concern with the planned charter. The list is too random and
>>  cherry picked and I dont believe proper input from all the folks went into
>>  this. There are many other items that are required for a reasonable
>>  deployment of Proxy Mobile IPv6. Many items were proposed over the last 2
>>  years, some of them that were left out in the base spec, some that we
>>  realized as gaps when compared to other SDO protocols and some as
>>  optimizations that we realized while implementing PMIP6, these items
>>  should be in the initial scope.
>>
>>  I understand the charter needs to be limited in scope, but just 3 or 4
>>  random items, I'm not sure if this helps in short term PMIP6 requirements.
>>  I've no issue with the currently listed items, but there are other items
>>  that should get equal or higher priority.
>
> I have no problem with adding more. Even the charter says new things can be 
> added.
>
> However, from a process perspective what I did was to take the proposal on 
> the table, i.e., the full BOF scope and see what parts of that we already 
> have an agreement on. I didn't include other things that were not discussed 
> in the BOF. Maybe that would have been useful, but they were not on the 
> table.
>
> We could add more items now, if there's general agreement that those things 
> are useful. However, I do not want to declare an open season on doing 
> everything. We pick a reasonable subset of all proposed work, based on 
> priorities, community agreement that they are the right things to do, 
> management reasons to ensure that we are not doing too much, etc.
>

Ok

>>  For example, item #6, is absolutely required, from the perspective of
>>  having a complete specification of 5213. There we allowed a mobile node to
>>  perform handoff betweek two interfaces. We defined all the hooks on the
>>  network side, but we did not provide how a terminal vendor can support
>>  that. A simple informational draft on how some one move prefixes between
>>  interfaces will greatly help. Some guidance on how to create a virtual
>>  interface and also some related notes for each platform (Linux, BSD,
>>  Android ..etc). This should not fall in the controversial discussion scope
>>  of same address on two interfaces etc, thats a different problem, or about
>>  the issue of enhancing mobile node's capabilities. This is just
>>  informational work, required to leverage what 5213 already supports.
>
> I suspect this is about the scoping of the handoff work. Lets try to figure 
> out what makes sense (I personally believe the above item makes sense, for 
> instance) and what doesn't.
>
> The fact that these parts were not in the charter was not a declaration that 
> we're dismissing them. Its just that we didn't finish the discussion, but I 
> still wanted to let the other things move forward.
>

The current discussions should not have much bearing on this. This is
clearly not about any host changes, some informational work required
for completing 5213.


>>  Item #2, is required. The multimob BOF raised some issues, we need to
>>  show how multicast services can be enabled in PMIP network. May be this
>>  wont require extensions, a simple draft covering those aspects will help.
>
> As you may recall, in the Multimob BOF we did not have an agreement on what 
> exactly is needed, if anything. My own conclusion is that we probably need at 
> least an informational document that explains how to use RFC 5213 for 
> multicast. I think we discussed the possibility of doing this as some kind of 
> AD sponsored document or in one of the relevant WGs, as a joint work between 
> PMIP and multicast experts.
>
> I'm on the fence about adding this work to the charter right now, mainly 
> because the BOF back then was very inconclusive. I'd be happier if I saw an 
> actual well written draft from say you and some of the multicast experts. 
> There's no problem moving good documents forward, even if they are not in the 
> charter of some WG. Then again, I wouldn't necessarily mind a maintenance 
> like item for this in one of the WG charters either.
>


Ok, sure. We can probably first identify the issues and bring that work.



>>  I think, the charter should be bit more relaxed and more extensive. As I
>>  see it, atleast the folks are interested in doing the work. We should add
>>  atleast 4 or 5 more items to this list.
>
> Generally speaking IETF WG charters give specific work items that the WG 
> should work on. I had hoped that the charter text:
>
> "The NETEXT working group will also act as the primary forum where new 
> extensions on top of the Proxy Mobile IPv6 protocol can be developed. The 
> addition of such new extensions to the working group involves addition of the 
> extension to this charter through the normal rechartering process."
>
> gives an indication that we intend to do more! I am also personally very 
> happy to add more items to the group's charter. All in all, I do know that 
> the current charter is a bit on the thin side -- mostly because the 
> multihoming/interaccess issue is under discussion.
>
> There's also the question of general maintenance items. Some IETF WGs have a 
> general work item to fix problems and issue updates to existing 
> specifications. I think we need to do that for Proxy Mobile IPv6 as well. But 
> we have not decided whether that item should go to NETLMM or NETEXT WG yet. 
> Please rest assured that the work will be possible regardless of this.
>

Thanks


>
>>  5. Group Identifier Support for Proxy Mobile IPv6
>>
>>  This provides a simple and a generic semantic for assigning a group
>>  identifier
>>  to a mobile node's binding. GTP has very similar semantics, Connexion Set
>>  Id.
>>  Both #3 and #4 can leverage this. Additionally, in load balancer systems
>>  where
>>  the load balancer is in path for all signaling messages, it can use this
>>  as
>>  a
>>  tag for redirecting the message.
>>
>>  http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
>
> Since the bulk registration work is in the charter, can't you do the sensible 
> design (whatever it is) under that? There is no requirement that one charter 
> item equals one document.
>

Sure. This may be covered as part of other work items.



>>  6. Virtual-Interface Support on IP host for supporting Inter-tech
>>  handoffs:
>> 
>>
>>  RFC-5213 supports handoff between two interfaces. The ability to move
>>  prefixes between interfaces. In other words address continuity is assured
>>  with any IPv6 host on the planet and with absolutely no changes. This
>>  meets
>>  even Dave's comment, that "no changes to any IETF RFC's.". Now, what is
>>  not assured is the aspect of session continuity. Which requires a virtual
>>  interface implementation on the host, by binding the address/prefix to a
>>  virtual interface and by not exposing the physical interface or by hiding
>>  the handoff events from the layer-3 stack.
>>
>>  In essence, we need an informational specification which provides some
>>  general guidance to how to leverage the feature support provided in
>>  RFC-5213,
>>  along the lines of:
>>
>>  http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
>
> This is part of the discussion that we need to finish. But I plan to let the 
> rest of the stuff move forward even before we have done that.
>

This is for completing 5213. An informational draft on how to use
5213 featrures, really needed. And this should be in non controverisal
in scope.



>
>>  9. Partial Handoff Support
>>
>>  We are missing some semantics in 5213 for moving a subset of the prefixes
>>  between interfaces as part of the inter-tech handoff. This is about
>>  defining
>>  a new handoff value. This allows partial flow management, but moving the
>>  flows associated to a prefix, as a whole group.
>>
>>  http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00 
>> 
>
> A part of the topic we still need to discuss...

This is minor optimization to what 5213 already supports. Its
about providing a semantic on the network side. We dont have to
tie this to the other larger flow mgmt features, either way ..





>>  11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
>
> Can you expand on this?
>

This is for delegating prefix to a mobile node in a PMIP environment.
How the MN can use DHCP PD or other mechanisms to obtain a prefix.


Sri