Re: [DMM] questions about draft-mhkk-dmm-mup-architecture-00

[Satoru Matsushima]

Hi Linda, thanks for your question.

MUP is an architecture which is independent from specific mobile service
architectures (e.g., PMIP, 5G, 6G, xG, etc.,) and pluggable user plane part
for those architectures.
If you want MUP for a specific architecture and an interface in the
architecture, you can find appropriate session information to use MUP.

cheers,
--satoru


On Sat, Mar 30, 2024 at 11:04 PM Linda Dunbar 
wrote:

> Satoru, et al,
>
>
>
> Is the architecture proposed by draft-mhkk-dmm-mup-architecture-00 for the
> N3 Interface of 3GPP (i.e., the network connecting all the  gNBs and UPFs)?
> Or for the N6 Interface (UPFs and Data Network)?
>
>
>
> The document states that In MUP Architecture, session information between
> the entities of the mobile user plane is turned to routing information.
>
> Can you please elaborate what are the “session information” and the
> entities of the mobile user plane?
>
>
>
> Thank you very much,
>
>
>
> Linda Dunbar
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Meeting minutes draft for DMM@IETF119

[Satoru Matsushima]

Dear DMMers,

Our meeting minutes draft is available (Thanks Darren!) on the following
url:

https://notes.ietf.org/notes-ietf-119-dmm?view

Please review it and fill it with your corrections if needed. (Minh, please
correct your answer to the question from Yuya)

Best regards,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Proposal for discussion on SRv6 MUP

[Satoru Matsushima]

Hi Taihei, thank you for your mail and you don’t need to sorry. 
We had a hackathon project on SRv6 MUP in IETF116. If you plan to do next SRv6 
MUP hackathon, that would be great. I will be in the hackathon venue, and am 
happy to talk with you.

Cheers,
--satoru

> On Mar 15, 2024, at 20:30, Taihei Yamaguchi 
>  wrote:
> 
> Hello.
> I apologize for contacting you so suddenly.
>  My name is Taihei Yamaguchi from Keio University and I will be participating 
> in the DMM WG meeting at this IETF. 
> He is interested in SRv6 MUP technology and is thinking of participating in 
> the hackathon, although it will be his first time participating. 
> So, will the DMM WG implement and discuss SRv6 MUP at this hackathon meeting? 
> If I don't have such plans, I would like to do it.
> Taihei Yamaguchi(山口泰平)
> 
> WIDE Project / Keio University
> 
> Jun Murai Lab B2
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] DMM WG Agenda for IETF119

[Satoru Matsushima]

Dear DMMers,

We will have a DMM meeting at IETF119. Please let us know if you have any
topic to the meeting with your presentation title, presenter, and time.

DMM WG meeting session will be held on Monday 3/18 13:00 - 15:00 local time.

Cheers,
Sri, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM WG Adoption Poll (2) for "Mobile User Plane Evolution" - draft-zzhang-dmm-mup-evolution-06

[Satoru Matsushima]

Hi all, thanks for the discussions and comments. Please find the chair's
review on the WG adoption poll (2) from chair's slides for the yesterday
DMM WG meeting:

https://datatracker.ietf.org/meeting/118/materials/slides-118-dmm-chairs-slides

Cheers,
--satoru



On Fri, Oct 27, 2023 at 8:57 PM Kaippallimalil John <
john.kaippallima...@futurewei.com> wrote:

> Hello,
>
>
>
> I don’t object to the adoption of this work, but the focus of the draft
> should be changed to address details of realizing “ANUP”.
>
> That would be necessary for a useful RFC down the line, and not what 3GPP
> should (or should not) do.
>
>
>
> The current draft focus is on advocating why 3GPP should do something:
>
> (i.e., “If the ideas in this document are deemed reasonable, feasible and 
> desired among these  parties, they can then be brought to 3GPP for further 
> discussions.”.)
>
> This goal is perhaps better accomplished with a discussion paper in 3GPP 
> SA2/SA1, rather than an IETF RFC that says what is better to do in 3GPP.
>
>
>
> On the other hand, more information on realizing ANUP in “wireline”/IP and 
> mobility aspects should be provided.
>
> For example, aspects on addressing, mobility, performance, measurement, 
> manageability of entities and services, scalability, etc.
>
> I would note that 3GPP only defines AN and UPF functions, while this draft 
> can add value by describing how to realize an N x M AN and UPF instances 
> behaving as a single manageable “ANUP” entity.
>
> (and assuming/based on already defined 3GPP CP session and mobility 
> functionality)
>
> Regards,
>
> John
>
>
>
>
>
> *From:* dmm  *On Behalf Of * Satoru Matsushima
> *Sent:* Thursday, October 19, 2023 4:41 AM
> *To:* dmm 
> *Cc:* draft-zzhang-dmm-mup-evolut...@ietf.org
> *Subject:* [DMM] DMM WG Adoption Poll (2) for "Mobile User Plane
> Evolution" - draft-zzhang-dmm-mup-evolution-06
>
>
>
> Dear DMMers,
>
>
>
> This email starts a two-weeks DMM WG adoption poll (2) for ""Mobile User
> Plane Evolution" - draft-zzhang-dmm-mup-evolution-06.
>
>
>
> https://datatracker.ietf.org/doc/draft-zzhang-dmm-mup-evolution/
>
>
>
> Please review the draft and post any comments on this mail thread prior to
> Friday, November 3rd, 2023.
>
>
>
> Regards,
>
> Sri, Satoru
>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: New Version Notification for draft-duongph-dmm-computing-aware-ts-mup-sr-01.txt

[Satoru Matsushima]

Thanks Dương,
cheers,
--satoru

On Sat, Oct 21, 2023 at 3:51 PM Dương Phùng Hà 
wrote:

> Dear DMM Working Group,
>
> My name is Phung Ha Duong. I will attend the IETF 118 Prague onsite,
> especially the DMM meeting.
> If it is possible, I would like to get 10 minutes for a presentation about
> my new draft.
>
> https://www.ietf.org/archive/id/draft-duongph-dmm-computing-aware-ts-mup-sr-01.html
>
> Thank you for your consideration and look forward to hearing from you.
>
> Regards.
> Duong
>
> -- Forwarded message -
> From: 
> Date: Fri, Oct 20, 2023 at 9:13 PM
> Subject: New Version Notification for
> draft-duongph-dmm-computing-aware-ts-mup-sr-01.txt
> To: Ha-Duong Phung , Minh-Ngoc Tran <
> mipearlska1...@dcn.ssu.ac.kr>, Younghan Kim 
>
>
> A new version of Internet-Draft
> draft-duongph-dmm-computing-aware-ts-mup-sr-01.txt has been successfully
> submitted by Ha-Duong Phung and posted to the
> IETF repository.
>
> Name: draft-duongph-dmm-computing-aware-ts-mup-sr
> Revision: 01
> Title:Computing Aware Traffic Steering Use Cases of Mobile User Plane
> using Segment Routing
> Date: 2023-10-20
> Group:Individual Submission
> Pages:15
> URL:
> https://www.ietf.org/archive/id/draft-duongph-dmm-computing-aware-ts-mup-sr-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-duongph-dmm-computing-aware-ts-mup-sr/
> HTML:
> https://www.ietf.org/archive/id/draft-duongph-dmm-computing-aware-ts-mup-sr-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-duongph-dmm-computing-aware-ts-mup-sr
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-duongph-dmm-computing-aware-ts-mup-sr-01
>
> Abstract:
>
>5G support new emerging high reliability and low-latency services by
>Mobile Edge Computing.  Multiple instances of the same service can be
>deployed over different edge sites to enable high availability,
>scalability and better response time.  However, due to different
>computing loads and network resources overtime, a specific edge site
>might not always guarantee service quality.  Routing user traffic to
>an overloaded edge site can significantly affect user service
>experiences.  Current 5G mobile network does not have a method to
>dynamically steer traffic to an optimal service instance based on
>network status and edge sites' computing resources availability.
>
>This document describes solutions to provide computing-aware traffic
>steering methods for the 5G mobile user plane using Segment Routing.
>The solution explains how to use Segment Routing to deliver mobile
>user traffic dynamically to the best edge site destination based on
>both computing and networking resource information in the mobile user
>plane.
>
>
>
> The IETF Secretariat
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] DMM WG Agenda for IETF118

[Satoru Matsushima]

Dear DMMers,

We will have a DMM meeting at IETF118. Please let us know if you have any
topic to the meeting with your presentation title, presenter, and time.

Cheers,
Sri, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM WG Adoption Poll (2) for "Mobile User Plane Evolution" - draft-zzhang-dmm-mup-evolution-06

[Satoru Matsushima]

Katsuhiro, Jeffrey, please clarify what the control plane means here. E.g.,
(1) control plane in mobility management (MM) and session management (SM)
in 5G architecture, (2) signaling protocols for N1/2 and N4, or (3) control
plane for IP routing, BGP, etc.,

Cheers,
--satoru

On Sat, Oct 21, 2023 at 5:28 AM Jeffrey (Zhaohui) Zhang  wrote:

> Hi Katsuhiro,
>
>
>
> Please note that this document does not conflict with draft-mhkk.
>
>
>
> Regarding “Control plane convergence should indeed play a pivotal role”, I
> observe that draft-mhkk is still based on the separate N2/N4 signaling in
> case of 5G, even though the N4 is translated to BGP.
>
>
>
> In fact, while the AN + UPF integration will benefit from integrated
> signaling in 6G, in 5G the integration can be done as an implementation
> choice w/o integrating N2/N4, and it can even use BGP signaling (that was
> defined for draft-mhkk) – as in
> https://datatracker.ietf.org/doc/draft-zzhang-dmm-anup5g-signaling/.
>
>
>
> Thanks.
> Jeffrey
>
>
>
> Juniper Business Use Only
>
> *From:* dmm  *On Behalf Of * Horiba, Katsuhiro
> *Sent:* Friday, October 20, 2023 10:03 AM
> *To:* dmm@ietf.org
> *Subject:* Re: [DMM] DMM WG Adoption Poll (2) for "Mobile User Plane
> Evolution" - draft-zzhang-dmm-mup-evolution-06
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hello,
>
> > ANUP solely addresses user plane convergence and tries to liaise with
> 3GPP,
> > but I'm afraid this is a half-baked attempt.
>
> I concur with this observation, as a co-author of
> draft-mhkk-dmm-srv6mup-architecture-05.
>
> Control plane convergence should indeed play a pivotal role in realizing
> the original DMM concept,
>
> as the control plane information serves as the foundation for route
> advertisements from (R)AN.
>
> The genuine potential of ANUP can be fully realized when both user and
> control plane convergence are achieved.
>
> Is there anyone willing to take the lead in driving control plane
> convergence for (R)AN within the IETF?
>
> Best Regards,
> Katsuhiro Horiba
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Is IPv6 UDP checksum deployment impact an input to 3GPP?

[Satoru Matsushima]

Dear DMMers,

During IETF117 DMM meeting, we had a report of the IPv6 UDP checksum
deployment impact in the following I-D:

https://datatracker.ietf.org/doc/draft-murakami-dmm-udp-checksum-impact-gtpu/

In the meeting room, the chairs observed that DMMers were interested in
this draft as an input to 3GPP.

Please let us know any of your feedback, comments on this draft, and to be
an input to 3GPP.

Regards,
-satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] DMM WG Adoption Poll (2) for "Mobile User Plane Evolution" - draft-zzhang-dmm-mup-evolution-06

[Satoru Matsushima]

Dear DMMers,

This email starts a two-weeks DMM WG adoption poll (2) for ""Mobile User
Plane Evolution" - draft-zzhang-dmm-mup-evolution-06.

https://datatracker.ietf.org/doc/draft-zzhang-dmm-mup-evolution/

Please review the draft and post any comments on this mail thread prior to
Friday, November 3rd, 2023.

Regards,
Sri, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] DMM WG Adoption Poll (1) for "Architecture Discussion on SRv6 Mobile User plane" - draft-kohno-dmm-srv6mob-arch-07

[Satoru Matsushima]

Dear DMMers,

This email starts a two-weeks DMM WG adoption poll (1) for "Architecture
Discussion on SRv6 Mobile User plane" - draft-kohno-dmm-srv6mob-arch-07.

https://datatracker.ietf.org/doc/draft-kohno-dmm-srv6mob-arch/

Please review the draft and post any comments on this mail thread prior to
Friday, November 3rd, 2023.

Regards,
Sri, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Adoption call for I.D.: draft-zzhang-dmm-mup-evolution-06 (Mobile User Plane Evolution)

[Satoru Matsushima]

Hi Jeffrey, thanks for the clarification.

I understand you don't need a WG adoption for you to go to 3GPP. I agree
with that.

When it comes to liaison with 3GPP, IMO the contents from IETF/DMM to other
SDO(s) should be an actual work in DMM. So I'm not clear whether we can
input 3GPP your draft as it is outside of IETF work. Of course we can input
any drafts which DMM WG can work on.

Best regards,
--satoru



On Thu, Sep 14, 2023 at 5:40 AM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi Satoru,
>
>
>
> Please see zzh> below.
>
>
>
> Juniper Business Use Only
>
> *From:* dmm  *On Behalf Of * Satoru Matsushima
> *Sent:* Tuesday, September 12, 2023 4:08 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* dmm@ietf.org
> *Subject:* Re: [DMM] Adoption call for I.D.:
> draft-zzhang-dmm-mup-evolution-06 (Mobile User Plane Evolution)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey, Tianji,
>
>
>
> Your draft says:
>
>
>
>This document is not an attempt to do 3GPP work in IETF.  Rather, it
>discusses potential integration of IETF/wireline and 3GPP/wireless
>technologies - first among parties who are familiar with both areas
>and friendly with IETF/wireline technologies.  If the ideas in this
>document are deemed reasonable, feasible and desired among these
>parties, they can then be brought to 3GPP for further discussions.
>
>
>
> What I extracted from the above text is that you won't do any
> substantial standardization work in DMM/IETF about the contents described
> in your draft, since IETF is not a  right venue for that. And you will go
> to 3GPP with your supporters.
>
>
>
> Zzh> Indeed. There is no standardization to be done in IETF. It is an
> informational document that discusses the proposal and many relevant
> aspects, which could be very valuable input to 3GPP.
>
>
>
> If it is correct, I'm not clear on what "WG adoption" means here. In case
> that this is an informational document composed by you, however no further
> substantial work could be expected, do we really need "WG adoption"? or do
> you need WG adoption to go 3GPP? If so, what is the reason behind it?
>
> Zzh> We don’t need WG adoption to go to 3GPP, but it is good to have an
> informational WG document (and eventually an informational RFC) for two
> purposes:
>
> Zzh> a) to document the (rough) consensus that this is a
> reasonable/natural user plane evolution.
>
> Zzh> b) to provide this to 3GPP as input when sought (more below).
>
> Let me share an experience between 3GPP in the past. A substantial uplane
> protocol work had been initiated in DMM, and then 3GPP (CT WG4) started a
> study for user plane protocol and a liaison between DMM was initiated by
> 3GPP. I think that way would be a case where we inform 3GPP one of our WG
> documents, but that itself would not be the goal for that work.
>
> Zzh> Similar approach will be taken. A 3GPP study will be initiated by
> 3GPP delegates who agree with this ANUP approach. They will point out the
> existence of the DMM informational document as input. Neither party needs
> to initiate an official liaison, but if 3GPP does, we can respond with this
> document. During the progress of our draft, we could also initiate a
> liaison to invite comments from 3GPP.
>
> Could you elaborate if we really need adoption, and what will you do in
> DMM after the adoption.
>
> Zzh> As explained above, we believe it is important and valuable to adopt
> this document:
>
> Zzh> a) The adoption process itself may trigger further discussions that
> will improve the proposal and the document.
>
> Zzh> b) It’s good to have an official draft to document the proposal and
> (rough) consensus among IETF/DMM, whether the proposal will be accepted in
> 3GPP or not.
>
> Zzh> c) The official document will be available as input to 3GPP if/when
> they do their study.
>
> Zzh> After adoption we’ll continue to enhance the proposal and improve the
> document (e.g. discuss and document more topics/issues that may be raised,
> like what we did all along) until it is ready to become an informational
> RFC.
>
> Zzh> Thanks!
>
> Zzh> Jeffrey
>
> --satoru
>
>
>
>
>
> On Sat, Sep 2, 2023 at 5:35 AM Jeffrey (Zhaohui) Zhang  40juniper@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> Thanks, Tianji for presenting in IETF117 and requesting adoption in the
> presentation and here.
>
>
>
> As a co-author, I obviously agree with what Tianji said here and want to
> see it adopted. I am sure other co-authors share the same view even though
> they did not explicitly echo “agree/support as co-

Re: [DMM] Adoption call for I.D.: draft-zzhang-dmm-mup-evolution-06 (Mobile User Plane Evolution)

[Satoru Matsushima]

Hi Jeffrey, Tianji,

Your draft says:

   This document is not an attempt to do 3GPP work in IETF.  Rather, it
>discusses potential integration of IETF/wireline and 3GPP/wireless
>technologies - first among parties who are familiar with both areas
>and friendly with IETF/wireline technologies.  If the ideas in this
>document are deemed reasonable, feasible and desired among these
>parties, they can then be brought to 3GPP for further discussions.


What I extracted from the above text is that you won't do any
substantial standardization work in DMM/IETF about the contents described
in your draft, since IETF is not a  right venue for that. And you will go
to 3GPP with your supporters.

If it is correct, I'm not clear on what "WG adoption" means here. In case
that this is an informational document composed by you, however no further
substantial work could be expected, do we really need "WG adoption"? or do
you need WG adoption to go 3GPP? If so, what is the reason behind it?

Let me share an experience between 3GPP in the past. A substantial uplane
protocol work had been initiated in DMM, and then 3GPP (CT WG4) started a
study for user plane protocol and a liaison between DMM was initiated by
3GPP. I think that way would be a case where we inform 3GPP one of our WG
documents, but that itself would not be the goal for that work.

Could you elaborate if we really need adoption, and what will you do in DMM
after the adoption.
--satoru


On Sat, Sep 2, 2023 at 5:35 AM Jeffrey (Zhaohui) Zhang  wrote:

> Hi,
>
>
>
> Thanks, Tianji for presenting in IETF117 and requesting adoption in the
> presentation and here.
>
>
>
> As a co-author, I obviously agree with what Tianji said here and want to
> see it adopted. I am sure other co-authors share the same view even though
> they did not explicitly echo “agree/support as co-author” 
>
>
>
> We appreciate that DMM provided a venue for us to discuss/present the
> topic/updates and gather input and supporters. We believe all the issues
> that were brought up have been sufficiently discussed and addressed in the
> draft, and we have not seen objections to the proposal, so it is
> appropriate to adopt this informational draft as a WG document. The
> adoption process, and work on the document by the WG after adoption will
> improve it further.
>
>
>
> Hopefully, people are coming back from their vacations and will speak up
> their thoughts.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* dmm  *On Behalf Of *Tianji Jiang
> *Sent:* Monday, August 14, 2023 6:16 PM
> *To:* dmm@ietf.org
> *Subject:* [DMM] Adoption call for I.D.:
> draft-zzhang-dmm-mup-evolution-06 (Mobile User Plane Evolution)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear DMM Team:
>
>
>
> During the IETF-117, we have presented and discussed our IETF draft:
> ‘Mobile User Plane Evolution’ (draft-zzhang-dmm-mup-evolution:
> https://datatracker.ietf.org/doc/draft-zzhang-dmm-mup-evolution/
> 
> ). In the presentation, we explained the fundamental ideas of the I.D.,
> along with our objectives. As we have stated, this was the 6th iteration
> of the I.D. Including this time (of IETF-117), different versions of the
> drafts have been presented & discussed thru the IETF-114, -115, -116 &
> -117.
>
>
>
> At the moment, we believe we have covered sufficiently various aspects of
> the MUP-evolution, i.e., the potential integration of gNB & UPF with
> targeting at B5G & 6G. These are comprised of both IP-domain requirements &
> wireless technologies. Further, as of now,
>
>- The 3GPP 4G LIPA work, i.e., the Local IP Access, bodes well for our
>(B5G, 6G) ‘ANUP-like’ proposal.
>- The 3GPP Rel-19 planning (5G) is on-going and some potential work
>(of the I.D.) could be possibly brought it to 3GPP for further study
>(Rel-19); and
>- The 3GPP Rel-20 (6G roadmap) targets toward the beginning of Y-2025,
>which is a perfect timing for exploration and adoption of the ANUP-like
>work.
>
>
>
> Given all the work that have been done so far, we have, during the
> IETF-117 DMM session, initiated a possible adoption-call of the I.D., in
> the ‘informational’ track. We have emphasized our I.D. just serves as input
> to 3GPP and we don’t intend to do 3GPP work in the IETF community. For a
> procedural question from an on-site attendee of the DMM session, the
> 3GPP-to-IETF liaison manager has shared his opinion and said there is no
> problem to bring the ‘normal document’ to 3GPP for discussion/reference.
>
>
>
> At the end of the session, the DMM chair suggested we bring this draft to
> the email alias. So, we are here to officially initiate the adoption-call
> of our I.D.
>
> Team, please share your opinions, comments, questions, etc. Thank you.

[DMM] DMM WG agenda for IETF117

[Satoru Matsushima]

Dear DMMers,

We will have a DMM meeting at IETF117. If you have any topic to the meeting
please let us know your presentation title, presenter, and time for your
topic.

Cheers,
Sri, Dapeng, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM Agenda for IETF115

[Satoru Matsushima]

Hi Jeffrey, sure.
--satoru

On Mon, Nov 7, 2022 at 9:21 AM Jeffrey (Zhaohui) Zhang 
wrote:

> Hi,
>
>
>
> I would also want to present a topic that was prepared for IETF114 but was
> not presented due to a glitch in uploading the slides: IP VPN with IP/UDP
> payload transportation.
>
> Please see two slide decks for the two topics.
>
>
>
> I’d like to get 10-15 minutes for each presentation.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Jeffrey (Zhaohui) Zhang
> *Sent:* Wednesday, October 26, 2022 10:19 PM
> *To:* Satoru Matsushima ; dmm 
> *Subject:* RE: [DMM] DMM Agenda for IETF115
>
>
>
> Hi,
>
>
>
> I’d like to request a 10-15 minute slot to have some follow-up discussions
> on draft-zzhang-dmm-mup-evolution-02.
>
>
>
> Thanks.
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* dmm  *On Behalf Of *Satoru Matsushima
> *Sent:* Tuesday, October 25, 2022 8:03 PM
> *To:* dmm 
> *Subject:* [DMM] DMM Agenda for IETF115
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear DMMers,
>
>
>
> We will have a DMM meeting in IETF115. If you have any topics to the
> meeting please let us know the title, presenter name and slot time for
> your presentation.
>
>
>
> Cheers,
>
> Sri, Dapeng, Satoru
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] DMM Agenda for IETF115

[Satoru Matsushima]

Dear DMMers,

We will have a DMM meeting in IETF115. If you have any topics to the
meeting please let us know the title, presenter name and slot time for
your presentation.

Cheers,
Sri, Dapeng, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] DMM Agenda for IETF113

[Satoru Matsushima]

Dear DMMers,

We will have a DMM meeting in IETF113. If you have any topic to the meeting 
please let us know title, presenter, and time for your topic.

Cheers,
Sri, Dapeng, Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] I-D Action: draft-mhkk-dmm-srv6mup-architecture-00.txt

[Satoru Matsushima]

Thank you Hannu.

The routing instances are running on SR nodes, as MUP GW may be an SR node, as 
well as MUP PE, which can be supposed to participating intra-domain routing 
using BGP.
# if  s/BPG/BGP/; s/MPU/MUP/; can be applied to your mail.

Cheers,
--satoru

