Re: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-12.txt

[Bertz, Lyle T [CTO]]

FYI - This is a YANG fix for default config statements to be consistent with 
NMDA statements made in the Appendix.

Apologies for the submission spam.  Please look at the version 11 diff for 
substantive updates.

Lyle

> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Monday, June 18, 2018 11:28 AM
> To: i-d-annou...@ietf.org
> Cc: dmm@ietf.org
> Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-12.txt
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> 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   : Protocol for Forwarding Policy Configuration (FPC) 
> in DMM
> Authors : Satoru Matsushima
>   Lyle Bertz
>   Marco Liebsch
>   Sri Gundavelli
>   Danny Moses
>   Charles E. Perkins
> Filename: draft-ietf-dmm-fpc-cpdp-12.txt
> Pages   : 152
> Date: 2018-06-18
>
> Abstract:
>This document describes a way, called Forwarding Policy Configuration
>(FPC) to manage the separation of data-plane and control-plane.  FPC
>defines a flexible mobility management system using FPC agent and FPC
>client functions.  A FPC agent provides an abstract interface to the
>data-plane.  The FPC client configures data-plane nodes by using the
>functions and abstractions provided by the FPC agent for the data-
>plane nodes.  The data-plane abstractions presented in this document
>are extensible in order to support many different types of mobility
>management systems and data-plane functions.
>
>
> The IETF datatracker status page for this draft is:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-fpc-
> cpdp%2F=02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524c
> db9ab808d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%
> 7C636649361159769899=uqAllFzyY5vSwRqzBeVTuPaNq%2BFUDIEqg
> eliqcAYa7Y%3D=0
>
> There are also htmlized versions available at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.i
> etf.org%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp-
> 12=02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524cdb9ab8
> 08d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6366
> 49361159769899=OSmW7IzcLUxZomr8EiBhf8%2FbifZWF3LBA1Zlfxru
> gOs%3D=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp-
> 12=02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524cdb9ab8
> 08d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6366
> 49361159769899=DxNQ8Z4GXI20s61WdgaogAA1tCQS9Zqi3bXUraYR
> 6Xo%3D=0
>
> A diff from the previous version is available at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dmm-fpc-cpdp-
> 12=02%7C01%7Clyle.t.bertz%40sprint.com%7Cbafa5ea885524cdb9ab8
> 08d5d53888c9%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6366
> 49361159769899=DIC5VjKMh%2BIo%2FnYXtsAZSfxXUhvO053bQOet4
> Dib8xQ%3D=0
>
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fdmm=02%7C01%7Clyle.t.bertz%40
> sprint.com%7Cbafa5ea885524cdb9ab808d5d53888c9%7C4f8bc0acbd784bf5
> b55f1b31301d9adf%7C0%7C1%7C636649361159769899=O44%2B2IE
> HepRltTBF6qxgF1zqHtzZNvRtmD5AO6MFraM%3D=0



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

Re: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-11.txt

[Bertz, Lyle T [CTO]]

All,

   The following changes have been made since version 10 as noted during IETF 
101:

  Service-Endpoints eliminated.  Service-Group and DPN interfaces
  changed to hold information previously held by Service-Endpoint as
  noted in *ML* during IETF 101.

  Scrubbed YANG for NMDA compliance and Guidelines (RFC 6087bis).

  Monitor lifecycle, ServiceGroup, policy and policy installation examples 
added.  All
  examples updated to be consistent with any edits that were made.

Other changes
 Service-Group resides under the Topology-Information-Mode

  The Domain now has a checkpoint and the Topology Information Model
  checkpoint was removed to avoid any overlaps in checkpoints.

  Monitor lifecycle, policy and policy installation examples added.

  Editing

Thanks!

Lyle

> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Monday, June 18, 2018 9:07 AM
> To: i-d-annou...@ietf.org
> Cc: dmm@ietf.org
> Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-11.txt
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> 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   : Protocol for Forwarding Policy Configuration (FPC) 
> in DMM
> Authors : Satoru Matsushima
>   Lyle Bertz
>   Marco Liebsch
>   Sri Gundavelli
>   Danny Moses
>   Charles E. Perkins
> Filename: draft-ietf-dmm-fpc-cpdp-11.txt
> Pages   : 152
> Date: 2018-06-18
>
> Abstract:
>This document describes a way, called Forwarding Policy Configuration
>(FPC) to manage the separation of data-plane and control-plane.  FPC
>defines a flexible mobility management system using FPC agent and FPC
>client functions.  A FPC agent provides an abstract interface to the
>data-plane.  The FPC client configures data-plane nodes by using the
>functions and abstractions provided by the FPC agent for the data-
>plane nodes.  The data-plane abstractions presented in this document
>are extensible in order to support many different types of mobility
>management systems and data-plane functions.
>
>
> The IETF datatracker status page for this draft is:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-fpc-
> cpdp%2F=02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a453
> 52d2a08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C6
> 36649276530433038=wySdutjo24ubIZVgc5oHfunUE%2BF%2F%2BDl2h
> kH5RVpjUy8%3D=0
>
> There are also htmlized versions available at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.i
> etf.org%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp-
> 11=02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a45352d2a
> 08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636649
> 276530443048=0AqctjYJ09O4hkY97i059PxZb9p5rCcXynEpGY2NiSI%3D
> =0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-fpc-cpdp-
> 11=02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a45352d2a
> 08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636649
> 276530443048=BHYt4WB00qZhor%2F0C2ZixuY0DNBkWjiekLvHcDCxfZo
> %3D=0
>
> A diff from the previous version is available at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dmm-fpc-cpdp-
> 11=02%7C01%7Clyle.t.bertz%40sprint.com%7C2b411db4bf0a45352d2a
> 08d5d524d4fd%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C1%7C636649
> 276530443048=PAg40E2Z8rnDV9QPKzewR0WEIG1OvZrtOgkA60oos2E
> %3D=0
>
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fdmm=02%7C01%7Clyle.t.bertz%40s
> print.com%7C2b411db4bf0a45352d2a08d5d524d4fd%7C4f8bc0acbd784bf5b5
> 5f1b31301d9adf%7C0%7C1%7C636649276530443048=kub6vt76MbXEX
> tBYvpoNvf0MPno2Y7zw6wxofjcLd4o%3D=0



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.

___

Re: [DMM] IETF101 - Call for agenda items

[Bertz, Lyle T [CTO]]

Sri:

Please add the following if Charlie has not already requested.

Topic Name: FPC update
Time: 30 minutes
Draft Reference: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp.txt

Lyle

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, February 23, 2018 7:44 PM
To: dmm@ietf.org
Subject: [E] Re: [DMM] IETF101 - Call for agenda items

Gentle reminder.

The DMM WG scheduled is to meet in London, on Tuesday; 15:50-18:20; Afternoon 
session II.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_meeting_101_agenda.html%26d%3DDwICAg%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DIdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT%26m%3DOTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs%26s%3DlYub_Nr7BCAucf6sLruhiltVbjxQQqjGoQ5cBvaVxNY%26e=02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876619847=nZtS8fKZAogt5WDtoJE2x%2BSL687LS9uTQHcMzjqPEtU%3D=0=

Please send your proposals that you want to be included in the agenda.


Sri



On 2/7/18, 1:16 PM, "dmm on behalf of Sri Gundavelli (sgundave)"
 wrote:

>The DMM working group is planning to meet in IETF 101, at London. If
>you need a presentation slot, please send your request to the chairs
>with the following information.
>
>
>Topic Name:
>Presenter Name:
>Time:
>Draft Reference:
>
>
>Thanks!
>Dapeng & Sri
>
>
>
>>
>
>___
>dmm mailing list
>dmm@ietf.org
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldef
>ense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailm=
>02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c%
>7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876619847=4
>h7eVUi%2BAn4st70TnM72Zus2yZzDa2zq%2Bmjsyl5pitk%3D=0
>an_listinfo_dmm=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&
>r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT=OT
>SVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs=aHD_lLO6FH_eeWxMo1COnoB44JL
>m1w359nC6QQzWwBg=

___
dmm mailing list
dmm@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_dmm%26d%3DDwICAg%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DIdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT%26m%3DOTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs%26s%3DaHD_lLO6FH_eeWxMo1COnoB44JLm1w359nC6QQzWwBg%26e=02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876619847=K7xP51wxvCzY%2BQHZxTCZr7yBQGHYyFnfr1RZD4W3XJ0%3D=0=

___
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%7C99419711144e4acc0b7508d57e14bb6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876629856=H0NCCFi7AlJJiFANpx3EgNipqqPsuAm4hHDkp76tE%2BU%3D=0



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

Re: [DMM] FPC Working Session

[Bertz, Lyle T [CTO]]

Due to schedules, the daily meetings for FPC are cancelled for this Thursday 
and Friday.

Lyle

-Original Appointment-
From: Bertz, Lyle T [CTO]
Sent: Monday, January 29, 2018 12:54 PM
To: Bertz, Lyle T [CTO]; Charlie Perkins; Satoru Matsushima; Marco Liebsch; Sri 
Gundavelli (sgundave); Moses, Danny
Subject: FPC Working Session
When: Thursday, February 22, 2018 9:00 AM-10:00 AM (UTC-06:00) Central Time (US 
& Canada).
Where: Skype Meeting


1 hour.

We'll try to complete policy.  I'll set up a few use cases as well.  We'll only 
focus on policy aspects of the context.

Proposed Use Case(s) (all assume DPN Selection has occurred)

3 policies are proposed
1.  Account for and DROP all port 22 destined to the mobile.
2.  Set the AMBR for all traffic from 10.5.5.0 to 3Mbps.
3.  For (UE on port 318 and 10.6.5.5 port 9335) account on bucket X, set 
traffic-class to Y, set max bit rate to 2Mbps.

Part 1 - Basic Policy Management
1.  Create a Descriptor.
2.  Create an Action.
3.  Create a Rule.
4.  Create a Policy.

