IETF94 DMM WG Meeting Minutes 1. DMM WG Meeting is called to order at 9am by Dapeng Liu, chair of the meeting. Alex helped with jabber. The chair presents wg status and meeting agenda. Fred Templin presented AERO DHCPv6 PD implications (draft-templin-aerolink-63). Client may be host, router, or hybrid host/router. In any case, prefix is entirely owned by the client so that DAD is not necessary on AERO interface. Seil Jeon presented use cases and API for source IP address selection (draft-sijeon-dmm-use-cases-api-source-02.txt). It is intended to select the new address as much as possible. Terminal may have multiple sustained IP addresses with distributed mobility anchors. According to source address selection rule 8 in rfc 3484, the default address selection takes the longest matching prefix, which may not be the new address. Propose to add ON_NET property API as IPv6_XX_SRC_ON_NET in addition to being a sustained IP address. Dapeng asked how the MN knows which is serving address and which is new address. Ans. This is only between application and MN. Sri suggests to generalize, to list the properties of the different addresses so that the MN may choose. Danny asks if there is use case for application to not choose new sustained IP prefix. Want to ensure the new parameters are really needed. Ans. It is proposed as a Brian asks whether it is possible to use rule 6 in rfc 3483 to use label in the policy table for address selection. Ans. Will check. Sri added that the use of label may also be combined with the use of coloring. About 4-5 people have read the document. Chair suggests to trigger more discussion before considering adoption. Dennis presented update of exposing the mobility state work team. Next steps on new draft for link-state info exposure. Item 1 (communicate IP address type between application and IP stack on the MN) next steps are Initiate last call for ondemand-mobility draft New draft for link-state info exposure is planned. Item 2 and 3 (convey IP address type information from network to MN, dynamically configure a required type of IP address): Chair request more people to review this draft. Marco asks to clarify which draft. There has been no response to Alpher’s draft. draft-moses-dmm-dhcp-ondemand-mobility-01 . Dennis mentioned there were interests. Yet few people in the room have read it. Chair suggests people should review the document before issuing LC. Brian asked whether anybody reads any other draft? There are some. Item 4 (how MN decides which layer of mobility support on a given flow) The individual draft was draft-yegin-ip-mobility-orchestrator-00 It is soliciting comments. Anthony presented on mid-session anchor switching. Sri asks about whether it is moving the 64-bit prefix of the link between the router and the MN. Ans. Therefore the previous router needs to release the prefix and the new router needs to request prefix delegation. The question of scalability with BGP route updates is raised. Fred clarified the different uses of mobility within a network versus across networks. Micro-mobility can be used within network. BGP updates are only used for mobility across networks. Carlos also commented that from his analyses there are scalability issues with BGP route updates. Ans. In addition to Fred’s clarification, the BGP is only a place holder. The solution is intended for use with SDN network where the forwarding table updates of the distributed switches/routers are accomplished through the command from a centralized controller. Question is raised on whether the updates are propagated to the Internet. Ans. This solution is intended for cases with a centralized control plane, and is therefore most appropriate to be used within a data center. Sri asked how to restrict the mobility within the scope. Ans. With global mobility moving to any network, the network should use other mobility mechanism such as tunneling. That can be the scope of another draft to be written. Marco commented that we need to take care of migrating the context from pAR to nAR. It may be good to use BGP as an example only, but not binding it to the solution. Marco asked whether BGP is only an example here. Ans. Yes. Chair thinks there are interests on this topic and suggests to seek opportunities to make this draft more mature. The scope should be clarified in the draft, and it should seek alignment with work of other teams. Ans. Drafts from other work teams have been referenced in this draft. John presented on prefix-cost. Danny asks there is need to convey the information to the application developers. Ans. Examples are the connection manager in 3GPP. Danny suggests alternatives such as expecting applications indicate what they want (e.g., indicate to socket) and communicate it to network and let the network provide the resources. For example, a slow link is not suitable for real-time applications. Ans. Will discuss such additional method separately. Sri asks whether there are use cases. Ans. They are in the motivation slides where a MN moves to a different AR. The new path is not yet optimal. Marco asks that wt one already has 3 different IP addresses. Does this complement that work. Yes it complements. For example, a sustained IP address can change in cost as the MN moves. The cost can come from a combination of policies, e.g., charging, etc. Marco presented on control-data plane separation. John commented that the idea of abstraction is good. ChunShan Xiong commented that the network may deploy both models (with and without centralized network controller) combined together. John asks whether mobility control function includes session management. Ans. Mobility control function will include some session information needed for mobility. As to whether it should include other session control functions, we limit the scope to mobility in this draft. Satoru suggests to have a declarative model as a base model. More attributes and parameters may then be added. Ans. Agree. Sri agrees with Satorou. The draft can emphasis on standardization of attributes. Chair commented that the security part needs more work. Ans. Agree. Vic Liu presented update on deployment scenario. (draft-liu-dmm-deployment-scenario-05) More details on NFV deployment are added. Sri agrees to read and provide comments. MIP Maintenance work: Sri presented on LMA controlled MAG parameter options: binding re-registration control sub-option, and Heartbeat control sub-option. John commented that a minor correction will be provided. Chair asks: several people（6） have read and the same people agree on adoption. Will use mailing list for feedback and adoption. Yan presented on prefix renumbering: draft-yan-dmm-dnprenum-03 6 people support the adoption. Will confirm adoption in mailing list. draft-seite-dmm-rg-multihoming-02 Sri commented on protocol extension only to allow multiple CoA. Not on use cases. It has removed reference to BBF use cases in this version. Praveen asked to remove mention of DSL. Ans. Yes. Praveen questioned about hybrid access that for a single PDN with 2 addresses, is it a link or connection. Ans. interface Bechet commented that the multihoming is a fixed network problem, which is outside the scope of PMIP. Brian commented that dmm has the responsibility of maintaining the protocol of PMIP. It is also an option so that people may use it for other uses not necessary on mobility. 8 people support the adoption. Will confirm call for adoption in mailing list. Overflow presentations: Jong-Hyouk presented on deprecated network prefix provision (draft-jhlee-dmm-dnpp-00) If the deprecated network prefix is not known to the new network, ingress filtering may drop packets of the deprecated address. Brian asks clarification on deprecated address. Ans. CoA. Brian also comments RS/RA extension should also go to 6man. Charlie presented on mind update. (draft-ietf-dmm-4283mnids) Will use mailing list for WGLC. need more review. Hui presented on motivations and use cases of Virtual CPE. (draft-fu-dmm-vcpe-models-00) Sri supports this draft. All presentations have been completed, and there are no further questions. Chair closes session at 11:28.