Network-Based Mobility Extensions IETF 79 WG meeting (Beijing, China) Tuesday, November 9th, 2010 1520-1700 Afternoon Session II and 1710-1810 Afternoon Session III (Emerald) Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) Minutes of meeting by: Carl Williams (carlw@mcsr-labs.org) Elena Demaria (elena.demaria@telecomitalia.it) 1) Agenda for IETF 79 meeting was presented by Basavaraj ------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG status update Chairs 5 Mins 3. Logical Interface Support for multi-mode IP Hosts Telemaco Melia 15 Mins I-D: draft-ietf-netext-logical-interface-support-01 4. Proxy Mobile IPv6 Extensions to Support Flow Mobility Carlos Bernardos 25 Mins I-D: draft-bernardos-netext-pmipv6-flowmob-01 5. Flow mobility support in PMIPv6 Tran Minh Trung 20 Mins I-D: draft-trung-netext-flow-mobility-support-00 6. PMIPv6 inter-working with WiFi access authentication Marco L./Sri Gundavelli 10 Mins I-D: draft-liebsch-netext-pmip6-authiwk-00 7. Multi-access Indicator for Flow Mobility Rajeev Koodli 5 Mins I-D: draft-koodli-netext-multiaccess-indicator-00.txt 8. a. Scenarios of the usage of multiple home network prefixes on a logical interface I-D: draft-hong-netext-scenario-logical-interface-02.txt b. Hybrid home network prefix for multihoming in PMIPv6 I-D: draft-hong-netext-hybrid-hnp-03.txt Yong-Geun Hong 15 Mins 9. Next steps Chairs 5 Mins 2) Working group status update ------------------------------- Basavaraj provided an update on working group activities including working group documents and additional proposals for the working group. Runtime LMA Assignment Support for PMIP6 (draft-ietf-netext-redirect-04). Draft presented at several IETF meetings. Author said nothing more to present at this IETF. This draft had several reviews and has been succinctly updated. It has completed working group LC. Author said to submit to IESG for review. There is security consideration issue that was raised on email alias. Whether we need two options (which draft has) or if we converge on just one we need to decide before submitting to the IESG. Bulk Re-registration for Proxy Mobile IPv6 (draft-ietf-netext-bulk-re-registration-02). Yokota-san and X. Cui have provided comments and draft was revised. Sri said it is ready for Working Group LC. Basavaraj said however that we need to have review of these documents and if we dont get reviews we will not progress documents. PMIPv6 localized routing problem statement (draft-ietf-netext-pmip6-lr-ps-03). Basavaraj stated already done working group LC. It has been a while since we reviewed document so we will do a short 1 week LC on this document and then forward to IESG. Localized Routing for PMIP6 (draft-ietf-netext-pmip-lr-01). Basavaraj wants reviews done before issuing a WG LC. Suresh has presented previous meetings. Basavaraj says that people arent paying attention to this document. He said he wants at least two reviews before going to working group last call. Carlos has volunteered and as well as Gaetan. Basavaraj wants reviews completed in next couple of weeks. Radius support for PMIP6 (draft-ietf-netext-radius-pmip6-00). Authors feel that the reason that there isnt so much interest in this draft is that there is lack of expertise in this room on radius. One option is to have experts from RADEXT or DIME to take a look at draft and provide feedback. Basavaraj also stated that the other way he looks at it isnÕt interest in these extensions at all for PMIPv6. We have to make a decision of what we want to do with this draft. Sri stated that he thinks this is essential and needs to be done. Basavaraj stated that we must solicit experts and that no one has reviewed this ID. AAA experts must be solicited by the authors for performing review. Julien suggested that this may not be required. Julien stated that there may be different options. Basavaraj stated that his reading is that even the authors arent making an effort to move this ID forward. Basavaraj stated that we need to say that this is needed for deploying the protocol; otherwise, it wont move forward. DIME and RADEXT working groups could provide expert advice. It is up to the authors to contact them. If authors want chairs to do Working group LC across RADEXT and DIME we can do that. 3) Logical Interface Support for Multi-mode IP hosts ------------------------------------------------------ Telemaco Melia presented draft-ietf-netext-logical-interface-support-01. Telemaco stated that together with Sri and other authors that he is only going to provide a brief update since last IETF and the discussion that has been going on over past weeks. Telemaco gave a picture of changes they did and went over them. Telemaco went over ND support for logical interfaces; been discussing support in terminal device and got implementation done. Got some feedback. Also went through comments at last IETF such as MTU issues. This is what we did since last IETF as well as we also worked on aligning ID with solution draft on flow mobility. Telemaco stated that they provided text with respect to the properties of the logical interface. Telemaco went over bullets with that text. Telemaco stated that he had off-line discussions prior to the working group meeting with 3GPP folks that property 6 bullet listed in his slide was relaxed. Property 6 states that: ŅThe Logical interface should transmit uplink packets on the same physical interface on which the downlink packet was received for the particular prefix/flow.Ó Telemaco then covers the discussion of the points he just made. The Virtual Link Layer ID Š we had a lot of discussion on this point. Telemaco says that we agreed that the Logical interface has a virtual link-layer identifier and it is used for ND operations; is stored in binding cache of LMA and used as source link-layer for sending packets from this logical interface. Telemaco stated that physical interface SHOULD be able to send packets with the VLL-ID as the source link-layer address and SHOULD be able to receive packets with the VLL-ID as the destination link-layer address. Julien: stated that some link-layers do not have link layer IDs. Telemaco Response: yes, so what we agreed is that there will be a configure exchange when bring up interface. The most common use case will be WiFi. Most WiFi interfaces can change MAC address. Julien: If you have to cope with the case that you cannot do that, why not use this same mechanism all the time. If you have to deal with the case that you cant change the link-layer id because there is no link-layer id, and you have a solution for this then why not use it all the time. Telemaco Response: what we discussed was an alternative to a mapping between the logical interface and the physical interface. Dont yet have complete picture. This is what we are currently working on. There are cases that we wont be able to support it right now and working on. Rajeeve: If you are designing for case dont work then why not use for default case and use it uniformly. Julien: It is logical and doesnÕt exist - only exist in host as a construct. Only the host sees the logical interface. There is no link-layer for the logical interface so dont need link-layer id. If you introduce this link-layer ID on wire then you run into problems everywhere. ND will break. Only host sees logical interface and why tell the rest of the world of it. Telemaco Response: It will simplify the solution. Julien: Only host sees logical interface and why tell the rest of the world about it by having an ID for it. You dont need to do this. Telemaco: Because the network has to be aware of it. Julien: No, it is logical. Sri: You need to abstract the physical interfaces. Julien: If you want to do slack the use then use EUI64 ID and you can ping from any interface you have. That is different from layer 2. Response: If you have this, the logical interface and use ND what you have to do is keep state for all logical interfaces. How many soft states you want to keep in the logical interfaces? Julien: Physical interface should be able to send packets with the VLL-ID - What about receiving? If I cant receive packets at the link-layer ID. Julien: You are making a lot of assumptions of what layer 2 you are using. Maybe this is WiFi. If it only works on WiFi, just write it. Basavaraj: Transmission is ok but receiving is problem. Julien: DonÕt need this fake thing it is just causing problems. Kent: I am assuming in the VLL-ID case only applies when you dont have it. For WiMAX you wouldnt use any specific vll-id and use R6 for example. I think it will still work but donÕt need to use vll-id. There is case where you have2 link layer id on physical oneÉ but only in case you support link layer ID on the physical. For non-link layer how does it apply here. I dont see the LL-id being applied for that case. Response: Ok. Julien: So what you are saying is that sometimes you use it and sometimes you do not? Kent: You dont have MAC address then you dont use it obviously. Kent: Use it when link layer is supported on the physical. Julien: what if one of the physical interfaces has a MAC address and the other does not. how do you deal with that case. Say you have 3G and you have WiFi, how do you do this? Julien: if you take step back, all pmip stuff was done for point to point links - then link layer ID is pointless. On many point to point links you donÕt have link layer IDs. It is a point to point link you dont need link layer IDs, you just send frame there and it arrives. If you expose then you run into problems. We have been discussing this for 20 minutes already. Just get rid of it. Julien: PMIP doesnÕt work on shared access links (doesnt work on wifi by itself). Šmake it point to point link. One VLAN per Mobile node and then in layer 2 destination put broadcast. Sri: Support: RA unicast. Julien: RA unicast is a different story. PMIP works on point to point links it is written in the spec. wanted to have it work on shared links but nobody wanted to do it. Now it is done this way and you canÕt change this. Julien: PMIPv6 only works on point to point links. Julien: are we changing this. We are not charter to change this. I am repeating myself now. Sri: I agree. As long as point to point semantics with same prefix and stick to mobile node and even if shared link if you can achieve that at the end of day what you have is a point to point link. Basavaraj: Obviously this issue needs additional discussion. I would recommend that the concept of how we use the virtual link layer id and what are assumptions and if we assume it works on certain access networks- we need to have further discussion. We can note it in minutes and move on. Telemaco continues on with his presentation and states that the link scoped unicast traffic is generated by logical interface. is sent through all physical interfaces associated to the logical interface. Telemaco says that because of the properties of the PMIPv6 domain this mode of operation of the logical interface does not add any issue from the point of view of ND Basavaraj: there may be some concerns as Neighbor discovery concerns. Telemaco: For the unicast case for link scope. Not sending multicast packet you are sending same packet on both links. Rajeeve: what you are saying is that you are sending same unicast packet on multiple physical interfaces. Not sending mulicast. Telemaco: yes. Telemaco: You have 2 options (comes in next slide) either you keep states for the ND procedures on any physical interface or you can in this case replicate the packet. We are discussing this and this is one of the option and we know it is working because we tested it. Suresh: if one of the interface is not up ICMP error can be generated. How does it work? Telemaco: From an IP stack perspective we dont change anything so if the logical interface sees that there is a packet generated for refresh neighbor cache for instance and one of the sub-interfaces is active and the other one is not active, then the inactive sub-interface is not going to be used. From a neighbor cache perspective of the logical interface there will be one entry which is the MAC because they share the same link local address. Telemaco: So from that perspective if I know which link is going to be used there is nothing wrong going on the neighbor cache. It looks like a normal neighbor cache and not touched and from this perspective it works. You just need to use the same packet on both links and it works. Suresh: what if same address exist on two of these interface that the packet goes out through how do you resolve duplication across multiple links for the same link local address? How do you maintain the neighbor cache? Telemaco: Which address is duplicated? Suresh: Let say that link local traffic - for example an address resolution NS Š is a link local multicast traffic . So letÕs say that I send a packet out to trying to resolve fad::3 for example and it is going out through multiple physical links, it is possible that there is somebody on both links whoÕs got the same address but different link-layer addresses, how do you handle merging these two things into the neighbor cache? Telemaco: There are only the MACs behind. And the MACs are configured per mobile node. Suresh: still point to point is ok. Julien: is this point to point or is this shared. They said it is shared. Julien: what if I send a MLD message to get some multicast traffic. I send an MLD join to receive multicast traffic am I going to receive it on all my physical interfaces Telemaco: Possible yes. Julien: You say link local multicast traffic, do you talk about neighbor discovery or link local multicast traffic? Response: I am using Neighbor Discovery here as we are talking about Neighbor Discovery. Julien: Am I only to do this for Neighbor discovery packets? Or am I suppose to do this for all the link local traffic? Telemaco: we are focusing here on neighbor discovery. If you want to know about other taffic, than we need to examine it. Julien: What I do when I send a MLD join - it is a multicast packet and link local - do I send it through all my physical interfaces? Then I am receiving all my traffic through all my physical interfaces. Jari: I am also wondering about that. I guess that the goal would be here that we do the construction of a particular interface and the end result is such that that host doesnÕt see a difference. It behaves as a normal interface. If it starts to receive packets multiple times, then that could be a problem. Basavaraj: The authors dont really understand how to deal with multicast join. Dealt with neighbor discover. Authors donÕt understand and they need to take a look. Telemaco: wasnÕt initially in scope. Carlos: The way in which we discussed it briefly is that this we are assuming this is in a constraint environment and control environment and talking to the same LMA (controlled environment). The MLD would go out through the LMA and traffic back and would be one single traffic back we shouldnt be receiving twice the response. It is only one single source request. I donÕt see a real deployment case where we would actually be receiving twice traffic on the two interfaces where we are sharing the link local or sharing the address for this case. Jari: one special case where this works is point to point links and nothing on other side; it doesnt matter what you send. You wont receive anything and there is nothing to receive your packet. If you speak on this in more general sense you have multiple of interfaces and you have applications like MLD or multicast DNS I am not sure what the right behavior is. For MLD it will be one behavior - one stream and for multicast dns I would like to resolve my name if it happen to be on some other interface. It seems like a tricky problem. Maybe scoping this down to where this could work it might be a reasonable approach. We havent got an agreement on this yet. We have multiple opinions and I am reflecting the current discussion. Suresh: why cant you keep state. Response: we can. Julien: We should discuss this on alias. Rajeeve: we need to have people to look at drafts weeks before meeting and also for the authors if there are sticky issues than authors should alert working group on the mailing list. Must do both. Telemaco: We can trigger discussion on mailing list but it would be nice to receive feedback as well. Basavaraj: we need to put on mailing list and not just discuss between the authors. Telemaco: says there are other slides such as MTU considerations and said this is easy to resolve. Then we are discussing support of LIF conceptual data structure. This is work that is going on subject to discussion. Comment: one way to address issue of logical interfaces is to provide examples. In 3g you have pdp context for primary connection. It would help discussion if you use those examples for discussion. Basavaraj: we will take this discussion to the mailing list and interest of time we need to move forward. We hope people are active on mailing list and provide feedback to authors. Basavaraj: we have two documents that discuss the flow mobility work. 4) Proxy Mobile IPv6 Extensions to Support flow Mobility --------------------------------------------------------- Carlos Bernardos presented draft-bernardos-netext-pmipv6-flowmob-01. Carlos stated that the first time this ID was presented was at IETF 78. Carlos went over changes since -00. Main changes were that he added more text on prefix deployment models. Carlos also added text on partial handoff scenarios. Next steps: design choices still open in draft. Feedback from the working group is welcomed. Carlos has asked for working group adoption. Julien: sent feedback on mailing list; shared prefix versus single prefix is irrelevant. What you need here is a prefix set. And member interfaces and move interfaces. Carlos Response: we are only high-lighting the scenario. Other case from point of how you deal with it from LMA and all sessions and you may know to signal information on MAG. Julien: start document with a model and then describe the model. How you address each case. With one of flows Š MAG doesnÕt need to know about the flow. Carlos Response: By default you only send info about prefix. Julien: why: Carlos Response: there are some use cases that you need that. Rajeeve: If you start from there you can see where this shared or unique. At time of mobile attachment, if it is same prefix, than nothing to do. Other thing is what you convey in the message. /64 is already there. With /64 you have a kind of wildcard and if you go over /64 you have more granularity. When LMA decides to move the flow it checks if prefix is valid on MAG or not. Parviz: from the application perspective is mobility seamless Carlos response: Yes, both interfaces are attached at same time. Vijay: is there are requirement that there is seamless mobility. Carlos: No, but have it anyways. Rajeeve: what do you mean by seamless. Basavaraj: Move flow from one MAG to another MAG. Whether it is seamless we are not looking at. Comment: do you agree the target should we move them seamlessly? Basavaraj: We are not worried about that at the moment. Rajeeve: Optimization comes next. We want basic operational document. So that flow movement happens. Let us first get basic mechanism working first. Rajeeve: Basic assumption we have a logical interface here. We arenÕt dealing with interface handover. We are not looking at interface handover. Sri: So I agree. With respect to flow granularity however I disagree. We have to stay within the scope of the prefix. This works for the use cases and how 3GPP can use it. If we try to do more than we have issues. Sri: Approach RFC 5213 Š it is called inter-technology handover. Melia: There are technologies that accept flow. Why should we cut off our legs. Sri: Not cutting of legs. It is about scope. The constraints: Interfaces. Rajeev: I have a comment on overall scope. CanÕt change anything on MN link. But can punch into the layer 2. You can explicity state that how to handle from MAG to mobile that it can be specified in the access layer. Sri: That is not in current scope. Rajeeve: Not making assumption about protocol that you need to specify. There are access specific signaling that is possible. Sri: What is this interface? At the end of the day someone has to implement. Basavaraj: I dont know about granularity aspect - dont know if you need signaling. Julien: Dont have changes on MN - that is the end of the story. Rajeeve: Let us figure lower bound on the mailing list. Regarding what we can do with layer 2 between the MN and MAG - let us discuss on the mailing list. The baseline is /64 so we have a wildcard granularity. Zuniga: Operator will have traffic selector and will want to send them to the UE. Carlos: You must have a customer for this solution. Most likely this will be an operator. We have shown that basically this is seamless. Worst case you get jitter and latency. 5) Flow Mobility Support in PMIPv6 ----------------------------------- T.Tran (ETRI) presented another ID on flow mobility. T. Tran stated that there are common points and different points with the previously presented draft. Sri: State diff between two drafts. T.Tran: First diff is donÕt require information from MN to MAG Š no extensions. differentatie clearly when flow description and home network description - pmipv6. Sri: can we agree that these are similar. Carlos: we dont require 5-tuple list Š that is optional. Comment: proactive method proposed here. We think of two cases. Rajeev: you should read draft. We are getting caught up in terms. Comes back to point when protocol needs to be involved. If it is already , then you can call this pro-active. Speaker: if this is pro-active. Rajeev: one mag one prefix another mag you iniated mobility session. Shared from beginning. Initiated tghat signaling. There is no difference there. No requirement for 5-tuple. Base line is /64. Comment: when you update prefix on 2nd mag, I donÕt see any prefix advertisement. Other thing I donÕt know how these drafts will work without specification of. How will host need to use that.. Basavaraj: fundamental assumption is the need for logical interface. It is in draft. Comment: is it tracking the interface id? Is binding cache tracking logical or physical? Response: logical interface id. Comment: both have same logical. How will LMA use it? Response: based on flow information. Flow mobility. Sri: solution is based on knowledge that the MN and LMA know exactly how to route flow. Basavaraj: suggestion to move forward asking both ID authors and work together and harmonize differences and common things. Hopefully we can create harmonize the document for a potential working group document. Basavaraj stated how quickly can come with single draft for consideration for a working group document. 6) PMIPv6 inter-working with WiFi Access Authentication -------------------------------------------------------- Marco Liebsch presented draft-liebsch-netext-pmip6-authiwk-00. Marco noted that this is new draft. Netext is not chartered to work on it. This is just analysis and documentation only. Not extensions. Marco stated that RFC5213 assumes completed authentication procedure before registration. Marco noted that approach/solution is not documented in the IETF. Enable WLAN trusted access Š 3GPP recommendations for security and for PMIP operation using non-3GPP radio access. Also, there is the WIMAX forum specification for WiFi inter-working. Marco stated that the document objective is for a general BCP for AuthN inter-working with PMIPv6. Also, that it serves to provide advanced documentation including other SDOÕs deployment and recommendations to use a particular authentication method as well as includes inter-working between WiFi AuthN and operatorÕs AAA. Finally Marco stated that the document will identify protocol gaps and need for IETF specification. Marco asked is such a document useful for the IETF and has a reasonable scope. Comment: Is there any info on BBF? I think there is some work being done? Not aware of any details. Comment: recently there has been discussion in BBF in connection to the 3gpp common architecture for fixed line access. If the mobile initially attached to 3gpp network or moves to hotspot, then UE is not visible to the RG or BRASÉ this is where 3gpp and BBF to work together so that the UE can be known to BBF access. So wifi in that case complicates picture. Parviz: I agree for today that if you look at architecture that is being discussed, wireless lan controller is not in architecture map. Personal view wireless lan controller can be co-located. Basavaraj: take BBF discussion to mailing list. Yokota-san: interesting work. Wifi/ap and controller mag box --- (* combined or controller *) Marco: This is wireless lan specific. Comment: is only thing you mean that if you make auth available to mag and extract that thing that the mobile becomes ?? Comment: Because I heard you talk about un-trusted. Response: Trusted relationship with the network. Comment: today this is what happens in 3gpp - wifi is untrusted. Parviz: Business model can own and operate a hot spot. It is business question. Not IETF topic. Want to control all the hotspots, then this is an topic to pursue. Sri: if you look in wireless enterprise model, it is trusted. If it managed hotspot. Basavaraj: dont know if this debate about trusted and untrusted is relevant to what you are trying to proposal. Marco: we can address this on mailing list. Kent: this is already commercially deployed. The whole trusted wifi 3g. Basavaraj: what are we proposing to be done? Marco: maybe documenting for the IETF community. We propose just to describe for IETF. Comment: if you actually look at .... goes to auth server interesting part to combine all of them into one auth. Speed up the process instead of cascading them. Raj: how many have read the draft? - only 2 people. Basavaraj: how many people think that describing this in doc makes sense? 6 or 7 hands. Basavaraj: how many people see no value from this I-D?. No one raised hands. Basavaraj: Some people said yes but we wont make any decision now. So people should read doc and we can guage interest on the mailing list. 7) Multi-access Indicator -------------------------- Rajeeve Koodli presented draft-koodli-netext-multiaccess-indicator. Rajeeve stated that it is important that when a mobile node attaches to the mobile network using multiple access networks that the mobile network gateway to know whether the mobile node is capable of simultaneous multi-access. This is important so that the mobile network gateway can distribute the traffic flows using the appropriate interface. Rajeeve states that this document defines a new EAP attribute which can be used for such an indication to the mobile network gateway. Rajeeve stated that the document defines a new flag for the MIP6-Feature-Vector AVP in RFC 5447, which may need IANA assignment. This document defines a new EAP attribute to extend the capability of the EAP-AKA protocol. This attribute is passed from the MN to the AAA server. The document doesnÕt specify any new messages or options to the EAP-AKA protocol. Comment: isnt this info be available to the MAC? Rajeev: the attribute exchange is between mobile and AAA server. Rajeeve: we can write a draft. I think LMA needs to know if it is authorized. Jari: I think you were extending EAP. Of course you may want to worry about independence. Even if you have information coming from more than one source. That is only concern I have. Basavaraj: LMA needs to know you have logical interface. And in order to provide flow mobility you need logical interface. Rajeeve: this is only one way to do it. Not only that the mobile has the logical interface capability but also it is authorized. Parviz: The RAT type can be whatever the multi-access information on attachment is unclear. The authenticator is not the pdn-gw Basavaraj: what does the working group think about specifying this here? How many have read the doc? One hand. Basavaraj: LMA needs to know MN has logical interface - that is gap now. This is one way of handling the issue. Basavaraj: I will pose question on mailing list and give people time to read doc and take the question on mailing list so people can make informed decision. 8) Scenarios of the usage of multiple home network prefixes on a logical interface --------------------------------------------------------------- Y-G. Hong from ETRI presented draft-hong-netext-scenario-logical-interface-02. Mr. Hong stated that a logical interface is used to hide the existence and the change of physical interface from the IP layer of a host and it also can be used for a multiple interfaces mobile node in PMIPv6 domain. Mr. Hong explained that there are various usages of multiple home network prefixes on the logical interface if a LMA assigns multiple home network prefixes to a multiple interfaces mobile node with a logical interface. His document describes the usages. Mr. Hong asked is describing various scenario of the usage of the logical interface in PMIPv6 necessary and is there interest in working group? Yuri: I think this work is related to flow mobility drafts. So this work is tightly coupled with that work. So from my point of view Š it will be part of draft that describes flow mobility. Telemaco: This shouldnt be part of separate document. If there is something missing then put into the main document. Basavaraj: letÕs take a look at scenarios and how best to document it. We can put it in appendix of logical interface draft. From my perspective we can capture as part of flow mobility document. 9) Hybrid home network prefix for multihoming in PMIPv6 -------------------------------------------------------- Y-G Hong presented 2nd draft draft-hong-netext-hybrid-hnp-03. Mr. Hong stated that if the flow is classified by home network prefix, to support flow mobility between different interfaces. To enable PMIPv6 to support both inter-technology handoff and simultaneous access at the same time. Goals of draft to propose a hybrid home network prefix assignment scheme Š 1. Separate prefix for the purpose of inter-technology handoff and the purpose of simultaneous access; (2) During flow mobility, some flow (prefix) is moved to another interface and some flow (prefix) is left over. Basavaraj: has anybody read draft? No one. Basavaraj: is going to ask for feedback on the alias for this draft. Comment: would this be a competing solution for what Rajeev is proposing? Rajeeve: I dont know. My reading is that Home network prefix is used for these two things - simultaneous access and for inter-technology handoff. Basavaraj: read the draft and see if it is solving problems. Wrap-up discussion of Beijing working group meeting. Basavaraj: Regarding next step: - Not having enough discussion on mailing list. - Logical interface document and flow mobility document Š hopefully can move forward. - Localized routing and bulk and run-time IDs - we need to get people to review and comment and feedback - otherwise we are not making progress.