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 (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) 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.