Part 2 - Mobility Policy Management (single context).
5.  Create a Mobility Context with a pre-configured policy.
6.  Create a Mobility Context with a dynamic policy.
7.  Change the DPN assigned in the SGW / MAG role (mobile moves), aka 
handover in a
a.  make before break model.
b.  break before make.

Part 3 - Secondary context (bearers)
8.  Add a secondary context
9.  Secondary context update based upon 7a and 7b.
10. Remove a secondary context




.
--> Join Skype Meeting<https://meet.ad.sprint.com/lyle.t.bertz/305GZ9T8>
  Trouble Joining? Try Skype Web 
App<https://meet.ad.sprint.com/lyle.t.bertz/305GZ9T8?sl=1>
Join by phone
913-315-1921 (US) English (United States)
913-553-3030 (US) English (United States)
Find a local number<https://dialin.ad.sprint.com>

Conference ID: 3895350
 Forgot your dial-in PIN?<https://dialin.ad.sprint.com> 
|Help<https://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033=5=2009>


Please see the   find a local number   link above for toll free numbers
[!OC([1033])!]
.



  

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] FPC Calls

[Bertz, Lyle T [CTO]]

Due to scheduling conflicts we are cancelling today and tomorrow's calls.  See 
y'all on Friday.

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

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

[Bertz, Lyle T [CTO]]

Summary
- Migration to template style which is something Charlie has discussed before.

- Notation updates to streamline the information model.  It's a bit of a 
balance between too verbose with lots of implications and overly explanatory.  
We're looking at using a style that eliminates the need to talk about 
id/type/value in the model all of the time.

- A generalization of the template style and process so that it is straight 
forward

- Use cases, use cases, use cases. This includes showing or at least being 
confided we can show the information models for
> session initiation
> added resource (dedicated bearers in the LTE world but essentially dividing 
> traffic by a rule and sending it through a different set of resources)
> solicitation for rules from the client for traffic that arrives at a DPN and 
> the DPN has no rules to deal with the traffic
> embedded rules (lots of discussion on this)
> the ugliest use case we can find - VoLTE (pre-configuring dynamically 
> constructed rules for hot standby and then selecting them later) which uses 
> SDP to drive the rules
> parent context and how it helps in some of these use cases

- short discussion on having a richer update model similar to YANG-Patch (RFC 
8072) which has insert, merge, move, replace & remove instaed of just 'update'. 
 Also being a patch method it allows us to skinny down communications but none 
of this has been decided yet.

In theory this is all about Section 4 (except the last item) but the 
implication is a streamlined protocol model

Lyle



-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
Sent: Monday, February 12, 2018 9:25 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] FPC meetings - Cancelling tomorrow's meeting

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] <lyle.t.be...@sprint.com>のメール:
> 
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm=02%7C01%7CLyle.T.Bertz%40sprint.com%7C6a9217e3a8614ed015b508d572915f6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636540891052791263=0e9qdO%2F3EV0N%2B5brPv2uQo2tPuc2IC20ZTdPUZ%2FJg%2F4%3D=0

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

[DMM] FPC meetings - Cancelling tomorrow's meeting

[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] Updated FPC Working Sessions

[Bertz, Lyle T [CTO]]

Will now go during weekdays through 2/23.

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.
--- Begin Message ---
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Bertz, Lyle T [CTO]":MAILTO:lyle.t.be...@sprint.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Charlie Pe
 rkins:MAILTO:charles.perk...@earthlink.net
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Satoru Mat
 sushima:MAILTO:satoru.matsush...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Marco Lieb
 sch:MAILTO:marco.lieb...@neclab.eu
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Sri Gundav
 elli (sgundave):MAILTO:sgund...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moses, Dan
 ny":MAILTO:danny.mo...@intel.com
DESCRIPTION;LANGUAGE=en-US:1 hour.\n\nWe’ll try to complete policy.  I’
 ll set up a few use cases as well.  We’ll only focus on policy aspects o
 f the context.\n\nProposed Use Case(s) (all assume DPN Selection has occur
 red)\n\n3 policies are proposed\n1.  Account for and DROP all port 22 
 destined to the mobile.\n2.  Set the AMBR for all traffic from 10.5.5.
 0 to 3Mbps.\n3.  For (UE on port 318 and 10.6.5.5 port 9335) account o
 n bucket X\, set traffic-class to Y\, set max bit rate to 2Mbps.\n\nPart 1
  – Basic Policy Management\n1.  Create a Descriptor.\n2.  Create
  an Action.\n3.  Create a Rule.\n4.  Create a Policy.\n\nPart 2 
 – Mobility Policy Management (single context).\n5.  Create a Mobilit
 y Context with a pre-configured policy.\n6.  Create a Mobility Context
  with a dynamic policy.\n7.  Change the DPN assigned in the SGW / MAG 
 role (mobile moves)\, aka handover in a\na.  make before break model.\
 nb.  break before make.\n\nPart 3 – Secondary context (bearers)\n8. 
  Add a secondary context\n9.  Secondary context update based upon 
 7a and 7b.\n10. Remove a secondary context\n\n\n\n\n..
 ..
 .\n--> Join Skype Meeting\n  Trouble Joining? Try Skyp
 e Web App<https://meet.ad.sprint.com/lyle.t.bertz/305GZ9T8?sl=1>\nJoin by 
 phone\n913-315-1921 (US) English (United Sta
 tes)\n913-553-3030 (US) English (United Stat
 es)\nFind a local number<https://dialin.ad.sprint.com>\n\nConference ID: 3
 895350\n Forgot your dial-in PIN?<https://dialin.ad.sprint.com> |Help\n\n
 \nPlease see the   find a local number   link above for toll free numbers\
 n[!OC([1033])!]\n.
 ..
 ..\n\n\n
RRULE:FREQ=WEEKLY;UNTIL=20180223T15Z;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR;WK
 ST=SU
SUMMARY;LANGUAGE=en-US:FPC Working Session
DTSTART;TZID=Central Standard Time:20180202T09
DTEND;TZID=Central Standard Time:20180202T10
UID:04008200E00074C5B7101A82E008F02A54450099D301000
 01000509D60F510BF294FBC875D9D83DCFA21
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20180201T175942Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:2
LOCATION;LANGUAGE=en-US:Skype Meeting
X-MICROSOFT-CDO-APPT-SEQUENCE:2
X-MICROSOFT-CDO-OWNERAPPTID:954013666
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
--- End Message ---
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] FPC Policy - Working Session & Concepts

[Bertz, Lyle T [CTO]]

All,

For tomorrow we'll start the work on Policy.

Concepts.

Policy structure (Policy, Rule, Descriptor and Action) definitions are 
templates.   They may be complete or require further complementary information, 
referred to as Settings, to complete them.  Indexed (given a key) structures 
are referenceable and reusable.

Settings may be provided when one template re-uses another, e.g. when a Policy 
(template) references a Rule (template), but the model currently limits adding 
complementary settings to a few key structures in order to reduce system 
complexity.  Otherwise, the model would look like Policy references Rule with 
some Settings which references a Descriptor with some Settings and also an 
Action with some Settings.

Policies may be referenced when creating a Context which indicates that the 
Client would use a pre-configured policy.  However, it is not unusual for the 
Client to acquire from a Policy Decision Point a dynamically constructed policy 
(dynamic policy) and request its installation at the time of Context creation.  
What is most likely, however, it is that a Context is modified or is created 
because of a policy based service request, i.e. usually one that requires 
Quality of Service such as Voice.   Dynamic policies are *highly customized* as 
they are often negotiated between endpoints using a protocol such as SDP within 
a SIP control plane.  As such, these policies are not reusable and effectively 
disappear when the associated Context is removed.

It is hoped but not guaranteed that the application of Settings will reduce the 
probability of needing a dynamic policy.   Hence, dynamic policies cannot be 
dismissed in the architecture.

Complementary settings are provided for DPNs, Installed DPN policies, 
Interfaces and their protocols as well as Contexts.  Note, we will not discuss 
in detail these elements but focus on the Policy Information model first.  
Other locations may be specified depending upon the outcome of the final draft.

The goal of the system is to ensure that the DPN has sufficient information at 
the time of packet processing to carry out policy enforcement.

We'll discuss these concepts and details tomorrow.

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] FPC Working Session - 31JAN2018

[Bertz, Lyle T [CTO]]

Good progress.


1.   Validated entity model can support DDDS selection (3GPP, IETF)

2.   2 proposals enclosed with updates per todays' discussion & a few open 
questions.

Tomorrow is open questions and starting policy.

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.


FPC Working Session - Topology Session 2r2.pptx
Description: FPC Working Session - Topology Session 2r2.pptx
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FPC - Topology

[Bertz, Lyle T [CTO]]

Comments inline

From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Tuesday, January 30, 2018 12:20 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; dmm@ietf.org
Subject: Re: [DMM] FPC - Topology


Hello Lyle,

I have comments on the slides, and could benefit from larger discussion on the 
mailing list.

On slide 3, the presentation indicates three Indexed Sets -- DPNs, Domains, and 
Interface Groups.  Reference to entities of those three entity types is made 
available by Keys into the relevant Indexed Set.  An Interface, on the other 
hand, is not shown as referenced by a Key into an Indexed Set.  All of the 
relevant Interface information is directly exhibited as attributes and 
sub-attributes of a DPN.  I think this is a consistent and somewhat 
understandable way of organizing the entities and attributes in our Information 
Model.

On slide 4, there is the following:


Missing - protocol & settings required for selection
Should Reside in Group?


I think it is more natural for the protocols and settings for an Interface to 
be shown as attributes for that Interface.  The Interface Group enables access 
to the list of Interfaces on the DPN.  So, selection of a DPN might proceed as 
follows:
- For each DPN, look at its Interface Groups
  = For each Interface Group, look at the protocols and settings that are 
supported.

If this isn't efficient, then we should reorganize the model.  Continuing to 
slide 5, there are three questions, which are relevant to this.