> 2021/11/02 23:54、Flinck, Hannu (Nokia - FI/Espoo) 
> のメール:
> 
> Hello Satoru
>  
> Thank you for the draft. I get confused with the various routing instances 
> and in which node they are running. I guess the missing chapter 7 would have 
> clarified this.
> But between which nodes in your example you run BPG? Is the figure 1 correct 
> by indicating that that gNBs are in MPU segment?   Which entry runs NG-AP in 
> this set up?
>  
> Best regards
> Hannu
>  
> From: dmm mailto:dmm-boun...@ietf.org>> On Behalf Of 
> Satoru Matsushima
> Sent: Tuesday, October 26, 2021 4:42 AM
> To: dmm mailto:dmm@ietf.org>>
> Cc: draft-mhkk-dmm-srv6mup-architecture@ietf.org 
> <mailto:draft-mhkk-dmm-srv6mup-architecture@ietf.org>
> Subject: [DMM] Fwd: I-D Action: draft-mhkk-dmm-srv6mup-architecture-00.txt
>  
> Hi DMMers,
>  
> We have submitted a new draft of an SRv6 mobile user plane architecture for 
> DMM. Please take a look at it. Any feedbacks from the WG are really 
> appreciate.
>  
> Cheers, 
> --satoru
> 
> Begin forwarded message:
> 
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> Date: October 26, 2021 2:38:43 JST
> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> Subject: I-D Action: draft-mhkk-dmm-srv6mup-architecture-00.txt
> Reply-To: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : Segment Routing IPv6 Mobile User Plane Architecture 
> for Distributed Mobility Management
>Authors : Satoru Matsushima
>  Katsuhiro Horiba
>  Ashiq Khan
>  Yuya Kawakami
>  Tetsuya Murakami
>  Keyur Patel
>  Miya Kohno
>  Teppei Kamata
>  Pablo Camarillo
>Filename: draft-mhkk-dmm-srv6mup-architecture-00.txt
>Pages   : 11
>Date: 2021-10-25
> 
> Abstract:
>   This document defines the Segment Routing IPv6 Mobile User Plane
>   (SRv6 MUP) architecture for Distributed Mobility Management.  The
>   requirements for Distributed Mobility Management described in
>   [RFC7333] can be satisfied by routing fashion.
> 
>   Mobile services are deployed over several parts of IP networks.  A
>   Segment Routing over IPv6 (SRv6) network can accommodate all, or part
>   of those networks thanks to the large address space of IPv6 and the
>   network programming capability described in [RFC8986].
> 
>   Segment Routing IPv6 Mobile User Plane Architecture can incorporate
>   existing session based mobile networks.  By leveraging SRv6 network
>   programmability, mobile user plane can be integrated into the SRv6
>   data plane.  In that routing paradigm, session information between
>   the entities of the mobile user plane is turned to routing
>   information.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mhkk-dmm-srv6mup-architecture/ 
> <https://datatracker.ietf.org/doc/draft-mhkk-dmm-srv6mup-architecture/>
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-srv6mup-architecture-00 
> <https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-srv6mup-architecture-00>
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> https://www.ietf.org/mailman/listinfo/i-d-announce 
> <https://www.ietf.org/mailman/listinfo/i-d-announce>
> Internet-Draft directories: http://www.ietf.org/shadow.html 
> <http://www.ietf.org/shadow.html>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Fwd: I-D Action: draft-mhkk-dmm-srv6mup-architecture-00.txt

[Satoru Matsushima]

Hi DMMers,

We have submitted a new draft of an SRv6 mobile user plane architecture for 
DMM. Please take a look at it. Any feedbacks from the WG are really appreciate.

Cheers, 
--satoru

Begin forwarded message:

> From: internet-dra...@ietf.org
> Date: October 26, 2021 2:38:43 JST
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-mhkk-dmm-srv6mup-architecture-00.txt
> Reply-To: internet-dra...@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : Segment Routing IPv6 Mobile User Plane Architecture 
> for Distributed Mobility Management
>    Authors : Satoru Matsushima
>  Katsuhiro Horiba
>  Ashiq Khan
>  Yuya Kawakami
>  Tetsuya Murakami
>  Keyur Patel
>  Miya Kohno
>  Teppei Kamata
>  Pablo Camarillo
>Filename: draft-mhkk-dmm-srv6mup-architecture-00.txt
>Pages   : 11
>Date: 2021-10-25
> 
> Abstract:
>   This document defines the Segment Routing IPv6 Mobile User Plane
>   (SRv6 MUP) architecture for Distributed Mobility Management.  The
>   requirements for Distributed Mobility Management described in
>   [RFC7333] can be satisfied by routing fashion.
> 
>   Mobile services are deployed over several parts of IP networks.  A
>   Segment Routing over IPv6 (SRv6) network can accommodate all, or part
>   of those networks thanks to the large address space of IPv6 and the
>   network programming capability described in [RFC8986].
> 
>   Segment Routing IPv6 Mobile User Plane Architecture can incorporate
>   existing session based mobile networks.  By leveraging SRv6 network
>   programmability, mobile user plane can be integrated into the SRv6
>   data plane.  In that routing paradigm, session information between
>   the entities of the mobile user plane is turned to routing
>   information.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mhkk-dmm-srv6mup-architecture/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-srv6mup-architecture-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Our next DMM meeting

[Satoru Matsushima]

Dear DMMers,

As the circumstance is changing and our discussion progress, the DMM WG chairs 
have decided that our next meeting will be IETF112 in Madrid. On-site meeting 
would help us to host more intensive discussions rather than on-line in limited 
slot and time.

We really look forward that we can meet in Madrid safely in person.

Cheers,
--
Sri & Dapeng & Satoru

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Call for Agenda: IETF110 DMM

[Satoru Matsushima]

Folks,

DMM meeting in IETF110 online will be held at March 8th 1600-1800 UTC.
If you have any topic for the IETF110 DMM meeting, please send the chairs your 
topic with the title and the presenter.

Cheers,
--satoru

> On Jan 22, 2021, at 11:07, IETF Meeting Session Request Tool 
>  wrote:
> 
> 
> 
> A new meeting session request has just been submitted by Sri Gundavelli, a 
> Chair of the dmm working group.
> 
> 
> -
> Working Group Name: Distributed Mobility Management
> Area Name: Internet Area
> Session Requester: Sri Gundavelli
> 
> 
> Number of Sessions: 1
> Length of Session(s):  2 Hours
> Number of Attendees: 25
> Conflicts to Avoid: 
> 
> 
> 
> 
> 
> 
> 
> 
> People who must be present:
> Sri Gundavelli
> Erik Kline
> Dapeng Liu
> Satoru Matsushima
> 
> Resources Requested:
> 
> Special Requests:
> Preferred days: Monday or Tuesday
> -

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] First online DMM meeting

[Satoru Matsushima]

Folks,

Thank you for joining the first online meeting of DMM working group. I believe 
that we had acquired some meetecho operation skills which can help us next our 
meetings. But sorry for that we missed some discussions through the meeting so 
please post your follow up comments on the topic we had today in agenda if you 
need.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] dmm - Requested session has been scheduled for IETF 109

[Satoru Matsushima]

Uploaded revision of the agenda, just to fix the mime type.

https://datatracker.ietf.org/meeting/109/materials/agenda-109-dmm-02

cheers,
--satoru

> 2020/11/14 0:00、Sri Gundavelli (sgundave) 
> のメール:
> 
> Please review the agenda for IETF 109.
>  
> https://datatracker.ietf.org/meeting/109/materials/agenda-109-dmm-00.txt 
> 
>  
> Satoru & Sri
>  
>  
> ___
> dmm mailing list
> dmm@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmm 
> 
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FW: dmm - Requested session has been scheduled for IETF 109

[Satoru Matsushima]

Thanks Uma, 

All, please let us know the title, presenter and time you need for your slot 
We’ll upload the agenda soon.

Cheers,
--satoru

> On Oct 31, 2020, at 4:53, Uma Chunduri  wrote:
> 
> 
> Dear Sri,
> 
> We would like to ask a 10 mins slot to update the WG for the to be published 
> draft-clt-dmm-tn-aware-mobility (08 version - would be done on 11/02). The 
> changes are mostly  to address the  recent comments received in the list.
> 
> --
> Uma C.
> 
>> On Mon, Oct 26, 2020 at 3:49 PM Sri Gundavelli (sgundave) 
>>  wrote:
>> Folks - We have the meeting scheduled for Nov 17th. Please send any topics 
>> that you want to present.
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> On 10/23/20, 2:16 PM, ""IETF Secretariat""  wrote:
>> 
>> Dear Sri Gundavelli,
>> 
>> The session(s) that you have requested have been scheduled.
>> Below is the scheduled session information followed by
>> the original request. 
>> 
>> 
>> dmm Session 1 (1:00 requested)
>> Tuesday, 17 November 2020, Session II 1430-1530
>> Room Name: Room 3 size: 503
>> -
>> 
>> 
>> iCalendar: https://datatracker.ietf.org/meeting/109/sessions/dmm.ics
>> 
>> Request Information:
>> 
>> 
>> -
>> Working Group Name: Distributed Mobility Management
>> Area Name: Internet Area
>> Session Requester: Sri Gundavelli
>> 
>> 
>> Number of Sessions: 1
>> Length of Session(s):  1 Hour
>> Number of Attendees: 35
>> Conflicts to Avoid: 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> People who must be present:
>>   Sri Gundavelli
>>   Erik Kline
>>   Dapeng Liu
>>   Satoru Matsushima
>> 
>> Resources Requested:
>> 
>> Special Requests:
>> 
>> -
>> 
>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Review of draft-ietf-dmm-srv6-mobile-uplane-07

[Satoru Matsushima]

Hi Carlos,

Thanks for your review.
The authors will address your comments and get back to you when the decription 
is failed. :-)
Before that the draft needs to be back from expire state. So authors, please 
submit a revision with minimum update.

Cheers,
--satoru

> 2020/06/23 2:15、CARLOS JESUS BERNARDOS CANO のメール:
> 
> Hi Pablo, all,
> 
> Please find attached my review of the draft. I think it specifies very useful 
> stuff. Some points about the way it's presented can be improved, IMHO.
> 
> I hope you don't mind that I made my comments handwritten (which you might 
> also think are encrypted ;) ) on the PDF version of the draft.
> 
> If you have any questions about my comments, do not hesitate contacting me.
> 
> Thanks!
> 
> Carlos
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF106 - Call for Agenda Items

[Satoru Matsushima]

One correction for a typo:

> Reminder:
> The draft cut-off date: 4th November UTC 23:59 (2 weeks before the meeting).


Regards,
--satoru


> 2019/10/22 12:07、Satoru Matsushima のメール:
> 
> Folks,
> 
> The DMM chairs are planning the dmm meeting in Singapore at IETF106:
> 
> 18th November, Monday Afternoon Session II (15:50-17:50)
> 
> If you have a draft or any topics you would like to discuss, please send your 
> request for agenda time to the dmm chairs. Please include the information in 
> the request as following:
> 
> The title of the presentation:
> Presenter name:
> Time you need:
> Draft reference: 
> 
> Please have agenda items to us by 2019-11-04 (November 4th).
> 
> Reminder:
> The draft cut-off date: 14th November UTC 23:59 (2 weeks before the meeting).
> 
> Dapeng & Sri & Satoru

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] IETF106 - Call for Agenda Items

[Satoru Matsushima]

Folks,

The DMM chairs are planning the dmm meeting in Singapore at IETF106:

18th November, Monday Afternoon Session II (15:50-17:50)

If you have a draft or any topics you would like to discuss, please send your 
request for agenda time to the dmm chairs. Please include the information in 
the request as following:

The title of the presentation:
Presenter name:
Time you need:
Draft reference: 

Please have agenda items to us by 2019-11-04 (November 4th).

Reminder:
The draft cut-off date: 14th November UTC 23:59 (2 weeks before the meeting)..

Dapeng & Sri & Satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] New chair addition for dmm

[Satoru Matsushima]

Thanks Suresh-san, Sri-san,Look forward to helping DMM progress.

Cheers,
--satoru

2019/07/24 9:34、Sri Gundavelli (sgundave) のメール:

> Welcome Satoru-san. This is great news. Looking forward to working with you.
> 
> Sri
> 
> 
> Sent from my iPhone
> 
>> On Jul 24, 2019, at 9:31 AM, Suresh Krishnan  wrote:
>> 
>> Hi all,
>>  I would like to announce the appointment of Satoru Matsushima as a new 
>> co-chair for the dmm working group. Sri and Dapeng will continue as 
>> co-chairs.
>> Satoru-san has been an active participant in the group and will be able to 
>> provide much appreciated operator input and additional cycles to achieve the 
>> group’s milestones. Please welcome Satoru-san as chair.
>> 
>> Thanks
>> Suresh
>> 
>> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF105 - Call for agenda items

[Satoru Matsushima]

Dear DMM chair,

I’d request a slot for SRv6 user plane update:

Topic Name: SRv6 Mobile User Plane
Presenter: Satoru Matsushima
Time: 20min
Draft Reference: draft-ietf-dmm-srv6-mobile-uplane-05

Best regards,
--satoru

2019/07/08 22:41、Sri Gundavelli (sgundave) のメール:

> Gentle reminder. Please send your requests by 11th of July.
> 
> 
> Sri
> 
> 
> On 6/30/19, 10:02 AM, "dmm on behalf of Sri Gundavelli (sgundave)"
>  wrote:
> 
>> Folks:
>> 
>> We are planning to have a f2f DMM WG meeting at IETF-105. It is currently
>> scheduled for Wednesday, 24 July 2019, Morning Session I 1000-1200.
>> If you have any topics to present, please send your request to the chairs
>> (as a response to this email) with the following information.
>> 
>> 
>>>> Topic Name:
>>>> Presenter Name:
>>>> Time:
>>>> Draft Reference (if any):
>> 
>> 
>> - Dapeng & Sri
>>> 
>>> 
>>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] 6.6. T.M.GTP4.D description (Re: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-05.txt

[Satoru Matsushima]

Thanks Kentaro for you prompt review prior to my announce. :-)

> Thank you for updating the draft. Nice to see T.M.Tmap was renamed to 
> T.M.GTP4.D corresponding to End.M.GTP4.E. :)

It helps to improve consistency of the draft, thanks.

> Some feedback about the updated description.
> 
> > 6.6. T.M.GTP4.D
> > ...
> > The prefix of B’ SHOULD be an End.M.GTP4.E SID with its format
> > instantiated at an SR gateway with the IPv4 SA of the receiving
> > packet.
> 
> "The B’" is IPv6 SA so I think this should correspond to S' in End..M.GTP4.E 
> rather than to SID.

Actually no, because it is assumed that the prefix of B’ could be a SID for 
End.GTP4.E instantiated in SRGW. But you’re correct the B’ doesn’t need to be 
filled with arg.mob.session.

Cheers,
--satoru

> So it might be more clear to depict the packet format (diagram) again and 
> mention B' has the following format with the IPv4 SA of the receiving packet.
> 
> 0 127
> +--++--+
> | Source UPF Prefix|IPv4 SA | any bit pattern(ignored) |
> +--++--+
>128-a-b a b
> 
> -- 
> Kentaro Ebisawa 
> 
> -- Original Message --
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Cc: dmm@ietf.org
> Sent: 2019/07/08 21:16:07
> Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-05.txt
> 
>>  
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Distributed Mobility Management WG of the 
>> IETF.
>>  
>>Title   : Segment Routing IPv6 for Mobile User Plane
>>Authors : Satoru Matsushima
>>  Clarence Filsfils
>>  Miya Kohno
>>  Pablo Camarillo
>>  Daniel Voyer
>>  Charles E. Perkins
>> Filename: draft-ietf-dmm-srv6-mobile-uplane-05.txt
>> Pages   : 28
>> Date: 2019-07-08
>>  
>> Abstract:
>>   This document shows the applicability of SRv6 (Segment Routing IPv6)
>>   to the user-plane of mobile networks.  The network programming nature
>>   of SRv6 accomplish mobile user-plane functions in a simple manner.
>>   The statelessness of SRv6 and its ability to control both service
>>   layer path and underlying transport can be beneficial to the mobile
>>   user-plane, providing flexibility, end-to-end network slicing and SLA
>>   control for various applications.  This document describes the SRv6
>>   mobile user plane behavior and defines the SID functions for that.
>>  
>>  
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
>>  
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-05
>> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-05
>>  
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-05
>>  
>>  
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>  
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>  
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt

[Satoru Matsushima]

Hi,

We’ve updated the srv6 mobile u-plane draft. Thank you for your review comments 
and feedback on the draft.
Many of them have still not been covered but the authors are still going to 
work on it for the next meeting.

We’ll get back to you and hope to discuss for further updates during IETF104.

Best regards,
--satoru



> 2019/03/12 5:12、internet-dra...@ietf.orgのメール:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the 
> IETF.
> 
>Title   : Segment Routing IPv6 for Mobile User Plane
>    Authors : Satoru Matsushima
>  Clarence Filsfils
>  Miya Kohno
>  Pablo Camarillo Garvia
>  Daniel Voyer
>  Charles E. Perkins
>   Filename: draft-ietf-dmm-srv6-mobile-uplane-04.txt
>   Pages   : 28
>   Date: 2019-03-11
> 
> Abstract:
>   This document shows the applicability of SRv6 (Segment Routing IPv6)
>   to the user-plane of mobile networks.  The network programming nature
>   of SRv6 accomplish mobile user-plane functions in a simple manner.
>   The statelessness of SRv6 and its ability to control both service
>   layer path and underlying transport can be beneficial to the mobile
>   user-plane, providing flexibility and SLA control for various
>   applications.  This document describes the SRv6 mobile user plane
>   behavior and defines the SID functions for that.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

[Satoru Matsushima]

More precisely on the latter point,

> 
>> Particularly the discussion around slicing is very speculative. And 
>> conclusion thereof that “The expected evaluation points from this aspect 
>> should be whether the candidate protocols can support to indicate a network 
>> slice in the UP packets.” Firstly, IETF doesn’t have any work on slicing, on 
>> the contrary. Secondly, the need for such indication in the 3GPP has been 
>> discussed in the ongoing 3GPP CT4 meeting this week with fully opposing 
>> views for such network slice indication. (Network slicing is supported in 
>> 3GPP Rel-15 already, and nothing new was defined in the user plane in 
>> Rel-15. There was no need for that!)
> 
> It looks not accurate view of the latest discussion in 3GPP CT4. CT4 agreed 
> not to introduce any NEW identifiers to indicate network slice for 5GC and 
> its transport. Existing identifiers can be expected for that purpose in user 
> plane.

3GPP CT4 sees Network Slice consists of 5GC slice and transport slice while 
what's the transport slice is out of scope. As the 5GC control plane has 
maintained the context of 5GC slice, no identifier is needed in user plane to 
indicate *5GC slice*. Existing identifiers like VIDs, MPLS labels and IP 
addresses can be expected to indicate transport slices if it exists.

Cheers,
--satoru



> 
> 
> Hope it helps our understanding correct.
> 
> Best regards,
> --satoru
> 
> 
> 
> 
>> 2018/12/14 15:14、Sri Gundavelli (sgundave) のメール:
>> 
>> Folks – Sorry for the delay on this. Given the number of support votes for 
>> the company I am affiliated with, I thought it would be best for my co-chair 
>> Dapeng reviews this feedback, and in consultation with the AD, makes the 
>> decision on this. We will close it soon. 
>> 
>> Sri
>> 
>> 
>> 
>> From: Sri Gundavelli 
>> Date: Wednesday, December 5, 2018 at 9:18 AM
>> To: "dmm@ietf.org" 
>> Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 
>> as DMM WG document
>> 
>> Thanks for all the feedback. The adoption call is now closed. We will review 
>> the feedback and decide on the next steps.
>> 
>> Sri
>> 
>> 
>> 
>> From: dmm  on behalf of Sri Gundavelli 
>> 
>> Date: Wednesday, November 28, 2018 at 10:42 AM
>> To: "dmm@ietf.org" 
>> Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 
>> as DMM WG document
>> 
>> Gentle reminder.  The below adoption call will close next week, the 4th of 
>> December, 2018. Please provide your feedback. 
>> 
>> 
>> Sri
>> 
>> 
>> 
>> From: dmm  on behalf of Sri Gundavelli 
>> 
>> Date: Tuesday, November 13, 2018 at 4:34 PM
>> To: "dmm@ietf.org" 
>> Subject: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as 
>> DMM WG document
>> 
>> Folks:
>> 
>> During IETF 102 and 103, the authors of the document, 
>> draft-hmm-dmm-5g-uplane-analysis.txt have provided the overview of this 
>> document. The chairs felt there is good amount of work that went into the 
>> document and the analysis has value. The document quality is very high. 
>> There was also generally good feedback and interest for the work from the 
>> community. We are therefore considering adopting this document as a DMM WG 
>> document, to be moved on Informational Standards track.  
>> 
>> There were also few concerns/comments on the 1.) Relevance of this document 
>> to 3GPP in the immediate time frame 2.) Archival Value of the document 3.) 
>> Target Audience  - IETF or 3GPP. 
>> On #3, there was also a view that the document should be restructured to 
>> make it IETF focussed.  With this background, we would like to ask the WG to 
>> provide some feedback on their interest for this work. Please provide 
>> substantial comments as why this should be adopted, or why it should not be 
>> adopted. If there is interest, and if there are no other concerns from 
>> AD/IESG/Others, then we may take up this work at some point. 
>> 
>> Draft Pointer: 
>> https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-02
>> 
>> 
>> The adoption call will end on 4th of December, 2019.
>> 
>> 
>> Regards
>> Dapping & Sri
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document

[Satoru Matsushima]

Thank you Sri, and all,

During that, let me make clear some questions and comments. First one:

> So the purpose of this draft seems to explicitly be to do work for 3GPP that 
> they have explicitly said they DO NOT WANT.

It’s wrong. In the LS of CP-173160 requested any information regarding user 
plane. So please re-read the following:

> 2. Actions:
> To IETF DMM:
> ACTION: CT4 respectfully asks IETF DMM to provide any information 
> that may be relevant to the above CT4 work by July 2018.
> 

And the LS of C4-185491 didn’t say they don’t want. It just said that the 
evaluation criteria for the user plane protocol study (FS_UPPS) in 5GC shall be 
defined by 3GPP CT4. It should be very natural and responsible.

Second one is that:

> Particularly the discussion around slicing is very speculative. And 
> conclusion thereof that “The expected evaluation points from this aspect 
> should be whether the candidate protocols can support to indicate a network 
> slice in the UP packets.” Firstly, IETF doesn’t have any work on slicing, on 
> the contrary. Secondly, the need for such indication in the 3GPP has been 
> discussed in the ongoing 3GPP CT4 meeting this week with fully opposing views 
> for such network slice indication. (Network slicing is supported in 3GPP 
> Rel-15 already, and nothing new was defined in the user plane in Rel-15. 
> There was no need for that!)

It looks not accurate view of the latest discussion in 3GPP CT4. CT4 agreed not 
to introduce any NEW identifiers to indicate network slice for 5GC and its 
transport. Existing identifiers can be expected for that purpose in user plane.


Hope it helps our understanding correct.

Best regards,
--satoru




> 2018/12/14 15:14、Sri Gundavelli (sgundave) のメール:
> 
> Folks – Sorry for the delay on this. Given the number of support votes for 
> the company I am affiliated with, I thought it would be best for my co-chair 
> Dapeng reviews this feedback, and in consultation with the AD, makes the 
> decision on this. We will close it soon. 
> 
> Sri
> 
> 
> 
> From: Sri Gundavelli 
> Date: Wednesday, December 5, 2018 at 9:18 AM
> To: "dmm@ietf.org" 
> Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 
> as DMM WG document
> 
> Thanks for all the feedback. The adoption call is now closed. We will review 
> the feedback and decide on the next steps.
> 
> Sri
> 
> 
> 
> From: dmm  on behalf of Sri Gundavelli 
> 
> Date: Wednesday, November 28, 2018 at 10:42 AM
> To: "dmm@ietf.org" 
> Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 
> as DMM WG document
> 
> Gentle reminder.  The below adoption call will close next week, the 4th of 
> December, 2018. Please provide your feedback. 
> 
> 
> Sri
> 
> 
> 
> From: dmm  on behalf of Sri Gundavelli 
> 
> Date: Tuesday, November 13, 2018 at 4:34 PM
> To: "dmm@ietf.org" 
> Subject: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as 
> DMM WG document
> 
> Folks:
> 
> During IETF 102 and 103, the authors of the document, 
> draft-hmm-dmm-5g-uplane-analysis.txt have provided the overview of this 
> document. The chairs felt there is good amount of work that went into the 
> document and the analysis has value. The document quality is very high. There 
> was also generally good feedback and interest for the work from the 
> community. We are therefore considering adopting this document as a DMM WG 
> document, to be moved on Informational Standards track.  
> 
> There were also few concerns/comments on the 1.) Relevance of this document 
> to 3GPP in the immediate time frame 2.) Archival Value of the document 3.) 
> Target Audience  - IETF or 3GPP. 
> On #3, there was also a view that the document should be restructured to make 
> it IETF focussed.  With this background, we would like to ask the WG to 
> provide some feedback on their interest for this work. Please provide 
> substantial comments as why this should be adopted, or why it should not be 
> adopted. If there is interest, and if there are no other concerns from 
> AD/IESG/Others, then we may take up this work at some point. 
> 
> Draft Pointer: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-02
> 
> 
> The adoption call will end on 4th of December, 2019.
> 
> 
> Regards
> Dapping & Sri
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

