[DMM] Meeting Minutes - DMM@IETF99

["Sri Gundavelli (sgundave)" <[e-mail]>]

Thanks to Lyle Bertz for capturing this notes.



On 7/20/17, 12:22 AM, "Bertz, Lyle T [CTO]" <[e-mail]>
wrote:

>Copied over from Etherpad for your reference.
>
>** DMM Working Group Agenda **
>
>
>Date:  Wed, July 19th, 2017
>Time:  9:30 AM to 12:00 PM, CEST
>Location:   IETF99 - Prague, Czech Republic
>Meeting Chairs: Dapeng Liu (Alibaba) & Sri Gundavelli (Cisco)
>
>
>9:30  AM:
>Title: Administrivia & Intro, WG organization & milestones
>Time: 15 minutes
>Description: Agenda, Note-taker negotiation and WG Progress Update
>Presenters: Chairs
>
>
>9:45 AM:
>Title: Protocol for Forwarding Policy Configuration (FPC) in DMM
>Time: 25 minutes
>Presenter: Lyle Bertz
>Description:  Document Status and Changes
>Draft: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-07
>
>- have been working weekly since Chicago
>- focus on topology and policy
>- implementation from Verizon (demo'd at MWC)
>- ONOS and OpenDayLight.
>- this is an information model (abstract)
>- enhanced type model - DPN type
>- topology is only for DPN selection
>Suresh (AD): how soon before deadline?
>Lyle: Aiming for end of Sept.
>Sri: when are reviewers assigned?
>Suresh: when you tell me its ready from YANG perspective. These specs are
>obscure for those outside the area. Let's avoid last-minute surprise.
>Lyle: understaood.
>Dapeng: volunteers within this WG? (no one volunteered)
>Suresh: without review, this document doesn't leave WG. Wants to see
>non-author read.
>Lyle: invite anyone to pop into the weekly calls.
>SSuresh: we need people within the group to review. Wants to see more
>discussion on list.
>Lyle: we have write-up internally, will see if impact on mobility.
>Determines how much before
>
>
>
>
>10:10 AM:
>Title: MN Identifier Types for RFC 4283 MN Id Option
>Time: 15 minutes
>Presenter: Charlie Perkins (and Suresh Krishnan on IESG feedback)
>Description: IESG DISCUSS Status
>Draft:  https://www.ietf.org/id/draft-ietf-dmm-4283mnids-04.txt
>- Lots of discussion around types and issues on mailing lists wrt the
>draft
>- Security issue
>    - Believe we have possible resolutions for issues that were raised
>    - Presented many parts of the mailing list discussion in the
>presentation
>    - RFID Types explained further
>    - Noted adding more types for LPWAN
>- Reviewed commentary from mailing list
>    - Privacy concerns
>        - MNIDs by their nature are privacy issues
>        - recommend encrypting all MNIDs
>    - Why so many MNIDs?
>        - people ask for them
>        - this proposal is a registry
>        - MUST encrypt (proper security measures) can help with the
>    - Low energy on mailing list on what is needed
>        -  push registry to drive the expert review
>        - ensure IANA considerations in the registry are strong
>        - confirmed - only really for newer MNID types
>        - plan is to change IANA policy, get approval, designate the
>experts and move on
>- Next steps
>    - straw proposal
>    - keep id types and make further considerations and re-submit for
>last call
>- No hard delivery date for the next steps
>
>
>10:25 AM:
>Title: Distributed Mobility Anchoring
>Time:  15 minutes
>Presenter: H Anthony Chan
>Description: Update on the changes related to last call comments
>Draft: 
>https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-
>06
>- 4 reviews resulting in 3 version updates; 1 review pending
>- Reviewed each change
>    - In 06
>        - deleted slicing from the document
>        - deleted security management
>        - Removed description of the forwarding table
>- Noted the draft does not propose a solution but describes the mobility
>anchor and parameters used in communication/signaling
>- Described in detail the many different examples by which DMA can be
>achieved
>- Clarified scope of document and organized it so that you don¹t have to
>read everything
>- Chair wants to ensure that all 4 prior reviewers approve the changes in
>the latest spec version
>
>
>10:40 AM:
>Title: On Demand Mobility Management Socket Extensions
>Time: 15 minutes
>Presenter: Danny Moses
>Description: Update on changes to the draft since IETF 98
>Draft: https://www.ietf.org/id/draft-ietf-dmm-ondemand-mobility-11.txt
>- reviewed l(blocking issue)
>- noted request from chairs to address socket blocking (setsockopt)
>raised in IETF 98 by Erik Kline
>    - 3 alternatives proposed and put on list
>    - Noted that there was no mailing list response
>    - Dave Dolson made a comment (off list) but did not select one of the
>3 options nor discussed it on the mailing list
>    - Selected 2nd alternative
>        - Chair asked if issue originator was satisfied by the solution?
>        - What is the guarantee of the SetSc return? session has been
>successfully allocated and assigned to the client
>        - v6 Only noted several times
>        - Requests for accepting 2nd alternative
>            - As long as the function is documented that it blocks
>            - For POSIX, a non-blocking version or call back version is
>async probably should be provided
>            - AD - Do we need another abstract function?
>            - EK - depends on OS
>        - In general, bind is hard to use cause the AF must be known
>            - More than 1 V6 address in the return? no
>            - SetSc uses return address
>            - Another approach raised - set preferences then do something
>else
>        - Michael - the text is not clear that the APIs are abstract;
>needs to make clearer
>            - does not mind but concerned by issues raised in other IETF
>99 meetings
>            - Suresh - although we don¹t do language bindings; goal is to
>stay abstract
>            - Lyle - Suggested to change any reference of Œcode¹ to
>pseudo code to make it more apparent it is not a language binding.  This
>seems to address the concern
>        - Suresh - this work and privacy access are orthogonal; not sure
>how the flags are considered or merging (RFC 5014 and this work)
>            - Need to check between specs and make some new considerations
>- Support of future on demand types
>    - add new continuity type similar to 3GPP SSC mode 3
>    - time limited session continuity
>    - valid and preferred lifetime
>    - Suresh - already signaled in the framework
>    - What is the graceful replacement use case (will ask on mailing list)
>
>10:55 AM:
>Title: DMM Deployment Models and Architectural Considerations
>Time: 5 minutes
>Presenter: Seil Jeon
>Description: Update on the draft status
>Draft:  https://www.ietf.org/id/draft-ietf-dmm-deployment-models-01.txt
>- quick update
>- Chair suggest to authors to fined reviewers (offline) for the document
>
>
>11:00 AM:
>Title: SRv6 for Mobile User-PlaneTime: 15 minutes
>Presenter: Satoru Matsushima
>Description: Applicability of SRv6 (Segment Routing IPv6) to user-plane
>of mobile networks
>Draft: 
>https://tools.ietf.org/html/draft-matsushima-spring-dmm-srv6-mobile-uplane
>-00
>- Context; a new proposal
>- Showed current example of mobile network and tunneling solution
>- Showed SRv6 impact
>- Gave Srv6 in a nutshell review
>- Showed examples of how this solution supports
>- related to FPC yang as a possible way to implement the solution
>Questions
>- Xingpeng- Does this work use the prefix types for on demand mobility?
>    - Don¹t think this is binding to the MN address assignment.
>- Marco -  May add more items to the paths that are not representative of
>roles
>    - How is QoS handled? It is mentioned in the draft
>- Dapeng - Why this vs. any other solution?  Gets rid of tunnels
>- Sri - Very good work item but not in the charter.  Keep progressing and
>will discuss with AD.
>- Author hopes to update
>
>
>11:15AM:
>Title:  Network-based and Client-based DMM solutions using Mobile IP
>mechanisms
>Time: 15 minutes
>Presenter:  Carlos Jesús Bernardos Cano
>Description: Use of MIP protocol in DMM architecture
>Draft (s):
>https://www.ietf.org/id/draft-bernardos-dmm-cmip-07.txt
>https://www.ietf.org/id/draft-bernardos-dmm-pmip-08.txt
>https://www.ietf.org/id/draft-bernardos-dmm-distributed-anchoring-09.txt
>- reviewed the various documents
>- noted prior demos @ IETF
>- noted open source code availablity
>- ask WG if this work should continiue and will follow this up on the
>maling list
>
>
>11:30 AM:
>Title: Anchor-less Mobility Management
>Time: 10 minutes
>Presenter:  Xinpeng(Jackie) Wei
>Description:
>Draft:  https://tools.ietf.org/id/draft-wei-dmm-anchorless-mm-01.txt
>- reviewed proposal
>- described MEC use case (smart relocation) and changes for DMM
>- has the author looked at LISP? Yes
>
>11:40AM:
>Title: Router Advertisement Prefix Option Extension for On-Demand Mobility
>Time: 10 minutes
>Presenter: Wu-chiX Feng
>Description: Extensions to ND for indicating Mobility Service Type
>Draft:  https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-00.txt
>- reviewed
>- suggested it was brought to 6man (was done)
>- no conflict with X bit but there is another proposal to burn anohter
>bit which eats 2 of the 3 R-bits
>- Suresh noted an extension mechanims for the exhaust or control through
>a registry
>- Alex - Who makes the demand?
>
>    - Authors: We don't want to change the semantics of RS with this
>proposal. Network will provide alternatives for the 'who'?
>
>- If there is an argument to modify RS we could try but authors were
>discouraged.
>- PBD option may be good for this.
- This should be discussed in 6MAN Working group, suggested by Suresh and
others.

>
>11:50 AM:
>Title: FORCES for FPC
>Time: 5 minutes
>Presenter: Jamal Salim
>Description: Proposal for using FORCES on FPC as a south bound protocol
>Draft: TBD
>- Lyle - As an author we are interested in finishing the information model
>- as an implementor interested in the protocol
>
>
>
>11:55 AM:      Adjourn
>________________________________________