>> It requires a scan of all DPNs each time.  In v09 we put the groups as a 
>> separate structure (peer of the DPN) so that all DPNs that could meet the 
>> Roles of a Group were sufficient.  However, this did not help all cases.  I 
>> have seen 3 cases:

1.   A specific group was named in the selection (this is what DDS does as 
you need a domain to start the search).

2.   A role was needed (this is the academic option as in I see it in specs 
but not in practice).  It does exist as an internal selection mechanism, e.g. 
load balancing.  However, this a special case where we can designate it as a 
collection of homogenous groups. In our model the driver may be that we are 
looking for any Role in the tenant.
The takeaway is DPN selection starts with a named group in *current* standards 
and could be role based in customarily invisible methods.




  *   How are Interfaces specifically mapped to a Group (DPN with 2 interfaces 
but only 1 is part of Group)?

Right now the Interface is a part of the DPN definition, and the Interface 
Group was thought to be a way of collecting the information about what kinds of 
interfaces are available.  That is O.K. as far as having the ability to 
partition the Interfaces of a DPN into non-overlapping Groups, but there is no 
reverse structure for getting the Interface details from the Interface Group.  
If the latter is needed, then we should modify the definition of the Interface 
Group appropriately.  We might put an Interface-Key as an attribute of the 
Interface-Group, but the Interface Group is in an Indexed Set and the 
Interface-Key as currently (as an L-Key) defined only makes sense within the 
context of a DPN.

>> An interface can appear in multiple groups.  For example, if an operator 
>> used for peering with partners A & B we would see the same interface in a 
>> groups set aside for each partner.  A reverse structure is needed though as 
>> this is used for load balancing or just trying to figure out if the group is 
>> suitable for the request.


Perhaps we first need to know the structure of the DPN-selection Algorithm to 
know how best to organize Interfaces in the Information Model.


>> We cannot specify a specific DPN selection model; rather an algorithm that 
>> selects candidates that can meet the request needs.  There will always be 
>> other considerations such as network state, performance info from say an 
>> ALTO etc. that will drive the specific DPN selection.


  *
  *   What about Interfaces NOT in a group? What do we do with those settings?

In the current DPN definition, this is not a problem... right?

>> It is not a problem for a DPN but it would only be used for internal 
>> selection.

  *
  *   Relation be Roles & Interfaces is unclear

For a DPN to serve a particular role, it needs to have certain types of 
Interfaces.  A substantial part of the "type" of an interface is determined by 
the set of Protocols that the Interface supports.  Besides that, the Interfaces 
will have certain Settings that further define their usefulness.


Slide 6 encodes a great deal of information, some of which depends on an 
understanding of DDDS.  Maybe it is appropriate to include within the FPC 
document an appendix recounting the salient details of DDDS, with some emphasis 
on the DDDS view of Interface Groups and DPN selection.

If yo

[DMM] FYI - FPC Working sessions

[Bertz, Lyle T [CTO]]

All,

Apologies for sending out tomorrow's meeting directly.  Enclosed is an invite 
for daily FPC working sessions (Wednesday through Friday).  We'll focus on 
policy and keep iterating as we progress.

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.
--- Begin Message ---
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Bertz, Lyle T [CTO]":MAILTO:lyle.t.be...@sprint.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Charlie Pe
 rkins:MAILTO:charles.perk...@earthlink.net
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Satoru Mat
 sushima:MAILTO:satoru.matsush...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Marco Lieb
 sch:MAILTO:marco.lieb...@neclab.eu
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Sri Gundav
 elli (sgundave):MAILTO:sgund...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moses, Dan
 ny":MAILTO:danny.mo...@intel.com
DESCRIPTION;LANGUAGE=en-US:1 hour.\n\nWe’ll try to complete policy.  I’
 ll set up a few use cases as well.  We’ll only focus on policy aspects o
 f the context.\n\nProposed Use Case(s) (all assume DPN Selection has occur
 red)\n\n3 policies are proposed\n1.	Account for and DROP all port 22 desti
 ned to the mobile.\n2.	Set the AMBR for all traffic from 10.5.5.0 to 3Mbps
 .\n3.	For (UE on port 318 and 10.6.5.5 port 9335) account on bucket X\, se
 t traffic-class to Y\, set max bit rate to 2Mbps.\n\nPart 1 – Basic Poli
 cy Management\n1.	Create a Descriptor.\n2.	Create an Action.\n3.	Create a 
 Rule.\n4.	Create a Policy.\n\nPart 2 – Mobility Policy Management (singl
 e context).\n5.	Create a Mobility Context with a pre-configured policy.\n6
 .	Create a Mobility Context with a dynamic policy.\n7.	Change the DPN assi
 gned in the SGW / MAG role (mobile moves)\, aka handover in a \na.	make be
 fore break model.\nb.	break before make.\n\nPart 3 – Secondary context (
 bearers)\n8.	Add a secondary context\n9.	Secondary context update based up
 on 7a and 7b.\n10.	Remove a secondary context\n\n\n\n\n...
 ..
 \n--> Join Skype Meeting\nTrouble Joining? Try
  Skype Web App <https://meet.ad.sprint.com/lyle.t.bertz/305GZ9T8?sl=1>  \n
 Join by phone\n913-315-1921   (US) 		English (United Sta
 tes) \n913-553-3030   (US) 		English (United States)  \n
 Find a local number <https://dialin.ad.sprint.com>  \n\nConference ID: 389
 5350\n Forgot your dial-in PIN? <https://dialin.ad.sprint.com>  |Help
\n\n \nPlease see the   find a local number   link above for toll free 
 numbers \n[!OC([1033])!]\n
 ..
 ...\n\n
RRULE:FREQ=DAILY;UNTIL=20180202T15Z;INTERVAL=1
SUMMARY;LANGUAGE=en-US:FPC Working Session
DTSTART;TZID=Central Standard Time:20180131T09
DTEND;TZID=Central Standard Time:20180131T10
UID:04008200E00074C5B7101A82E008F02A54450099D301000
 01000509D60F510BF294FBC875D9D83DCFA21
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20180129T185416Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Skype Meeting
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:954013666
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
--- End Message ---
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] FPC Touchpoint - Interface Groups

[Bertz, Lyle T [CTO]]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Bertz, Lyle T [CTO]":MAILTO:lyle.t.be...@sprint.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=dmm@ietf.o
 rg:MAILTO:dmm@ietf.org
DESCRIPTION;LANGUAGE=en-US:All\,\n\nThis will be a very short working sessi
 on on Interface Groups and the selection use case.\n\nAgenda:\nProposed In
 terface Group Model\, DPN (Topology Model) in support of the selection use
  case.\n\nUse Case:\nSelection of suitable DPN Interface\n\nTopology Eleme
 nts:\nDPN-1\, Role = PGW\, Reference Points (protocols) = S5 (gtp)\, S5 (p
 mip)\, GTP-U Sequence Numbers = OFF\nDPN-2\, Role = PGW\, Reference Points
  = S5 (gtp)\, S8 (gtp)\nDPN-3\, Role = LMA\, Reference Points = LMA (pmip)
 \n\nSelect DPNs that can serve as\nA - PGW can serve an S5 Reference point
  with Sequence Numbers ON (answer should be DPN-2).\nB - PGWs can serve an
  S5 Reference point with Sequence Numbers OFF (answer should be DPN-1 or D
 PN-2)\nC – LMA using pmip (answer should be DPN-3)\n\nIf this agenda doe
 s not fit well let’s change it up (suggestions welcomed).\n\n...
 ..
 \n--> Join Skype Meeti
 ng<https://meet.ad.sprint.com/lyle.t.bertz/305GZ9T8>\n  Trouble Joining? T
 ry Skype Web App<https://meet.ad.sprint.com/lyle.t.bertz/305GZ9T8?sl=1>\nJ
 oin by phone\n913-315-1921 (US) English (Uni
 ted States)\n913-553-3030 (US) English (Unit
 ed States)\nFind a local number<https://dialin.ad.sprint.com>\n\nConferenc
 e ID: 3895350\n Forgot your dial-in PIN?<https://dialin.ad.sprint.com> |He
 lp<https://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033=5=20
 09>\n\n\nPlease see the   find a local number   link above for toll free n
 umbers\n[!OC([1033])!]\n..
 ..
 .\n\n\n\n  \n\nThis e-mail may
  contain Sprint proprietary information intended for the sole use of the r
 ecipient(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
 .\n
SUMMARY;LANGUAGE=en-US:FPC Touchpoint - Interface Groups 
DTSTART;TZID=Central Standard Time:20180130T09
DTEND;TZID=Central Standard Time:20180130T093000
UID:04008200E00074C5B7101A82E00870395314FE98D301000
 01000D105CE11A98E30488DDDE344070FCD39
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20180129T183835Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Skype Meeting
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:920459234
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Policy in the FPC draft - definitions, context transfer, keys, indexing, etc.

[Bertz, Lyle T [CTO]]

Charlie,

Thanks for the example.   A couple of notes.

I appears that in your proposed terminology for Descriptors and Actions it is 
not clear where Attribute Values appear.  Are they the Settings we’ve been 
using?

To your proposal “For simplicity, I suggest that the Policy Keys enable access 
to the same policies throughout a Domain.”  I would point out that in the 
Naming section (usually Section 4.4 in many of the drafts) we note that the 
keys are universal to the tenant and analogous to the G-Key.   Thus, any Client 
signaling on behalf of the same tenant will use the same Policy keys.  If we 
want these keys to span multiple tenants the domain concept may be practical 
but we need to be clear about the scope (is it a G++ key ;) )?  Also, we can’t 
assume much higher order coordination.

As to you point about looking at multiple locations for Assigned vs. Embedded 
(dynamic) rules, it is a known issue.