[Satoru Matsushima]

Thanks Sridhar for your followups.


> Just pointing people to drafts doesn’t help in understanding. It requires 
> people to go off, put in a lot of time where the odds are their question will 
> not be answered.
> 
> [SB] TS 29.244 is not a draft but rather a full fledged technical 
> specification. The issue with repeating content from elsewhere instead of 
> just pointing is the risk of providing inaccurate information in IETF draft.

I don’t believe that 3GPP forbid anyone to publish any books, papers to 
describe what the 3GPP system and the protocols and how it works.

And it was one of our reasons to introduce the user plane analysis draft that 
introduces 3GPP specifications in familiar way for IETF people which could help 
to bridge two SDOs. 


Best regards,
--satoru


> 2018/09/06 19:24、Sridhar Bhaskaran のメール:
> 
> My comments inline marked [SB]
> 
> > >>> It was never clear to me and no one could ever explain exactly why a 
> > >>> TEID is needed. I presumed for accounting reasons. But if there was a 
> > >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
> > >>> addresses be used for accounting?
> > 
> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel 
> > and hence consequently a bearer. Once the bearer context is identified the 
> > QoS and charging policy applicable to the bearer is applied. So the purpose 
> > of TEID is not just for accounting. Its for QoS treatment, charging and 
> > bearer context identification.
> 
> You told me what a TEID is but you didn’t say why you need to use it versus 
> using the destination IP address for the tunnel.
>   
> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU 
> > session whereas the QFI carried in GTPU extension header identifies the 
> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> 
> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which 
> tells us (1) the UE, (2) the destination it is talking to, (3) the 
> encapsualting node, and (4) the decapsulating node.
> 
> So again, why use more space in the packet, when you have sufficient 
> information to identify a user, and therefore their packet policy?
> 
> [SB] Lets say we only use UE IP address and no TEID. How will you identify 
> the bearer context the packet belongs? One UE may use multiple radio bearers 
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are 
> IP level markings which could be changed by any on path routers. In order to 
> uniquely identify the bearer / qos flow a particular packet for a UE belongs, 
> GTPU uses TEID. 
> 
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are 
> not always unique. The same IP pools can be shared across multiple PDNs / DNs 
> as long as these PDNs / DNs are separate autonomous networks. So just relying 
> on UE IP address alone will result in wrong context identification for the 
> uplink traffic. There is a clear one to one mapping of Radio bearer to the 
> EPS bearer / QoS flow required all the way upto the anchor node for charging 
> and QoS treatment. This comes from the requirements in stage 2 documents (c.f 
> section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for 5G). 
> 
> There are also requirements to support non-IP protocols like Ethernet PDU and 
> Unstructured PDU types in 5G.
> 
> >> 
> > >>> How can packets be sent if the session is not setup. If the session is 
> > >>> not setup, the encapsulator should have no state. And packets should be 
> > >>> dropped locally and not go far to get an error back. This sounds 
> > >>> architecturally broken.
> > 
> > [Sridhar] The purpose of GTP-U error indication is to signal in band to the 
> > sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost 
> > for any reason. "No session exist" does not mean Session 
> 
> What does lost mean? You mean the path from encapsulator to decapsulator is 
> not working? And since we are in a packet network, that path can be restored 
> quite quickly.
> 
> [SB] Lost here means - the "context" at the receiving entity is deleted. For 
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and 
> correspondingly the GTPU context. If gNB or eNB loses a context for known 
> reasons, there could be signaling from gNB / eNB to AMF/MME and corresponding 
> removal of PDU session / EPS bearer at the core network. But if the context 
> is removed due to administrative reasons or unforeseen local errors, 
> signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU error 
> indication is an inband error detection mechanism.
> 
> Note TEID identifies a context at the receiving side. So all GTPU error 
> indication tells is that the receiver is not able to identify any context for 
> the received TEID.
> 
> 
> > is not setup. "No session exist" scenario after a session setup can happen 
> > due to local error conditions, bearers released for administrative 

Re: [DMM] Comments on SRv6-mobile-userplane-02

[Satoru Matsushima]

Thank you Hannu for your comments.

I found the word ‘anchor’ 18 times in the draft, and I agree with you that 
those need to be clarified. 

Best regards,
--satoru

> 2018/09/05 20:53、Flinck, Hannu (Nokia - FI/Espoo) 
> のメール:
> 
> Hello 
>  
> The draft SRv6-mobile-userplane seems to use the term “anchor”  or 
> “anchoring” quite a lot, but what exactly is meant is much unclear. It looks 
> to me that the meaning changes during the progression of the text, or depends 
> on the context. As it appears to be such key term of the draft I would 
> recommend that you define it somewhere in this document.
>  
> In details:
>  
> On page 7 you talk about “anchoring SID” and “next anchoring point”. In the 
> traditional mobility settings there is one anchoring point. So, I do not know 
> what is “next anchoring point”.. 
>  
> Then on page 17 you mention “anchoring functionality”. What is this 
> functionality exactly? Has it something to do with mobility anchors as in 
> “Distributed Mobility Anchoring” and/or “Proxy Mobile IPv6 extensions for 
> Distributed Mobility Management” drafts that also talk about mobility anchors?
>  
> Finally, the last sentence of the draft “ It's notable that SRv6's network 
> programming nature allows a flexible
> and dynamic anchor placement.”  Given all the options of the anchoring in 
> this draft, I do not know that this means? Flexible mobility anchor 
> placement? Next anchor  placement? Anchoring SID placement maybe?
>  
> What do you mean by saying “All control-plane protocols are expected to 
> leverage these function type-codes to signal each function” ?  Does it mean 
> that all control planes need to be implemented to use these function types? 
> Or carry them or what exactly?
>  
> Best regards
> Hannu
>  
>  
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF102 - Call for agenda items

[Satoru Matsushima]

Dear DMM WG chairs,

I’d request a 15min slot for draft-ietf-dmm-srv6-mobile-uplane by one of the 
authors.

Topic Name: SRv6 Mobile User Plane 
Presenter Name: TBD
Time: 15min
Draft Reference: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane


Best regards,
--satoru

> 2018/06/07 0:03、Sri Gundavelli (sgundave) 
> のメール:
> 
> Folks - Gentle reminder. Please send your requests for agenda slots for
> IETF 102. If you have already done so, you can ignore this. Please include
> the following information.
> 
> 
>  ---
>  Topic Name:
>  Presenter Name:
>  Time:
>  Draft Reference:
> ---
> 
> 
> 
> 
> Sri
> 
> 
> 
> 
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
>> (sgundave)
>> Sent: Thursday, May 3, 2018 5:32 PM
>> To: dmm@ietf.org
>> Subject: [E] [DMM] IETF102 - Call for agenda items
>> 
>> The DMM working group is planning to meet in IETF 102, week of 16th of
>> July, 2018 at Montreal. We currently have requested for one meeting,
>> which is a 2.5 hour slot.
>> 
>> We realize in IETF101 we had many items with a fully packaged agenda, and
>> could not allocate enough time for any of the topics. For this meeting,
>> we want to avoid that problem by asking for an additional meeting slot,
>> but we want to be sure there are enough items for discussion before we
>> lock the resources.
>> 
>> So, if you need a presentation slot, please send your request to the
>> chairs (as a response to this email) with the following information. We
>> still have time and so its not required that you need a published I-D,
>> but do let us know in the next few days if you are planning to make a
>> presentation. 
>> 
>> 
>> ---
>>> Topic Name:
>>> Presenter Name:
>>> Time:
>>> Draft Reference: (Optional)
>>> ---
>> 
>> Regards
>> Dapeng & Sri
 
>>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>> listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiS
>> ODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=3YmCyVAoiC_
>> ugQMmv8VcJoITk2D8QR4ZHgE34zzz0CY=AHrommWakT2klf1og05nny7we_JVQm8flSZ8ZZ7
>> ASgw=
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Overall review on "draft-bogineni-dmm-optimized-mobile-user-plane-00"

[Satoru Matsushima]

Dear Kalyani, and the draft authors,

Thank you so much for working on this I-D which brings much information 
regarding user plane protocols in IETF. It looks very promising work on IETF 
side corresponding to the user plane protocol study work (FS_UPPS) in 3GPP CT4.

Since I’m in the loop in the offline discussion of updating the draft, let me 
leave to bring detail comments on this version but instead here I’d bring 
following my overall comments on the draft as the rapporteur of FS_UPPS on 3GPP 
side.


1. Clarification on the TR/TSes

As the LS(*) pointed the User Plane protocol and several User Plane related 
specs in 3GPP, clarifying those specs in terms of user plane are highly 
appreciated. As I presented in London(**), the approach for this study in CT4 
will be investigation and comparison for the candidates protocols including 
existing protocol that needs criteria to do that. Clarifying 5G specs in terms 
of user plane based on IETF expert’s analysis would be very helpful to figure 
out that criteria.

In CT4 side, we don’t have prefer logistic for the outcome of the 
clarification. The I-D has just a section of overview of 5G system but it looks 
quite a document already so that another concise clarify focused document in 
Internet Draft style sounds make sense to me. 


2. Contents organization

The I-D contains SRv6, LISP and ILA as the candidate user plane protocols. 
Those protocols seem to have each characteristics and certain level of impacts 
to the 3GPP 5G architecture. However it was difficult to find those features 
and impacts when I went thorough the draft. Though the LS asks DMM to provide 
any information regarding User Plane protocol, it would be nice at least if you 
can provide over-the-wire packet format, for instance, with the features of 
each protocol. And it would be followed by expected impacts to the 3GPP control 
plane of each candidates, as I said in London. In addition to that, 
distinguishably describing more impacts to the architecture beyond Release 15 
would be much helpful to clearly understand on what those candidates require 
the architecture to be changed, as INT AD, Suresh, stated in London if I recall 
correctly. It would be also highly appreciated if those can be found out at a 
glance from the draft. That make us easy to digest it.

Please note that it does not mean the candidates need to be in apple-to-apple 
evaluation. It just needs the clear differences between the candidates to be 
highlighted in terms of user plane, control plane and architectural impact.


3. Use of term ‘Optimization'

The word “optimized” in the draft title seems ambiguous on that optimize for 
what. If you try to introduce how those candidates optimize something, it would 
be better to make clear the target of the optimization. But again the LS asks 
any information on user plane, the I-D doesn’t necessarily describe it. 

(*) https://datatracker.ietf.org/liaison/1572/
(**)https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-study-on-user-plane-protocol-at-3gpp-00


Hope that helps, and I’m happy to cooperate together on the user plane study on 
both IETF/3GPP sides.

Best regards,
--satoru


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

Uma, I’m happy to hear that from you. 

I was just afraid that some vendors are trying to sell NAPT traversal cellular 
boxes with additional license fee. 
As you all know, 5G radio requires us to deploy APs much dense that we expect 
several or many IPv4 10/8 and even 100.64/10 should be required to cover the 
footprint of operators.

What I imagined was if a business person in a vendor finds that hidden 
bottleneck, I expected that the guy proposes NAPT traversal products to his 
company and easily convinced to get the go sign.
I have to admit that he/she must be a smart business person. If a operator who 
fully depends on IPv4 as backhaul/core transport, I expect that the operator 
couldn't resist to that attractive proposal. 

I hope you don’t do that even after you know my imagination.

Cheers,
--satoru

> 2018/05/30 10:36、Uma Chunduri のメール:
> 
> Hi Satoru,
> 
> In-line [Uma]:
> 
> Cheers!
> --
> Uma C.
> (responding as an individual)
> 
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
> Sent: Tuesday, May 29, 2018 6:23 PM
> To: Uma Chunduri 
> Cc: Dino Farinacci ; dmm 
> Subject: Re: [DMM] User Plane Protocol Study in 3GPP
> 
> Hello Uma, let me clarify something. 
> 
> Are you proposing that we need to work on mobile user plane protocol with 
> IPv4 NAPT?
> [Uma]: Nope, I did not say that.
> Or, does your employer plan to develop NAPT traversal cellular equipments and 
> application gateway for the user plane protocol?
> [Uma]:  You are assuming on something which I didn't say anything about.  I 
> was just responding to Dino's question on "IPv6 only NGC" ..
> 
> 
> It seems reinvent of PPTP.
> 
> Cheers,
> -satoru
> 
>> 2018/05/24 2:07、Uma Chunduri のメール:
>> 
>> Dear All,
>> 
>> For the Dino's question -
>> 
>>> Do you think carriers will build an IPv6-only NGC at this point in time?
>> 
>> I don't think so (from the existing deployments perspective, including early 
>> 5G transitions). 
>> 
>> So, IMO - any mobility solution ought to be underlay independent - to allow 
>> flexibility for the operators. I see this discussion is independent of 
>> address space exhaustion or IPv6 address to UE..
>> 
>> --
>> Uma C.
>> 
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
>> Sent: Tuesday, March 20, 2018 5:02 PM
>> To: Satoru Matsushima 
>> Cc: dmm 
>> Subject: Re: [DMM] User Plane Protocol Study in 3GPP
>> 
>> That sounds like you want to do IPv4 over IPv6. Do you think carriers will 
>> build an IPv6-only NGC at this point in time?
>> 
>> Dino
>> 
>>> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima 
>>>  wrote:
>>> 
>>> Next header type maybe?
>>> Interestingly GTP-U doesn’t have it.
>>> 
>>> Sent from my iPhone
>>> 
>>> 2018/03/20 18:17、Dino Farinacci のメール:
>>> 
>>>> How? Please summarize in one sentence and don’t me to a draft.
>>>> 
>>>> Dino
>>>> 
>>>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>>>>  wrote:
>>>>> 
>>>>> Yes , supports IPv4 PDU with minimum effort.
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> 2018/03/20 16:47、Lyle Bertz のメール:
>>>>> 
>>>>>> I did not get to ask but I know your presentation talks about IPv6 but 
>>>>>> is there a requirement to support IPv4 mobile or dual stack?
>>>>>> 
>>>>>> Lyle
>>>>> 
>>>>> ___
>>>>> dmm mailing list
>>>>> dmm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

Hello Uma, let me clarify something. 

Are you proposing that we need to work on mobile user plane protocol with IPv4 
NAPT?
Or, does your employer plan to develop NAPT traversal cellular equipments and 
application gateway for the user plane protocol?

It seems reinvent of PPTP.

Cheers,
-satoru

> 2018/05/24 2:07、Uma Chunduri のメール:
> 
> Dear All,
> 
> For the Dino's question -
> 
>> Do you think carriers will build an IPv6-only NGC at this point in time?
> 
> I don't think so (from the existing deployments perspective, including early 
> 5G transitions). 
> 
> So, IMO - any mobility solution ought to be underlay independent - to allow 
> flexibility for the operators. I see this discussion is independent of 
> address space exhaustion or IPv6 address to UE..
> 
> --
> Uma C.
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Tuesday, March 20, 2018 5:02 PM
> To: Satoru Matsushima 
> Cc: dmm 
> Subject: Re: [DMM] User Plane Protocol Study in 3GPP
> 
> That sounds like you want to do IPv4 over IPv6. Do you think carriers will 
> build an IPv6-only NGC at this point in time?
> 
> Dino
> 
>> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima  
>> wrote:
>> 
>> Next header type maybe?
>> Interestingly GTP-U doesn’t have it.
>> 
>> Sent from my iPhone
>> 
>> 2018/03/20 18:17、Dino Farinacci のメール:
>> 
>>> How? Please summarize in one sentence and don’t me to a draft.
>>> 
>>> Dino
>>> 
>>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>>>  wrote:
>>>> 
>>>> Yes , supports IPv4 PDU with minimum effort.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> 2018/03/20 16:47、Lyle Bertz のメール:
>>>> 
>>>>> I did not get to ask but I know your presentation talks about IPv6 but is 
>>>>> there a requirement to support IPv4 mobile or dual stack?
>>>>> 
>>>>> Lyle
>>>> 
>>>> ___
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-bernardos-dmm-pmipv6-dlif-01 as DMM WG document

[Satoru Matsushima]

Support.

Cheers,
--satoru

> 2018/03/28 6:25、Sri Gundavelli (sgundave) のメール:
> 
> Folks:
> 
> During IETF 99 and IETF 100 we polled the room for their interest in taking 
> up draft-bernardos-dmm-pmipv6-dlif- as a DMM working group document. In both 
> those occasions there was good amount of support for taking up this work. The 
> chairs would like to confirm the same over the mailing list.  Please provide 
> your feedback on the same. 
> 
> This adoption call will end by 11th of April, 2018.
> 
> Pointer:
> https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01
> 
> 
> Regards
> Sri
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01)

[Satoru Matsushima]

Hi Arashmid, 

Yes, it needs to be clarified. Here I think that in terms of GTP-U over IPv6 
case, gNB could be signaled a remote IPv6 endpoint address to which the SRGW 
binds a SID with appropriate payload type, such as IPv4/IPv6/Ethernet. In 
enhanced mode the SID doesn’t need to be allocated per session basis.

Wrt supporting unstructured PDU type, we may need to clarify which NH type to 
be used to carry over IPv6.

Cheers,
--satoru

> 2018/04/10 17:45、Arashmid Akhavain のメール:
> 
> Hi Pablo,
>  
> We might need to add some clarification w.r.t state reduction as well and 
> explain this in the context of different modes.
>  
> Cheers,
> Arashmid
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Pablo Camarillo 
> (pcamaril)
> Sent: 10 April 2018 03:27
> To: Kentaro Ebisawa ; dmm 
> Subject: Re: [DMM] Next Header in End.M.GTP6.D 
> (draft-ietf-dmm-srv6-mobile-uplane-01)
>  
> Hi Kentaro,
>  
> You are right. For each PDU session type you will have a different instance 
> of an End.M.GTP6.D SID. We can add a note in the next revision of the draft 
> in case this is not clear.
>  
> Thank you.
>  
> Cheers,
> Pablo.
>  
> From: dmm  on behalf of Kentaro Ebisawa 
> 
> Date: Wednesday, 4 April 2018 at 11:08
> To: dmm 
> Subject: [DMM] Next Header in End.M.GTP6.D 
> (draft-ietf-dmm-srv6-mobile-uplane-01)
>  
> Hi,
>  
> In "6.2. End.M.GTP6.D", how would SR Gateway know if user packet inside GTP 
> is IPv4 or IPv6?
> I think this info is required to set newly added SRH.NextHeader field in step 
> 3~5.
>  
> My understanding is that information would be provided by the control plane, 
> and if that's correct, should SR Gateway have 2 (or more) SIDs corresponding 
> to the type of user packet and also inform gNB to use different SIDs 
> (dstAddr) based on user packet type?
> One could also have SID per TEID, but I'm not sure if that's a good design 
> choice considering the effort to reduce state in network nodes.
>  
> Thanks,
> -- 
> Kentaro Ebisawa 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [5gangip] Reviewing GTP (was: re: Notes from today's meeting)

[Satoru Matsushima]

Thank you Behcet,

Ok, I was supposed that Alex is going to make a reference doc for GTP in IETF, 
and John is going to review GTP in ETSI.

As I mentioned at last DMM meeting, investigating GTP-U by IETF experts’s eyes 
is highly appreciated. Please see following link and find some GTP-U info. 
Maybe IETF-friendly style explanation is helpful for you. :-)

https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-study-on-user-plane-protocol-at-3gpp-00


I’m really happy to cooperate with all people those who are interested in to 
work on it.

Best regards,
--satoru



> 2018/03/31 0:26、Behcet Sarikaya <sarikaya2...@gmail.com>のメール:
> 
> Hi Satoru,
> 
> On Fri, Mar 30, 2018 at 12:12 AM, Satoru Matsushima 
> <satoru.matsush...@gmail.com> wrote:
> Hello John,
> 
> If it would useful, I’d like to cooperate that GTP review work at user plane 
> point of view. Thanks.
> 
> 
> 
> Thanks for the offer but I think you are confused of what is going on below 
> in the mails, so many people's mails including two John's, Jon Crowcroft and 
> John Grant.
> 
> Reviewing GTP is an idea we have in 5gangip and currently Alex is taking the 
> lead.
> As a GTP expert you are welcome to join him.
> 
> Alex has this ambitious idea of writing a draft (not an RFC, we do not write 
> RFCs, some drafts become RFCs) on GTP which could be used as a reference to 
> GTP in IETF (to enable the operators  to run GTP in IPv6).
> 
> In our case, we encourage writing a requirements document for end to end 
> privacy enabled mapping system for 5G for which the starting point should be 
> the GTP and address the issues of tunneling and other aspects.
> 
> I believe this has nothing to do with what is going on in dmm.
> 
> Regards,
> Behcet
> 
> Cheers,
> --satoru
> 
> > 2018/03/29 19:38、John Grant <j...@ninetiles.com>のメール:
> >
> > On Mon, Mar 26, 2018 at 4:49 AM, Alexandre Petrescu  > gmail.com>
> >  wrote:
> >
> >
> >
> > Le 23/03/2018 à 09:08, Jon Crowcroft a écrit :
> > is there a technical reason we can't just re-visit MIPv6 in 5g in 2018?
> >
> > If it were up to me...
> >
> > To revisit, I would start looking at the tunnelling mechanism, identify
> > what's missing from GTP, or how is it too heavy.
> >
> > That's something we're looking at in ETSI ISG NGP 
> > http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols
> >
> > There's also a one-day workshop on the topic in Cambridge at the end of 
> > April 
> > https://www.cambridgewireless.co.uk/events/uk5g-death-ip-realising-opportunities-next-generat/
> > --
> > John Grant
> > Nine Tiles, Cambridge, England
> > +44 1223 862599 and +44 1223 511455
> >
> > http://www.ninetiles.com
> >
> >
> >
> >
> > ___
> > 5gangip mailing list
> > 5gan...@ietf.org
> > https://www.ietf.org/mailman/listinfo/5gangip
> 
> ___
> 5gangip mailing list
> 5gan...@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [5gangip] Reviewing GTP (was: re: Notes from today's meeting)

[Satoru Matsushima]

Hello John,

If it would useful, I’d like to cooperate that GTP review work at user plane 
point of view. Thanks.


Cheers,
--satoru

> 2018/03/29 19:38、John Grant のメール:
> 
> On Mon, Mar 26, 2018 at 4:49 AM, Alexandre Petrescu  gmail.com>
>  wrote:
> 
> 
> 
> Le 23/03/2018 à 09:08, Jon Crowcroft a écrit :
> is there a technical reason we can't just re-visit MIPv6 in 5g in 2018?
> 
> If it were up to me...
> 
> To revisit, I would start looking at the tunnelling mechanism, identify
> what's missing from GTP, or how is it too heavy.
> 
> That's something we're looking at in ETSI ISG NGP 
> http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols
> 
> There's also a one-day workshop on the topic in Cambridge at the end of April 
> https://www.cambridgewireless.co.uk/events/uk5g-death-ip-realising-opportunities-next-generat/
> -- 
> John Grant
> Nine Tiles, Cambridge, England
> +44 1223 862599 and +44 1223 511455
> 
> http://www.ninetiles.com
> 
> 
>  
> 
> ___
> 5gangip mailing list
> 5gan...@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Satoru Matsushima]

One thing I want to follow my comment.

> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.


I think that we have to have OAM functionality in addition to that criteria.

Best regards,
--satoru



