[netext] IETF82 Working group meeting minutes

[<[e-mail]>]

Please see the Netext WG meeting minutes from IETF82. If you find any
discrepancies, please let me know.

-Basavaraj


Network-Based Mobility Extensions WG meeting at IETF82 (Taipei, Taiwan)

Wedensday, November 16, 2011
0900-11:30 Morning session I  (Room 101B)

Chairs:  Basavaraj Patil ([e-mail])
         Rajeev Koodli ([e-mail]) attending remotely via Meetecho

These meeting minutes are courtesy of:
1. Ved Kafle (kafle at nict.go.jp)
2. Carl Williams (carlw at mcsr-labs.org)

Thanks also to the Meetecho team for providing support with the
remote-participation tools.

------------------------------------------------------------

1. Work group status update:

Basavaraj provided an update on working group activities including
working group documents.  Basavaraj stated that the working group made
good progress between IETF 81 and IETF 82.  The draft
draft-ietf-netext-redirect-12 is in the RFC editors queue.  Basavaraj
stated that thanks to reviewers that the working group also was able
to forward three IDs to the IESG:
(1) draft-ietf-netext-radius-pmip6-05; (2) draft-ietf-netext-pmip-lr-07;
(3) draft-ietf-netext-bulk-re-registration-08.

Basavaraj stated that the goal is to get the following drafts to
working group last call prior to IETF 83 for :
(1) draft-ietf-netext-pd-pmip; and
(2)
draft-ietf-netext-access-network-option.

Basavaraj stated that further reviews and feedback is being looked for
(1) draft-ietf-netext-pmipv6-flowmob;
(2) draft-ietf-netext-logical-interface-support.

..........................................

2. Logical Interface Support for Multi-mode IP hosts
I-D: draft-ietf-netext-logical-interface-support
Presenter: Sri Gundavelli

Sri states that six of the previous 7 open issues were address since
version
-01 of the I-D . (1) Behavior of ND; (3) Use of the Virtual LLID; (4)
Point-to-point Links; (5) Multicast Traffic; (6) MTU issues;
(7) UL/DL packet processing.

Raj: ND related question ­ logical interface hides the fact that you
     have multiple active multiple physical interfaces. When you send a RS
     what you are saying is that the RS is being sent to both
     interfaces. It will then respond by send replicate and send out on
     both interfaecs?
Sri:  exactly
Raj: In absent of logical interfaces would that be normal behavior?
Jari: It is correct action to send it on both in general but the issue
      is more about what is the definition of link-up?
Jari: In case of router discovery it is a good approximation to send
     out an RS when one of the interfaces comes up.
Jari: there is another aspect to think about ­ what is the DNA
     behavior ­ how does IP layer know what is going on. I suppose you
     are changing source link layer address.
Sri:  link layer address must be same ­ from perspective of the upper
layer and what is sent.
Jari: If you have a link layer address ­ it must be same.

Jouni: how to expose different routers to logical i/f
Sri: exposing multiple neighbors is possible
Sri: this is not concerned with multihoming, above logical i/f it looks
single homing
Raj: what about DHCP including some v4 addresses? DHCP aspects covered?
Sri: discovery messages will be sent to all physical i/f; somehow covered.

Raj: Regarding MTU ­ if you receive RA from both interfaces with two
different MTU which one.
Sri:  Lowest one of the access technologies.
Jari: What does IPv6 say?
Sri:  Good point and will look into it.

Raj:  Asked for reviewers.
Pete McCann:  Will review.
Raj:  Ask that the issues on slide 1 be looked at and determined if
      they have been resolved satisfactorily..
It was also agreed that the document should be sent to 6man for review as
well.

..................................................

3. Proxy Mobile IPv6 Extensions to Support flow Mobility
I-D: draft-ietf-netext-pmipv6-flowmob-02
Presenter: Carlos Bernardos

Carlos Bernardos (editor) updated briefly the status of
draft-bernardos-netext-pmipv6-flowmob.

Sri:  What are the open issues?
Carlos:  It is to work on details and then wait for to request
	 comments.  We are lacking input so there is no formal list.
Carlos:  We have to provide clean details on signaling.
Sri:  LMA initiated flow mobility ­ I am just trying to think of other
contention points.

Raj:  This draft depends on logical interface draft ­ do you have any
      questions or comments on logical interface that derives from flow
      mobility. 

Carlos: Not really.  Co-authors of flow mobility also co-authors of the
logical interface draft.

It was agreed that Jouni Korhonen and Alper Yegin will perform a
review of this document.

........................................................

4. Prefix delegation for PMIPv6
I-D: draft-ietf-netext-pd-pmip-01
Presenter: Carl Williams