The problem is lifecycle.  Dynamic Rules are typically signaled via special 
instructions in a mobility protocol or, more likely, using another interface.   
In our case we planned to place them in the Mobility Context just to ensure 
they disappear with the Context and the Policy subtree does not contain Rules 
that can come/go quickly and quickly increases the size of the Policy Set (it 
will be the size of all policies in the system).   If we put it in the Policy 
tree we now have housekeeping of Rule deletion in the Policy tree.  It’s a 
tradeoff.   We noticed that using only the Policy Set (no embedded Rule 
concept) was tough on the over the wire operations.  For example we needed 
either 2 operations, specific order processing (policies before context) for 
operations and coordination between people working on static policy and the 
mobility protocol (which is what ultimately killed the design as humans and 
call processing operate at two different speeds).  The other issue was that a 
lot of create/delete on a large index was not performing well in the DPN or SDN 
controller.

It’s always tradeoffs. For the DPN it knows it needs more work for the Embedded 
(Context) Rule.  The Agent / Client are responsible for installing the pre 
configured policy on the DPN so that it no blocking occurs when an Assigned 
Policy is referenced in a Context.


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Charlie Perkins
Sent: Sunday, January 28, 2018 11:04 AM
To: dmm@ietf.org
Subject: [DMM] Policy in the FPC draft - definitions, context transfer, keys, 
indexing, etc.


Hello folks,

Policy seems always to be complicated.  I wrote up a scenario that, I think, 
captures many of the complications and relevant areas of application.  I also 
think the explanations about policy management as used in the scenario mostly 
represent the intention of the text currently in the FPC draft.  If the 
description about how policy is managed for the handover scenario is 
appropriate, I would like to use it and carry out a slight reorganization of 
the descriptions in the draft.

Regards,
Charlie P.

==

Example for mobile node movement from DPN-1 to DPN-2.

MN has two flows:

  *   = F1: best effort traffic
  *   = F2: voice call


When MN attaches to the access network of DPN-1, DPN-1 constructs a Mobility 
Context for MN.  It has the following (say, at network entry):

  *   = MN's IP address (MN_IP)
  *   = Policy X for F1
  *   = Policy Y for F2
  *   = other stuff (charging ID, current remaining credit, ...)


When MN moves to the access network of DPN-2, DPN-2 should receive the Mobility 
Context for MN from DPN-1, and make the necessary modifications so that the 
Mobility Context for MN is parameterized for operation with DPN-2.

Suppose that for this example, DPN-1 routes all traffic to/from MN through a 
common gateway G-11.  Also suppose that FPC Client has installed two policies 
on both DPN-1 and DPN-2 -- one for best effort traffic, one for voice.

Then DPN-1 might store in the Mobility Context for MN the following rules:

  *   = R1: If (packet belongs to flow F1), then route through G11
  *   = R2: If (packet belongs to flow F2), then route through G11
  *   = R3: Else, drop

In simplest terms, at DPN-1 don't support any fancy applications, and route all 
packets through G11.  Observe that the actual rules would certainly be 
different, but I think this is sufficient for the example.  As this description 
of the scenario proceeds, the need for other policies will be considered.

How did rules R1, R2, and R3 get installed on DPN-1?  Presumably the FPC Client 
has a list of policies that are supported in the Domain (i.e., operator's 
network).  One policy (X) could be called "Handling-Best-Effort" with 
Policy-Key P-12 and the other policy (Y) could be called "Handling-Voice" with 
Policy-Key P-37.  Keys P-12 and P-37 are unique within the namespace available 
to the FPC-Client for data-plane 

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Bertz, Lyle T [CTO]]

​

wrt

"What if we make that to be two different access-network features, and enable 
selection of Interface Groups for each feature?"


> emergency calls when roaming are not treated the same when they are domestic. 
>   this is especially true when it comes from an automobile.In fact, they 
> are often set aside as different APNs.   I'd like to be able to support the 
> current DDDS implementations as well as TS 29.303.  Furthermore, such 
> scenarios are indexed given their criticality; requiring an index to be built 
> from a feature scan or security scenarios is not placing the operator in a 
> comfortable situation.




From: Charlie Perkins <charles.perk...@earthlink.net>
Sent: Monday, January 22, 2018 7:10 PM
To: Bertz, Lyle T [CTO]
Cc: dmm@ietf.org
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

Thanks for the detailed reply.  It clears up a lot of questions in my mind.  To 
briefly reply:

- The reason I was asking about whether or not an Interface Group lived on a 
DPN was to help me figure out how to structure the Interface Group definition.  
It's already structured as an Indexed Set, and so we will have an 
Interface-Group-Key.  The DPN structure will have a list of such keys, for each 
Interface Group that exists and includes an Interface from the DPN.  I think 
this is O.K. for your scenario of different security zones.  Notably, we do not 
provide that as an attribute of an Interface, but then again I don't think we 
could reasonably be expected to delineate all possible attributes of Interfaces.

An Interface Group will also have a DPN-Key, for the DPN that hosts its 
interfaces.

Your example about having to select a DPN to handle emergency calls as well as 
"normal" call processing is very interesting.  What if we make that to be two 
different access-network features, and enable selection of Interface Groups for 
each feature?  Then we are still O.K. with having each Interface Group to be 
configured with only one DPN-Key.

Regards,
Charlie P.

On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:
Your scenarios are correct.  I think we are in agreement but I want to clarify 
a few things:

Wrt your statement “(b) it makes good sense for all the Interfaces of an 
Interface Group to be hosted on the same DPN.”

Ack.  I agree when the required interfaces within an Interface Group can be 
hosted on the same DPN to service a request.  However, we leave DPN selection 
up to the implementations as they may have proprietary or other perfectly good 
reasons not to do this.  By the above statement I have interpreted it as a 
recommendation and not a mandate, i.e. it is not a requirement in FPC to do 
this.   Is that correct?

Wrt the statement “I just want all of the Interfaces of an Interface Group to 
be on the same DPN”

I wish that was always the case but when the interface types are different or 
have a different purpose, e.g. normal calls vs. emergency calls, this is not 
the case in practice.

In the model then are you proposing the Interface Groups only reside under the 
DPN structure? If so, then one must load all DPNs and index them by Interface 
Groups Id to determine they are from the same group.  The purpose in pulling 
them out was to create a single Set that could be used to house the typing and 
common configuration information.   DPN interfaces assigned to support an 
Interface Group are then assigned to it.  Thus, if a DPN had 2 interfaces which 
are of the same type but in different security zones (or have different 
routes/networks served) they may not be able to serve in the same group.

Lyle



From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 3:25 PM
To: Bertz, Lyle T [CTO] 
<lyle.t.be...@sprint.com><mailto:lyle.t.be...@sprint.com>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

I agree that:

  1.  - Interface Groups are designed to be used to select DPN.
  2.  - Interface Groups may contain a number of different Interface Types
  3.  - There may be more than one Interface Group providing equivalent 
service, at least for the purpose of selecting a DPN.
For (1) -- I imagine that the selection process would look to make sure that 
the Interface Group has the proper interfaces that are needed (say, by the FPC 
Client).  Then, the FPC Client would select the DPN hosting the Interface 
Group, set up connectivity with the interfaces in the Peer Interface Group(s), 
and all is good.

For (2) -- this is really the motivation for the concept of Interface Groups.

For (3) -- really a follow-on from (1): the FPC Client would then look at the 
other properties of the DPN hosting the Interface Group, to determine which was 
the least cost, or highest benefit, choice.  Or alternatively the FPC Client 
would look at the Settings on the I

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Bertz, Lyle T [CTO]]

Your scenarios are correct.  I think we are in agreement but I want to clarify 
a few things:

Wrt your statement “(b) it makes good sense for all the Interfaces of an 
Interface Group to be hosted on the same DPN.”

Ack.  I agree when the required interfaces within an Interface Group can be 
hosted on the same DPN to service a request.  However, we leave DPN selection 
up to the implementations as they may have proprietary or other perfectly good 
reasons not to do this.  By the above statement I have interpreted it as a 
recommendation and not a mandate, i.e. it is not a requirement in FPC to do 
this.   Is that correct?

Wrt the statement “I just want all of the Interfaces of an Interface Group to 
be on the same DPN”

I wish that was always the case but when the interface types are different or 
have a different purpose, e.g. normal calls vs. emergency calls, this is not 
the case in practice.

In the model then are you proposing the Interface Groups only reside under the 
DPN structure? If so, then one must load all DPNs and index them by Interface 
Groups Id to determine they are from the same group.  The purpose in pulling 
them out was to create a single Set that could be used to house the typing and 
common configuration information.   DPN interfaces assigned to support an 
Interface Group are then assigned to it.  Thus, if a DPN had 2 interfaces which 
are of the same type but in different security zones (or have different 
routes/networks served) they may not be able to serve in the same group.

Lyle



From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 3:25 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: dmm@ietf.org
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

I agree that:

  1.  - Interface Groups are designed to be used to select DPN.
  2.  - Interface Groups may contain a number of different Interface Types
  3.  - There may be more than one Interface Group providing equivalent 
service, at least for the purpose of selecting a DPN.
For (1) -- I imagine that the selection process would look to make sure that 
the Interface Group has the proper interfaces that are needed (say, by the FPC 
Client).  Then, the FPC Client would select the DPN hosting the Interface 
Group, set up connectivity with the interfaces in the Peer Interface Group(s), 
and all is good.

For (2) -- this is really the motivation for the concept of Interface Groups.

For (3) -- really a follow-on from (1): the FPC Client would then look at the 
other properties of the DPN hosting the Interface Group, to determine which was 
the least cost, or highest benefit, choice.  Or alternatively the FPC Client 
would look at the Settings on the Interfaces of the Group, to see which 
Interfaces had the best fit for the purposes of the FPC Client.

If I have these scenarios right, then (a) we don't need to introduce any 
further virtual DPN definitions for proper operation and (b) it makes good 
sense for all the Interfaces of an Interface Group to be hosted on the same DPN.



The intent of the structure is for use during DPN selection.   To maintain it 
as a DPN means some DPNs are used during selection but others are not.