> 2018/03/27 15:57、Satoru Matsushima <satoru.matsush...@gmail.com>のメール:
> 
> Thank you Tom,
> 
> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. (No 
> offensive, please don’t get me wrong.)
> 
> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
> type encapsulation in IETF.
> IMO Unified concept in that encapsulation doesn’t seem to work in that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
> 
> Nevertheless I think that that aspect would be a criteria for user plane 
> protocols comparison provided to 3GPP. But I don’t think it is good idea that 
> we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It 
> would be better to pick SRv6 and some generic foo-over-UDP protocol to be 
> compared with GTP-U supported functionalities.
> 
> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.
> 
> Best regards,
> --satoru
> 
> 
> 
>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>> 
>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
>> <satoru.matsush...@gmail.com> wrote:
>>> Thank you Tom for your suggestion.
>>> 
>>> Do you think that GUE has some advantages against GTP-U?
>> 
>> I believe so. GUE is designed to be a general purposed multi use case
>> encapsulation. The defined GUE extensions deal with problems and
>> provide features of encapsulation (header security, fragmentation,
>> payload security, checksum handling etc.). This is done without
>> resorting to expensive TLV processing. GUE also allows "private data"
>> that could be used for use case specific info-- so TLVs or GTP
>> extensions could be encoded so in that sense it's a superset of GTP
>> functionality. As I mentioned, GUE has a mode for encapsulating IP in
>> UDP with minimal overhead (direct IP over UDP).
>> 
>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>> beyond GTP-U?
>>> 
>> I think so. Perhaps the biggest advantage is the GUE can be used
>> accross different use cases and technologies. It's generic protocol so
>> it could be used for multiple use cases in a mobile network. For
>> instance, a UE might talk to a a low latency service application via
>> GUE. To the server this looks much more like simple virtualization or
>> encapsulation and GUE includes potential optimizations. Similarly, GUE
>> also could be use to connect across different access technologies that
>> might not be 3GPP (like roaming between WIFI and a mobile network).
>> Conceptually, other IETF defined encapsulations could also be used for
>> this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically designed
>> to be multi use case, low overhead, but still extensible.
>> 
>> We intend to use ILA in a similar multi-use case fashion, however when
>> encapsulation is required (like SR TE is needed, or we need an
>> encrypted tunnel) then I believe GUE is a good alternative for that
>> case to provide necessary functionality and extensibility.
>> 
>> Tom
>> 
>>>> 2018/03/27 9:16、Tom Herbert <t...@quantonium.net>のメール:
>>>> 
>>>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>>>> <sgund...@cisco.com> wrote:
>>>>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>>>>> 
>>>>> We are also waiting for Lyle to share his notes. Please review and
>>>>> comment, if you see any mistakes.
>>>>> 
>>>> 
>>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>>> Why not using UDP encapsulation?"
>>>> 
>>>> There is some rationale for UDP encapsulation here to maximize
>>>> compatibility with the network and potentially intermed

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Satoru Matsushima]

Thank you Tom for your suggestion.

Do you think that GUE has some advantages against GTP-U?
When it comes to foo over UDP capsulation, does GUE benefit user plane beyond 
GTP-U?

Best regards,
--satoru



> 2018/03/27 9:16、Tom Herbert のメール:
> 
> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>  wrote:
>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>> 
>> We are also waiting for Lyle to share his notes. Please review and
>> comment, if you see any mistakes.
>> 
> 
> With regards to SR encapsulation: "this is using IP-in-IP as default.
> Why not using UDP encapsulation?"
> 
> There is some rationale for UDP encapsulation here to maximize
> compatibility with the network and potentially intermediate nodes like
> firewalls. For example, in the performance numbers that Kalyani
> posted, the TPS for SR over IPIP routing was lower than other
> encapsulations. The reason for this is that the particular NIC (ixgbe)
> is not parsing over IPIP or using flow label to get a good hash for
> RSS. This is symptomatic of network devices that don't provide as good
> support for protocols outside of TCP and UDP. There are likely routers
> that would not be able to provide flow specific ECMP for similar
> reasons. There was a comment in dmm meeting that ECMP for IPIP was
> expected to by solved by using flow label in the hash. This is a great
> idea, but unfortunately there is significant resistance to using flow
> label for this purpose since it is not guaranteed to be persistent for
> a flow and that can cause problems for stateful devices like
> firewalls.
> 
> UDP encapsulation is the typical answer to network protocol
> compatibility. Several UDP encapsulation techniques have been defined
> as well as some foo over UDP to run existing encapsulations over UDP
> (e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
> overview of considerations for UDP encap protocols.
> 
> If a UDP encapsulation is considered for use with SR, I would suggest
> GUE is an option. GUE has some unique features:
> 
> - It's extensible (both common extensions are defined and allows
> custom extensions per use case)
> - It's generic (can encapsulate any IP protocol)
> - It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
> encapsulation overhead)
> - It allows encapsulation of extension headers
> 
> The last point may be of particular interest to SR. SR over IPIP might
> be more precarious compared to other encapsulations since it
> introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
> be used to normalize SR packets to look like UDP to the network. This
> might look something like:
> 
> IP|UDP|GUE|Routing_hdr|IP|payload
> 
> The UDP and GUE header are effectively treated as routing shim at each
> segment hop so SR is processed as without regard to the encapsulation.
> To intermediate nodes these packets looks like any other UDP packet so
> there's no compatibility issue.
> 
> Tom
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

Next header type maybe?
Interestingly GTP-U doesn’t have it.

Sent from my iPhone

2018/03/20 18:17、Dino Farinacci <farina...@gmail.com>のメール:

> How? Please summarize in one sentence and don’t me to a draft.
> 
> Dino
> 
>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>> <satoru.matsush...@gmail.com> wrote:
>> 
>> Yes , supports IPv4 PDU with minimum effort.
>> 
>> Sent from my iPhone
>> 
>> 2018/03/20 16:47、Lyle Bertz <lyleb551...@gmail.com>のメール:
>> 
>>> I did not get to ask but I know your presentation talks about IPv6 but is 
>>> there a requirement to support IPv4 mobile or dual stack?
>>> 
>>> Lyle
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

BTW 5G Rel-15 doesn’t support IPv4v6 type session. But Docomo is trying to get 
back v4v6 to the updated Rel-15 stage 2 spec.
I don’t know why. 

> 2018/03/20 16:47、Lyle Bertz のメール:
> 
> I did not get to ask but I know your presentation talks about IPv6 but is 
> there a requirement to support IPv4 mobile or dual stack?
> 
> Lyle

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Satoru Matsushima]

Yes , supports IPv4 PDU with minimum effort.

Sent from my iPhone

2018/03/20 16:47、Lyle Bertz のメール:

> I did not get to ask but I know your presentation talks about IPv6 but is 
> there a requirement to support IPv4 mobile or dual stack?
> 
> Lyle

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Satoru Matsushima]

Thanks authors,

Actually this draft sounds interesting for me. Some points for that are 
following:

1. Utilizing existing control plane for distributed mobility functions.
2. Those mobility functions could be programmed through some interface, i.e: FPC
3. I’d see some similarity with MFA ideas.
4. SRv6 could be user plane protocol with the control plane protocol.

One question here is that whether the authors are interested in User Plane 
white paper which Kalyani lead files this solution.

Cheers,
--satoru

> 2018/03/06 22:17、Carlos Jesús Bernardos Cano のメール:
> 
> Hi,
> 
> We have submitted a revised version of our draft addressing the
> comments we got in Singapore:
> 
> - Added some statements about which model from draft-ietf-dmm-
> deployment-models our solution follows (addressing a comment received
> from Sri).
> - Added some text relating to draft-ietf-dmm-ondemand-mobility
> (addressing a comment received from Danny).
> 
> Additionally, we added some terminology from draft-ietf-dmm-deployment-
> models and other minor changes.
> 
> In Singapore we got quite good support of the document. I'd like to
> request feedback/reviews from the WG.
> 
> Thanks!
> 
> Carlos
> 
> 差出人: internet-dra...@ietf.org
> 件名: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt
> 日付: 2018年3月2日 17:16:29 GMT
> 宛先: 
> 返信先: internet-dra...@ietf.org
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>Title   : Proxy Mobile IPv6 extensions for Distributed 
> Mobility Management
>Authors : Carlos J. Bernardos
>  Antonio de la Oliva
>  Fabio Giust
>  Juan Carlos Zuniga
>  Alain Mourad
>   Filename: draft-bernardos-dmm-pmipv6-dlif-01.txt
>   Pages   : 32
>   Date: 2018-03-02
> 
> Abstract:
>   Distributed Mobility Management solutions allow for setting up
>   networks so that traffic is distributed in an optimal way and does
>   not rely on centralized deployed anchors to provide IP mobility
>   support.
> 
>   There are many different approaches to address Distributed Mobility
>   Management, as for example extending network-based mobility protocols
>   (like Proxy Mobile IPv6), or client-based mobility protocols (as
>   Mobile IPv6), among others.  This document follows the former
>   approach, and proposes a solution based on Proxy Mobile IPv6 in which
>   mobility sessions are anchored at the last IP hop router (called
>   mobility anchor and access router).  The mobility anchor and access
>   router is an enhanced access router which is also able to operate as
>   local mobility anchor or mobility access gateway, on a per prefix
>   basis.  The document focuses on the required extensions to
>   effectively support simultaneously anchoring several flows at
>   different distributed gateways.
> 
>   This document introduces the concept of distributed logical
>   interface, which is a software construct that allows to easily hide
>   the change of anchor from the mobile node.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bernardos-dmm-pmipv6-dlif/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01
> https://datatracker.ietf.org/doc/html/draft-bernardos-dmm-pmipv6-dlif-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-bernardos-dmm-pmipv6-dlif-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Hello Tom,

Thank you for your feedback.

> ...snip...

> - Pick a handful of representative formats, maybe something like five,
> and do an an equivalent comparison. For instance, it should be easy to
> deduce the equivalent packet formats for traditional mode in SR that
> are needed for GTP and ILA.

I want to do. But I’d keep them until it is clear those are truly not deployed 
in rest of world.
When it’s clear I remove them.


> - Don't count the outer Ethernet header as overhead. It's always there
> and not counted against MTU.

When it comes to overhead, it affects not only for MTU size, but also consumed 
bandwidth.
In that perspective, I’d keep Ethernet header in it. Or, do you want to resume 
the discussion of ‘killing ethernet’ thread in ietf at ietf list?


> - Don't use colors to highlight differences. The use of 'red' in the
> spreadsheet is subjective and also confusing in itself. For instance,
> I don't understand why 'No SRH' (line 1) is black but basic GTP over
> IPv4 (line 5) is red when they are both reported to have 58 bytes of
> overhead.

This is comparison of overhead size against SRv6 Mobile User Plane so that SRv6 
is base and no need to be colored.
I can change red to other color.


> - Is the math is off? For instance, in line 1 the overhead is an IPv6
> header and and Ethernet header, shouldn't that be 40+14=54 instead of
> 58?

FCS counted.

Cheers,
--satoru


> 
> Tom
> 
> 
> 
> 
> 
>> 
>>> 
>>> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced 
>>> mode)? In GTPU the QFI/RQI markings are carried in a GTPU extension header, 
>>> defined as a container. Please refer the following documents for details
>> 
>> Thank you for those latest references! Actually I was seeking them from last 
>> CT4 meeting folder. ;-)
>> 
>> And yes, we still leave it at this time since defining 3GPP specific 
>> extension headers and messages should be up to 3GPP decision.
>> We don’t want to violate that responsibility. Nevertheless, in case that 
>> those GTP-U extension header and messages are carried as its encoding, TLV 
>> in SRH would work to do that with just one or few code points to 3GPP which 
>> looks not big deal. If you are interested, it would be nice if we can write 
>> a draft with that idea with you and John.
>> 
>> Cheers,
>> --satoru
>> 
>>> 
>>> Incoming LS from RAN3 to CT4: 
>>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip
>>> 
>>> Corresponding agreed CR in CT4: 
>>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip
>>> 
>>> LS out from CT4 to RAN3: 
>>> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
>>> 
>>> Thanks
>>> Sridhar
>>> 
>>> -Original Message-
>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
>>> Sent: Tuesday, March 13, 2018 6:55 AM
>>> To: John Kaippallimalil <john.kaippallima...@huawei.com>
>>> Cc: dmm <dmm@ietf.org>
>>> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>> 
>>> John,
>>> 
>>>> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
>>>> 
>>>> A few questions for clarification:
>>>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push 
>>>> an SRH..."
>>>> In this case the outer IPv6 address representing a SID would contain a 
>>>> TEID.
>>>> So for 1000 PDU sessions - would there be as many IPv6 addresses
>>>> (representing SIDs/TEID in the outer header)
>>> 
>>> Right. It is not limited but in a typical case given that a /64 per node 
>>> for the SID space which allows each node allocate a SID per session basis.
>>> 
>>> 
>>>> 
>>>> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on
>>>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other 
>>>> fns - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to 
>>>> chain functions along the path to UPF1,
>>>> or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
>>>> upto the anchor UPF2.
>>> 
>>> Please see the section 5.2.1 of packet flow on uplink.
>>> We assume that there’s no UPF1 along the path in the diagram.
>>> 
>>> 
>>>> 
>>

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Dear Sridhar,

It’s nice to see you in DMM list as well. :-)

> [...snip...]


> 1. Section 5.2.2 of the draft says,
> 
> UPF2_in : (Z,A)  -> UPF2 maps the flow w/
>SID list <C1,S1, gNB> 
> 
> When the packet arrives to the UPF2, the UPF2 will map that
>   particular flow into a UE session.
> 
> Does this mean the UPF2 is aware of the gNB the UE is latched on and hence 
> after each mobility, the information regarding current gNB is signaled / 
> programmed till the UPF2 (which could be the PDU session anchor UPF)?

Right. It’s equivalent with GTP-U case where there’s no N9 along the path.
One significant difference between GTP-U and enhanced mode is that the packets 
of PDU sessions which belong to a same SR policy will use same set of SIDs in 
the header.


> 
> 2. For traditional mode (basic mode), could you please elaborate on the MTU 
> overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 
> header + 8 octets UDP header + 12 octets GTPU header + Extension header for 
> QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI 
> (this part is not clear - see my next question). In your blog 
> https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
>  I noticed in Fig.1 the MPLS / TE headers included in calculation. So does 
> the MTU overhead saving talked about for SRv6 assume that underlay TE 
> technologies are replaced? It is not clear from the draft. If there are any 
> other drafts that provide a clear calculation on the MTU savings, could you 
> please point to them?

I hope that the following spreadsheet helps for that purpose. I’ve updated it 
align to the latest draft after I shared it in last month. 

https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing

As the draft says that traditional mode is as same as existing user plane 
protocol, it is also equivalent in terms of overhead size.
You can find that both GTP-U and traditional mode of SRv6 cost 58 bytes as the 
overhead.


> 
> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced mode)? 
> In GTPU the QFI/RQI markings are carried in a GTPU extension header, defined 
> as a container. Please refer the following documents for details

Thank you for those latest references! Actually I was seeking them from last 
CT4 meeting folder. ;-)

And yes, we still leave it at this time since defining 3GPP specific extension 
headers and messages should be up to 3GPP decision. 
We don’t want to violate that responsibility. Nevertheless, in case that those 
GTP-U extension header and messages are carried as its encoding, TLV in SRH 
would work to do that with just one or few code points to 3GPP which looks not 
big deal. If you are interested, it would be nice if we can write a draft with 
that idea with you and John.

Cheers,
--satoru

> 
> Incoming LS from RAN3 to CT4: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip
> 
> Corresponding agreed CR in CT4: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip
> 
> LS out from CT4 to RAN3: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
> 
> Thanks
> Sridhar
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Tuesday, March 13, 2018 6:55 AM
> To: John Kaippallimalil <john.kaippallima...@huawei.com>
> Cc: dmm <dmm@ietf.org>
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> John,
> 
>> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
>> 
>> A few questions for clarification:
>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push 
>> an SRH..."
>> In this case the outer IPv6 address representing a SID would contain a TEID.
>> So for 1000 PDU sessions - would there be as many IPv6 addresses 
>> (representing SIDs/TEID in the outer header)
> 
> Right. It is not limited but in a typical case given that a /64 per node for 
> the SID space which allows each node allocate a SID per session basis.
> 
> 
>> 
>> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on 
>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns 
>> - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to chain 
>> functions along the path to UPF1,
>>  or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
>> upto the anchor UPF2. 
> 
> Please see the section 5.2.1 of packet f

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

John,

> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール:
> 
> A few questions for clarification:
> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
> SRH..."
> In this case the outer IPv6 address representing a SID would contain a TEID.
> So for 1000 PDU sessions - would there be as many IPv6 addresses 
> (representing SIDs/TEID in the outer header)

Right. It is not limited but in a typical case given that a /64 per node for 
the SID space which allows each node allocate a SID per session basis.


> 
> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on path (gNB 
> --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - S1, C1)
> Would the SR path at gNB (uplink) be (a) the list of SIDs to chain functions 
> along the path to UPF1,
>   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
> upto the anchor UPF2. 

Please see the section 5.2.1 of packet flow on uplink.
We assume that there’s no UPF1 along the path in the diagram.


> 
> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
> service chaining ..."
> 3GPP service chaining is at N6 interface, but in this case, is the policy for 
> traffic steering implemented at the N3  interface.
> Would PCF/SMF provision this at gNB.

When it comes to enhanced mode for control-plane side, it may literally be 
enhanced.
But at this revision of the draft, it is assumed that gNB is capable to resolve 
SR policy from remote endpoint address of tunnel to SIDs list while N2 is 
unchanged and kept as it is.

Cheers,
--satoru


> 
> Thanks,
> John
> 
> 
> 
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
> Sent: Mittwoch, 7. März 2018 12:23
> To: Marco Liebsch
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Marco,
> 
>> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
>> 
>> Satoru,
>> 
>> since I read this at different places, let me ask one clarifying question 
>> about the stateless motivation: 
>> 
>> I see that for SRv6 you may not need a state at the egress (at least 
>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need a 
>> state at both edges of the communication since the DL egress serves as 
>> uplink ingress, correct?
> 
> 2x unidirectional tunnels to form bidirectional paths require 4 states in 
> total at both the ingress and egress.
> In SR case it requires just 2 states at the ingresses for both directions.
> 
> Cheers,
> --satoru
> 
> 
> 
>> 
>> marco
>> 
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
>> Sent: Dienstag, 6. März 2018 17:23
>> To: Tom Herbert
>> Cc: dmm
>> Subject: Re: [DMM] Fwd: I-D Action: 
>> draft-ietf-dmm-srv6-mobile-uplane-01.txt
>> 
>> Hello Tom,
>> 
>>>> A Big progress is that the draft supports interworking with GTP over
>>>> IPv6 in addition to GTP over IPv4.
>>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>>> instead of SRH insertion by default.
>>>> 
>>> 
>>> Hi Satoru,
>>> 
>>> If there are no intermediate hops od SIDs being set when 
>>> encapsulating would a SR header still be needed or could this just be 
>>> simple IP in IP encpasulation?  If is no SR header then it's possible 
>>> that ILA might then be used to completely eliminate the encapsulation 
>>> overhead.
>> 
>> I think you’re right. You would find that case in the draft as ‘Traditional 
>> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
>> is also equivalent with that mode. In addition, this draft introduces 
>> ‘Enhance Mode’ to cover more advanced cases.
>> 
>> IMO SR is designed not to maintain path states except at an ingress node. So 
>> the packet need to preserve original DA in the header that keep the egress 
>> node in stateless. It would be great if ILA is designed in the similar 
>> concept as well.
>> 
>> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
>> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
>> choose which one need to be prioritized would depend on each deployment case 
>> in operators IMO.
>> 
>> Cheers,
>> --satoru
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] SRv6 for 5G Mobile [was Re: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt]

[Satoru Matsushima]

FYI. A blog entry posted to APNIC:

"Reducing the complexity of 5G networks using Segment Routing IPv6"
https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/

Please take a look.

Cheers,
--satoru


> 2018/03/06 9:34、Satoru Matsushima <satoru.matsush...@gmail.com>のメール:
> 
> Dear folks,
> 
> A new revision of SRv6 Mobile User Plane draft has been submitted to IETF.
> 
> I’d present brief summary of the updates, but the agenda seems already full 
> so that it is uncertain I can do that.
> 
> So let me share the summary of update on the -01 version here.
> 
> A Big progress is that the draft supports interworking with GTP over IPv6 in 
> addition to GTP over IPv4.
> And we have made change SRv6 function to IPv6 encapsulation with SRH instead 
> of SRH insertion by default. 
> 
> Another changes have been made. 5G architecture in 3GPP is shown as a 
> reference architecture, as the discussion on the list many people ask SRv6 
> applicability for 5G. As the result, many terminologies are aligned based on 
> the reference.
> 
> You can see many improvements in terms of readability, especially on packet 
> flow explanations. I hope that many of us understand how SRv6 works for the 
> deployment cases described in the draft. 
> 
> Pablo has contributed those significant part of progresses and improvements. 
> He's now onboard as a co-author of the draft.
> 
> Best regards,
> --satoru
> 
>> 転送されたメッセージ:
>> 
>> 差出人: internet-dra...@ietf.org
>> 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>> 日付: 2018年3月6日 7:42:01 JST
>> 宛先: <i-d-annou...@ietf.org>
>> CC: dmm@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Distributed Mobility Management WG of the 
>> IETF.
>> 
>>Title   : Segment Routing IPv6 for Mobile User Plane
>>Authors : Satoru Matsushima
>>  Clarence Filsfils
>>  Miya Kohno
>>  Pablo Camarillo
>>  Daniel Voyer
>>  Charles E. Perkins
>>  Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>>  Pages   : 23
>>  Date: 2018-03-05
>> 
>> Abstract:
>>   This document discusses the applicability of SRv6 (Segment Routing
>>   IPv6) to user-plane of mobile networks.  The source routing
>>   capability and the network programming nature of SRv6, accomplish
>>   mobile user-plane functions in a simple manner.  The statelessness
>>   and the ability to control underlying layer will be even more
>>   beneficial to the mobile user-plane, in terms of providing
>>   flexibility and SLA control for various applications.  It also
>>   simplifies the network architecture by eliminating the necessity of
>>   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
>>   and so on.  In addition, Segment Routing provides an enhanced method
>>   for network slicing, which is briefly introduced by this document.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01
>> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Marco,

> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール:
> 
> Satoru,
> 
> since I read this at different places, let me ask one clarifying question 
> about the stateless motivation: 
> 
> I see that for SRv6 you may not need a state at the egress (at least not for 
> traffic forwarding) but for
> Uplink/Downlink (UL/DL) you need a state at both edges of the communication 
> since the DL egress
> serves as uplink ingress, correct?

2x unidirectional tunnels to form bidirectional paths require 4 states in total 
at both the ingress and egress.
In SR case it requires just 2 states at the ingresses for both directions.

Cheers,
--satoru



> 
> marco
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Dienstag, 6. März 2018 17:23
> To: Tom Herbert
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Hello Tom,
> 
>>> A Big progress is that the draft supports interworking with GTP over 
>>> IPv6 in addition to GTP over IPv4.
>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>> instead of SRH insertion by default.
>>> 
>> 
>> Hi Satoru,
>> 
>> If there are no intermediate hops od SIDs being set when encapsulating 
>> would a SR header still be needed or could this just be simple IP in 
>> IP encpasulation?  If is no SR header then it's possible that ILA 
>> might then be used to completely eliminate the encapsulation overhead.
> 
> I think you’re right. You would find that case in the draft as ‘Traditional 
> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
> is also equivalent with that mode. In addition, this draft introduces 
> ‘Enhance Mode’ to cover more advanced cases.
> 
> IMO SR is designed not to maintain path states except at an ingress node. So 
> the packet need to preserve original DA in the header that keep the egress 
> node in stateless. It would be great if ILA is designed in the similar 
> concept as well.
> 
> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
> choose which one need to be prioritized would depend on each deployment case 
> in operators IMO.
> 
> Cheers,
> --satoru
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Hello Tom,

>> A Big progress is that the draft supports interworking with GTP over IPv6 in
>> addition to GTP over IPv4.
>> And we have made change SRv6 function to IPv6 encapsulation with SRH instead
>> of SRH insertion by default.
>> 
> 
> Hi Satoru,
> 
> If there are no intermediate hops od SIDs being set when encapsulating
> would a SR header still be needed or could this just be simple IP in
> IP encpasulation?  If is no SR header then it's possible that ILA
> might then be used to completely eliminate the encapsulation overhead.