Provide means to enable DHCPv6 Prefix Delegation for a Proxy Mobile
IPv6 deployment because RFC 3633 is sufficient for PMIPv6
     - Binding Cache Entry (BCE) and Binding Update List Entry (BULE)
     extended with a new prefix information field as specified in
     RFC3963. This prefix information field is used to store the
     mobile network prefix information

Sri: there is no context transfer between MAG?
Carl: yes; LMA is used for it
Behcet: does it need change in DHCP client? If so it can be outside netext
scope.
Raj: Prefix delegation is not a new item, it falls within the charter;
     same thing was done in nemo etc.
Jouni: since routers are also supporting DHCP pd, there is no problem
       to adopt DHCP pd for mobile routers in PMIPv6;
Rajiv: if routers support DHCP; they should support DHCP PD.

Carlos Bernardos agreed to do a review of this I-D.

........................................................


5. Optimizing IP Mobility Authentication with EAP
I-D: draft-perkins-netext-eapbu
Presenter: Charles Perkins

Jouni:  if multiple routers are requested, do you do a bunch of
	PBU/PBAcks between LMA and MAG ­ then you have multiple extensions
	with AAA at same time.

Raj:  PBU with EAP with authentication option is actually being
      carried in Radius attribute.  Encapsulating the PBU in the radius
      access request message ­ not shown here but implied here.  If you
have
      multiple EAP messages that are going through then LMA acts as a
relay.
      Subsequent messages wouldn¹t necessary contain that data option ­
just
      forwarded through LMA.
Sri:  Today we use the CUI in some cases ­ Access and home network are
      in two administration domains.  What are considerations?
Charlie:  You should be able to use a lot of different identifiers ­
	  CUI is a good point.  No compelling the identification to NAI.
Alper:  why not carry EAP over radius and then you can piggy back binding
update over radius.
Charlie:  I want to get rid of this separate access authentication and I
am happy either way.
Alper:  Either way you need to maintain Radius between access network
	and core network ­ radius and similar diameter have a lot of
	attributes ­ you don¹t want to put them in the binding update ­ they
	need to stay with the AAA messaging.
Alper:  I thought that Raj stated that PBU is carried over radius.
Charlie:  If you have more radius specific information then this is a
convenient approach.
Pete:  Then it would like the DIAMETER-Mobile IP approach done a number of
years ago.
Charlie:  If you want to run 802.1x then it is not obvious how to do that.
Pete:  This is the proxy version of the DIAMETER-Mobile IP
       application.  It looks like the MAG and LMA must be in the same
trust
       domain.  Normally if an access router is authenticating a device it
       goes to a local AAA server that it trusts and in this case it going
to
       the remoteŠ.
Charlie:  Point is to allow mobility smoothly not just in the home
	  domain.  Part of the point is to tell what the authorization domain
	  is.  You want to roam remotely you have to allow the access
	  authorization to eventually be done in the home network.  Now if you
	  want a concentrator in the access network
Pete:  For scalability
Charlie: that point was brought up earlier.
Pete:  It is not just concentrating the access network but also
       encapsulating the business agreements between the different
operators
       and those are typically done with radius brokers.
Charlie:  Essentially you want another vertical line here that says AAA
aggregator ­ no problem.
Charlie:  I agree with that.
Pete:  I agree with what Jouni said that the overhead being dominated
       by the EAP method ­ if  you are not careful ­ in particular if you
are
       using one of these EAP TLS methods ­ that can be numerous round
trips.   
Charlie:  I agree ­ you can view this as me asking the working group
	  if this is a sensible approach.  If it is, then let us make a better
	  EAP method.   
Pete:  And if you are talking about handoff, then you can get some
       input from HOKEY working group because they are looking at EAP
methods
       and dealing with keying material.
Charlie:  I doubt if they give me feedback because the working group is
shutting down.
Pete:   ok but folks that did that work you can ask.
Charlie: You are right.
Raj:  Yokota-san is asking about accounting aspect.   Are accounting
messages relayed through the LMA.
Charlie:  LMA doesn¹t take on the accounting ­ PBU and PBA in encap
	  radius ­ and identifier will give it the proper home network to go to
	  but the proper home network need to go to the proper AAA server and it
	  will check authorization. If the LMA has that ability is not part of
	  scope of this document.

........................................................

6. Service Selection for Mobile IPv6
I-D: draft-korhonen-netext-rfc5149bis-00.txt
Presenter: Jouni Korhonen

To update RFC5149 from informational to standard track category
- update service selection identifier field encoding to UTF-8
- extend identifiers with additional ³index²

