Network-Based Mobility Extensions WG meeting at IETF80 (Prague, CZ) THURSDAY, March 31, 2011 1300-1500 Afternoon Session I (Grand Ballroom) Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) These meeting minutes are courtesy of: 1. Dorothy Stanley (dstanley@arubanetworks.com) 2. Carl Williams (carlw@mcsr-labs.org) ------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) - See the agenda, http://www.ietf.org/proceedings/80/slides/netext-0.pptx - Chair reviewed the agenda, no changes identified 2. Working group status update ------------------------------- Basavaraj provided an update on working group activities including working group documents and additional proposals for the working group. Basavaraj stated that the WG made some progress since the last IETF. The PMIPv6 localized routing PS has been approved by IESG and is on RFC editor queue. Thanks to Marco for quickly reacting to comments. Basavaraj also stated thanks to people who actually reviewed the document. Basavaraj reminded us that the only way to make progress in the working group is to do reviews and help improve the documents. Marco said we had a few comments on the LR-PS I-D and would address them shortly. The other document that has made progress is the Runtime LMA Assignment Support for PMIP6 (draft-ietf-netext-redirect). Good reviews on document and multiple revisions. Jouni who is the editor has addressed all comments and the I-D is in IESG for approval. Last call deadline is April 10. Regarding the Bulk Re-registration for Proxy Mobile IPv6 (draft-ietf- netext-bulk-re-registration) there has been a chair review. Working group members have provided comments in the past and draft was revised. Chair has done review and found that the quality of document is not on par to what can be sent to IESG. Chairs asked authors to update the I-D. It was noted that some progress was made on several sections but other sections need addressed. Basavaraj said that Sri has promised to address those comments as well. We should probably have a document for last call by mid-April. Radius support for PMIP6 (draft-ietf-netext-radius-pmip6-00) is a document required for deploying PMIPv6. One update to I-D based on implementation experience. Basavaraj noted that some implementers identified some attributes required for Radius messaging for PMIPv6. That update has been made. Basavaraj has requested several reviews of document before going to IESG. Need some reviews on document before he can submit it. Basavaraj has encouraged authors to find reviewers in RADEXT and DIME as well to take a look at this document. Suresh who is editor of Localized routing for PMIPv6 (draft-ietf-netext-pmip-lr) stated that the document is ready for Working group last call. Basavaraj said no review on document till now. Author and editor has it in their interest to have reviews be done. Basavaraj said he requires 3 reviews on document. Carlos said he will review it. Jouni also will review it. Basavaraj stated that with respect to Logical Interface support for multi-mode IP hosts (draft-ietf-netext-logical-interface-support) that issues are being captured in tracker. Basavaraj stated that the authors are working through these issues. In particular at least 6 issues were captured in the tracker on the document. As soon as we have resolution on them we can revise the draft and move forward. Basavaraj stated that he was looking into updating the working group milestones. The chairs were considering dropping a couple of milestones but then stated that he heard some views that we should keep these milestones. Basavaraj has not had a chance to update the deadline for these milestones. He noted that they are outdated and he will need to update. Next part of meeting is to discuss the two main topics of logical interface and flow mobility. Basavaraj stated that as far as flow mobility is concerned we are charted for a work on flow mobility and had a lengthy discussion on mailing list. Issues had been raised but we have not converged on solution on mailing list at least. So we should use our face-to-face meeting time now to come to conclusion on these issues. Basavaraj said that we really need to make some forward progress on the documents. Basavaraj said that if we cannot reach common agreement, we will seek WG consensus on proposed solutions for these issues and decide accordingly. Those are the two things we will focus on todays meeting. 3. Logical Interface Support for Multi-mode IP hosts ---------------------------------------------------- I-D: draft-ietf-netext-logical-interface-support Presenter: Sri Gundavelli Slide 2 - Open Issues summary Slide 3 - Issue 3 - Behavior of ND - Receive from any/physical interface - WLAN0, Ethernet 0. Dont see technical issues with this text. - Julian - Generic comment - dont have normative text. Need to describe black box operation. This is a requirements document; made a conscious decision to avoid IEEE shall/must wording. - Julian - Insist on the use of requirements language. Logical interface mapping - link layer id is an issue. - Issue is not with keywords. Is ad-hoc. Describe in terms of communications model. - Doc handles those issues, specifies relationship between logical and physical interfaces. - Interface drivers have send and receive vectors. Send out through the same path. Marking on some packets. - As a reader, had trouble understanding what you are doing here. Should be clear to the reader. Have packet, gets replicated. How does DHCP work? - Upper layers should not see a difference. - Julian - issue with multicast, duplication. - Sri - agree we need to resolve - Chair - Not specifying the implementation. - Sri - specifying requiring logical interface. - Chair - When have logical interface, how does it work? Some cases replicated, some not. This is not clear today. Saying how it should behave, not how it should be done. - Julian - Needs to be more detailed – sending and receiving algorithm, how it should work externally. - Jari Arkko - Valuable to have such a description, more useful to describe what happens below the interfaces. One way to solve it, may be other ways too. Consider alternative implementation approaches. - Speaker - ND behavior for logical interface – useful outside the context? - Slide 4 - Issue - 1, Linklayer Id of the Logical Interface. What identifier do you project? Pick a random one? Can't do this in all cases - WiMax for example. Wi-Fi - no issue. Issue is what do we pick? Asking for WG guidance. In network environments, link layer identifier - Speaker - can use VLAN ID, 802.1Q over WLAN. - Sri - talking about the MAC address. Can change it typically. Want consistency between logical and physical interfaces. Pick one, or generate it. - Jari - This section is too hand-wavy, need more specifics. Case when no link identifier - still works, don't need to add one. If have link layer identifiers, used for a purpose, can't use a random identifier. How does it work with 2 WLANs, only works if both are settable. - Juan Carlos - Speaking as an author. Issue is on the WiMax side, last paragraph addresses this. Copy the WiMax address to the Wi-Fi side. Don’t have virtual identifiers, they are valid values. - Jari - Need discussion of secure discovery interaction. - Sri - as long as use is consistent. - Chair - Is there another way to choose? - Sri - use across all interfaces when needed. Have an issue when logical interface breaks down. - Julian - Trying to solve all cases in one pass. Pull them apart and document each one. The generic case doesn't fly. - Slide 5 - Issue 4 - Point to Point Links - Sri reviews issue. - Julian - Interface appears as a link to the application. Why appear as a shared link when it is really a point-to-point link. - Sri - Can stay silent on this. - Alex - Application sees logical interface as a shared interface. Need to see as any other interface, Then difference is to be the default route. - Sri - agree it needs to appear as any other interface. - Alex - Implementing mobile Proxy IPv6 in Wi-Fi. Needs modification for 802.1Q - logical node in client/mobile node; Looking for point to point node in Wi-Fi. - Sri - is on AP, for VLAN - Juan-Carlos - Have been discussing this also. LAN - 2 peers. Default Gateway - is this an issue to resolve? - Julian - Reviewed proposed text. IOCTL on the AP. Realize a point-to-point link at L2 is not defined here. - Alex - trying to do something on Wi-Fi that hasn't been done. Slide 6 - not yet resolved Slide 7 - Issue 6 - MTU considerations for the LI - have proposed text. - Julian - What if it becomes smaller. - Sri - can change MTU Slide 8 - Issue 7 UL/DL Packet Processing - - Sri reviewed issue and proposed text. - Jari - what are your assumptions on prefixes? How does it know that from policy - Sri - from the host perspective, general enough; may have multiple prefixes. - Julian - have not agreed on prefix use. - Chair - mark as unresolved and move on. 4. Proxy Mobile IPv6 Extensions to Support Flow Mobility -------------------------------------------------------- I-D: draft-bernardos-netext-pmipv6-flowmob-02 - Summarize the discussion on the ML Raj - Discussion of issues raised http://www.ietf.org/proceedings/80/slides/netext-2.pdf http://www.ietf.org/proceedings/80/slides/netext-3.pptx Presenter: Carlos Bernardos Slide 2 - Background and charter Slide 3 - Background and Draft History Slide 4 - Overview of the current solution Slide 5 - Overview of basic concepts Slide 6 - Issue 1 - Lack of customers for the work; disagree- interest expressed on the mailing list Slide 7 - Issue 2 - Policy consistency/coherence at LMA and NM - can have static pre-configuration or add mechanisms to endure dynamic consistency. Slide 8 -Issue 3 - Dependency on layer 2 signaling triggers. Note that Layer 2 triggers is not the same as layer 2 signaling. Slide 9 - Issue 4 - dynamic prefix management versus dynamic attachment of interfaces from sessions Slide 10 - Issue 5 - Knowledge of mobile node's signal condition at the LMA Discussion - - Stefano - Commend authors on slides - very creative. Slide on policy - slide 7. Real scenario today, device at enterprise, device purchased from service provider. Enterprise to tell SP how to configure LMA? - Carlos - Have text for this. Also allow the MN to ignore the advice. - Stefano - not a good design - Carlos - see as a last resort; assume policies are thee and consistent. - Stefano - If assumptions are not realistic, then designing something that is not realistic. - Carlos - Disagree that this is not realistic. - Rajiv - Policy is an overloaded term; how it's configured is irrelevant here. Use experience - far from that now. Mobile node knows conditions - agree. Haven't captured - LMA asking to move a flow. Mobile doesn't see the aggregate flow. Have scenarios from mobile and network perspectives. Ask "can I move this flow for a certain number of seconds." If MAG says ok, then can move the flow. - Jari - Have policy assumptions - important. IETF view into this operation; at least do no harm. Potential issue to think about - what if the other end isn't doing flow mobility? What happens then? Need to be failsafe in those situations? - Carlos - have text for this. - Rajiv - There is a draft re: EAP-AKA, mobile device indicates its ability and willingness to accept dual mobility. LMA goes through AAA to get characteristics. - Jari - Accept that. Might be other similar failure modes. - Julian - Slide 8 says no assumption of L2 signaling. Where is the baseline? Need layer 2 triggers. Think it is a kludge. Use l2 signaling. EAP-AKA signaling there anyway. Mobile node should decide, it is the only one that knows. - Carlos - Disagree. Current draft doesn't assume L2 signaling, may need to modify this. May be other ways - test/probe. Investigate further. - Rajiv - Need to be very clear of what you mean by L2 signaling. EAP-AKA provides one such mechanism - document this. Assume there is authentication, a database to query. - Jari - Don't think database is sufficient. Must either have no failure modes where packets get dropped, and know when you can do the additional mechanisms. Idea of having the mobile decide, and reflect that choice back to the network. - Rajiv - Need to know how to know that the mobile node can support this. Agree that mobile node knows the conditions. Need to capture the network intentions also. Approach should be network friendly also. - Chair - can't get data from a static profile, need to get from device in operation. - Julian - can we agree that layer 2 signaling to indicate the capability and willingness of the mobile to do flow mobility? - Jari - Mobile to network perspective, Mobile may need info about the network first. Network to mobile perspective - can both ask and test. Pretty much the design space. - Sri - How is this assumption changing anything? Be clear about when and what assumptions are made. - Chair - As Jari stated. Need to know that a logical interface is implemented. - Rajiv - can be more than one way of knowing the mobile’s willingness to support flow mobility, document at least one. - Stefano - need to be consistency on the policy. - Chair - Flow mobility is what we are defining. How this gets indicated as part of policy is out of scope. - Stefano - asking to have it captured that the assumption is that there must be coherence between the policies. Capture as one of the assumptions for this draft. - Chair - What do you mean? - If the LMA and MN want to do opposite operations, doesn't work. - Sri - Consistency for the policy assumption. - Speaker - Does this draft support moving a flow initiated from the MN and from the LMA? Yes. If MN - then that indicated support for flow mobility. - Chair - resolution on unmutable prefix set assigned to MN at attach. - Julian - Also, can we agree that L2 signaling is required? Proposed solution not generic. No need to assign prefix on the fly. - Rajiv - Either there is a single BCE on the LMA. Rely on AKA, have one session. Don't want to rule out other options. Combine capability of the MN to accept traffic from multiple prefixes. - Julian - Different session cases; only need to describe one. - Chair - on Logical interfaces - have proposed resolutions. - Flow mobility document - getting closer, summarize issues resolved, work on remaining, then ask authors to produce a new draft, get WG consensus to adopt that draft. - Meeting adjourned. ******************************************************** Agenda items: No time to discuss. 5. Bulk re-registration updates 5 Mins I-D: draft-ietf-netext-bulk-re-registration 6. Access Network Information Option for PMIP6 10 Mins I-D: draft-gundavelli-netext-access-network-option-00.txt Presenter: Sri Gundavelli See http://www.ietf.org/proceedings/80/slides/netext-4.ppt 7. Policy Signaling for Multi-access Mobility 10 Mins I-D: draft-koodli-policy-multiaccess-mobility-00.txt Presenter: Rajeev Koodli See http://www.ietf.org/proceedings/80/slides/netext-5.ppt 8. Prefix delegation for PMIPv6 7 mins I-D: draft-zhou-netext-pd-pmip-00.txt Presenter: Joy Zhou See http://www.ietf.org/proceedings/80/slides/netext-6.pptx