I think you’re right. You would find that case in the draft as ‘Traditional 
Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA is 
also equivalent with that mode. In addition, this draft introduces ‘Enhance 
Mode’ to cover more advanced cases.

IMO SR is designed not to maintain path states except at an ingress node. So 
the packet need to preserve original DA in the header that keep the egress node 
in stateless. It would be great if ILA is designed in the similar concept as 
well.

If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
choose which one need to be prioritized would depend on each deployment case in 
operators IMO.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 - Call for agenda items

[Satoru Matsushima]

Thank you chairs,

I was bit amazed when I saw the 150min slots has already been fully booked. 
Hope we can have another meeting session during the week.

Cheers,
--satoru


> 2018/03/06 13:58、Sri Gundavelli (sgundave) <sgund...@cisco.com>のメール:
> 
> https://datatracker.ietf.org/meeting/101/materials/agenda-101-dmm.txt
> 
> 
> Hope this helps.  We had to reduce the presentation times to accommodate
> you guys.
> 
> We wanted to allocate proper time for each presentation,  so we can have
> some good discussions, but we are back to this short presentation-time
> format. 
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> On 3/5/18, 4:10 PM, "Seil Jeon" <seilj...@gmail.com> wrote:
> 
>> Hi Chairs,
>> 
>> I also hope this should not be late.
>> I'd like to request a 10 min slot for small update and discussion of DMM
>> Deployment Models draft.
>> 
>> 
>> Regards,
>> Seil Jeon
>> 
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
>> (sgundave)
>> Sent: Monday, March 5, 2018 1:07 PM
>> To: Satoru Matsushima; dmm@ietf.org
>> Subject: Re: [DMM] IETF101 - Call for agenda items
>> 
>> Revised …
>> 
>> https://datatracker.ietf.org/meeting/101/materials/agenda-101-dmm.txt
>> 
>> 
>> 
>> On 3/5/18, 2:45 PM, "Satoru Matsushima" <satoru.matsush...@gmail.com>
>> wrote:
>> 
>>> Dear DMM chairs,
>>> 
>>> I hope this is not too late. I’d request a 10min slot to present the
>>> updates of SRv6 Mobile User Plane draft.
>>> 
>>> Cheers,
>>> --satoru
>>> 
>>>> 2018/03/06 1:50、Sri Gundavelli (sgundave) <sgund...@cisco.com>のメール:
>>>> 
>>>> Folks - This is the Agenda for the DMM Working Group meeting at
>>>> IETF101.
>>>> 
>>>> https://datatracker.ietf.org/doc/agenda-101-dmm/
>>>> 
>>>> Thanks
>>>> Dapeng & Sri
>>>> 
>>>> 
>>>>> 
>>>> 
>>>> ___
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>> 
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Dear folks,

A new revision of SRv6 Mobile User Plane draft has been submitted to IETF.

I’d present brief summary of the updates, but the agenda seems already full so 
that it is uncertain I can do that.

So let me share the summary of update on the -01 version here.

A Big progress is that the draft supports interworking with GTP over IPv6 in 
addition to GTP over IPv4.
And we have made change SRv6 function to IPv6 encapsulation with SRH instead of 
SRH insertion by default. 

Another changes have been made. 5G architecture in 3GPP is shown as a reference 
architecture, as the discussion on the list many people ask SRv6 applicability 
for 5G. As the result, many terminologies are aligned based on the reference.

You can see many improvements in terms of readability, especially on packet 
flow explanations. I hope that many of us understand how SRv6 works for the 
deployment cases described in the draft. 

Pablo has contributed those significant part of progresses and improvements. 
He's now onboard as a co-author of the draft.

Best regards,
--satoru

> 転送されたメッセージ:
> 
> 差出人: internet-dra...@ietf.org
> 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 日付: 2018年3月6日 7:42:01 JST
> 宛先: <i-d-annou...@ietf.org>
> CC: dmm@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the 
> IETF.
> 
>Title   : Segment Routing IPv6 for Mobile User Plane
>Authors : Satoru Matsushima
>  Clarence Filsfils
>  Miya Kohno
>  Pablo Camarillo
>  Daniel Voyer
>  Charles E. Perkins
>   Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt
>   Pages   : 23
>   Date: 2018-03-05
> 
> Abstract:
>   This document discusses the applicability of SRv6 (Segment Routing
>   IPv6) to user-plane of mobile networks.  The source routing
>   capability and the network programming nature of SRv6, accomplish
>   mobile user-plane functions in a simple manner.  The statelessness
>   and the ability to control underlying layer will be even more
>   beneficial to the mobile user-plane, in terms of providing
>   flexibility and SLA control for various applications.  It also
>   simplifies the network architecture by eliminating the necessity of
>   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
>   and so on.  In addition, Segment Routing provides an enhanced method
>   for network slicing, which is briefly introduced by this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 - Call for agenda items

[Satoru Matsushima]

Dear DMM chairs,

I hope this is not too late. I’d request a 10min slot to present the updates of 
SRv6 Mobile User Plane draft.

Cheers,
--satoru

> 2018/03/06 1:50、Sri Gundavelli (sgundave) のメール:
> 
> Folks - This is the Agenda for the DMM Working Group meeting at IETF101.
> 
> https://datatracker.ietf.org/doc/agenda-101-dmm/
> 
> Thanks
> Dapeng & Sri
> 
> 
>> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] SRv6 for Mobile User-Plane

[Satoru Matsushima]

Hi Pablo,

Let me focus on one point.

> [...snip...]

>
> >  
> > Uplink
> > Note: S1, S2 represent service functions and C1 represents a node for 
> TE purposes
> > UE sends its packet (A, Z) on a specific wireless bearer to its gNB
> > gNB’s CP associates the session from the UE (A) with IPv6 address B and 
> TEID T (N2 interface unchanged)
> > gNB_out: (gNB, B) (GTP: TEID T) (A, Z)   ;; 
> Interface N3 is unchanged
> > SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z)   ;; new End.GTP.UP
> > S1_out: (SRGW, C1) (U2::1, C1; SL=1)(A, Z)
> > C1_out: (SRGW, U2::1) (A, Z)  ;; 
> assuming PSP
> > UPF2_out:  (A, Z)   
>  ;; End.DT
> >  
> 
> Don’t you need to care about TEID at SRGW in aggregate mode?
> I think it is okay for uplink in basic mode since it allocates SID per 
> tunnel.
> [PC]: For the basic mode, yes it is ok. For the aggregate mode, we can ignore 
> the TEID since we don’t have scaling issues on the BSID. A BSID is an 
> indirecton to an SR policy, and hence we can have many BSIDs pointing to the 
> same SR policy. Hence I would not expect any scalability issue here.


That’s interesting. But using T.Encap would be also one of your intent to 
support IPv4 PDU case, right?
If it’s right, U2::1 doesn’t indicate specific one single session in this case 
so that it won’t work for IPv4 PDU case IMO.

And there’s also an interesting point in the packet flow that the SRGW uses S1 
as the first SID but it doesn’t exist in SRH while the SL=2 points S1.
It sounds a good solution to save overhead size. Is it acceptable SRH handling 
in terms of SRv6 spec?

Cheers,
--satoru


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] SRv6 for Mobile User-Plane

[Satoru Matsushima]

Pablo,

First of all, thank you for your thorough review on the draft, and concrete 
proposal to improve it.
I think I agree almost on the three proposals. Let me comment on some of your 
points.


> [...snip...]

>  
> I believe its straightforward to support IPv4 UE traffic by doing SRv6 with 
> T.Encaps behavior. Hence, I think this should be documented in the draft.

Yes.


> The encapsulation behavior should be the default one, both for IPv4 and IPv6 
> UE traffic. However, a specific provider is allowed to do SRH insertion 
> within a controlled domain [draft-voyer-6man-extension-header-insertion-02] 
> for UE IPv6 traffic.
> Also, in order to reduce overhead at the UPFs when using encapsulation, I 
> would replace the End.B6 function for a new End.MAP function. 
> For example, if we consider the following topology:
> UEgNBUPF1UPF2
>  
> Then the uplink packet flow for the basic mode would look like this:
> UE_out: (A, Z)
> gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps  
> UPF1_out:  (gNB, U2::1) (A, Z) -> End.MAP
> UPF2_out:  (A, Z) -> End.DT
>  
> The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID.


So ‘End.MAP’ function you proposed looks that the dest address in outer header 
works as last SID in SRH but just one SID doesn’t require SRH in the packet 
over the wire. If it corrects, I think it’s a good idea. I’d appreciate if you 
can contribute text and pseudo code for End.MAP to the draft. I tend to replace 
basic mode with it.


>  
> Notice that using encapsulation, if you compare it with today user-plane 
> using IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 
> header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP).

That sounds make sense. I’ve studied and shared a comparison of total overhead 
size for various deployment cases. That study shows it as well.


>  
> ===
>  
> With respect to the aggregation mode, aside from using the encapsulation mode 
> as described before, I would also like to add a note on the I-D on the fact 
> that we can support the aggregation mode without changes in the N2 interface:
> The current I-D for aggregation mode assumes that the gNB (uplink) has 
> knowledge of an SR policy that contains all the SIDs belonging to TE, NFV and 
> so on. Even though the I-D does not describe how the gNB is retrieving this 
> information, I would like to make a statement on the fact that there are two 
> alternatives:
> A. The N2 interface is modified in order to signal a SID list to the gNB.
> B. The N2 interface is not modified. In this case, we signal through the N2 
> interface an SRv6 BindingSID, that the gNB is going to resolve into a SID 
> list via an SDN controller either using PCEP, reverse DNS lookup or LISP.


Maybe you have seen End.B6 defined as L2-anchor function in the section of 
aggregate mode. I think that the current draft doesn’t cover the case of N2 
no-change. But I have to admit that the text need to be more clear to mention 
for that. Any text for it would be really welcome.


>  
> I’m aware that the I-D focuses on the user-plane, however I believe it’s 
> important to state this alternatives since it simplifies the adoption and 
> reduces impact in the existing mobile architectures (without going into the 
> details on the mechanisms for each one of the alternatives of LISP, PCEP, 
> reverse DNS-lookup).

I think that we are on the same page. Deploying srv6 for mobile user-plane 
provides programmability of data-path for not only existing style of mobility 
management, but also any other type of optimization logics from various 
aspects, such as ID-LOC, ETSUN for example.



>  
> ===
>  
> On the other hand, the current I-D proposes a mechanism for stateless 
> interworking with legacy access networks that doesn’t support SRv6 (SGW 
> and/or eNB). This mechanism presented in the I-D is limited to IPv4/GTP 
> legacy networks. I would like to propose a mechanism to support interworking 
> with legacy gNBs that does not support SRv6 but do support IPv6/GTP.
> The main benefit comes from the fact that we can leverage an SRv6 BindingSID 
> to have remote classification and steering of the UE traffic over an SR 
> policy [draft-filsfils-spring-segment-routing-policy].

Yes indeed. IPv6/GTP case should be supported in addition to the IPv4/GTP case.



>  
> In this scenario, I propose that we add the notion of an SR GW -as the 
> current stateless interworking node in the I-D-. This SR GW can be either a 
> software based platform -e.g. VPP- or any existing router -the mechanism is 
> simple and can be supported in existing HW-. This SR GW receives through the 
> control plane the SR policies and installs the required Binding SIDs.
>  
> Then, for any UE connecting to a gNB, the N2 interface is going to signal an 
> IPv6 address and a TEID. However, the difference is that with this new 
> mechanism the IPv6 address that we are going to signal is going to be an SRv6 
> BindingSID instantiated 

Re: [DMM] FPC meetings - Cancelling tomorrow's meeting

[Satoru Matsushima]

Lyle, that sounds good.
What does update the document? Is there anything the call outcomes? Some brief 
minutes would help people to find out the points for the updates.

Cheers,
--satoru

> 2018/02/13 11:00、Bertz, Lyle T [CTO] のメール:
> 
> All,
>  
> I sent out invites for FPC meetings for 1 hour daily at 9 am CST a  few weeks 
> ago.  We are cancelling tomorrow’s meeting so that we can focus on document 
> updates.
>  
> Thanks!
>  
> Lyle
> 
> 
> This e-mail may contain Sprint proprietary information intended for the sole 
> use of the recipient(s). Any use by others is prohibited. If you are not the 
> intended recipient, please contact the sender and delete all copies of the 
> message.
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Satoru Matsushima]

Hello Kalyani,

> [..snip..]

> If you mean SRv6 Mobile Uplane draft, it is already a WG document, not my 
> draft. So I’d collect opinions on this from WG. I’m sorry for that.
> As a co-author of the draft, I’m afraid I disagree. SRv6 Mobile Uplane draft 
> specifies SRv6 functions for mobile user plane, which should be architecture 
> agnostic.
> 
> [KB] Sections 7.2, 7.3 refer to 3GPP terminology like eNB, SGW, PGW. My 
> comment was suggesting that you include 5G terminology and CUPS terminology 
> as well so it is clear how your proposal can be used in various scenarios.
> 

Now I’ve got your point. Thank you.


>> 
>> [KB] I am also still not clear if the blue icons (which I think represent 
>> IP/MPLS nodes) in your slides are included in SRv6 architecture or not.
> 
> I put some text what those icons indicate. Please find them in the slides. 
> The blue icons represent IPv6 or SRv6 node.
> [KB] Seems like the IPv6/SRv6 nodes do not interact with SMF. Is that the 
> intent? 

IPv6/SRv6 nodes interact with SMF but it’s indirect, is my idea.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Satoru Matsushima]

Hello Uma,

> 
> When it comes to service function type UPF, you name it. Following draft 
> exhibits how service chain can be done by SRv6:
> https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00
> 
> [Uma]: I presume this is on N6 interface once de-capsulation is done at 
> eventual UPF.  So can I say this is one more alternative to NSH ??

SRv6 can be a SFP in terms of SFC architecture. SRH is able to bring NSH in a 
TLV. See 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-08#section-3.1.6



>Do you see any relevance of this in any other interface?
> 

I’ve moved it to another thread. I’d like to discuss it in that thread.


>> Also you show IPv6/SRv6 nodes in those slides. Are the UPFs ‘overlaid’ on 
>> IPv6/SRv6 nodes?
>> Are these UPFs VNFs? Or are UPFs implemented on IPv6/SRv6 nodes?
>> 
> 
> When you see UPF specifically it should be controlled by SMF through N4, they 
> are not the UPFs.
> But you might see them as UPFs if a SMF doesn’t control them directly but the 
> SMF can put the sessions to it through some other means.
> 
> [Uma]: Didn't quite understand. Are you referring southbound interface like 
> PCEP here?

It looks same question from Behcet. Let me think just an example, if a SMF sees 
an IPv6 address as an UPF address, is actually an IPv6 segment ID of a TE path 
through several IPv6 routers and links, a southbound could be PCEP but not 
limited. BGP-LS should work to disseminate that segment and FPC may work to 
disclose it to the SMF and the TE path would be attached mobility sessions by 
the SMF as if it is an UPF. 

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Non-mobility functions in Uplane [was Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt]

[Satoru Matsushima]

Kalyani,
# Subject changed.

> 
> Maybe you can see SRv6 mobile uplane as a set of SRv6 functions like a SRv6 
> profile for mobile with some augment.
> 
> When it comes to service function type UPF, you name it. Following draft 
> exhibits how service chain can be done by SRv6:
> [KB] I think these are non-mobility functions as being discussed on the email 
> thread with Marco Liebsch.


I saw that discussion. Non-mobility functions of which deployed on SGi/Gi-LAN 
types can still be considered as functions deployed in N6.
IMO I couldn’t find that assumption in TS23.501. So it would be a clarification 
point whether those type of UP functions can be deployed within mobility 
management data path programmed by SMF utilizing (multiple) N9.

Thought?

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Satoru Matsushima]

Hello Kalyani,

> 
> When you see UPF specifically it should be controlled by SMF through N4, they 
> are not the UPFs.
> But you might see them as UPFs if a SMF doesn’t control them directly but the 
> SMF can put the sessions to it through some other means.
> 3GPP SA2 has studied on that case (ETSUN). We consider how SMF deal with that 
> case and SRv6 may help to solve the issues to it in simpler way.
> Please let me know if you are interested in.
> [KB] is there a TR for ETSUN that I can read?

You can read it later on this September. See 
https://portal.3gpp.org/ngppapp/CreateTdoc.aspx?mode=view=SP-170743


> 
> [KB] I think your document needs to separate out 3 architectures: one for 4G 
> - SGW/PGW; one for 4G - CUPS; and one for 5G - UPF.

If you mean SRv6 Mobile Uplane draft, it is already a WG document, not my 
draft. So I’d collect opinions on this from WG. I’m sorry for that.
As a co-author of the draft, I’m afraid I disagree. SRv6 Mobile Uplane draft 
specifies SRv6 functions for mobile user plane, which should be architecture 
agnostic.


> 
> [KB] I am also still not clear if the blue icons (which I think represent 
> IP/MPLS nodes) in your slides are included in SRv6 architecture or not.

I put some text what those icons indicate. Please find them in the slides. The 
blue icons represent IPv6 or SRv6 node.

Cheers,
--satoru

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Satoru Matsushima]

Hello Kalyani,

> [..snip..]

> Your slides 9 – 13 show interactions between UPFs and SMF. There are 2 kinds 
> of UPFs:
> Anchor type UPF and service function type UPF. What are the functionalities 
> of these?

Please find some functionalities in the SRv6 mobile Uplane draft:
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-00#section-5

When it comes to anchor, it should be equivalent with PSA, PDU Session Anchor, 
in TS23.501 of 3GPP 5G_ph1 terminology.

You would also find various SRv6 functions in the network programming draft:
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-03

Maybe you can see SRv6 mobile uplane as a set of SRv6 functions like a SRv6 
profile for mobile with some augment.

When it comes to service function type UPF, you name it. Following draft 
exhibits how service chain can be done by SRv6:
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00


> What are the changes in SMF functionalities to support SRv6? Is the interface 
> between
> SMF and UPFs based on N4/Sx (PFCP in TS 29.244)?

SMF functionalities seems still work in progress so that I couldn’t say clearly 
what the change to it.
In CUPS architecture for both Rel-14 and Rel-15, PFCP is expected as Sx and N4 
for SRv6 Uplane with no change to over-the-wire messages in basic mode 
operation:
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-00#section-8.1


> Also you show IPv6/SRv6 nodes in those slides. Are the UPFs ‘overlaid’ on 
> IPv6/SRv6 nodes?
> Are these UPFs VNFs? Or are UPFs implemented on IPv6/SRv6 nodes?
>  

When you see UPF specifically it should be controlled by SMF through N4, they 
are not the UPFs.
But you might see them as UPFs if a SMF doesn’t control them directly but the 
SMF can put the sessions to it through some other means.
3GPP SA2 has studied on that case (ETSUN). We consider how SMF deal with that 
case and SRv6 may help to solve the issues to it in simpler way.
Please let me know if you are interested in.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Satoru Matsushima]

Hello Kalyani,

Thank you for your feedbacks. I’ll take it into account.

And yes, slide 6 shows just one deployment scenario. A spreadsheet which I 
shared in my google drive would help to see the rest of scenarios.
Perhaps those would be deployed on somewhere in operators.

Cheers,
--satoru

> 2018/02/06 22:23、Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>のメール:
> 
> Satoru:
>  
> Your slide 6 shows one implementation (other operators may have other 
> implementations).
> Below is the Figure from CT4 TR 29.891. Can you show how your slide 7 impacts 
> this
> end-to-end protocol stack and which interfaces are impacted?
>  
> 
>  
>  
> Your slides 9 – 13 show interactions between UPFs and SMF. There are 2 kinds 
> of UPFs:
> Anchor type UPF and service function type UPF. What are the functionalities 
> of these?
> What are the changes in SMF functionalities to support SRv6? Is the interface 
> between
> SMF and UPFs based on N4/Sx (PFCP in TS 29.244)?
> Also you show IPv6/SRv6 nodes in those slides. Are the UPFs ‘overlaid’ on 
> IPv6/SRv6 nodes?
> Are these UPFs VNFs? Or are UPFs implemented on IPv6/SRv6 nodes?
>  
> It would be beneficial if you can provide clarifications and add a section to 
> your draft.
>  
> Kalyani
>  
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
> Sent: Tuesday, February 6, 2018 2:53 AM
> To: Bogineni, Kalyani <kalyani.bogin...@verizonwireless.com>
> Subject: [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt
>  
> Hello Kalyani,
>  
> >  Do you have a deck that shows 5G architecture, procedures and
> > services for your functions?
>  
> Hope you find it in a tdoc from the following link:
>  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.3gpp.org_ftp_tsg-5Fct_WG4-5Fprotocollars-5Fex-2DCN4_TSGCT4-5F81-5FReno_Docs_C4-2D176177.zip=DwIFAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=v2OzLQOmEladDjJ7cnv7BOUHOIJU3q5_zuGVajrMM6U=vvhsviIu1Hxx94-BJWqR63wLWmlzMdhh_X8op2Xv_y4=
>  
> Cheers,
> --satoru
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Questions about SRv6 mobile user-plane

[Satoru Matsushima]

Hello Tom,

To make the overhead discussion quantitative and realistic, I’ve made a 
spreadsheet of user-plane total overhead comparison by deployment scenarios.


https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing

This includes not only for mobility, but also range of possible cases of real 
deployment in operators to fulfill isolation, quality and reliability 
requirements for mobile networks. Some of them seem most likely cases, but 
others sound extreme. But I’d like to share all those scenarios to make us 
aware of them when it comes to packet overhead in real deployments.

The total overhead length of the scenarios which exceed 2x SIDs (58) and 4x 
SIDs (90) cases are highlighted with red color to the number and the cell 
respectively in the sheet. Please take a look at it. The sheet looks a bit busy 
but you may find some interesting points, or errors. Any comments and 
corrections from all of you are really welcome.

Best regards,
--satoru


> 2018/01/27 2:13、Tom Herbert のメール:
> 
> Hello,
> 
> I am working on a comparison between ILA and SRv6 for the mobile user-plane. 
> I have some questions/comments about SRv6 and particularly on the example use 
> cases that were depicted in the slides that were presented in IETF100:
> 
> https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/
> 
> - It's clear from the depicted use cases that extension header insertion is 
> being done by intermediate nodes, but extension header insertion is currently 
> prohibited by RFC8200. There was an I-D posted on 6man to allow this for SR, 
> but that was met with pushback. Is there going to be followup to resolve this?
> 
> - For the uplink use cases, this seems to be more like using SR to source 
> route to an egress router. In other words, it's not strictly related to 
> mobility. Is there some connection to mobility that I'm missing?
> 
> - The size or number of SR headers in the uplink cases seems to be larger 
> than necessary (IMO minimizing these is important since each additional sid 
> is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and 
> DA=A2::1-- this seems to be redundant information. Also this depicts a second 
> SR being inserted, but the first one should no longer be relevant. Why not 
> just discard the first one and save the overhead? In the second scenario, DA 
> is changing from A2::1 to A3::1, but AFAICT that was not done per the SR 
> processing. What is the operation that happened here? (it's actaully looks 
> like an ILA transfomation).
> 
> - Considering the points above, could this have been done in the following 
> manner to minimize overhead? A1 creates one SRH with one sid and makes DA=A2. 
> A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet address, 
> and EH is removed.
> 
> - For downlink this does see to be relevant to mobility. But I have the same 
> question, wouldn't it be less overhead to only use one SRH and one sid? i.e. 
> A3 creates an SRH with just one sid that is the S:: (identifier in 
> identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 
> restores original packet for delivery.
> 
> - One possible typo. In the last use case slide SA=S:: and DA=D::, I believe 
> these should be swapped?
> 
> Thanks,
> Tom
> 
>  
> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] white paper for optimized mobile user plane solutions for 5G

[Satoru Matsushima]

Hello Kalyani,

+1. White paper looks a good work to start the user-plane study here in IETF. I 
support it.

I think that comparison with quantitive measurements may need to use specific 
deployment metrics in each operator.

But through this white paper work, if we figure out clear criteria for 
apple-to-apple comparison to candidate protocols for 3GPP use cases, that would 
be greatly help to move the study forward.

Hope that make sense and work with you on it.

Cheers,
--satoru

> 2017/12/14 6:13、Bogineni, Kalyani のメール:
> 
> Folks:
>  
> In response to the 3GPP CT4 study item on user plane protocols, we propose 
> that a white paper
> be developed that can compare the different IETF protocols. Attached is an 
> outline. Please let me
> know if you would like to contribute. 
>  
> Kalyani Bogineni
> Verizon
>  
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Satoru Matsushima]

Lyle, sorry for my late response. 

> [...]

> Type of the accompanying value.

Ah, okay.



>  There was a line continuation that made reading it awkward in some e-mail 
> clients.
> 
> In Descriptors it is the type of Descriptor Value
>>Descriptor-Id = 22
>>Descriptor-Type = IPFilterRule 
>>Descriptor-Value = in ip from any to assigned 22
> In Actions it is the type of Action Value

It sounds reasonable for me, define a type of value instead of a concrete 
value. 
So do we agree to change “Descriptor/Action-Value” to 
“Descriptor/Action-Value-Type” in Descriptor/Action-Definition set?


> 
> However, we gave an Action Type (Drop) where the value is unnecessary.  The 
> same would be for the type 'Permit'.  In other standards we use a boolean 
> value 'Gate' (True=Drop; False=Permit).

I think so too.

cheers,
--satoru


> 
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Tuesday, November 28, 2017 7:32 PM
> To: Moses, Danny <danny.mo...@intel.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
> 
> Now I seems I’m confused when I see what does the type define.
> 
> Does the type define type of value, or type of action/descritor?
> 
> Cheers,
> --satoru
> 
>> 2017/11/28 14:11、Moses, Danny <danny.mo...@intel.com>のメール:
>> 
>> I am OK with the current structure.
>> 
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
>> Sent: Tuesday, November 28, 2017 23:45
>> To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; dmm@ietf.org
>> Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
>> 
>> So, then I don’t see the point of changing the current structure. Other 
>> opinions?
>> 
>> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
>> Sent: Dienstag, 28. November 2017 19:42
>> To: Marco Liebsch; dmm@ietf.org
>> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>> 
>> I intentionally left out my opinion from the analysis.  I am against both as 
>> the reusability for a value of a Descriptor/Action (especially descriptor) 
>> does not meet the define once, use many objective for Descriptors.  The 
>> define once, use many for Rule re-use is already present in Policy.
>> 
>> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
>> Sent: Tuesday, November 28, 2017 9:54 AM
>> To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; dmm@ietf.org
>> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>> 
>> Hi Lyle,
>> 
>> I see the analysis you brought, thanks for that. My proposal #2 is not 
>> my preference as it was only an attempt to extend and match what 
>> Satoru had in mind without losing the value in current 
>> descriptors/actions. Maybe it did not help ;-)
>> 
>> I just see that an action value belongs to an actions type. Clearly 
>> there are types which don’t require a value, e.g. drop. Here value is void 
>> and re-usability is ensured, IMO.
>> But moving the value entirely out of action / descriptor I just saw 
>> shortcomings.
>> 
>> So, you brought examples and arguments against proposal #1 and proposal #2.
>> But I could not conclude if there are any preferences or alternative? Do we 
>> leave it as it is now?
>> 
>> marco
>> 
>> 
>> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
>> Sent: Montag, 20. November 2017 15:15
>> To: Marco Liebsch; dmm@ietf.org
>> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>> 
>> Marco,
>> 
>> Thank you for the write up of both proposals.  Forgive the length of the 
>> response but I wanted to provide concrete examples based upon the existing 
>> data types.
>> 
>> Summary, see below for examples and details:
>> -  Satoru’s Proposal (Proposal 1) - the use of only ID/Type could be 
>> replaced by making the Type a U-Key (similar to a registry or identity in 
>> YANG). In any arrangement though only the Type could be use.  The downside 
>> for Proposal 1 is reusability.  
>> -  Marco’s Proposal (Proposal 2) - To make sense the setting MUST 
>> not be in any of the existing Settings, i.e. it is a setting that MUST NOT 
>> be tied to the Mobility-Context, DPN Interface or the fact that a DPN was 
>> assigned to enforce a Rule.  Does such an example exist?
>> 
>>>>>>>>>>>> My Opinion <<<<<<<<<<<<<
>> 
>> I would not pursue Propos