Raj: Request authors to clarify more about the problem statement and
     applicability; usage and service selection parameters, get
     additional feedback from WG;

........................................................

7. Problem Statement of Flow Mobility Triggering	
I-D: draft-tian-netext-flow-mobility-trigger-ps-00
Presenter: Tian Tian

- making the trigger for flow mobility clear
- host based and net based triggers possible
  - Host based triggering
    - L3-signaling trigger
    - L2-signaling trigger (MAG trigger) ­ maybe outside ietf scope
    - Explicit flow trigger ­ MN sends trigger to MAG (maybe outside
netext scope)
  - Network based triggering
    - LMA trigger (issue: how lma know that MN supports flow mob)
Raj: host-based triggering is outside netext scope
Sri: this is some how related with MN-aware document discussed long ago.
Raj: MN-aware was about link model Š
Sri: since IETF should provide how MN interface looks like; this can be an
informational document
Rajiv: multi-access indicator ID can be used to indicate if the MN
supports flow mobility

........................................................

8. PMIPv6 Multihoming Support for Flow Mobility
I-D: draft-sarikaya-netext-fb-support-extensions
Presenter: Behcet Sarikaya

- Current pmip RFC has no flow mobility; LMA does not know that MN has
different i/f
- Solution:
   - The bindings in binding cache from each interface are kept
     together so that the flows can be moved among interfaces

In binding: one home interface (for incoming flows); and many secondary
interfaces

Raj: Wg members, please read the draft; provide comments.

........................................................

9. MN Status Option for Proxy Mobile IPv6
I-D: draft-tu-netext-mn-status-option-00
Presenter: Yangwei Tu

Yangwei presented problem statement regarding sleep mode and flow
mobility and solution for optimization for moving flow mobility to
interface that may have went into sleep mode.

Sri:   can you clarify on wifi what idle state.  I think there is good
       stuff but trying to figuring how it can be used.
Yangwei: On wifi it is called power saving mode.  Similar but different.
Sri:  It can be access technology type specific.
Yangwei:  yes.
Sri:  It is important information but see how it can be applied in
       different use cases.  Overall you have to build more things to
       justify it. 
Raj:  If flow is switched when you send packets down to next MAG ­
       what you expect to happen that you would page the mobile.
Yangwei:  But this would cause delay to the mobile.
Raj:  not sure if problem per-se.
Yangwei:  we don¹t want bad user experience.  Mobile move out of
       coverage ­ no method to move data that sent to MAG 2 and can¹t
       be sent to MAG 3.  Takes time to do and bad service.
Raj:  We have done work to deal with fast handover.  Please take a
       look at these fast handover drafts. I recommend more discussion
       on list.  Please create more discussion on list

........................................................

10. Quality of Service Option for Proxy Mobile IPv6
I-D: draft-liebsch-netext-pmip6-qos-00.txt
Presenter: Marco Liebsch

Marco presented QoS option for PMIPv6.  Set of enforcement of QoS in
network an access network.

Raj:   With regard to the ³Support enabling QoS differentiation of
       traffic between MAG and LMA for any non-3G access² ­ assuming you
have
       some kind of QoS on the radio bearer you are trying now to specify
QoS
       between the MAG and LMA?
Marco:  we don¹t expect that between the LMA and the MAG that serves a
	non-3GPP network is more fine granular ­ in access we need more fine
	granular policies to allow for the mapping radius qos.
Raj:  What are you doing with the awareness ­ between the MAG and LMA
       you have multiple flows and so on ­ what are you doing between
       the MAG and LMA ­ are you doing diffserv markings?  Other part
       of question is how to enforce it.
Marco:  For dynamic QoS flows in diffserv network we have to discuss ­
       so far we assume static rules.   For dynamic ones it depends on
       where intelligence is located.  Do you think it should be
       dynamic. 
Raj: Not sure.  Still trying to figure out what you do between the MAG
       and LMA regarding handling the traffic as a result of the QoS
       requirement awareness ­ that is sort of thing I am asking.
Marco:  PMIP is the vehicle to exchange this information.  If you want
       intelligence than this is out of scope of PMIP (NETEXT).   We
       should make use of use cases.
Raj:  I would appreciate use cases of how this would be use.
Raj: How many people think of interest?  How many people think that
       PMIP should handle QoS information?   8 hands raised.
Raj:  How many people think that PMIP should not do this work?  A
       couple of hands.
Raj:  Please enhance the draft with use cases and discuss on mailing list.

..............................................................


Chair concluded the meeting with next steps for a couple drafts ­
working group review of logical interface draft and flow mobility in
particular. Last call by next IETF meeting.