I agree with this completely, if I understand it.  After the selection occurs 
based on the suitability of the Interface Group, its function is done.  I did 
not in any way mean to suggest that the Interface Group was ever going to be a 
DPN or a virtual DPN.

I just want all of the Interfaces of an Interface Group to be on the same DPN.

Regards,
Charlie P.


On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:
k. I think that we are crossing conversations now.

“An Interface Group on a DPN would also have have attributes for Peer Interface 
Groups residing on other DPNs. ” < Did not see that.

Interface Groups (aka DPN Groups) can be used for DPN pool selection (multiple 
options) with a different interface strategy.
Interface Groups (aka DPN Groups) may also contain hetergeneous DPN-Type 
(interface types).  In this case the totality of services could be provided by 
more than one DPN.

If we say that this is ‘just a virtual DPN with a selection strategy of 
multiple underlying DPNs” I feel that we are jamming too many concepts into the 
DPN.  Overloading is okay until one is overloaded ;)

The intent of the structure is for use during DPN selection.   To maintain it 
as a DPN means some DPNs are used during selection but others are not.

I would propose that we keep this concept separate for now, look at proposed 
changes and then revisit this issue.


From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 12:07 PM
To: Bertz, Lyle T [CTO] 
<lyle.t.be...@sprint.com><mailto:lyle.t.be...@sprint.com>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

An Interface Group on a DPN would also ha

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

More inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

More follow-up inline.  We're getting closer.


On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:
>
> Hello Lyle and all,
>
> I think I agree with most of what you say below.  I'm concerned with how to 
> organize the information in the model.  So, for that purpose, please verify 
> whether my following understandings are correct.
>
> - The mobility context resides on a DPN.
>
> - The mobility context provides necessary information (e.g., QoS) for a 
> single mobile node.
>
> - The DPN uses it to manage data-plane traffic for that mobile node.
>
>>> This may be too broad of a view. What about a mobile node with 
>>> multiple mobility sessions? In such a case it may be managing one or 
>>> more (but not necessarily all of) the mobile node's mobility 
>>> sessions

Yes.  This is why I did not put "all" between "manage" and "data-plane".

LB > Ok.  We should probably be more explicit though for the casual observer if 
this language is used in the specification.

>
> In my earlier email on this subject, I was using Mobility Context as 
> describing something more associated with a mobile node, than with a 
> particular flow.  If you want it to mean "bearer", then we ought to call it a 
> Bearer.
>
> Maybe it would be easier to understand if we had something called a 
> "Mobile-Node Context", and in that context we had a set of Bearer Contexts 
> (or, just Bearers).  Each bearer would inherit from the Mobile Node context 
> simply by being part of it.  The Mobile Node context (serving as "parent") 
> would determine max bandwidth, IP address, etc. Back in the old days, we also 
> defined security aspects and some other factors, as part of what FPC would 
> call the "mobility context".
>
>>> We have several concepts that have hierarchy, e.g. Service Level (sr-id or 
>>> APN - apn-oi if I recall), device level, Mobility Session, bearers, flow 
>>> based filters (effectively living within a bearer).

There isn't anything about Service Level in the first part of the document, and 
I did not find anything about Service-ID that referenced mobility context.  
Mobility Context does not define Service Level. Similarly for APN.  The string 
"-oi" does not occur in the document.

Device level is a mystery to me.

Now, this isn't to say that your comment is irrelevant.  But, at minimum, the 
relevance is not spelled out in the current document.
LB> Ack.  They are not mentioned these in the documents; I was merely providing 
examples.

>>> We also have the 5G concepts as well.

We have, in fact, an infinitude of mutually contradictory 5G concepts.  
I might suggest that they look at Mobile IP, which was designed exactly 
to provide high-speed, low-latency, application-independent mobility 
management.  But, I digress.
LB> I am in agreement here but I believe that as Release 15 is finalized in 
3GPP we will see clarity.  My question would be if other next generation 
standards / technologies follow so that we have a tractable problem space but I 
too, digress.

>>>The one thing that is obvious is that the idea of hierarchy applies 
>>> whether it is pacers/shapers, bearers or filters that apply some charging / 
>>> gating / marking.  A light touch of lifecycle (fate sharing) amongst the 
>>> hierarchy,  data does not need to be repeated within the hierarchy and 
>>> building the data structure by requiring a parent id if it was a child 
>>> (implying the parent must exist!) was the best we could do without 
>>> necessarily making decisions that may appear to preclude a specific set of 
>>> mobile network technologies.

We certainly agree on the existence of hierarchy pervading our problem 
space.  And on the need to consider fate-sharing for between mobile-node 
authorizations and allocated bearers.  But my suggested approach of 
having the Bearers delineated under an inclusive Mobility Context 
provides for that in a natural way.  Perhaps the word "bearer" shows too 
much bias towards 3GPP, in which case we could simply use "mobility 
session" or "flow".
LB> Ack.  I think I would object to the use of Bearer.   Flow(s) may be too 
granular.  Maybe a verbal delineation between a Flows-Context (implying 1 or 
more) and some other concept such as Session-Context (old terminology) or 
Mobility-Context.imo though it may be more beneficial to state it as a 
context type and imply some 

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

Comments inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: Monday, January 22, 2018 11:54 AM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; Marco Liebsch 
<marco.lieb...@neclab.eu>
Cc: dmm@ietf.org
Subject: Re: Parent versus child mobility context

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how to 
organize the information in the model.  So, for that purpose, please verify 
whether my following understandings are correct.

- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a single 
mobile node.

- The DPN uses it to manage data-plane traffic for that mobile node.

>> This may be too broad of a view. What about a mobile node with multiple 
>> mobility sessions? In such a case it may be managing one or more (but not 
>> necessarily all of) the mobile node's mobility sessions

- Your description seems to imply that there are separate mobility contexts for 
each mobility session (i.e., for each bearer, or flow) that terminates (or 
originates) on the mobile node.

>> Yes.

In my earlier email on this subject, I was using Mobility Context as describing 
something more associated with a mobile node, than with a particular flow.  If 
you want it to mean "bearer", then we ought to call it a Bearer.

Maybe it would be easier to understand if we had something called a 
"Mobile-Node Context", and in that context we had a set of Bearer Contexts (or, 
just Bearers).  Each bearer would inherit from the Mobile Node context simply 
by being part of it.  The Mobile Node context (serving as "parent") would 
determine max bandwidth, IP address, etc. Back in the old days, we also defined 
security aspects and some other factors, as part of what FPC would call the 
"mobility context".

>> We have several concepts that have hierarchy, e.g. Service Level (sr-id or 
>> APN - apn-oi if I recall), device level, Mobility Session, bearers, flow 
>> based filters (effectively living within a bearer).   We also have the 5G 
>> concepts as well.  The one thing that is obvious is that the idea of 
>> hierarchy applies whether it is pacers/shapers, bearers or filters that 
>> apply some charging / gating / marking.  A light touch of lifecycle (fate 
>> sharing) amongst the hierarchy,  data does not need to be repeated within 
>> the hierarchy and building the data structure by requiring a parent id if it 
>> was a child (implying the parent must exist!) was the best we could do 
>> without necessarily making decisions that may appear to preclude a specific 
>> set of mobile network technologies. 

If you really want to maintain Parent Context and Child Context as independent 
structure elements, then we need to make a new indexed set for them.


>> We just used a pointer from a Context to a Parent Context. If the value was 
>> non-empty it was a child and the parent Id must point to a valid Context.

Regards,
Charlie P.


On 1/22/2018 5:30 AM, Bertz, Lyle T [CTO] wrote:
> ++ mailing list
>
> I agree with you Marco.
>
> Keeping the parent/child relation is crucial.   Although we often cite 
> dedicated vs. default bearers (LTE) we need to also ack that we use 
> hierarchical concepts throughout mobility and forwarding management 
> protocols, e.g. meters, session and sub-session (includes accounting), etc.
>
> Lifecycle association here (fate sharing of the children with the parent) is 
> an important concept.  Many of the mobility systems assume gateways (LMAs and 
> MAGs) have knowledge of the relationships between sessions and sub-session 
> and will often kill the session in order to reduce signaling overhead.  They 
> also assume when installing a session / sub-session that any violation of 
> hierarchy rules, e.g. setting a child's max bit rate above a parent's, would 
> be properly enforced, i.e. it is an error or the child's value is ignored.
>
> For FPC we also use it to avoid sending redundant data (does one need 
> to send the mobile's IP address for any sort of sub-session work if it 
> is tied to a parent that already has it?)
>
> -Original Message-
> From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
> Sent: Monday, January 22, 2018 5:49 AM
> To: Charlie Perkins <charles.perk...@earthlink.net>; Bertz, Lyle T 
> [CTO] <lyle.t.be...@sprint.com>
> Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; Sri Gundavelli 
> (sgundave) <sgund...@cisco.com>; Moses, Danny <danny.mo...@intel.com>; 
> Weaver, Farni [CTO] <farni.wea...@sprint.com>; Matsushima Satoru 
> <satoru.matsush...@g.softbank.co.jp>
> Subject: RE: Parent versus child mobility context
>
> 

Re: [DMM] Parent versus child mobility context

[Bertz, Lyle T [CTO]]

++ mailing list

I agree with you Marco.

Keeping the parent/child relation is crucial.   Although we often cite 
dedicated vs. default bearers (LTE) we need to also ack that we use 
hierarchical concepts throughout mobility and forwarding management protocols, 
e.g. meters, session and sub-session (includes accounting), etc.

Lifecycle association here (fate sharing of the children with the parent) is an 
important concept.  Many of the mobility systems assume gateways (LMAs and 
MAGs) have knowledge of the relationships between sessions and sub-session and 
will often kill the session in order to reduce signaling overhead.  They also 
assume when installing a session / sub-session that any violation of hierarchy 
rules, e.g. setting a child's max bit rate above a parent's, would be properly 
enforced, i.e. it is an error or the child's value is ignored.

For FPC we also use it to avoid sending redundant data (does one need to send 
the mobile's IP address for any sort of sub-session work if it is tied to a 
parent that already has it?)

-Original Message-
From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins <charles.perk...@earthlink.net>; Bertz, Lyle T [CTO] 
<lyle.t.be...@sprint.com>
Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com>; Moses, Danny <danny.mo...@intel.com>; Weaver, Farni [CTO] 
<farni.wea...@sprint.com>; Matsushima Satoru 
<satoru.matsush...@g.softbank.co.jp>
Subject: RE: Parent versus child mobility context

That has been introduced to reflect e.g. dedicated bearers which come on top of 
default bearers hence have some level of dependency. If context associated with 
a default bearer gets closed, dependent context will follow. To me it makes 
sense. Others?

marco

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Montag, 22. Januar 2018 06:29
To: Bertz, Lyle T [CTO]
Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave); Moses, Danny; 
Weaver, Farni [CTO]; Matsushima Satoru
Subject: Parent versus child mobility context


Hello folks,

I have looked at this several times, and I would like to propose simplifying it 
to simply be a mobility context.  I don't see that the extra complication is 
worth it, especially right now.  If, in the future, we need it for something, 
we could put it back in.

Thanks for your consideration of this request.

Regards,
Charlie P.



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

Re: [DMM] Indexed sets

[Bertz, Lyle T [CTO]]

I agree with the text below.  The text is great but your Example 4 is a bit 
confusing to me.  Hopefully you can help me out with that later or having it in 
the entire revision will probably clear that up for me (it is often hard to see 
clarity in the snippets).

I would change "the YANG models" to "the FPC YANG models" as we do not want to 
speak for all YANG models.


-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Sunday, January 21, 2018 11:11 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: Marco Liebsch <marco.lieb...@neclab.eu>; Satoru Matsushima 
<satoru.matsush...@gmail.com>; Sri Gundavelli (sgundave) <sgund...@cisco.com>; 
Moses, Danny <danny.mo...@intel.com>; Weaver, Farni [CTO] 
<farni.wea...@sprint.com>; Matsushima Satoru 
<satoru.matsush...@g.softbank.co.jp>
Subject: Indexed sets

Hello folks,

Here is some relevant text I developed to explain this concept.  It was mostly 
present in the previous document I sent out last week. Below, I have some 
follow-up questions regarding the concept.

>To encourage re-use, the YANG models define indexed sets of various
>types of entities.  To access such an model entity, other model
>elements contain an attribute which is typically denoted as
> "entity-
>Id".  When such an attribute is encountered, the referencing model
>element will indicate how to supply any needed values so that the
>entity model will be fully defined when used in any instance of the
>referencing model element.  For example: Figure 4 shows 2 entities:
>
>   EntityA definition references entityB model elements.
>
>   EntityB model elements are in a set indexed by entity-Id.
>
>Each EntityB model element has an Id which allows it to be uniquely
>identified, and a Type which specifies its form, allowing for
>creation of an instance by inserting entityB-Values as indicated.
>  .
>  .
>  |
>  +-[entityA]
>  |  +-[entityB-Id]
>  |  +-[entityB-Values]
>  .
>  .
>  |
>  +-[entityB] 
>  |  +-[entityB-Id]  (M)
>  |  +-[entityB-Type]
>  .
>  .
>
> Figure 4: Indexed sets of entities
>
>Indexed sets are specified for the following kinds of entities:
>
>   Domains
>   DPNs
>   Policies
>   Descriptors
>   Actions
>   Interface Groups

==

According to this, for example with "DPN", we would have a DPN-Id that allows 
one to locate the DPN (i.e., find what had been previously called a 
DPN-reference).  With that in mind, I put in the following lines in the DPN 
structure:

> |
> +-[DPN] 
> | +-[DPN-Id] ,  (O)

But this isn't really correct.  As I read it, the structure would mean that 
there is a thing called a "DPN-Id Key", and another thing called a "DPN-ID 
Name".  What we really want is a DPN-Key and a DPN-Name.

That could be specified more simply as follows:

> |
> +-[DPN] ,  (O) 
>

If we could use this to mean that there are attributes denoted "DPN-Key"
and "DPN-Name", then we have a natural and understandable structure. These 
attributes would apply to the *elements* of the DPN Set, not the DPN-Set 
itself.  In this case, I would rewrite the relevant parts of the document to 
replace instances of "DPN-Id" to instead use "DPN-Key".  And similarly for 
other indexed sets.

I hope you will agree, so that we can get to unambiguous language for 
describing this important concept without the currently existing redundancy.

Somewhat less important, but still of interest:

In the example above, there seems to be an implicitly described entity called a 
"DPN-Set" which is a set of DPNs.  In the text, when we need to refer to the 
set of DPNs, I propose that we use exactly the naming convention that it is 
called "DPN-Set".  That would be slightly but significantly different than "a 
set of DPNs", and if you approve, the nomenclaure "DPN Set" (i.e., lacking the 
'-') should probably not be used.

Regards,
Charlie P.




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

Re: [DMM] Question about Interface Groups

[Bertz, Lyle T [CTO]]

No, I don’t think they should reside under a DPN.   Groups like these also span 
multiple DPNs which would make containment graphs far too confusing.


From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Sunday, January 21, 2018 10:51 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: Marco Liebsch <marco.lieb...@neclab.eu>; Satoru Matsushima 
<satoru.matsush...@gmail.com>; Sri Gundavelli (sgundave) <sgund...@cisco.com>; 
Moses, Danny <danny.mo...@intel.com>; Weaver, Farni [CTO] 
<farni.wea...@sprint.com>; Matsushima Satoru 
<satoru.matsush...@g.softbank.co.jp>
Subject: Question about Interface Groups

Hello folks,

Can we have it so that all the Interfaces of an "Interface Group" (formerly, 
"DPN Group") reside on the same DPN?

If so, I can make good sense out of the text in the document, but otherwise I 
think there are big problems.

I have some other questions, but this is the main thing right now.  If the 
answer to my question is "Yes" I think I will have a sensible revision tomorrow.

I have some more questions, not quite as important, which I will put in 
separate emails.

Regards,
Charlie P.
On 1/18/2018 5:26 AM, Bertz, Lyle T [CTO] wrote:
Charlie,

Glad to hear things are going well.  I’m looking forward to your document 
update.

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] New Version Notification for draft-bertz-dime-policygroups-05.txt

[Bertz, Lyle T [CTO]]

Version bump and

we have a basic implementation (just the data structures) started here


https://gerrit.opencord.org/#/admin/projects/c3po?



A new version of I-D, draft-bertz-dime-policygroups-05.txt
has been successfully submitted by Lyle Bertz and posted to the
IETF repository.

Name:   draft-bertz-dime-policygroups
Revision:   05
Title:  Diameter Policy Groups and Sets
Document date:  2017-12-29
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-bertz-dime-policygroups-05.txt
Status: https://datatracker.ietf.org/doc/draft-bertz-dime-policygroups/
Htmlized:   https://tools.ietf.org/html/draft-bertz-dime-policygroups-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-bertz-dime-policygroups-05
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-bertz-dime-policygroups-05

Abstract:
   This document defines optional Diameter attributes for efficient
   policy provisioning.




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.

The IETF Secretariat



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] New Version Notification for draft-bertz-dime-diamimpr-01.txt

[Bertz, Lyle T [CTO]]

This is a version bump


A new version of I-D, draft-bertz-dime-diamimpr-01.txt
has been successfully submitted by Lyle Bertz and posted to the
IETF repository.

Name:   draft-bertz-dime-diamimpr
Revision:   01
Title:  Diameter Specification Recommendations
Document date:  2017-12-29
Group:  Individual Submission
Pages:  33
URL:
https://www.ietf.org/internet-drafts/draft-bertz-dime-diamimpr-01.txt
Status: https://datatracker.ietf.org/doc/draft-bertz-dime-diamimpr/
Htmlized:   https://tools.ietf.org/html/draft-bertz-dime-diamimpr-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-bertz-dime-diamimpr-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-bertz-dime-diamimpr-01

Abstract:
   This document reports on formatting errors, uses cases, and
   inconsistencies found in various standards specifications related to
   the Diameter interface requirements.  Recommendations are made to
   reduce errors, support common use cases and build specifications in
   such a way that programmatic verification of Diameter specifications
   can be done with minimal to no errors.




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.

The IETF Secretariat


[https://ssl.gstatic.com/ui/v1/icons/mail/no_photo.png]?





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] New Version Notification for draft-bertz-dime-predictunits-03.txt

[Bertz, Lyle T [CTO]]

This is a version bump


A new version of I-D, draft-bertz-dime-predictunits-03.txt
has been successfully submitted by Lyle Bertz and posted to the
IETF repository.

Name:   draft-bertz-dime-predictunits
Revision:   03
Title:  Diameter Predicted Units
Document date:  2017-12-29
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-bertz-dime-predictunits-03.txt
Status: https://datatracker.ietf.org/doc/draft-bertz-dime-predictunits/
Htmlized:   https://tools.ietf.org/html/draft-bertz-dime-predictunits-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-bertz-dime-predictunits-03
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-bertz-dime-predictunits-03

Abstract:
   This document specifies the conveyance of predicted usage information
   for proper dimensioning of network services that use Diameter based
   authorization.




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.

The IETF Secretariat

?




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

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

[Bertz, Lyle T [CTO]]

Wrt "So do we agree to change “Descriptor/Action-Value” to 
“Descriptor/Action-Value-Type” in Descriptor/Action-Definition set?" < I am 
okay with that.

-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
Sent: Monday, December 11, 2017 8:37 PM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: Moses, Danny <danny.mo...@intel.com>; dmm@ietf.org
Subject: Re: [DMM] FPC: Move Descriptor-/Action-Value into Rule

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.  
>

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

[Bertz, Lyle T [CTO]]

Type of the accompanying value.  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

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).



-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 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 keywo

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

[Bertz, Lyle T [CTO]]

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<mailto: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 proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
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-Settings = [ assign = ... ]
Action-Reference
Action-Id-Reference = 11

For 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 used.  The result w

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

[Bertz, Lyle T [CTO]]

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 proposal, we will call it Proposal 2:
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Descriptor-Value = in ip from any to assigned 22
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-Settings = [ assign = ... ]
Action-Reference
Action-Id-Reference = 11

For 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 used.  The result would be the elimination of the 
Descriptor-Definition and Action-Defintion.

The downside for Proposal 1 is reusability.  If I wanted to reuse the value "in 
ip from any to assigned 22" with a different list of Descriptors then it must 
be redefined in the model.  This is due to the fact that 
'Descriptor-Id-Reference' points to an entry in the Descriptors-Definitions 
List.  If I made a local key then reuse is possible but now I need a local key 
for each Descriptor and compound key of Rule-Id / Descriptor-Id  in the 
entry.   This also becomes problematic when the Descriptors are smaller than 
the Identifiers that reference them.

For Proposal 2, the idea is to permit settings (variable substitution) to occur 
within the Rule components.  In the I-D we have settings in the following 
locations:

* Interface-Settings in the DPN  - Settings that are important for an 
interface but not required to be known during DPN Selection.

* Interface-Settings in the DPN-Type - Settings that are crucial to DPN 
interface suitability during DPN selection.

* Interface-Settings in the DPN-Peer-Group - Settings that MUST be used 
when the specified DPN-Peer-Group is being communicated to. This is used for 
inter-operator or cross-border communications.

* Policy-Settings in Configurable-Policy - Settings that apply to a 
Configurable-Policy on a DPN.  Recall that Configurable-Policy affects MULTIPLE 
Mobility-Contexts (Mobility Sessions).

* Within a Mobility Context we have

* DPN-Settings-Complementary in the DPN-References - Settings 
applicable to the 

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

[Bertz, Lyle T [CTO]]

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 
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 のメール:
>
> 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

___
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



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

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

[Bertz, Lyle T [CTO]]

I support the adoption.

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, November 14, 2017 6:03 PM
To: dmm@ietf.org
Subject: [DMM] Call for adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

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




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] FPC version 09 - changes

[Bertz, Lyle T [CTO]]

All,


**This is not a new version of FPC**  I am merely sending out the list of 
changes for the one sent out last week.

Version 09 is the result of work at IETF 99 and subsequent meetings.

Changes since the last version:

1.   No new features added (sorry) but just better support for

a.   indexing / access and data types

b.  use cases

c.   limiting the creativity of others, i.e. creating well known locations 
to extend the model

2.   Information Model

a.   Added notation to denote data types and associated attributes such as 
Name

   i.  Shrinks 
document

 ii.  Allows 
designers to understand data types, e.g. Set vs. List

b.  Settings Strategy

   i.  Most 
properties are placed in structures noted as 

1.   Provides well known locations to place properties / extensions

2.   Allows for a deterministic search order for the Agent

3.   Used to complete or make concrete the Policies in question

c.   Full design review of the Topology tree

   i.  Improved 
support for DPN selection information

1.   Reminder: FPC permits Agent AND/OR Client to select DPNs and even 
policy placement

 ii.  Stronger 
support of Domain Concepts (which are used for slicing, dedicated cores, etc.)

d.  Policy simplified - much more like v03/v04

   i.  
Descriptors/Actions and Rules are largely the same

 ii.  
Rule-Definition is now a top level structure in Policy (it was buried in Policy)

iii.  
Elimination of Policy Group

e.  Context is now Mobility-Context to be more emphatic about what it is

f.Vports are now Configurable-Policy

   i.  
Reorganized to use DPN as key to speed up Client/Agent processing

 ii.  Assigns 
Policies directly (no more Policy-Groups)

g.   Mobility-Context

   i.  Allows 
for assignment of predefined Policy (in the policy tree) and then 
sub-assignment to a DPN

 ii.  
Dynamically built rules, e.g. those built during signaling that are unusable 
outside of the Mobility-Context, are embedded with DPN information

iii.  Settings 
at the Rule, DPN and Mobility-Context level provide a few locations for settings

3.   Messaging Model

a.   Cleaned up inconsistencies between headers and responses

b.  Reorganized based upon Information model updates

c.   Removed features no longer necessary due to other RFCs, e.g. use of 
PATCH frameworks eliminates needs for cloning

d.  Promoted one feature (Command bitsets) to mandatory as opposed to an 
optional feature (although it is an optional attribute).



4.   TODOs

a.   Clean up errors/omissions/etc

b.  Feedback from all

c.   Ensure we are good with Domains

d.  Examples, examples, examples validating the information model (they do 
NOT need to be in the document)

The document is much smaller.  This is due to 3a, 3c, 2a and 2d.

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

Re: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt

[Bertz, Lyle T [CTO]]

There appears to be a bug in either the submission tool or confd (I suspect it 
has to do with caching and updates).  Will take this offline. 

Lyle

-Original Message-
From: Benoit Claise [mailto:bcla...@cisco.com] 
Sent: Monday, March 13, 2017 8:19 AM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>; 
draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org; rkre...@cesnet.cz; Per Hedeland 
<p...@tail-f.com>
Subject: Re: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt

Including Radek (developing yanglint) and Per (confd), in case they've got the 
bandwidth to help you.

Regards, Benoit
> We will as soon as we can isolate the error.  The error is unhelpful.  Do you 
> have any guidance on it?
>
> Also, is there any way to rid ourselves of those tailf warnings?  They happen 
> quite often and our developers now ignore most errors coming from confd as 
> noise.
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Benoit Claise
> Sent: Monday, March 13, 2017 6:17 AM
> To: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org
> Subject: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt
>
> Dear authors,
>
> I see that you have posted a new draft version. Great.
> Note that ietf-dmm-fpc-p...@2017-03-08.yang still fails validation.
> See 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cl
> aise.be%2FIETFYANGPageCompilation.html=02%7C01%7Clyle.t.bertz%40s
> print.com%7C05650ca67a00476a5b9008d46a03b748%7C4f8bc0acbd784bf5b55f1b3
> 1301d9adf%7C0%7C0%7C636250011571481523=RwDlcOxUAxOoCew0qs9nMQsjb
> tZ0vXQ4HgUKL8ABdn8%3D=0 Please correct the mistake and post a 
> new version.
>
> Regards, Benoit
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fdmm=02%7C01%7Clyle.t.bertz%40sprin
> t.com%7C05650ca67a00476a5b9008d46a03b748%7C4f8bc0acbd784bf5b55f1b31301
> d9adf%7C0%7C0%7C636250011571481523=u5sSjji78baaTpWJkQWc0Wk2Y1Ajt
> zRhWkSJAn5cgcQ%3D=0
>
> 
>
> 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

Re: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt

[Bertz, Lyle T [CTO]]

We will as soon as we can isolate the error.  The error is unhelpful.  Do you 
have any guidance on it?

Also, is there any way to rid ourselves of those tailf warnings?  They happen 
quite often and our developers now ignore most errors coming from confd as 
noise.

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Monday, March 13, 2017 6:17 AM
To: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org
Subject: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt

Dear authors,

I see that you have posted a new draft version. Great.
Note that ietf-dmm-fpc-p...@2017-03-08.yang still fails validation.
See 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.claise.be%2FIETFYANGPageCompilation.html=02%7C01%7Clyle.t.bertz%40sprint.com%7C05650ca67a00476a5b9008d46a03b748%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636250011571481523=RwDlcOxUAxOoCew0qs9nMQsjbtZ0vXQ4HgUKL8ABdn8%3D=0
Please correct the mistake and post a new version.

Regards, Benoit

___
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%7C05650ca67a00476a5b9008d46a03b748%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636250011571481523=u5sSjji78baaTpWJkQWc0Wk2Y1AjtzRhWkSJAn5cgcQ%3D=0



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

Re: [DMM] RFC 4006 failover of alternate and backup servers

[Bertz, Lyle T [CTO]]

Wrong list! My apologies! Please disregard.

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Thursday, February 02, 2017 9:21 AM
To: dmm@ietf.org
Subject: [DMM] RFC 4006 failover of alternate and backup servers

All,

The CC-Session-Failover AVP in its definition uses 'backup server' but the ENUM 
value for FAILOVER_SUPPORTED states


"Moving the credit-

   control message stream to a backup server MAY require that

   information related to the credit-control session should also be

   forwarded to an alternative server."



It is a bit vague to me what the point was here.  They use the term backup 
server and talk about the info related to credit-control session being 
forwarded to an 'alternate server' implying it is not the backup? But the 
diameter server in this case is the backup server.



Could someone elaborate on this please?  It seems a bit vague to me.



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

Re: [DMM] dime - New Meeting Session Request for IETF 98

[Bertz, Lyle T [CTO]]

k. so it's not in the dmm charter?

Where then should I submit the 'mobility over diameter' spec then?

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, February 01, 2017 10:28 PM
To: jouni.nospam ; dmm@ietf.org
Subject: Re: [DMM] dime - New Meeting Session Request for IETF 98

:) Its by design .. even your email client does not want you to leave DMM.

Thank you for all your contributions.

Sri



On 2/1/17, 5:00 PM, "dmm on behalf of jouni.nospam"  wrote:

>I was gently reminded that even if mobility could be achieved by
>tunneling packets over Diameter AVPs, it is not really in the charter
>of the DMM.. yet!
>
>..and now I will turn off the address autocompletion on this $¢@#&^!
>email client ;-)
>
>- Jouni
>
>
>
>> On Feb 1, 2017, at 7:51 AM, jouni.nospam  wrote:
>>
>> Folks,
>>
>> We have asked for 1h slot for the IETF98. The main topic would be
>>RFC4006bis. We might have other short status/progress updates on
>>Diameter group signaling, and e2e security.
>>
>> - Jouni & Lionel
>>
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> From: "\"IETF Meeting Session Request Tool\""
>>>
>>> Subject: dime - New Meeting Session Request for IETF 98
>>> Date: January 31, 2017 at 5:13:31 PM PST
>>> To: 
>>> Cc: dime-cha...@ietf.org, d...@ietf.org, jouni...@gmail.com,
>>>stephen.farr...@cs.tcd.ie
>>> Resent-From: 
>>> Resent-To: jouni.nos...@gmail.com, lionel.mor...@orange.com
>>>
>>>
>>>
>>> A new meeting session request has just been submitted by Jouni
>>>Korhonen, a Chair of the dime working group.
>>>
>>>
>>> -
>>> Working Group Name: Diameter Maintenance and Extensions Area Name:
>>> Operations and Management Area Session Requester: Jouni Korhonen
>>>
>>> Number of Sessions: 1
>>> Length of Session(s):  1 Hour
>>> Number of Attendees: 150
>>> Conflicts to Avoid:
>>> First Priority:  detnet tsvwg tsvarea quic iccrg Second Priority:
>>> 6man v6ops  intarea
>>>
>>>
>>>
>>> People who must be present:
>>>  Stephen Farrell
>>>  Lionel Morand
>>>  Jouni Korhonen
>>>
>>> Resources Requested:
>>>  Meetecho support in room
>>>
>>> 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



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

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

[Bertz, Lyle T [CTO]]

+1

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, January 31, 2017 3:04 AM
To: Charlie Perkins 
Cc: dmm@ietf.org
Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: 
draft-ietf-dmm-fpc-cpdp-05.txt]

Hello Charlie,

If we keep the port term, your proposal is very good. I support the adoption of 
the vport term.

Thanks and best regards,
Marco

On 25 Jan 2017, at 19:14, Charlie Perkins 
> wrote:

Hello Marco,

What would you think about replacing the term "port" by "virtual port", which 
would usually be shortened to "vport" (or "Vport")?

I think it would have several benefits:

  *   it seems intuitively appealing, at least to me
  *   it avoids the unacceptable clash with the traditional meanings of the 
word "port"
  *   it fits well with my understanding of "data-plane node" and "context".
  *   it's a relatively easy editorial change to the draft

Regards,
Charlie P.

On 1/17/2017 1:05 AM, Marco Liebsch wrote:

The meaning of port changed throughout the evolution of this draft. Up to 
version 3 a port was a

forwarding construct that binds traffic selectors to traffic treatment actions. 
Any other term,

e.g. rule, could have made it. These are created (attach), modified (handover) 
or deleted per

the mobile node's location, IP address, etc.



>From version 4, what has been a port before is now more the 'context' 
>structure, whereas

the inherited port term is used to group policies and bind them to context. A 
different term would be more obvious.

Policy group binding (PGB) or even the proposed FPG are ok, though I am a bit 
puzzled why Flow appears in here.



marco





-Original Message-

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima

Sent: Donnerstag, 29. Dezember 2016 03:31

To: Charlie Perkins

Cc: dmm@ietf.org

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



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




This e-mail may contain Sprint proprietary information intended for the sole 
use of the recipient(s). Any 

Re: [DMM] We can't extract the YANG model from draft-ietf-dmm-fpc-cpdp

[Bertz, Lyle T [CTO]]

Thank you Benoit for pointing this out.  We will correct in the next update.

Lyle

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Monday, October 24, 2016 10:07 AM
To: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org
Subject: [DMM] We can't extract the YANG model from draft-ietf-dmm-fpc-cpdp

Dear authors,

The YANG model in your draft doesn't follow the convention from RFC 7950, and 
therefore can't be extracted.
See https://tools.ietf.org/html/rfc6087 section 3.1 Also, use 
http://www.yangvalidator.org/ for troubleshooting.

Extracting 'ietf-ip-tunnel@   ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt',
Line 3451 - Yang module 'ietf-dmm-fpcbase' with no  and not 
starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 4057 - Yang module 
'ietf-dmm-fpcagent' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 4724 - Yang module 
'ietf-pmip-qos' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 5387 - Yang module 
'ietf-traffic-selector-types' with no  and not starting with 
'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 5980 - Yang module 
'ietf-dmm-threegpp' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 6601 - Yang module 
'ietf-dmm-fpc-pmip' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 6894 - Yang module 
'ietf-dmm-fpc-policyext' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 3451 - Yang module 
'ietf-dmm-fpcbase' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 4057 - Yang module 
'ietf-dmm-fpcagent' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 4724 - Yang module 
'ietf-pmip-qos' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 5387 - Yang module 
'ietf-traffic-selector-types' with no  and not starting with 
'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 5980 - Yang module 
'ietf-dmm-threegpp' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 6601 - Yang module 
'ietf-dmm-fpc-pmip' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 6894 - Yang module 
'ietf-dmm-fpc-policyext' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 3451 - Yang module 
'ietf-dmm-fpcbase' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 4057 - Yang module 
'ietf-dmm-fpcagent' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 4724 - Yang module 
'ietf-pmip-qos' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 5387 - Yang module 
'ietf-traffic-selector-types' with no  and not starting with 
'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 5980 - Yang module 
'ietf-dmm-threegpp' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 6601 - Yang module 
'ietf-dmm-fpc-pmip' with no  and not starting with 'example-'
ERROR: 'draft-ietf-dmm-fpc-cpdp-04.txt', Line 6894 - Yang module 
'ietf-dmm-fpc-policyext' with no  and not starting with 'example-'
ERROR: 'draft-toutain-lpwan-yang-static-context-hc-00.txt', Line 636
- Yang module 'LPWA-compression' with no  and not starting with 
'example-'
ERROR: 'draft-toutain-lpwan-yang-static-context-hc-00.txt', Line 636
- Yang module 'LPWA-compression' with no  and not starting with 
'example-'
ERROR: 'draft-toutain-lpwan-yang-static-context-hc-00.txt', Line 636
- Yang module 'LPWA-compression' with no  and not starting with 
'example-'
2016-06-20.yang'


Regards, Benoit

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



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

Re: [DMM] DMM FPC I-D - Implementation

[Bertz, Lyle T [CTO]]

You're correct.  The separation work mentioned below is SDN focused but 
multiple protocols between the Controller, acting as a FPC Agent, and DPN are 
used.

-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Sent: Monday, August 29, 2016 10:15 AM
To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com>
Cc: dmm@ietf.org; lionel.mor...@orange.com
Subject: Re: [DMM] DMM FPC I-D - Implementation

As I mentioned in my previous mail, 3GPP already supports control plane data 
plane separation, they just call it user plane control planes.

See:

https://en.wikipedia.org/wiki/System_Architecture_Evolution

I think you are confused by the SDN approaches in the control plane in 3GPP.

However, 3GPP decided not to pursue SDN. But they will pursue NFV instead.

FYI.

Regards,

Behcet

On Fri, Aug 26, 2016 at 3:00 PM, Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com> 
wrote:
> All,
>
>
>
> Last week at the Intel Developer Forum in San Francisco (US), Intel
> and Sprint demonstrated a virtual Evolved Packet Core (vEPC) that
> included, amongst other features, a SGW and PGW (3GPP functions similar to 
> MAG and
> LMA).   This software
>
> 1.   Used a Separated Control and Dataplane Node with an intermediate
> SDN Controller – Opendaylight’s Beryllium release.
>
> 2.   Used IETF DMM FPC-v03
> (https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/?include_tex
> t=1) for communication of some sessions (others were simulated to
> ensure we met the demonstration timelines).
>
>
>
> The Control and Dataplane software performs well (10Gbps down / 3Gbps
> up for 250K users) on a single Intel processor’s *core* based upon the
> open source DPDK libraries from Intel.  The demonstration shows the
> promise of separation of Control and Data planes.
>
>
>
> We had to deviate quite a bit from the version 03 specification to
> support 3GPP but version 04 adds the 3GPP model as an option.  Many of
> the general changes in version 04 are influenced by the implementation.
>
>
>
> Work is already underway to implement version 04 with several internal
> changes, e.g. moving from the Opendaylight MD-SAL (model driven)
> approach to the application driven (AD-SAL) approach, as focus is now
> on performance.  I hope to share more details in the future.  As a
> part of the final version of the FPC I-D we will submit an
> Implementation Status section in the draft per RFC 7942.
>
>
>
> Lyle Bertz
>
> Sprint
>
>
> 
>
> 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
>



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] DMM FPC I-D - Implementation

[Bertz, Lyle T [CTO]]

All,

Last week at the Intel Developer Forum in San Francisco (US), Intel and Sprint 
demonstrated a virtual Evolved Packet Core (vEPC) that included, amongst other 
features, a SGW and PGW (3GPP functions similar to MAG and LMA).   This software

1.   Used a Separated Control and Dataplane Node with an intermediate SDN 
Controller - Opendaylight's Beryllium release.

2.   Used IETF DMM FPC-v03 
(https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/?include_text=1) for 
communication of some sessions (others were simulated to ensure we met the 
demonstration timelines).

The Control and Dataplane software performs well (10Gbps down / 3Gbps up for 
250K users) on a single Intel processor's *core* based upon the open source 
DPDK libraries from Intel.  The demonstration shows the promise of separation 
of Control and Data planes.

We had to deviate quite a bit from the version 03 specification to support 3GPP 
but version 04 adds the 3GPP model as an option.  Many of the general changes 
in version 04 are influenced by the implementation.

Work is already underway to implement version 04 with several internal changes, 
e.g. moving from the Opendaylight MD-SAL (model driven) approach to the 
application driven (AD-SAL) approach, as focus is now on performance.  I hope 
to share more details in the future.  As a part of the final version of the FPC 
I-D we will submit an Implementation Status section in the draft per RFC 7942.

Lyle Bertz
Sprint



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