Re: [DMM] review comments on draft-ietf-dmm-srv6-mobile-uplane-00

[Satoru Matsushima]

Hi Ebisawa-san,

Thank you for your review. That’s helpful. Please see my comments in line:

> [...]

> ## Comments to Stateless Interworking
> 
> In general, I thought 5.4 and 6.3 could be combined or be more closer.
> I think organization of the document would be changed a lot from various 
> feedback so just my 2 cents at this point.

My intention was at first to introduce all user-plane functions followed by use 
cases.
There’s space to improve document structure which I agree. 


> 
> > 5.4.1. End.TM:
> >
> > 1. IF NH=SRH & SL > 0 THEN
> > 2. decrement SL
> > 3. update the IPv6 DA with SRH[SL]
> > 4. push header of TUN-PROTO with tunnel ID from S ;; Ref1
> > 5. push outer IPv4 header with SA, DA from S
> > 6. ELSE
> > 7. Drop the packet
> 
> 5.4.1 doesn't mention about PSP (pop SRH from packet) which is described in 
> 6.3.2.
> Do you expect any case where PSP would not happen for End.TM operation?
> If so, that means End.TM would be used in other situation than described in 
> 6.3.2, so might be more clear if you can describe that case as well.

Right. I agree that PSP should be expected in this case. Thanks.


> 
> > 5.4.2. T.Tmap: Transit behavior with tunnel decapsulation and mapping
> >
> > 4. insert the SRH (D, B; SL=1) ;; Ref2, Ref2bis
> 
> I assume D is end point node on public internet.
> Since it's not defined, adding description what is D might make it more clear.
> 
> > 6.3.2 Downlink: SRv6 to Legacy Access
> > ...
> > SID is bound to the next segment of S::1 , the L3-anchor node
> > does T.Insert process for the receiving packet to push a SRH
> > with SID list  with SL=1, where "B2" which encodes
> 
> Maybe  should be  Since B2 is Stateless Interworking 
> SID Encoding and not prefix?

Yes, correct. I’ll do fix it with appropriate diagram which Charlie pointed out.

> 
> 
> > The stateless interworking node of "B2" End.TM process for the
> > receiving packet according to the SRH. The node decrement SL
> > to 0, updates DA to "D::1" which the SL indicates, push IPv4
> > and tunnel headers with IPv4 DA, SA and TUN-ID extracted from
> > "B2", and forward the packet to the legacy network.
> 
> Since this is DL, shouldn't DA be "S::1" (MN) ?
> My understanding is SA for DL is always D::1 which would not change while 
> travelling from L3 Anchor to B2.

Yes, you’re right. Will fix it as well.

> 
> 
> > 6.3.2. Downlink: SRv6 to Legacy Access
> >
> > In case of an L2-anchor node receives a packet destine to SID
> > "A2::B2" and the SID is bound to "B2", the L2-anchor node does
> > End.B6 process for the receiving packet as same as previous
> > section. The node updates DA to B2 and forward the packet.
> 
> I could not find description of case when L3-anchor add A2::B2 as DA.
> Might be more clear if you can describe the format of A2::B2 and how to 
> generate B2 from A2::B2.

It doesn’t intend that A2::B2 derives B2 but in this case where an L2-anchor 
exists in between L3-anchor and stateless interworking functions, the L2-anchor 
binds A2::B2 to B2. I think that some diagram and clear notation would help to 
describe it.


> 
> 
> Also, it might be nice if you have matrix like below for 6.3 as similar to 
> the ones you have in 6.1 and 6.2.
> 
> +-++--+
> | User-plane Function | Uplink | Downlink |
> +-++--+
> | stateless interworking node | T.Tmap | End.TM |
> | L2-anchor | End.B6 | End.B6 |
> | L3-anchor | End.T | T.Insert |
> +-++--+
> 
> 

Yes, I agree. 

Following generic comments will also be taken into account in a next version. 
Thanks.

Cheers,
--satoru


> ## General Comments (not limited to stateless interworking)
> 
> 1. Might overlap with comments from Charlie, but I also thought it was 
> difficult to find out where in the network S1, C1, A2::1, D::1, A1::1 etc. 
> resides.
> Diagram of overall network including above addresses with list of node each 
> address corresponds would be helpful.
> 
> 
> 2. Any reason Access Point UL and L3-anchor DL only use T.Insert and not 
> T.Encap?
> Looks like it was intentionally removed in 
> draft-matsushima-spring-dmm-srv6-mobile-uplane-02, so sorry if it was already 
> discussed and clarified.
> If there are any issue between Access Point and L3-anchor which router reply 
> ICMP, it would be destined to MN or End Point on public internet.
> Since ICMP payload would have SRH which includes mobile network's 
> information, I was not sure if this is accepted for all operators.
> 
> 
> 3. It might be more clear to mention  is a SID list where S1 is 
> the first SID to visit and S3 is the last.
> (Although it is mentioned in SRv6 Network Programming draft)
> 
> 
> Thanks,
> --
> Kentaro Ebisawa @ Ponto Networks, Inc.
> Work:  | Mailing Lists: 
> 

___
dmm mailing list
dmm@ietf.org

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Satoru Matsushima]

DMM WG chairs,

> Authors:
> 
> Please submit, "draft-matsushima-spring-dmm-srv6-mobile-uplane-03" as 
> "draft-ietf-dmm-srv6-mobile-uplane-00” with exactly one change reflecting 
> Charlie as a co-author.
> 

I’ve just submitted it as “draft-ietf-dmm-srv6-mobile-uplane-00”. Please check 
it out.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Some review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-03

[Satoru Matsushima]

Thank you Charlie, for your comments.


> [...]

> As I mentioned in previous email to this mailing list, I think it is 
> important to describe previous efforts to provide a source-routing solution 
> for mobility management, and to suggest reasons why the SRv6 approach will 
> find success despite the difficulties encountered by earlier efforts.
> 
> Much of the flexibility and power of the mechanism derives from the assumed 
> existence of SRv6-capable routing nodes in the packet core, or at minimum at 
> the edges of the core.  This is a reasonable assumption, but it diverges a 
> bit from previous architectural guidelines by which we had attempted to 
> minimize the mobility design impact on existing networks.  I hope that we can 
> get some ideas about why such a new design philosophy is more appropriate now 
> than in previous years.

I at least know that source routing isn’t new technique. RSVP, MPLS with 
RSVP/CR-LDP and routing header in IPv6. Many of them were developed from 20+ 
years ago.
We can see one successful deployment of source routing is MPLS traffic 
engineering. But yes I couldn’t see it in mobility management. I don’t know why 
but you may know it. So please tell me what the difference. I can expect that 
source routing in end-to-end basis would be rejected by operators for some 
reasons. But both MPLS and network based mobility management are not in 
end-to-end source routing. I couldn’t understand the difference for the reason 
of the success and the fail. 


> 
> This document naturally relies on existing SRv6 documents for terminology and 
> understanding of the SRv6 operations.  In particular, reference is made to 
> [I-D.filsfils-spring-srv6-network-programming], which is a nontrivial 
> document to read.  I think it would be very nice if most of the terminology 
> were explained in at least some detail within the mobile-uplane document in 
> order to enable better progress within the [dmm] group.  Perhaps a lot of 
> people in this group have not read the SRv6 documents in any great detail, at 
> least not up to this point in time.

You’re right. As I mentioned in the meeting in Singapore, I’d seek more better 
way to explain SRv6 in mobile. So far I had followed the notion of SRv6 
illustration in the network programming draft. Borrowing some text in the 
network-programming draft would be an easy way.


> 
> As a general comment, I found it confusing about whether "legacy" means IPv4, 
> or "non-SRv6" IPv6.  For instance, I am not sure about whether "D::1" is IPv4 
> or IPv6 in the first paragraph of section 6.3.1.  As a related matter, I 
> think that relying solely on terminology like S::1, D::1, A2::1, A2::B2, and 
> so on soon becomes confusing.  More diagrams would be nice.

Those represent 128bits of IPv6 source address, destination address and segment 
IDs. I suppose that the reader in the IETF can understand that. If not, yes 
need to improve it that introduce diagrams looks a good idea.

> 
> The document states:
> 
>>Existing mobile user-plane with IPv6 underlay is expected to be
>>widely deployed.  Since IPv6 network should be interoperable with SRv6
>>endpoints accommodated on it, interworking with existing IPv6
>>network is out of scope of this document.
> 
> If I understand this correctly, it would be better to say that further 
> specification is not needed for interworking with existing IPv6 networks.  
> That's different than saying the interworking mechanism is out of scope.  And 
> yet perhaps there is anyway something to say about whether firewalls would 
> pass dataplane traffic carrying SRH (or why that doesn't matter).

Correct. Thank you.
Though I put the sentence of “IPv6 underlay is expected to be widely deployed.” 
But actually I didn’t see any of the case where IPv6 network as mobile 
user-plane transport layer. If someone know that, please let me know btw.


> The following claim needs a citation, I think:
> 
>> Mobile user-plane requires a rate-limit feature.
> 
> Previous work in [dmm] and earlier mobility management working groups in the 
> IETF have not placed this constraint in general for dataplane traffic.  Even 
> for control plane traffic, mechanisms for rate limitation have not been 
> designed very often.

FPC has integrated that function into the model I think.


> 
> Regarding the mechanism in the draft for rate limiting:
> 
>>In case of j bit length is zero in SID, the node should not do rate
>>limiting unless static configuration or control-plane sets the limit
>>rate associated to the SID.
> 
> It should also be allowed that rate limiting is not done when there has not 
> been any such rate-limit Locator provided.

Correct. But it seems too obvious for me.

> 
> The mobile-uplane document goes into some depth to explain how interworking 
> and anchoring work.  To do this, there are various examples with specific 
> (example) addresses and named nodes. However, it is very important that the 
> mobile 

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Satoru Matsushima]

Now I seems I’m confused when I see what does the type define.

Does the type define type of value, or type of action/descritor?

Cheers,
--satoru

> 2017/11/28 14:11、Moses, Danny のメール:
> 
> I am OK with the current structure.
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
> Sent: Tuesday, November 28, 2017 23:45
> To: Bertz, Lyle T [CTO] ; dmm@ietf.org
> Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule
>  
> So, then I don’t see the point of changing the current structure. Other 
> opinions?
>  
> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com] 
> Sent: Dienstag, 28. November 2017 19:42
> To: Marco Liebsch; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> I intentionally left out my opinion from the analysis.  I am against both as 
> the reusability for a value of a Descriptor/Action (especially descriptor) 
> does not meet the define once, use many objective for Descriptors.  The 
> define once, use many for Rule re-use is already present in Policy.
>  
> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu] 
> Sent: Tuesday, November 28, 2017 9:54 AM
> To: Bertz, Lyle T [CTO] ; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> Hi Lyle,
> 
> I see the analysis you brought, thanks for that. My proposal #2 is not my 
> preference as it was
> only an attempt to extend and match what Satoru had in mind without losing 
> the value in current
> descriptors/actions. Maybe it did not help ;-)
>  
> I just see that an action value belongs to an actions type. Clearly there are 
> types which don’t require
> a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
> But moving the value entirely out of action / descriptor I just saw 
> shortcomings.
>  
> So, you brought examples and arguments against proposal #1 and proposal #2.
> But I could not conclude if there are any preferences or alternative? Do we 
> leave it as it is now?
>  
> marco
>  
>  
> From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com] 
> Sent: Montag, 20. November 2017 15:15
> To: Marco Liebsch; dmm@ietf.org
> Subject: RE: FPC: Move Descriptor-/Action-Value into Rule
>  
> Marco,
>  
> Thank you for the write up of both proposals.  Forgive the length of the 
> response but I wanted to provide concrete examples based upon the existing 
> data types.
>  
> Summary, see below for examples and details:
> -  Satoru’s Proposal (Proposal 1) - the use of only ID/Type could be 
> replaced by making the Type a U-Key (similar to a registry or identity in 
> YANG). In any arrangement though only the Type could be use.  The downside 
> for Proposal 1 is reusability.  
> -  Marco’s Proposal (Proposal 2) - To make sense the setting MUST not 
> be in any of the existing Settings, i.e. it is a setting that MUST NOT be 
> tied to the Mobility-Context, DPN Interface or the fact that a DPN was 
> assigned to enforce a Rule.  Does such an example exist?
>  
> >> My Opinion <
>  
> I would not pursue Proposal 1 due to the loss of reusability which is a key 
> benefit of entities under the Policy Model.
> I would not pursue Proposal 2 if we cannot find clear examples that the 
> settings can be placed in other settings locations.  I cannot think of an 
> example at this time but I am just one person and hope the team can provide 
> such examples.
>  
> Lyle
>  
> >> Detail <<<
>  
>  
> Let’s take a step back.   Consider the IPFilterRule (RFC 6733) to block 
> inbound port 22 traffic (even from itself)
> “deny in ip from any to assigned 22”
>  
> Recall that from 6733, “The keyword "assigned" is the address or set of 
> addresses assigned to the terminal.”
>  
> If I use a ‘IPFilterRule’ Descriptor Type (it is not in the spec; I am making 
> up a new type here) and provide a value of descriptor “in ip from any to 
> assigned 22”  you will note the only Setting to deal with here is ‘assigned’.
>  
> In Satoru’s proposal, we will call it Proposal 1, we could see a Descriptor 
> example as
> Descriptor-Definition
> Descriptor-Id = 22
> Descriptor-Type = IPFilterRule
> Action-Definition
> Action-Id = 11
> Action-Type = deny (or drop)
> Rule-Definition 
> Rule-Id = 21231
> Descriptor-Match-Type = AND
> Descriptor-Reference
> Descriptor-Id-Reference = 22
> Descriptor-Value = in ip from any to assigned 22
> Action-Reference
> Action-Id-Reference = 11
>  
> We see the tradeoffs clearly in this example, when the value is directly 
> determined by the type as in the deny Action-Type, the Action Reference is 
> quite small.  In the case of the Descriptor we see the value is still 
> incomplete and the setting ‘assigned’ is applied.
>  
> For Marco’s 

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Satoru Matsushima]

I support the adoption as a co-author.

Cheers,
--satoru


> 2017/11/14 16:02、Sri Gundavelli (sgundave) のメール:
> 
> Folks:
> 
> The following message commences a two week call for opinions on the adoption 
> of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a DMM Working 
> document. 
> 
> ---
> The DMM working group is considering adopting the draft, 
> "draft-matsushima-spring-dmm-srv6-mobile-uplane-03” as a working group 
> document. The chairs have polled the room for opinions during IETF100, and it 
> was determined that there is good support for taking up this work. The chairs 
> would like to confirm the same in the mailing list.  Please provide your 
> feedback.
>   
> 
> Document Link:
> https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplane-03.txt
> 
> Slides:
> https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/
> 
> Background:
> https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mobile-data-plane-evolution-motivation-goals/
> ---
> 
> Regards
> Dapping & Sri
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

[Satoru Matsushima]

Thank you Marco for capturing my proposal.

My intention is that the agent should define descriptor/action-definition 
without concrete value so that rules can use them and the rules can define 
concrete values.
Otherwise the agent should define descriptor/action-definitions for each rules 
which seems no make sense to me.

So descriptor and action instantiation with concrete value should be defined in 
Rule definition subtree. So deleting Descriptor-Value from 
Descriptor-Definition subtree, deleting Action-Value from Action-Definition 
subtree and move them under Descriptor-Reference and Action-Reference 
respectively, is my proposal.

If you think it seems weird that reference tree has not just reference, I’d 
propose like following:

OLD:
  +-[Policy]
  |  +-[Policy-Definition] 
  |  | +-[Policy-Id]  (M)
  |  | +-[Rule-Reference] Set (M)
  |  | +-[Precedence]  (M)
  |  | +-[Rule-Id-Reference] (M)
  |  +-[Rule-Definition] 
  |  | +-[Rule-Id]  (M)
  |  | +-[Descriptor-Match-Type] (M)
  |  | +-[Descriptor-Reference] 
  |  | |+-[Descriptor-Id-Reference]
  |  | |+-[Direction] (O)
  |  | +-[Action-Reference] 
  |  |  +-[Action-Id-Reference]
  |  |  +-[Action-Order]
  |  +-[Descriptor-Definition] 
  |  | +-[Descriptor -Id]  (M)
  |  | +-[Descriptor-Type]
  |  | +-[Descriptor-Value]
  |  +-[Action-Definition] 
  |+-[Action-Id]  (M)
  |+-[Action-Type]
  |+-[Action-Value]
  |

NEW:
  +-[Policy]
  |  +-[Policy-Definition] 
  |  | +-[Policy-Id]  (M)
  |  | +-[Rule-Reference] Set (M)
  |  | +-[Precedence]  (M)
  |  | +-[Rule-Id-Reference] (M)
  |  +-[Rule-Definition] 
  |  | +-[Rule-Id]  (M)
  |  | +-[Descriptor-Match-Type] (M)
  |  | +-[Descriptor-Instance] 
  |  | |+-[Descriptor-Id-Reference]
  |  | |+-[Descriptor-Value]
  |  | |+-[Direction] (O)
  |  | +-[Action-Instance] 
  |  |  +-[Action-Id-Reference]
  |  |  +-[Action-Order]
  |  |  +-[Action-Value]
  |  +-[Descriptor-Definition] 
  |  | +-[Descriptor -Id]  (M)
  |  | +-[Descriptor-Type]
  |  +-[Action-Definition] 
  |+-[Action-Id]  (M)
  |+-[Action-Type]
  |

Cheers,
--satoru

> 2017/11/17 0:41、Marco Liebsch のメール:
> 
> Another proposal: 
> To not disrupt descriptors and actions by removing attributes that belong 
> together (ID-Type-Value), what about keeping the current format and apply a 
> new attribute 'x-value-settings' to Descriptor-Reference and Action-Reference 
> respectively?
> This should follow define once- use many paradigm.
>  
> Ending up in this:
>  
>   +-[Policy]
>   |  +-[Policy-Definition] 
>   |  | +-[Policy-Id]  (M)
>   |  | +-[Rule-Reference] Set (M)
>   |  | +-[Precedence]  (M)
>   |  | +-[Rule-Id-Reference] (M)
>   |  +-[Rule-Definition] 
>   |  | +-[Rule-Id]  (M)
>   |  | +-[Descriptor-Match-Type] (M)
>   |  | +-[Descriptor-Reference] 
>   |  | |+-[Descriptor-Id-Reference]
>   |  | |+-[Direction] (O)
>   |  | |+-[Descriptor-Value-Settings] (O)
>   |  | +-[Action-Reference] 
>   |  |  +-[Action-Id-Reference]
>   |  |  +-[Action-Order]
>   |  |  +-[Action-Value-Settings] (O)
>   |  +-[Descriptor-Definition] 
>   |  | +-[Descriptor -Id]  (M)
>   |  | +-[Descriptor-Type]
>   |  | +-[Descriptor-Value]
>   |  +-[Action-Definition] 
>   |+-[Action-Id]  (M)
>   |+-[Action-Type]
>   |+-[Action-Value]
>  
>  
> marco
>  
>  
>  
>  
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
> Sent: Donnerstag, 16. November 2017 16:33
> To: dmm@ietf.org
> Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule
>  
> Proposal from Satoru: Move Action-Value to 
> [Rule-Definition]->[Action-Reference]. Same 

Re: [DMM] Meeting Minutes from DMM Meeting@IETF100

[Satoru Matsushima]

Hi, thank you Danny and for the minute.

Please correct the minute for:

> Dave (Ericsson): was that presented in spring

-> Satoru: Not yet.


FYI I had a chat with spring chairs to share what's going on with SRv6.
Maybe I’d request sprint chairs a slot to present SRv6 Mobile UPlane in next 
IETF London.

Best regards,
--satoru





> 2017/11/15 6:05、Sri Gundavelli (sgundave) のメール:
> 
> Thanks to Danny Moses for capturing the meeting minutes.
> 
> Please review and suggest any edits.
> 
> https://datatracker.ietf.org/meeting/100/materials/minutes-100-dmm/
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP

[Satoru Matsushima]

Yes, a 128bits ID or a set of 128bits IDs (at least a pair of IPv6 SA and DA) 
looks sufficient. 
5-tuple usually means transport layer IDs which beyond the IPv6 standard 
headers but of course it could be a filter condition bound to what a 128bits ID 
represents.
--satoru



> 2017/11/15 21:35、Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>のメール:
> 
> Am I understanding that the hypothesis is that a 128 bit space (ID) is 
> sufficient to represent what is required in the packet to meet current and 
> planned mobility related use cases when coupled with the rest of the IPv6 
> standard header information (5-tuple)?
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Tuesday, November 14, 2017 8:54 PM
> To: Charlie Perkins <charles.perk...@earthlink.net>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 
> 3GPP
> 
> Hell Charlie,
> 
> First, of course it’s ok to forward and thank you for sharing it for DMM list.
> 
> Yes, I think that many operators have met various requirements for networks 
> which are supporting mobile user-plane nowadays.
> 
> My understanding is that mobility management itself is a bit complicated 
> system so that it is important that keep it simple as much as possible in 
> terms of mobility management. So other features should be isolated or 
> modulated as an independent pluggable feature into the system. I can see that 
> concept in current cellular mobile systems and also in the Rel-15 
> control-plane SBA which indicates that concept more explicitly IMO.
> 
> But when we see the user-plane, modulated concept that features in addition 
> to mobility management have decoupled horizontally to deploy in where like 
> Gi-LAN, and vertically decoupled in underlying layers, like VPWS/VPLS on top 
> of pseudo-wires and MPLS TE(TP)-LSPs. You can see them in the E-Line/E-LAN 
> spec in MEF to provide backhaul connectivity services for MNOs. So, the 
> outcome in the user-plane has been well complicated as you find in the 
> picture.
> 
> I’ve learned that even the control-plane protocols and functions are 
> modulated to keep mobility management simple, almost those actual services 
> are implemented in the data-plane network(s). Otherwise, those are useless. 
> IMO to simplify whole data-plane while mobility management still be simple 
> (ironic?), mobile user-plane need to be capable to integrate rest of 
> data-plane roles into it.
> 
> # I use the term ‘data-plane’ here in more generic while ‘user-plane’ means 
> mobility tunnel specifically.
> 
> Actually there's rest of the story of that picture. If we have plenty ID 
> space in one single data-plane layer to represent all required feature 
> including mobility, there’s no need to employ additional layers and 
> horizontally decoupling. This is my background thought for the SRv6 mobile 
> user-plane I-D. SRv6 is able to represent network functions as an 128bits ID 
> or a set of IDs. So it enable us to simplify the data-plane by integrating 
> all required functions into one IPv6 layer.
> 
> IMO What specific functions are required is not argument here, what 
> integration mechanism we really need for our solution would be a trigger we 
> embark. Of course I believe that it is SRv6.
> 
> Cheers,
> --satoru
> 
> 
> 
>> 2017/11/15 8:43、Charlie Perkins <charles.perk...@earthlink.net>のメール:
>> 
>> Hello folks,
>> 
>> I stumbled across this terrific diagram from email that was sent by 
>> Satoru-san yesterday.  I think it's an indication that current operators are 
>> not really asking for a simplified data plane.  Or, at least, that we really 
>> need to understand under what conditions they would accept an IETF-designed 
>> simplified data plane before embarking on a solution for their needs.
>> Regards,
>> Charlie P.
>> PS. I hope it is O.K. to forward this email...
>> 
>> ==
>> 
>> Alex,
>> 
>> 
>> Please take a look at the attached picture which one of the realities 
>> happened in some operator.
>> 
>> Cheers,
>> --satoru
>> 
>> 
>> 
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm=02%7C01%7Clyle.t.bertz%40sprint.com%7C728da357ddeb487c7caf08d52bd4d0ef%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636463115399812002=KbYQ%2FXFUxLZunyxYZl7wPLt%2FHvlIr8cejIUPWJqPZ%2BQ%3D=0
> 
> ___
&

Re: [DMM] [5gangip] To initiate user-plane study work in 3GPP

[Satoru Matsushima]

Ouch, s/Hell/Hello/; Sorry for that rude typo...

> 2017/11/15 10:54、Satoru Matsushima <satoru.matsush...@gmail.com>のメール:
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: Re: [5gangip] To initiate user-plane study work in 3GPP

[Satoru Matsushima]

Hell Charlie,

First, of course it’s ok to forward and thank you for sharing it for DMM list.

Yes, I think that many operators have met various requirements for networks 
which are supporting mobile user-plane nowadays.

My understanding is that mobility management itself is a bit complicated system 
so that it is important that keep it simple as much as possible in terms of 
mobility management. So other features should be isolated or modulated as an 
independent pluggable feature into the system. I can see that concept in 
current cellular mobile systems and also in the Rel-15 control-plane SBA which 
indicates that concept more explicitly IMO.

But when we see the user-plane, modulated concept that features in addition to 
mobility management have decoupled horizontally to deploy in where like Gi-LAN, 
and vertically decoupled in underlying layers, like VPWS/VPLS on top of 
pseudo-wires and MPLS TE(TP)-LSPs. You can see them in the E-Line/E-LAN spec in 
MEF to provide backhaul connectivity services for MNOs. So, the outcome in the 
user-plane has been well complicated as you find in the picture.

I’ve learned that even the control-plane protocols and functions are modulated 
to keep mobility management simple, almost those actual services are 
implemented in the data-plane network(s). Otherwise, those are useless. IMO to 
simplify whole data-plane while mobility management still be simple (ironic?), 
mobile user-plane need to be capable to integrate rest of data-plane roles into 
it.

# I use the term ‘data-plane’ here in more generic while ‘user-plane’ means 
mobility tunnel specifically. 

Actually there's rest of the story of that picture. If we have plenty ID space 
in one single data-plane layer to represent all required feature including 
mobility, there’s no need to employ additional layers and horizontally 
decoupling. This is my background thought for the SRv6 mobile user-plane I-D. 
SRv6 is able to represent network functions as an 128bits ID or a set of IDs. 
So it enable us to simplify the data-plane by integrating all required 
functions into one IPv6 layer.

IMO What specific functions are required is not argument here, what integration 
mechanism we really need for our solution would be a trigger we embark. Of 
course I believe that it is SRv6.

Cheers,
--satoru



> 2017/11/15 8:43、Charlie Perkins のメール:
> 
> Hello folks,
> 
> I stumbled across this terrific diagram from email that was sent by 
> Satoru-san yesterday.  I think it's an indication that current operators are 
> not really asking for a simplified data plane.  Or, at least, that we really 
> need to understand under what conditions they would accept an IETF-designed 
> simplified data plane before embarking on a solution for their needs.
> Regards,
> Charlie P.
> PS. I hope it is O.K. to forward this email...
> 
> ==
> 
> Alex,
> 
> 
> Please take a look at the attached picture which one of the realities 
> happened in some operator.
> 
> Cheers,
> --satoru
> 
> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-02

[Satoru Matsushima]

Oh I’ve just noticed that you are referring -02 version. But the latest version 
is -03.
Please find it from following link:

https://tools.ietf.org/html/draft-matsushima-spring-dmm-srv6-mobile-uplane-03

You can find much more about how stateless interworking works and its benefits.
Control-plane consideration has also been described well than -02 version.

Cheers,
--satoru


> 2017/11/13 20:14、Satoru Matsushima <satoru.matsush...@gmail.com>のメール:
> 
> Thank you Sri, for your review.
> 
>> 1.) It will be useful to identify the key data plane features used today in 
>> conjunction with the tunnel based approach and how those features are 
>> impacted when using SRv6 user plane. 
> 
> Sure. But I’d just cite existing document which well described current 
> approach. It would be sfc for mobile document as one of them:
> 
> https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility
> 
> But I couldn’t find tunneled path optimization and service chaining. So it 
> seems to be explained in our I-D, do you think so?
> 
> 
>> 2.) There are heartbeat protocols that is used for path check between the 
>> access and anchor.
> 
> Ok, that would be an OAM feature like ICMPv6 in SRv6. Will try to mention it.
> 
> 
>> Assuming those mechanisms are still in use between the access and anchor, I 
>> am wondering how these failure events impact the SRv6 states? For exam   
>> 3.) Discussion on definition of new SRv6 functions needed to support this 
>> architecture will help
> 
> Right. Those are End.TM and T.Tmap introduced for stateless interworking 
> between existing user-plane and SRv6 user-plane. Why “statless” is that not 
> to affect existing c-plane and to avoid more mobile state aware entities 
> because one of DMM purposes is to get rid out of mobile state from DPNs as I 
> understand.
> 
> 
>> 4.) It will be good if this document sets the overall context, allowing 
>> additional drafts to focus on specific aspects.
> 
> Yes, while the revise work I found that at least IPv4 support would be good 
> to explain in an additional draft. But in terms of overall context, it would 
> be nice if we can have another document to explain that overall context in 
> addition to this draft because it mentions specific solution already. I think 
> I can help to work on that generic document in case some volunteers we can 
> involve.
> 
> I’ll get back to following your comments on specific part of the draft.
> 
> Cheers,
> --satoru
> 
> 
> 
>> 
>> Please see inline for additional comments.
>> 
>> -
>>   Segment Routing IPv6 for Mobile User-Plane
>>   draft-matsushima-spring-dmm-srv6-mobile-uplane-02
>> 
>> Abstract
>> 
>>   This document discusses the applicability of SRv6 (Segment Routing
>>   IPv6) to user-plane of mobile networks that SRv6 source routing
>>   capability with its programmability can fulfill the user-plane
>>   functions, such as access and anchor functions.  It takes advantage
>>   of underlying layer awareness and flexibility to deploy user-plane
>>   functions that enables optimizing data-path for applications.
>>   Network slicing and an interworking way between SRv6 and existing
>>   mobile user-plane are also discussed in this document.
>> 
>> Status of This Memo
>> 
>>   This Internet-Draft is submitted in full conformance with the
>>   provisions of BCP 78 and BCP 79.
>> 
>>   Internet-Drafts are working documents of the Internet Engineering
>>   Task Force (IETF).  Note that other groups may also distribute
>>   working documents as Internet-Drafts.  The list of current Internet-
>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>> 
>>   Internet-Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time.  It is inappropriate to use Internet-Drafts as reference
>>   material or to cite them other than as "work in progress."
>> 
>>   This Internet-Draft will expire on May 3, 2018.
>> 
>> Copyright Notice
>> 
>>   Copyright (c) 2017 IETF Trust and the persons identified as the
>>   document authors.  All rights reserved.
>> 
>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>   Provisions Relating to IETF Documents
>> 
>> 
>> 
>> Matsushima, et al. Expires May 3, 2018  [Page 1]
>> Internet-Draft SRv6-mobile-uplane   October 2017
>> 
>> 
>>   (http://tru

Re: [DMM] Review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-02

[Satoru Matsushima]

>limiting unless static configuration or control-plane sets the limit
>rate associated to the SID.
> 
> 
> [Sri] In addition to Rate Limiting, probably few other QoS elements have to 
> supported here.
> 
> 
> 
> 
> Matsushima, et al. Expires May 3, 2018 [Page 10]
> Internet-Draft SRv6-mobile-uplane   October 2017
> 
> 
> 7.  Network Slicing Considerations
> 
>Mobile network may be required to create a network slicing that
>represent a set of network resources and isolate those resource from
>other slices.  User-plane functions represented as SRv6 segments
>would be part of a slice.
> 
>To represent a set of user-plane function segments for a slice,
>sharing same prefix through those SIDs within the slice could be a
>straightforward way.  SIDs in a network slice may include other type
>of functions in addition to the mobile user-plane functions described
>in this document, and underlay integration to meet SLA and quality
>requirements.
> 
>While network slicing has been discussed in the IETF and other
>standardization bodies, what functionalities are required for network
>slicing in mobile user-plane is further study item and to be
>discussed.
> 
> 
> [Sri] I am not sure if slicing discussion is relevant here
> 
> 8.  Control Plane Considerations
> 
>Mobile control-plane entities must allocate SIDs to user-plane
>function segments in case of those entities are distributed to
>accommodate in the SRv6 nodes, or those are separated from the
>endpoint but each of them corresponds to each SRv6 node.  In latter
>case, control-plane entity must advertise allocated SID to the
>endpoint through some means which are out of scope of this document.
> 
>Noted that in the case of aggregated segments for mobile user-plane
>functions, allocated SIDs for the segments can be pre-configured to
>SRv6 nodes.  The control-plane should utilize those SIDs to manage
>mobility sessions especially when increasing number of sessions is
>expected to hit the upper-limit of the user-plane nodes.
> 
>When a centralized controller interfaces to mobile control-planes is
>capable to allocate SIDs to the controlling SRv6 endpoints, the
>mobile control-planes just need to indicate the endpoint nodes and
>their user-plane functions to the controller.  In this case, the
>controller must allocate appropriate SIDs for the user-plane roles to
>the indicated SRv6 endpoints.  The controller must advertise
>allocated SIDs to the endpoints.  To build centralized controller for
>mobile user-plane is out of scope of this document.
> 
>However, to indicate endpoints and their user-plane functions from
>mobile control-plane to user-plane, the endpoint or the controller
>could take advantage of [I-D.ietf-dmm-fpc-cpdp].  It provides
>interface to the control-plane to manage the user-plane of mobile
>networks.
> 
> 
> 
> Matsushima, et al. Expires May 3, 2018 [Page 11]
> Internet-Draft SRv6-mobile-uplane   October 2017
> 
> 
>In case of stateless interworking, SID allocating entity needs to be
>aware SID prefix which interworking SRv6 endpoint and SRv6 domain
>allocate discussed in Section 6.3.  The mobile control-plane also
>need to allocate tunnel endpoint IPv4 address to which corresponding
>interworking segment destined from existing user-plane that is also
>discussed in Section 6.3.
> 
> 9.  Security Considerations
> 
>TBD
> 
> 10.  IANA Considerations
> 
>This document has no actions for IANA.
> 
> 11.  References
> 
> 11.1.  Normative References
> 
>[I-D.filsfils-spring-srv6-network-programming]
>   Filsfils, C., Leddy, J., daniel.vo...@bell.ca, d.,
>   daniel.bern...@bell.ca, d., Steinberg, D., Raszuk, R.,
>   Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
>   Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
>   Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
>   Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
>   Camarillo, "SRv6 Network Programming", draft-filsfils-
>   spring-srv6-network-programming-02 (work in progress),
>   October 2017.
> 
>[I-D.ietf-spring-segment-routing]
>   Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
>   Litkowski, S., and R. Shakir, "Segment Routing
>   Architecture", draft-ietf-spring-segment-routing-13 (work
>   in progress), October 2017.
> 
>[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>   Requirement Levels", BCP 14, RFC 2119,
>   DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
>   editor.org/info/rfc2119>.
> 
> 11.2.  Informative References
> 
>[I-D.ietf-dmm-fpc-cpdp]
>   Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
>   Moses, D., and C. Perkins, "Protocol for Forwarding Policy
>   Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09
>   (work in progress), October 2017.
> 
> 
> 
> Matsushima, et al. Expires May 3, 2018 [Page 12]
> Internet-Draft SRv6-mobile-uplane   October 2017
> 
> 
>[RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
>   Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
>   RFC 5213, DOI 10.17487/RFC5213, August 2008,
>   <https://www.rfc-editor.org/info/rfc5213>.
> 
>[TS.29281]
>   3GPP, , "General Packet Radio System (GPRS) Tunnelling
>   Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
>   September 2011.
> 
> Authors' Addresses
> 
>Satoru Matsushima
>SoftBank
>Tokyo
>Japan
> 
>Email: satoru.matsush...@g.softbank.co.jp
> 
> 
>Clarence Filsfils
>Cisco Systems, Inc.
>Belgium
> 
>Email: c...@cisco.com
> 
> 
>Miya Kohno
>Cisco Systems, Inc.
>Japan
> 
>Email: mko...@cisco.com
> 
> 
>Daniel Voyer
>Bell Canada
>Canada
> 
>Email: daniel.vo...@bell.ca
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Matsushima, et al. Expires May 3, 2018 [Page 13]
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane)

[Satoru Matsushima]

Hi Kentaro,

I've replied to your previous mail that I hope it would answer to your
questions.

On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa 
wrote:

> Hi,
>
> > Q2) Down Link packet (SRv6 to existing network)
> > > When the endpoint receives packet and the active segment of the
> > > packet indicates the SID, the endpoint pop the SRH of the SID, and
> > ...
> >
> > IPv6 Src: Origin Host
> > IPv6 Dst: SL[n]
> > Segment Left = n
> > SL[m] = Encoded SID
> > SL[m+1] = Segment m+1
> > SL[n] = Segment n
>
> Actually I think this differs for T.Insert case, where MN user packet is
> IPv6.
> # Unless I missed description that Stateless Interworking will always use
> encapsulation mode even if user packet is IPv6.


In DL, Stateless Interworking uses encapsulation for original IPv6 packet
with IPv4 and tunnel header.



>
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left = n
> SL[0] = MN address
> SL[1] = Encoded SID
> SL[n] = Segment n
>
>
As I mentioned in the previous mail, SL indicates SL[1] at the interworking
node.



> And interworking segment should behave like below.
>
> When the endpoint receives packet and the active segment of the
> packet indicates the SID, the endpoint pop the SRH of the SID,
> >> Set IPv6 destination address as SL[0] (MN's address), and
> then the endpoint encaps the payload with the encoded information in
> the SID which are tunnel identifier of tunnel header, source and
> destination IPv4 address of IPv4 header described in Figure 3.
>


Right, it looks more precise description to it. Thanks!



>
> Maybe having example packet headers described for each cases
> (encap/insert, User Packet = IPv4/IPv6) will help this makes more easier to
> understand.
>
>
Absolutely yes, it's helpful to understand. I'll update the I-D with that
example in next revision.

Thanks,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane)

[Satoru Matsushima]

Hi Kentaro,


On Mon, Aug 28, 2017 at 11:52 PM, Kentaro Ebisawa 
wrote:

> Hi,
>
> I have a few questions about how Encoded SID should be placed in Segment
> List and IPv6 Dst Address in Mobile User-Plane use case.
>
> # Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01.
> # I tried to check Slides from IETF 99 but link seems to be missing.
> # https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobi
> le-user-plane/


That looks weird. It's not only for that document.
All ietf99 meeting materials are mis-linked from "
https://datatracker.ietf.org/meeting/99/agenda; page.



>
> Q1) Up Link packet (existing network to SRv6)
>
> > outer IPv4 and tunnel header. And then the endpoint does T.Insert
> > process with the SID which consists of the allocated domain-wise SID
> > prefix, source and destination addresses, and tunnel identifier as
> > described in Figure 3. Then the endpoint send out the packet to the
> > SRv6 network along with its routing policy.
>


In above text, we assumed that the payload encapsulated in the IPv4 tunnel
is an IPv6 packet.
So the source address of the packet should be an MN's address.


> How would IPv6 src/dst addr and Segment List look like for this Up Link
> packet? (existing network to SRv6)
> My understanding is usually source address of the T.Insert node is not
> included in Segment List.
> But from above description, it looks like you intend to require Encoded
> SID (Fig 3) to be included in the Segment List of UL packet.
>
> For example, is below packet structure what you intended in case you have
> n segments to traverse in SRv6 nework?
>
> IPv6 Src: Encoded SID or T.Insert node ??
> IPv6 Dst: SL[n]
> Segment Left = n
> SL[0] = Segment 0
> SL[n] = Segment n
> SL[n+1] = Encoded SID
>
>
SL[0] must be original destination address of the IPv6 packet which the MN
sends out.
The SID which consists of the existing network tunnel info would be placed
at SL[1]. In case of that it means that the endpoint which the SID
indicates is egress of the SRv6 domain. If any other endpoints exist in the
segment list, that SID would be placed at SL[n] where n >=2.



> Q2) Down Link packet (SRv6 to existing network)
>
> > When the endpoint receives packet and the active segment of the
> > packet indicates the SID, the endpoint pop the SRH of the SID, and
>
> On the other hand, are there any reason that description in page 7 does
> not mandate m to be zero while requiring to pop the SRH?
>

As similar with UL, SL[0] must be original destination address. In DL
direction the interworking node must be egress of the SRv6 domain so that
the tunnel info encoded SID should be placed in SL[1].

Best regards,
--satoru



> My understanding of DL packet (SRv6 to existing network) is as below.
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left = n
> SL[m] = Encoded SID
> SL[m+1] = Segment m+1
> SL[n] = Segment n
>
>
> Regards,
> --
> Ponto Networks, Inc.
> Kentaro Ebisawa 
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt]

[Satoru Matsushima]

Hi Charlie,

First, thank you for raising this point to be discussed. I second that it needs 
to be more intuitive.


> 
> I am in the process of reviewing the FPC document.  It is an important 
> document and will be foundational for subsequent work in [dmm].

Yep, I really appreciate that you see this draft as a foundation for further 
works.


>  I would like to suggest a change in terminology.  I think the way "Port" is 
> currently defined in the document is very confusing, because it is not very 
> intuitively related to the traditional uses of "port" as in TCP, or in 
> switches.

Right. The coauthors had discussed this point many times but, me at least, 
couldn’t figure out more appropriate term instead of that so far...


> 
> As I understand it, "Policy" lives on the control plane side of the 
> interface, and "Port" is intended to denote a concept that is important on 
> the data plane side of the interface.

If you mean “control plane” as abstracted data-plane model in FPC agent,  I 
think that both “Policy” and “Port” exist on the control plane. In the current 
version of draft, Port is defined as “A set of forwarding policies.”


>  "Flow" is another word that is closely tied to the data plane, and it seems 
> to me that as currently defined in the document a "Port" is a collection of 
> flows that correspond to a specific Policy or Policy Group.

For me, “Flow” seems not to exactly indicate specific policy applied flow. It 
could indicate flow(s) which just have same characteristics in natural. 


> 
> So, I would like to propose that the word "Port" should be replaced by the 
> term "Flow Group".  Another alternative would be "Flow Policy Group", which 
> could then be abbreviated FPG. However, the latter has the perhaps 
> undesirable effect of tying the word "Policy" to a data-plane concept.

I think that the successor of port should keep same meaning of “A set of 
forwarding policies.” In that sense, FPG sounds make sense to me. 

in another aspect, we use Context as abstracted mobility session. I can see 
this as source of flow(s) and it looks already represent a group of those flows 
which are received and sent on each node. Attaching Context to a Port intends 
that applying a set of policies to a group of flows which are attributed to the 
context.


> 
> Thanks for any comments on this proposal to modify the terminology.
> 
> I think it is important to make the terminology as unambiguous and intuitive 
> as we possibly can, especially because the document is necessarily written at 
> a high level of abstraction.
> 

Yes, I fully agree with you, let’s keep the discussion.


> Regards,
> Charlie P.

Best regards,
--satoru


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FW: Network slicing side meeting at IETF97

[Satoru Matsushima]

Thank you Kiran,

I had joined the slice meeting and made a comment to a DMM colleague.
# My bad I didn't know the DMM multicast draft..

Let me summarize a little bit about discussions of the slice meeting.
Many people said their thought almost about network segregation in resource
perspective,
such as bandwidth beyond L2/L3 vpns in static or dynamic way to form them.

I second anima guy that he said that slicing needs to be service aspect
rather than resource.
It looks that the service means transmission and routing aspect. In DMM
point of view,
they are underlay of mobile and FPC data-plane model will be deployed on
top of that.

The conclusion of the slice side meeting is to have a slice bof in next
IETF meeting which
would be going to invite 3GPP experts. So I think that DMM guys need to
head up.

Regards,
--satoru


On Mon, Nov 14, 2016 at 11:17 AM, Kiran.Makhijani <
kiran.makhij...@huawei.com> wrote:

> FYI. In case you are interested.
> -Kiran
>
>
>
> On 14 Nov 2016, at 00:51, Dongjie (Jimmy)  wrote:
>
> Dear presenters,
>
> The network slicing side meeting will be held on Tuesday 19:00-21:00 in
> Studio 3. Could you please send your presentation slides to Stewart and me
> by end of today? Thanks a lot.
>
> Best regards,
> Jie
>
> -Original Message-
> From: detnet [mailto:detnet-boun...@ietf.org ]
> On Behalf Of Dongjie (Jimmy)
> Sent: Tuesday, November 08, 2016 7:57 PM
> To: 5gan...@ietf.org; det...@ietf.org; routing-discuss...@ietf.org;
> nf...@irtf.org; draft-galis-anima-autonomic-slice-network...@ietf.org;
> draft-vonhugo-5gangip-ip-iss...@ietf.org; draft-xuan-dmm-multicast-
> mobility-slic...@ietf.org; draft-ietf-teas-actn-framew...@ietf.org
> Cc: Stewart Bryant; Mach Chen
> Subject: [Detnet] Network slicing side meeting at IETF97
>
> Dear all,
>
> Following on from the recent discussions on network slicing, it seems
> useful to have a side meeting during next week's IETF to see if we can
> establish a common view on the definition and scope of network slicing,
> what work is currently being undertaken in the IETF on this problem space,
> and what (if any) new IETF work would be needed to create deployable
> network solutions.
>
> To that end we propose a side meeting on the topic of network slicing and
> have got a room to have this discussion on the Tuesday evening of the
> IETF week.
>
> Meeting Name: 5G Network Slicing Side Meeting Assigned Room: Studio 3
> Assigned Date: 11/15/2016 (Tuesday) Assigned Time: 19:00 - 21:00
>
> To make the most of this time, it would be useful if a few of us introduce
> to the rest our thoughts on the subject before having an open discussion.
> We have a projector, and so those introducing an aspect of this problem can
> use slides, but slides are not required.
>
> The topics we have so far are:
>
> 1.  Network slicing problem statement  - Stewart Bryant
> https://tools.ietf.org/html/draft-dong-network-slicing-
> problem-statement-00
>
> 2.  Autonomic slicing networking  - Alex Galis
> https://tools.ietf.org/html/draft-galis-anima-autonomic-
> slice-networking-00
>
> 3.  Multicast and mobility service on demand with network slicing  -
> Truong-Xuan Do
> https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00
>
> If you have experiences/understanding of network slicing related use
> cases, requirements or problems etc., we welcome their inclusion in the
> agenda to help bring the rest up to speed.
>
> Following that, we propose an open discussion to establish whether there
> are work items that we need to get included in any existing IETF WG
> charter, or whether we need to initiate any new work in the IETF.
>
> If you have comments on our proposed agenda, or you want to introduce an
> aspect of the problem to the rest of the group, then please contact us with
> name of the topic and how long you need to talk about it.
>
> Many thanks and best regards,
>
> Jie/Stewart/Mach
>
>
> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com
> ]
> Sent: Tuesday, November 01, 2016 11:22 PM
> To: 5gan...@ietf.org; det...@ietf.org; nf...@irtf.org;
> draft-galis-anima-autonomic-slice-network...@ietf.org;
> draft-vonhugo-5gangip-ip-iss...@ietf.org;
> draft-xuan-dmm-multicast-mobility-slic...@ietf.org;
> draft-ietf-teas-actn-framew...@ietf.org
> Cc: Mach Chen ; Dongjie (Jimmy)
> 
> Subject: Network Slicing - a suggestion that we meet to discuss in
> Seoul
>
>
>
>
> Hi,
>
> We were trying to pull together a problem statement for network
> slicing in a 5G context to understand how well the current IETF
> protocols address this problem, what their short comings might be, and
> what IETF work is necessary to have a deployable protocol suite to address
> this need.
>
> We have set down our first thoughts in
> https://tools.ietf.org/html/draft-dong-network-slicing-problem-stateme
> nt-00
>
> We find that there are 

[DMM] Fwd: I-D Action: draft-ietf-dmm-fpc-cpdp-04.txt

[Satoru Matsushima]

Folks,

As we promised at last meeting, 04 version of FPC draft has been 
published. We have made bunch of changes to evolve FPC data-plane
model and protocol including integration of model 1/2 and 
single/multiple DPN agent cases.

Total number of pages are more than 100 but we don’t intend to 
overwhelm readers. Almost essences exist on the first front pages,
so do not hesitate to read it.
 
Please make comments and discussions on the list.

Best regards,
--satoru


> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Distributed Mobility Management of the IETF.
> 
>Title   : Protocol for Forwarding Policy Configuration (FPC) 
> in DMM
>    Authors : Satoru Matsushima
>  Lyle Bertz
>  Marco Liebsch
>  Sri Gundavelli
>  Danny Moses
>   Filename: draft-ietf-dmm-fpc-cpdp-04.txt
>   Pages   : 131
>   Date: 2016-09-29
> 
> Abstract:
>   This document describes the solution of data-plane separation from
>   control-plane which enables a flexible mobility management system
>   using agent and client functions.  To configure data-plane nodes and
>   functions, the data-plane is abstracted by an agent interface to the
>   client.  The data-plane abstraction model is extensible in order to
>   support many different type of mobility management systems and data-
>   plane functions.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-fpc-cpdp-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WG Adoption call for draft-wt-dmm-deployment-models-00

[Satoru Matsushima]

I support this adoption.

cheers,
--satoru

On Sun, Jul 24, 2016 at 1:56 PM, Jouni  wrote:

> Folks,
>
> As already supported in IETF96 Berlin meeting we are ratifying the
> adoption of draft-wt-dmm-deployment-models-00 as a WG Item. The WG
> adoption call ends 8/7/2016. Voice you support or opposition (with a reason
> why) on the mailing list.
>
> - Dapeng & Jouni
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

[Satoru Matsushima]

Support.

Regards,
--satoru

On Thu, Jun 16, 2016 at 2:16 AM, Jouni  wrote:

> Folks,
>
> This email starts the WGLC #2 for draft-ietf-dmm-ondemand-mobility-05.
> Post your comment to the mailing list and also add your issues/correction
> requests/concerns etc into the Issue Tracker.
>
>WGLC #2 Starts: 6/15/2016
>WGLC #2 Ends: 6/29/2016 EOB PDT
>
> Regards,
>Jouni & Dapeng
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04

[Satoru Matsushima]

Behcet,

On Tue, Jun 30, 2015 at 1:24 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:

-- snip --


 Wait a minute, there is more.
 It seems like you have not read Sections 4.2 and 4.3.
 Yes, XMPP and OpenFlow are for Section 4.1 for switch control on
 mobile backhaul.
 This is related to a university project we were involved which used
 public domain OpenFlow tools like OpenDayLight.

 In route establishment, I am using Netconf or RPC protocol which you
 missed big and that was one of the main additions in Rev. 02.
 Please check it again.


Wow, thanks. I had overlooked it.
I had jumped to conclusions when I read section 4.1 that cover not only L2
but also L3 hand-over.
I couldn't imagine that each layer has different technique for hand-over.
Why is that?

I want to clarify one thing on your drat. Sec 4.3 in the draft mentions
that i2rs agent as netconf client but it is opposite
as far as I know. Am I wrong?




  But what I mentioned FPCP in vEPC is as a way to export mobility info to
 BGP
  speaker
  from control-plane nodes of mobility management.
 
  And more, many parameters should be aligned for these nodes to utilizing
  data-plane
  network so that the config data model should also be defined in FPCP. I
  think that's not
  part of signaling protocol roles.
 

 As I said in my mail before, I wonder why we need all those things?
 Why do we need another client/server system maybe other than what i2rs
 is defining?
 I think this is a big question FPCP lovers should answer? My point is
 that at least you should not need it in vEPC, I am saying that as
 someone who supports vEPC :-)


AFAIK, FPCP design is alined with i2rs architecture so that it has the
data-model with yang schema based on its information model of data-plane
node abstraction (Marco's idea) but currently it's an appendix. The
information model would make clear what are the mobility specific things
that might augment i2rs model. If nothing, there's no need to define it,
yes. As a co-author of FPCP, you are welcome to review the parameters which
FPCP defined whether each of those are really needed or not.



  Thought?

 Another main addition is Rev. 02 was Section 5 on multicast support
 which you missed or not commented?


Cool.
Does mobile node really need multicast? Is there any document that justify
for that?

cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] DMM WT#4 - 2 Discussion

[Satoru Matsushima]

Mainly for Anthony,

To support IPv4 for anchor node which connected to IPv6-only network,
some IPv6 transition solutions would be one of the anchor function.
Please take a look at
http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-04#section-3.5

Regards,
--satoru

On Wed, Jun 24, 2015 at 12:37 AM, Sri Gundavelli (sgundave) 
sgund...@cisco.com wrote:

  Thanks for all the discussion today on the WT#4 call. Attendees: Carlos
 Jesús Bernardos, Satoru Matsushima, Seil Jeon, KJ  Sun, Anthony Chen  Sri

  - Update from Seil
 - Update from Anthony
 - CPA/DPA sub-functions and roles; Session Re-anchoring; Flow stitching
 - Next steps on coming out with consolidated initial docs from WT#4



   From: dmm dmm-boun...@ietf.org on behalf of Sri Gundavelli 
 sgund...@cisco.com
 Date: Wednesday, June 17, 2015 at 5:05 PM
 To: dmm@ietf.org dmm@ietf.org
 Subject: [DMM] DMM WT#4 - 2 Discussion

   Thanks for all the discussion on the WT#4 call. Attendees: Marco
 Liebsch, Danny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao,
  Sri ..

  The Poll is now closed for the next call.

  Date: Tuesday, June 23rd at 7AM PDT
 WebEx Details below
 Agenda:

1. Seil Jeon will present his new proposal
2. Anthony Chen will talk about Functions of Anchor” (Tentative)
3. Follow up discussion on the attribute based node
selection/Deployment models
4. Follow up discussion on the CP/DP interface in relation to the WT4
discussions





Hi, Sri Gundavelli,  You are the host for this WebEx meeting.Host
 key: 480131 (Use this to reclaim host privileges.) *DMM WT#4
 Discussion*  Tuesday, June 23, 2015  7:00 am  |  Pacific Daylight Time
 (San Francisco, GMT-07:00)  |  1 hr 30 mins *Join WebEx meeting*
 https://cisco.webex.com/ciscosales/j.php?MTID=ma6d7e5c1f97e4d8747f8badf7ab4c46e
 Meeting
 number: 209 370 954  Meeting password: DMM *Join by phone*  
 *+1-408-525-6800
 %2B1-408-525-6800* Call-in toll number (US/Canada)  *+1-866-432-9903
 %2B1-866-432-9903* Call-in toll-free number (US/Canada)  Access
 code: 209 370 954  Global call-in numbers
 https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=316932207tollFree=1
   |  Toll-free calling restrictions
 http://www.webex.com/pdf/tollfree_restrictions.pdf Add this
 meeting
 https://cisco.webex.com/ciscosales/j.php?MTID=m33dd947463a55feffae4b40f5dfe9b16
 to your calendar. Can't join the meeting? Contact support.
 https://cisco.webex.com/ciscosales/mc IMPORTANT NOTICE: Please
 note that this WebEx service allows audio and other information sent during
 the session to be recorded, which may be discoverable in a legal matter.
 You should inform all meeting attendees prior to recording if you intend to
 record the meeting.

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04

[Satoru Matsushima]

Hi Behcet,

Sorry for my late response.

As I looked over your dmm-for-wifi draft, I found two protocols to be used
to separate
control and data plane such as XMPP and OpenFlow.

It seems like you want to work on that protocols to be implemented in data
plane nodes.
OpenFlow is another forum controlled protocol so I don't touch it in the
IETF.
XMPP sounds nice. If you adopt XMPP with same model of
draft-ietf-l3vpn-end-system,
it almost same with using BGP like the vEPC draft.

But what I mentioned FPCP in vEPC is as a way to export mobility info to
BGP speaker
from control-plane nodes of mobility management.

And more, many parameters should be aligned for these nodes to utilizing
data-plane
network so that the config data model should also be defined in FPCP. I
think that's not
part of signaling protocol roles.

Thought?

Regards,
--satoru




On Wed, Jun 3, 2015 at 4:25 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:

  Hi Matsushima-san,

 On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima
 satoru.matsush...@gmail.com wrote:
  Hi Behcet-san,
 
  On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya sarikaya2...@gmail.com
 
  wrote:
 
  Hi Satoru,
 
  Thanks for your reply.
 
  Let me continue the discussion with your text in Section 3.2 where you
  mention
  vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
  that defines FPCP Agent function and Client function.
 
  I don't understand how you could justify defining a new forwarding
  policy configuration protocol to do this Agent/Client functionality?
  Why not use similar Agent/Client models that are being defined rather
  than defining a new protocol?
  I think this point requires much stronger justification which I could
  not see in Section 3.2.
 
 
  The text just describes about a part of where FPCP may be applicable in
  vEPC.
 
 
 
 
  Are you that we have to to reinvent the wheel, rather than reusing
  something that is already available? How are we going to reinvent that
  wheel also remains to be seen, I think.
 
 
  Point taken. Which kind of wheel do you have in mind?

  Please check this draft:
 https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02

 Regards,

 Behcet
 
  cheers,
  --satoru
 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04

[Satoru Matsushima]

Hi Behcet-san,

On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:

 Hi Satoru,

 Thanks for your reply.

 Let me continue the discussion with your text in Section 3.2 where you
 mention
 vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
 that defines FPCP Agent function and Client function.

 I don't understand how you could justify defining a new forwarding
 policy configuration protocol to do this Agent/Client functionality?
 Why not use similar Agent/Client models that are being defined rather
 than defining a new protocol?
 I think this point requires much stronger justification which I could
 not see in Section 3.2.


The text just describes about a part of where FPCP may be applicable in
vEPC.




 Are you that we have to to reinvent the wheel, rather than reusing
 something that is already available? How are we going to reinvent that
 wheel also remains to be seen, I think.


Point taken. Which kind of wheel do you have in mind?

cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04 - /62s to UE, not /64s

[Satoru Matsushima]

Ah OK. thanks.
Slightly off-topic, I think that there is still chance for tethering with
single /64 if it is allocated as a off-link prefix.

But yes, I agree with you.

cheers,
--satoru

On Wed, May 27, 2015 at 8:31 PM, Alexandru Petrescu 
alexandru.petre...@gmail.com wrote:

 Hi,

 In addition to what Behcet says.

 I read the example below.  I think it is just an example, but just to make
 sure.

 Please - do not allocate /64s to end users in a cellular network. Allocate
 at least /62s to end users.

 This is to allow the smartphone to perform tethering (small network of
 wifi devices connecting through the smartphone to the Internet).

 The assumption of /64 to end user is not good at all.

 (and yes, I agree that these /62s may be aggregated into a larger prefix
 and advertised upstream as a single prefix instead of multiple host-based
 routes).

 Yours,

 Alex Petrescu

 Le 26/05/2015 22:34, Behcet Sarikaya a écrit :

 Hi Satoru,

 Thanks for your reply.

 Let me continue the discussion with your text in Section 3.2 where you
 mention
 vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
 that defines FPCP Agent function and Client function.

 I don't understand how you could justify defining a new forwarding
 policy configuration protocol to do this Agent/Client functionality?
 Why not use similar Agent/Client models that are being defined rather
 than defining a new protocol?
 I think this point requires much stronger justification which I could
 not see in Section 3.2.

 Are you that we have to to reinvent the wheel, rather than reusing
 something that is already available? How are we going to reinvent that
 wheel also remains to be seen, I think.

 Regards,

 Behcet



 On Sat, May 16, 2015 at 8:01 AM, Satoru Matsushima
 satoru.matsush...@gmail.com wrote:

 Hi Bechet-san,

 Thank you for your question.
 In step (15), I meant that EPC-E advertises prefix including UE assigned
 prefixes.

 For example, in the case of /64 prefixes assigned to UEs from a /56
 space,
 that /56
 is advertised by EPC-E to upstream routers. So the advertised route isn't
 host routes.

 Depends on configuration policy, but one case is that the source of that
 advertised
 /56 route might be statically configured in EPC-E.

 Regards,
 --satoru



 On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com
 
 wrote:


   Hi Matsushima-san,

 I have a question on your draft:
 In Sec. 3.2, page 11, you say
 In step (15), the EPC-E advertises routes to upstream routers ...

 Are these routes static/host routes?

 Regards,

 Behcet




 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm




 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] vepc draft Rev. 04

[Satoru Matsushima]

Hi Bechet-san,

Thank you for your question.
In step (15), I meant that EPC-E advertises prefix including UE assigned
prefixes.

For example, in the case of /64 prefixes assigned to UEs from a /56 space,
that /56
is advertised by EPC-E to upstream routers. So the advertised route isn't
host routes.

Depends on configuration policy, but one case is that the source of that
advertised
/56 route might be statically configured in EPC-E.

Regards,
--satoru



On Wed, May 13, 2015 at 4:51 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:

  Hi Matsushima-san,

 I have a question on your draft:
 In Sec. 3.2, page 11, you say
 In step (15), the EPC-E advertises routes to upstream routers ...

 Are these routes static/host routes?

 Regards,

 Behcet

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00

[Satoru Matsushima]

As a coauthor I support to adopt this draft as a WG doc.

Regards,
--satoru

On Thu, Apr 2, 2015 at 11:21 PM, Jouni Korhonen jouni.nos...@gmail.com
wrote:

 Folks,

 This emails starts a two week call for the I-D
   draft-wt-dmm-fpc-cpdp-00
 to confirm the adoption as a DMM WG document. The call ends April 16th EOB
 PDT.

 Express your support or opposition to the mailing list. During the IETF92
 meeting we got 10 voices for the adoption so at least the same amount
 supporting emails should be expected.



 - Jouni  Dapeng

 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [FPSM] next WT call

[Satoru Matsushima]

Hi Marco,

Is the timezone in the doodle CST?

cheers,
--satoru

On Fri, Dec 12, 2014 at 10:53 PM, Marco Liebsch marco.lieb...@neclab.eu
wrote:

  Folks,

  as follow-up of two good work team side meetings during IETF91, I’d like
 to schedule
 this year’s last telco. Please participate in the doodle poll (pointer
 below in this eMail)
 if you plan to attend.



 Best regards,

 Marco



 http://doodle.com/5ax4qr3zrtms3t94





 ___
 dmm mailing list
 dmm@ietf.org
 https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Going forward with the DMM work items

[Satoru Matsushima]

Hi Behcet,


On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya sarikaya2...@gmail.com
wrote:


 I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi
 we proposed new approaches like SDN.


Please don't get me wrong. My position hasn't been changed. BGP is used to
forwarding path management signaling.

In your draft, XMPP is the protocol that has same role of BGP. Good idea,
it is a pub-sub system as same as BGP. You may need to define data model
for dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs
either xmpp, netconf, or forces.

I suppose that you might want to adopt end-system VPN (
https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data
modeling. (actually it is BGP. :-) And, as you may know that there is a
draft which mentions about use case of BGP in i2rs. (
http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases)


 Having said that I don't think that the charter text on forwarding
 path and signaling is talking about the same thing.


Interesting. What do you expect for the charter text?
Why not you ask Marco, Anthony and Alper to explain their thought?




 In DMM fir WiFi we also adopted the anycast discovery, what is wrong with
 that?


How do you find the anycast address itself?




 Yes I agree, maybe other techniques like AAA can be worked out. Why
 not do it as extensions?


I suppose that it would be a part of enhanced anchoring work, isn't it?



 Really? My thinking was that vEPC does not need any involvement from
 MN because the prefix assigned to MN does not change.

 As I mentioned in my more recent mail, I think this item is based on
 2102 solution proposals in which MN had to deal with many prefixes.

 Can you clarify which network nodes need exposure to MN mobility
 state? The ones on the path already know MN prefix, right?


Quite not. I meant disclosing mobility information to network node that
likes such as BGP speaker.



 So you are saying that these three items gave you some good ideas to
 think about on how you can improve your solution, vEPC.


In my view, the charter items work well to achieve vEPC architecture model,
yes.
More precisely, as the result of discussions which I had so far with many
dmm people, I have noticed some parts which the draft needs more work to
achieve the architecture model.


 You are indicating that there is a major solution proposal, i.e. vEPC
 by you, but that can be improved here and there.

 You are missing the point that such a view point is not yet agreed by the
 group.


I know. So I am trying to express my thought, and then we can recognize
differences each other, and we can discuss. It's normal process in the ietf
I think.



 Without such an agreement on the base, isn't it quite concerning what
 the WT's or DT's will do?

 My understanding is that the formation of WT's or DT's is another way
 of saying that we don't like all those solutions out there, we will
 design our own solutions to the above 3.


I guess wg management, who are responsible to establish dmm standard,
expect standardizing dmm solution would be very hard work because they find
many variants for it. In that situation, it would be reasonable that they
appoint some persons to lead the work. I really appreciate those persons
who volunteer to take that role to out consolidated solution.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Going forward with the DMM work items

[Satoru Matsushima]

Hi Fred,

On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L fred.l.temp...@boeing.com
wrote:

 Hi,

  Maybe I can't attend next webex meeting tomorrow.

 That is too bad, because I will be briefing the AERO BGP routing system at
 the meeting tomorrow.


Yes, sorry to say.



 I read your proposal, but have not received any indication if you have
 read my AERO proposal yet. AERO uses
 BGP in a way that was first specified by RFC6179 in 2011 and carried
 forward into draft-templin-ironbis and
 draft-templin-aerolink. In AERO, BGP allows AERO Relays to  keep track of
 which AERO Client Prefixes (ACPs)
 are associated with which AERO servers. But, only the Servers are exposed
 to localized ACP mobility events;
 the BGP is only updated when an ACP moves to a new Server. This means that
 there will be very little churn
 in the BGP routing system itself. So, the BGP is not directly exposed to
 localized mobility events.


I know you are the guy who invent ISATAP so I understand you may utilize
same mechanism. You and me look big-believer of BGP ecosystem. In my draft,
3gpp defined mobility management is assumed to exist so the mobility
management exports BGP mobility information into routing information. Do
you assume 3gpp or ietf mobility management protocol/system in your draft
as well?


 Anycast has been widely used in other router discovery solutions. Two
cases are 6rd [RFC5969]

 and 6to4 [RFC3068]. But, anycast has known operational problems in real
 networks, and in fact
 has caused major headaches for 6to4 - even to the point that its
 deprecation is currently being
 called for:

 http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html
 http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html

 AERO Clients use DNS discovery to discover the address(es) of nearby
 Server(s) as the default
 means. Other solutions such as manual configuration, DHCP option, etc. are
 also possible.


Yes, I know, there are many type of endpoint discovery. Do you clear any
patent which claim the right of dns based endpoint discovery?


 It would be nice if you were to review the AERO architecture and explain
 to me the way in which
 this requirement is or is not addressed already there.


Well, will do. I suppose today you provides explanation to extract aero
into three work items. Thats works a lot for me to help reviewing the aero.

Cheers,
--satoru
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] How to progress DMM (was Re: demand for DMM traffic steering)

[Satoru Matsushima]

Hi Jouni,


2014/07/19 19:12、Jouni Korhonen jouni.nos...@gmail.com のメール：

 
 Ain't that quite visible from the agenda:
 
 1.1) have a look at the re-chartering text that it is roughly
   acceptable for everyone in the room. We can even do some
   minor online editing if there is something that requires
   immediate attention. The text has not been changed since
   14th Jun.

It seems a bit late to comment on the text. The charter text looks fine but I 
have one comment on para 3:
Routing based proposals must not propagate routing updates outside the IGP 
routing domain.

That sounds pretty old-fashion operation because even in an operator's domain 
we uses multiple ASes that 
independent each other in IGP point of view. So I suggest that using a word of 
administrative domain defined in RFC3753, instead of using IGP routing 
domain, such like:

Routing based proposals must not propagate routing updates outside the 
administrative domain.


 
 1.2) have the initial discussion how to proceed after IETF90.
 
 2) lenghty powerpoint marathon.. of many I-Ds that we have
   already heard a presentation before, so concentrate on
   possible updates and how the I-D fits under the current
   re-charter milestones.
 

Ack.


 3) on Friday conclude the next steps and the working procedues
   for carrying out the stuff. Decision making point here. (we
   probably need to add some minutes for the concluding
   discussions, so the longer presentations slots are subject
   to some adjustment)
 

Maybe I have limited time for Friday discussion due to my flight schedule...
--satoru


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm