[DMM] IETF117 side meeting on Mobile Traffic Steering

[Marco Liebsch]

We set up a 1 hour early bird side meeting at IETF117 on Monday, 24th July
2023, 08:30-09:30 local time in SF.

This is to follow-up a good discussion during and after the DMM WG session
at IETF116 and some mailing list as well as offline discussion until now.

 

Timing: 24th July 2023, 08:30-09:30

Location: Golden Gate 4 room

Link to side meetings: https://wiki.ietf.org/en/meeting/117/sidemeetings

 

We booked the smaller room but will also provide a zoom link for remote
attendance (please check the side meeting table before the meeting).

 

We'll have a short intro and background part followed by 2-3 short and crisp
presentations on use cases, requirements, BCP, gaps and more.

 

Intention is to conclude the side meeting with some better understanding of
the need and value of additional standards effort, in particular in
the scope of the IETF, towards the support of advanced mobile scenarios.
Results of the side meeting will be summarized then in the DMM WG meeting
during the week.

 

Looking forward to your contributions.

 

marco



smime.p7s
Description: S/MIME cryptographic signature
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments on "Mobile traffic steering"

[Marco Liebsch]

HI David,

many thanks for the positive and constructive feedback during the session
and on the mailing list.

 

I agree with your view of how mobile communication systems evolved in the
past and have several directions
in mind what and how it could be improved.

 

The point we wanted to make with this presentation and discussion is that
for an evolution of how mobile communication 
ecosystems can/will be used, the end-to-end view is required. And today’s
mobile communication systems don’t have all end-to-end
aspects in scope.

 

The intention is to develop a view how IETF technology can complement any
mobile communication system here with well-defined
interfaces for control, data plane and maybe even management.  The latter
may also be useful if we consider steering traffic
across a single administrative domain. The good thing is that it does not
conflict with any internals of a standardized mobile communication system,
whether it is based on any of the known SDOs or a WiFi enterprise network
or... 

 

A fundamental starting point is to come up with a good set of use cases that
benefit from the level of traffic steering we suggest.

These should include any more advanced scenarios, e.g. HAPs made out of
non-terrestrial networked components, such as LEO satellites,
drones, whatever. Having a non-stationary or not-always-present network
where nodes may move or disappear from the sky for
movement, energy, or failure reasons, we may want to mitigate such impact to
existing data sessions. A HAP may for example have
a mobility anchor on-board to access a platform and its services. Steering
of session’s traffic between such nodes is required in
case of topological changes, not because of end-device mobility but mobility
of network nodes and service platforms.

This is just one example taken out of the sky .. ;-)

 

The same requirement may apply to more traditional systems and use cases, as
we brought during the DMM session.

We think this could be a starting point, also to argue why some level of
continuity on L3 may be useful. Then look at the different aspects

of connecting and inter-working with any mobile communication system as
sketched on the last slide of my presentation deck.

 

Looking forward to jointly moving this ahead.

 

marco 

 

 

From: dmm  On Behalf Of David Lake
Sent: Montag, 27. März 2023 03:29
To: dmm@ietf.org
Subject: [DMM] Comments on "Mobile traffic steering"

 

Hi Marco

 

Thank you for the very interesting presentation.

 

There has been some parallel discussion on this in the 6gip mailing list and
I think there is good work to do here.

 

My concern is that the current mobility solution in 3GPP is essentially
inherited from GPRS and is more about L2 tunnels that true IP connectivity.
Many user applications are able to work across current network irrespective
of the underlying ‘bit pipe’ – I am currently able to watch videos, make
WhatsApp and iMessage calls on my end device no matter which network I am
connected to whether local cellular or IETF WiFI.

 

By contrast, if I want to use the native dialer on my iPhone when roaming
(which is normally VoLTE when at home on Vodafone UK), I am not able despite
Vodafone UK operating an ePDG for VoWiFi.  Instead, they actively look to
see if I have roamed out of country and then ONLY allow me to a local
carrier and expensive roaming for SMS and voice.

 

If I were to be in the US, then with 2G/3G sunset, I would not be able to
make any calls or SMS on the native iPhone app but OTT applications would
work perfectly…

 

My point is whether we, as IETF, need to concern ourselves at all with the
internal workings of the 3GPP networks because OTT applications seem to work
irrespective of what network provider they are connected to.   It is only
when I try and use the operator’s own services that I seem to run into
trouble!

 

I think there would be value in being able to tie the quality of outcome in
service (e.g. QCI, 5QI) of my OTT application if I am using an LTE/5GNR
bearer – for example, in the same way that VoLTE media is steered to a
dedicated bearer, why can’t WhatsApp or Facetime media ALSO be steered to a
dedicated bearer?

 

Very happy to work on this!

 

David Lake

 

Tel: +44 (0)7711 736784



5G & 6G Innovation Centres

Institute for Communication Systems (ICS)
University of Surrey
Guildford
GU2 7XH

 



smime.p7s
Description: S/MIME cryptographic signature
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03

[Marco Liebsch]

I support progressing this version of the document on the experimental track.

marco

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Mittwoch, 9. Januar 2019 19:44
To: dmm@ietf.org
Subject: [DMM] WGLC on draft-ietf-dmm-pmipv6-dlif-03

Folks - As we discussed in the WG meeting at IETF103, we are issuing WGLC on 
https://www.ietf.org/id/draft-ietf-dmm-pmipv6-dlif-03.txt.

We have also made one key change to the document status, moving it from 
Standards Track to Experimental Track. We the chairs have talked to the authors 
and they are OK with this change. We are dong this as we are not sure about any 
potential vendor implementations and so we chose to keep this on experimental 
track.

The document went through several revisions and there were good amount of 
reviews on this document.  The authors have addressed all the comments and 
there are no open issues that we are tracking at this time. We believe the 
document is ready for IESG reviews and like to confirm the same from the 
working group.


The following message commences a two week WGLC for all feedback.

Document Link:
 
https://www.ietf.org/id/draft-ietf-dmm-pmipv6-dlif-03.txt

The target status for this document is "Experimental".

Please post any comments/concerns on the draft.


Thanks!
Dapeng & Sri


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

[DMM] extended data plane discussion - N6 traffic steering

[Marco Liebsch]

Folks,

we submitted a new ID which extends the current data plane discussion from 
N9/N3 to N6 interfaces
of the mobile system's architecture.

We could discuss the use cases, problem statement and principles with some 
before submission, but
post this initial draft to get the larger community's feedback before we update 
with more details and the
received feedback.

Your comments are appreciated.

Best regards,
marco



Name: draft-fattore-dmm-n6-cpdp-trafficsteering

Revision: 00

Title:Control-/Data Plane Aspects for N6 Traffic Steering

Document date:   2018-09-20

Group: Individual Submission

Pages:  12

URL:
https://www.ietf.org/internet-drafts/draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/

Htmlized:   
https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-trafficsteering-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering





Abstract:

   Current standardization effort on the evolution of the mobile

   communication system reconsiders the mobile data plane protocol.  The

   IETF DMM Working Group has work that proposes and analyzes various

   protocols as alternative to the GPRS Tunneling Protocol for User

   Plane (GTP-U) for an overlay deployment in between the mobile

   device's assigned data plane anchor and its current radio base

   station, which are denoted as N9 and N3 interfaces.  In the view of

   some future deployment and the original intent per the very early DMM

   WG charter, a mobile device's data plane anchor may be highly

   distributed and re-selected for optimization throughout a mobile

   device's communication with one or more correspondent services.  Such

   re-configuration has impact on the packet routing in between the

   mobile device's data plane anchor and the one or multiple data

   networks hosting the services, which is denoted as N6 interface.

   This draft proposes and discusses a solution to control, setup and

   maintain traffic treatment policy on the cellular communication

   system's N6 interface while taking the UE's PDU session settings per

   the cellular system's control plane, such as QoS and locator

   information, into account.




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

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

[Marco Liebsch]

Tom, Behcet, I think TEID may still be needed in some cases, e.g. for mapping 
to a radio bearer
or to avoid superfluous packet classification if it has been done on the 
packet's path beforehand
already.

IMO, for non-encapsulation protocols, overloading of id-loc space seems 
interesting if the attribute
cannot be carried in extensions. What about encoding QoS class/flow IDs in that 
space as well ;-) ?

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Donnerstag, 6. September 2018 18:22
To: Behcet Sarikaya
Cc: ta-miyas...@kddi-research.jp; dmm
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya  wrote:
>
>
> On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
>>
>> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
>>  wrote:
>> > My comments inline marked [SB]
>> >
>> >> > >>> It was never clear to me and no one could ever explain exactly
>> >> > >>> why a
>> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
>> >> > >>> was a
>> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
>> >> > >>> inner addresses
>> >> > >>> be used for accounting?
>> >> >
>> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>> >> > tunnel and hence consequently a bearer. Once the bearer context is
>> >> > identified the QoS and charging policy applicable to the bearer is
>> >> > applied.
>> >> > So the purpose of TEID is not just for accounting. Its for QoS
>> >> > treatment,
>> >> > charging and bearer context identification.
>> >>
>> >> You told me what a TEID is but you didn’t say why you need to use it
>> >> versus using the destination IP address for the tunnel.
>> >>
>> >>
>> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>> >> > session whereas the QFI carried in GTPU extension header identifies
>> >> > the
>> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>> >>
>> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
>> >> which
>> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
>> >> encapsualting node, and (4) the decapsulating node.
>> >>
>> >> So again, why use more space in the packet, when you have sufficient
>> >> information to identify a user, and therefore their packet policy?
>> >>
>> > [SB] Lets say we only use UE IP address and no TEID. How will you
>> > identify
>> > the bearer context the packet belongs? One UE may use multiple radio
>> > bearers
>> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these
>> > are
>> > IP level markings which could be changed by any on path routers. In
>> > order to
>> > uniquely identify the bearer / qos flow a particular packet for a UE
>> > belongs, GTPU uses TEID.
>>
>> Sridhar,
>>
>> Couldn't the TEID be encoded in the outer IP address of an
>> encpasulation or network overlay in a similar way that VNIs are
>> encoded in IP addresses in virtual networking?
>>
>> Tom
>>
>
> ILA if used would remove any need for tunneling and TEID is for tunneling.
>
Behcet,

I was thinking if TEID is need then that can be encoded in a locator
easily enough.

Tom

> Actually if you read 29.244 it is completely based on legacy protocols with
> no IdLoc content at all, as Shunsuke mentioned.
>
> Behcet
>>
>> >
>> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
>> > are
>> > not always unique. The same IP pools can be shared across multiple PDNs
>> > /
>> > DNs as long as these PDNs / DNs are separate autonomous networks. So
>> > just
>> > relying on UE IP address alone will result in wrong context
>> > identification
>> > for the uplink traffic. There is a clear one to one mapping of Radio
>> > bearer
>> > to the EPS bearer / QoS flow required all the way upto the anchor node
>> > for
>> > charging and QoS treatment. This comes from the requirements in stage 2
>> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
>> > 5G).
>> >
>> > There are also requirements to support non-IP protocols like Ethernet
>> > PDU
>> > and Unstructured PDU types in 5G.
>> >
>> >> >>
>> >> > >>> How can packets be sent if the session is not setup. If the
>> >> > >>> session
>> >> > >>> is not setup, the encapsulator should have no state. And packets
>> >> > >>> should be
>> >> > >>> dropped locally and not go far to get an error back. This sounds
>> >> > >>> architecturally broken.
>> >> >
>> >> > [Sridhar] The purpose of GTP-U error indication is to signal in band
>> >> > to
>> >> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side
>> >> > is lost
>> >> > for any reason. "No session exist" does not mean Session
>> >>
>> >> What does lost mean? You mean the path from encapsulator to
>> >> decapsulator
>> >> is not working? And since we are in a packet network, that path can be
>> >> restored quite quickly.
>> >
>> >
>> > [SB] Lost here means - the 

Re: [DMM] draft-gundavelli-dmm-mfa

[Marco Liebsch]

Hi Arashmid,

slowly we move ahead ;-) but let's increase the pace to have a good picture 
before next meeting and solid material to discuss at IETF102.
Inline, please [ml2].

From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com]
Sent: Donnerstag, 7. Juni 2018 20:19
To: Marco Liebsch; Sri Gundavelli; dmm@ietf.org
Subject: RE: draft-gundavelli-dmm-mfa

Hi Marco,
Sorry about my tardy reply. Please see my comments inline [Arashmid]


From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: 11 May 2018 11:47
To: Arashmid Akhavain ; Sri Gundavelli 
; dmm@ietf.org
Subject: RE: draft-gundavelli-dmm-mfa

Hi Arashmid,

please find my take inline [ml].


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; dmm@ietf.org<mailto:dmm@ietf.org>
Subject: [DMM] draft-gundavelli-dmm-mfa

Hi Sri,
Please find below some questions and comments.

Best regards,
Arashmid

1- This technique certainly eliminates the need for fixed anchor points from 
the data plane point of view.
However, it is not clear what happens to other functions provided by the 
existing 3GPP fixed anchor points.
It should be possible to program the nodes for these additional functions as 
well. I think a list of existing functions or those required by 5G in 3GPP 
would be a good starting point for the discussion.

[ml] Good point, if we think about the MN's AG is a traditional data plane 
anchor with some extensions that enable it to be changed per the operation
described in this draft, all functions may move to the edge where the AG is 
deployed. That may work for metering, paging initiation and QoS
in case downstream labels are required for compatibility with the RAN.

[Arashmid] Do you mean that we move these functions into the AG itself? If so, 
then we need a mechanism to move say metering data from one AG to another
as MN moves around.

[ml2] Today the mobile gateway has all these functions and if we move that 
gateway to the edge and name it AG, yes, then it's all there.
Sri's draft assumes a current AG for a mobile node as well as 1..N 
correspondent data plane nodes, which are in the proximity of the
1..N correspondent services/nodes. If the correspondent node is a mobile, then 
this may be an AG, too, if it's a service, e.g. in a data center,
then it may be a policy router, PE router or something else. It's up to the 
control plane to decide which policy to enforce on which of these data plane 
nodes.
Where metering happens depends on the aggregate and probably that needs to 
happen on the AG for down and uplink. However, other functions,
such as QoS enforcement or chargeable event monitoring, may happen on the 
correspondent side already for downlink traffic.


But then there is no QoS enforcement in a large part of the network in between
the CN and the MN's AG. Hence, the approach would benefit from enforcement of 
downlink QoS rules on the CN's anchor /CNA. What do you think?
[Arashmid] Yes, it allows policies to be enforced right at the edge. I think we 
should capture this in the draft. But let's discuss what happens to policies
(both uplink and downlink) as MN moves around.

[ml2] sure, we can add more on this.

2- Performance is another issue. How fast can we detect and then program MFA 
nodes? This is the issue that applies to all different approaches. I think 
performance merits a section in the draft.

[ml] The draft depicts a reactive approach, which should work and in the worst 
case it suffers from some packets' re-ordering after enforcing
the optimized route. Pro-active extensions should be possible and improve that 
situation.
[Arashmid] If I am not mistaken, while things are settling down, .the old AG 
can forward the packets to the new one as well. Yes we might end
up with out of order packets due to path latency differentials. But as you 
said, proactive measures can ease up the situation. Should this be reflected
in the draft?

[ml2] we focus on the basic principles right now but appreciate such feedback. 
So far I can imagine some smartness on the control plane
to enable a proactive AG relocation, possible with the help of available 
handover support extensions, such as end marker packets, which in
this case should work in a control- data plane separated deployment. What do 
you think?


3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document well. 
Appendix?

[ml] Are you asking for details about other data plane protocols that are 
currently being discussed in the IETF? Since the MFA controller enforces 
policies
in the network edges (MN and CN side), these policies can result also in ILA or 
LISP mappings per an ingress node operation for the packets, no?
The current draft states at the beginning that it's not dependent on a 
particular data plane but it focuses on SRv6 so far. Which of the alternative 
data
plane protocols you think should be covered in the appendix?
[Arashmid] I was just thinking about adding an e

Re: [DMM] draft-gundavelli-dmm-mfa

[Marco Liebsch]

Hi Arashmid,

please find my take inline [ml].


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; dmm@ietf.org
Subject: [DMM] draft-gundavelli-dmm-mfa

Hi Sri,
Please find below some questions and comments.

Best regards,
Arashmid

1- This technique certainly eliminates the need for fixed anchor points from 
the data plane point of view.
However, it is not clear what happens to other functions provided by the 
existing 3GPP fixed anchor points.
It should be possible to program the nodes for these additional functions as 
well. I think a list of existing functions or those required by 5G in 3GPP 
would be a good starting point for the discussion.

[ml] Good point, if we think about the MN's AG is a traditional data plane 
anchor with some extensions that enable it to be changed per the operation
described in this draft, all functions may move to the edge where the AG is 
deployed. That may work for metering, paging initiation and QoS
in case downstream labels are required for compatibility with the RAN. But then 
there is no QoS enforcement in a large part of the network in between
the CN and the MN's AG. Hence, the approach would benefit from enforcement of 
downlink QoS rules on the CN's anchor /CNA. What do you think?

2- Performance is another issue. How fast can we detect and then program MFA 
nodes? This is the issue that applies to all different approaches. I think 
performance merits a section in the draft.

[ml] The draft depicts a reactive approach, which should work and in the worst 
case it suffers from some packets' re-ordering after enforcing
the optimized route. Pro-active extensions should be possible and improve that 
situation.

3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document well. 
Appendix?

[ml] Are you asking for details about other data plane protocols that are 
currently being discussed in the IETF? Since the MFA controller enforces 
policies
in the network edges (MN and CN side), these policies can result also in ILA or 
LISP mappings per an ingress node operation for the packets, no? The current
draft states at the beginning that it's not dependent on a particular data 
plane but it focuses on SRv6 so far. Which of the alternative data
plane protocols you think should be covered in the appendix?

4- Page 5, end of MFA-MNA paragraph:
" Typically, the MFA-MNA function will be collocated with the UPF in the 3GPP 
5G system architecture."
Couldn't it be collocated with the gNB as well? Or did you purposely took gNB 
out to avoid touching the N3 interface?

[ml] The draft is supposed to be independent of a particular access network.. 
Move the MNA closer to the access network
and you may run your last mile protocol on a 1meter patch cable to the NB. 
That's loose coupling and keeps the interface between
control plane and the MNA decoupled from the interface between NB and control 
plane. Of course you may collocate
and run the MNA tightly coupled with any access-specific node and even merge 
the interfaces to the control plane.

5- When correspondent nodes are mobile themselves. e..g. UE-UE communication, 
isn't the MFA-CNA is just another MFA-MNA? Some clarification in the draft 
might come handy.

[ml] Sure. To differentiate between policy enforcement points on the data plane 
which are associated with the MN or the CN we
chose these abbreviations. They may be of the same type of node.

6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-CNA 
in the figure.

[ml] Thanks for spotting this, we'll correct in the update.

7- How does paging work? Not sure about this one, but is it possible for a UE 
to go to be idle (a new inactive state has also been added in the spec) in one 
gNB and wake in another that connects to a different first hop router?

[ml] adopting the IETF DMM terminology of past work ;-), the dormant monitoring 
agent could be in the anchor or current MN-AG and detect packets that
are addressed to a MN in dormant mode. Different options exist here. Also, in 
case of a reactive mode per this version of the draft, the
MN's dormant state may be known only to the MFA NC, which initiates paging 
instead of updating the CN's AG and the MN's current AG (which is
not known as the MN is in dormant mode..). Multiple good or worse approaches 
are possible and this initial draft does not focus on them yet as we
want to sketch the key principles first and solicit feedback.

8- Page 19 after step 10: It might be useful to talk about how and when MFA-CN 
removes the rule for H1::/64 from AG-2. I guess it is something along what 
described in 4.3.

[ml] Definitely, more details need to be covered. Also here, multiple options 
are possible, either remove them after the data session terminated, or keep 
them until the
MN enters dormant mode.

9-  Page 20, section 4.3, step 1: Might be useful to indicate how the system 
would know when a flow is inactive and hence 

Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

[Marco Liebsch]

What about naming it nicely locator re-writing? Which is what it does and 
community reacts differently
on certain terms such as NAT..

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Dienstag, 20. März 2018 12:40
To: Tom Herbert; Lyle Bertz
Cc: dmm
Subject: Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

But, in any case, NAT is not such a bad word, its just that it pushed IPv6 
deployments out by 20 years.

Sri

On 3/20/18, 4:37 AM, "dmm on behalf of Sri Gundavelli (sgundave)"
 wrote:

>Tom:
>
>> ILA is not NAT! :-)
>
>As seen from the end point, I agree ILA is not NAT. But, that the 
>function that is needed at two places where you do translation of the 
>addresses from SIR to LOCATOR, or LOCATOR to SIR is a NAT function, and 
>you have a mapping state similar to NAT state. That¹s a NAT :-)
>
>
>Sri
>
>On 3/20/18, 4:29 AM, "dmm on behalf of Tom Herbert" 
> wrote:
>
>>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz 
>>wrote:
>>> We'll be quite time constrained during this session so I thought I 
>>>would ask  a couple of simple questions which I hope have already 
>>>been addressed in  previous e-mails:
>>>
>>> 1. Figures 14 & 15 are described as options and do not include an SMF.
>>> However, Figures 16 & 17 do.  It is a bit confusing.  Are 14 & 15 
>>>incorrect  or is an option to skip the SMF?  If correct, how does one 
>>>do any policy in  those figures?
>>>
>>> 2.  ILA appears to be super NAT'g (more than 1 NAT) but it is 
>>>unclear how  policy works.  I am not sure that in its current state 
>>>the proposed ILA  design addresses in Section 3.  Although it is 
>>>noted that not all functions  are supported at a specific UPF it is 
>>>unclear that policy, lawful intercept,  etc.. is supported at all.  
>>>Will this be section be updated?
>>>
>>Hi Lyle,
>>
>>ILA is not NAT! :-) It is an address transformation process that is 
>>always undone before the packet is received so that receiver sees 
>>original packet. In this manner ILA is really just an efficient 
>>mechanism of creating network overlays. In this manner additional 
>>functionality (policy, lawful intercept, etc.) can be higher layers 
>>independent of the actual overlay mechanism.
>>
>>Tom
>>
>>> 3. Will a feature support comparison be made for each solution with 
>>>the UPF  functions to ensure coverage?
>>>
>>> 4.  Will MFA be proposed as an option (
>>>
>>> draft-gundavelli-dmm-mfa-00
>>>
>>> )?
>>>
>>> Thanks!
>>>
>>> Lyle
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>___
>>dmm mailing list
>>dmm@ietf.org
>>https://www.ietf.org/mailman/listinfo/dmm
>
>___
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm

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

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

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

[Marco Liebsch]

That matches my view, Satoru. Still both edges require states hence the 
associated node has to have an
interface to the control plane. But I agree that in total fewer states are 
required because egress
does not need a host state for decap/re-write and removing the SRv6 header at 
egress is standard behavior. 

marco


-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
Sent: Mittwoch, 7. März 2018 12:23
To: Marco Liebsch
Cc: dmm
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Marco,

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

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

Cheers,
--satoru



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

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

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

[Marco Liebsch]

Satoru,

since I read this at different places, let me ask one clarifying question about 
the stateless motivation: 

I see that for SRv6 you may not need a state at the egress (at least not for 
traffic forwarding) but for
Uplink/Downlink (UL/DL) you need a state at both edges of the communication 
since the DL egress
serves as uplink ingress, correct?

marco


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Dienstag, 6. März 2018 17:23
To: Tom Herbert
Cc: dmm
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Hello Tom,

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

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

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

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

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

Re: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-08.txt

[Marco Liebsch]

Hi Carlos, Anthony,

I had a brief look and see a big improvement, way better to read. Since I 
volunteered during last f2f to review (..),
I'll take the current version and we can follow your proposal to talk before 
the f2f.

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Dienstag, 6. März 2018 22:40
To: Sri Gundavelli (sgundave); dmm@ietf.org
Subject: Re: [DMM] I-D Action: 
draft-ietf-dmm-distributed-mobility-anchoring-08.txt

Hi Sri,

Apologies for the delayed reaction. We were busy with the last minute I-D 
submission.

Regarding the changes that went into -08, this is my summary:

- Drastic shortening of the document, aiming at reducing its complexity and 
length. We have shortened from ~45 pages to ~15 pages.

- Simplification of the terminology and associated drawings, to just focus on 
data plane anchors (control plane is mentioned, but the document is about 
anchoring, so it is about data plane).

- Removal of parts about hierarchical networks and NEMO.

- Minimization of all the part about anchor mobility, as there is no solution 
that the WG has identified as viable. We limit the doc to anchor switching and 
anchor selection.

- Keep the focus on the document being informational (it is not normative, so 
no solution is specified).

Regarding open issues, I'd like to request some volunteers in the WG to take a 
look (even a first quick one) to provide some feedback about whether we are on 
the right track or not. It'd be really ideal if we could have some discussion 
before the f2f in London, so we could try to close/decide on open issues by the 
London meeting.

Thanks!

Carlos

On Fri, 2018-03-02 at 19:05 +, Sri Gundavelli (sgundave) wrote:
> Hi Carlos/Anthony/Authors,
> 
> Thanks for the updates. Please summarize the changes that went into
> -08
> version, and also let the WG know on the open issues.
> 
> Sri
> 
> 
> 
> On 3/2/18, 10:15 AM, "dmm on behalf of internet-dra...@ietf.org"
>  wrote:
> 
> > 
> > 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   : Distributed Mobility Anchoring
> >Authors : H. Anthony Chan
> >  Xinpeng Wei
> >  Jong-Hyouk Lee
> >  Seil Jeon
> >  Carlos J. Bernardos
> > Filename: draft-ietf-dmm-distributed-mobility-
> > anchoring-08.txt
> > Pages   : 15
> > Date: 2018-03-02
> > 
> > Abstract:
> >   This document defines distributed mobility anchoring in terms of 
> > the
> >   different configurations and functions to provide IP mobility
> >   support.  A network may be configured with distributed mobility
> >   anchoring functions for both network-based or host-based mobility
> >   support according to the needs of mobility support.  In the
> >   distributed mobility anchoring environment, multiple anchors are
> >   available for mid-session switching of an IP prefix anchor.  To 
> > start
> >   a new flow or to handle a flow not requiring IP session continuity 
> > as
> >   a mobile node moves to a new network, the flow can be started or
> > re-
> >   started using a new IP address configured from the new IP prefix
> >   which is anchored to the new network.  The mobility functions and
> >   their operations and parameters are general for different
> >   configurations.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobilit
> > y-ancho
> > ring/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anc
> > horing-
> > 08
> > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-distributed-mo
> > bility-
> > anchoring-08
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-distributed-mobili
> > ty-anch
> > oring-08
> > 
> > 
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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

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

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

Kalyani,

steering traffic on N6 in between a correspondent service (Data Network, DN) 
and a mobile's UPF,
and this is what I referred to, does not require N6/Gi-LAN functions, just 
routing policies in the transport network.
This can be policies at the N6 edges, means at the UPF side and the DN side, 
serving as ingress/egress for the
mobile's downlink and uplink traffic. Still these policies need information 
from the mobility control plane,
which is at least the locator (current UPF for that traffic).

But I understood that N6 is out of scope of your document, so it's fine.

Thanks,
marco

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Donnerstag, 8. Februar 2018 13:34
To: Marco Liebsch; Sri Gundavelli (sgundave); Dino Farinacci
Cc: i...@ietf.org; dmm
Subject: RE: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Marco:

There are 2 kinds of non-mobility nodes/functions:

-  One set is what you are referring to as N6 based functions, also 
called Gi-LAN functions that could be
chained to PGW/UPF on Gi/SGi/N6.

-  The second set of functions are related to transport (IP/MPLS) over 
which mobility traffic traverses.

The first set needs some kind of policy/charging control and will need 
interaction to the services interface.
The second set possibly don't need policy/charging control.

We need to see if some of the protocol choices like SRv6 are trying to address 
the second set also.

Kalyani

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Thursday, February 8, 2018 5:03 AM
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; 
Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

..sorry, correction in my first sentence below:
"True, control plane impact on data plane can be on N3, N9 but also on N6."..

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Donnerstag, 8. Februar 2018 10:50
To: Sri Gundavelli (sgundave); Bogineni, Kalyani; Dino Farinacci
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

My take on your latest feedback:
> I think you are talking about 2 features: one for mobility that needs the 
> database; another
> for non-mobility state transfer between user plane nodes (not necessarily 
> mobility nodes).

True, control plane impact on data plane can be on N3, N9 but also on N9. The 
latter is probably what you classify as non-mobility.
My point was to not break the N4 but rather look towards a reasonable and 
extensible protocol solution so that mapping
rules can be carried over it. In such case the mapping DB may be co-located 
with the SMF or external to the SMF. My main point
was to not make the control plane configuring the data plane through the 
service-based interfaces.

About the second case, I think it's interesting enough to include N6 where the 
mapping system would control
the data plane to steer traffic to the mobile's UPF(s). Think about 
decentralizing the UPFs and relocating a
UPF mid-session. The plain old but popular DMM scenario: How to enable IP 
address- and session continuity
when the anchor UPF changes.

Best regards,
marco


From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Mittwoch, 7. Februar 2018 18:23
To: Bogineni, Kalyani; Marco Liebsch; Dino Farinacci
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are 
two nodes that's where the translation/tunneling is happening. In a generic 
sense, it could be a layer-2 termination point, a first-hop router, or a 
transit router. When seen from 3GPP lens, there is only UPF and the N4 
interface that you talk about. But, there is N3 (eNB to UPF) and then there are 
also other nodes where there is an impact.  The translation/tunneling/steering 
may very well happen on some router connected to the service cloud/core (on 
N6),  or at some exit router where there is no 3GPP UPF function and there is 
no N4.


So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these 
protocols are doing some translation/tunneling only on UPF node? Or, we can 
introduce a two types of IP forwarding nodes, one collocated with UPF and 
another without UPF. I know how this dis

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

..sorry, correction in my first sentence below:
"True, control plane impact on data plane can be on N3, N9 but also on N6."..

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Donnerstag, 8. Februar 2018 10:50
To: Sri Gundavelli (sgundave); Bogineni, Kalyani; Dino Farinacci
Cc: i...@ietf.org; dmm
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

My take on your latest feedback:
> I think you are talking about 2 features: one for mobility that needs the 
> database; another
> for non-mobility state transfer between user plane nodes (not necessarily 
> mobility nodes).

True, control plane impact on data plane can be on N3, N9 but also on N9. The 
latter is probably what you classify as non-mobility.
My point was to not break the N4 but rather look towards a reasonable and 
extensible protocol solution so that mapping
rules can be carried over it. In such case the mapping DB may be co-located 
with the SMF or external to the SMF. My main point
was to not make the control plane configuring the data plane through the 
service-based interfaces.

About the second case, I think it's interesting enough to include N6 where the 
mapping system would control
the data plane to steer traffic to the mobile's UPF(s). Think about 
decentralizing the UPFs and relocating a
UPF mid-session. The plain old but popular DMM scenario: How to enable IP 
address- and session continuity
when the anchor UPF changes.

Best regards,
marco


From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Mittwoch, 7. Februar 2018 18:23
To: Bogineni, Kalyani; Marco Liebsch; Dino Farinacci
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are 
two nodes that's where the translation/tunneling is happening. In a generic 
sense, it could be a layer-2 termination point, a first-hop router, or a 
transit router. When seen from 3GPP lens, there is only UPF and the N4 
interface that you talk about. But, there is N3 (eNB to UPF) and then there are 
also other nodes where there is an impact.  The translation/tunneling/steering 
may very well happen on some router connected to the service cloud/core (on 
N6),  or at some exit router where there is no 3GPP UPF function and there is 
no N4.


So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these 
protocols are doing some translation/tunneling only on UPF node? Or, we can 
introduce a two types of IP forwarding nodes, one collocated with UPF and 
another without UPF. I know how this discussion will go in 3GPP; they will 
insist and say they we will never recognize any other node other what they 
created.

2.) Is N4 the only interface to these two types of node variants. Or we will 
have N4' to these both types of nodes from some AF (which can interwork with 
the service bus), and we don't' touch N4.

Marco's point is to keep this generic and not make this very UPF specific, as 
it will be too restrictive.



Sri




From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>, 
Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, Dino Farinacci 
<farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: "i...@ietf.org<mailto:i...@ietf.org>" 
<i...@ietf.org<mailto:i...@ietf.org>>, dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Marco, Sri:



Here is the services based 5G architecture.



[cid:image001.png@01D3A0CC.642ADEA0]



SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.



[cid:image002.png@01D3A0CC.642ADEA0]



Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.



[cid:image003.png@01D3A0CC.642ADEA0]



The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailt

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

Hi Kalyani,

My take on your latest feedback:
> I think you are talking about 2 features: one for mobility that needs the 
> database; another
> for non-mobility state transfer between user plane nodes (not necessarily 
> mobility nodes).

True, control plane impact on data plane can be on N3, N9 but also on N9. The 
latter is probably what you classify as non-mobility.
My point was to not break the N4 but rather look towards a reasonable and 
extensible protocol solution so that mapping
rules can be carried over it. In such case the mapping DB may be co-located 
with the SMF or external to the SMF. My main point
was to not make the control plane configuring the data plane through the 
service-based interfaces.

About the second case, I think it's interesting enough to include N6 where the 
mapping system would control
the data plane to steer traffic to the mobile's UPF(s). Think about 
decentralizing the UPFs and relocating a
UPF mid-session. The plain old but popular DMM scenario: How to enable IP 
address- and session continuity
when the anchor UPF changes.

Best regards,
marco


From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Mittwoch, 7. Februar 2018 18:23
To: Bogineni, Kalyani; Marco Liebsch; Dino Farinacci
Cc: i...@ietf.org; dmm
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

For all the approaches that we are talking (ILA, LISP, SRv6 ..etc), there are 
two nodes that's where the translation/tunneling is happening. In a generic 
sense, it could be a layer-2 termination point, a first-hop router, or a 
transit router. When seen from 3GPP lens, there is only UPF and the N4 
interface that you talk about. But, there is N3 (eNB to UPF) and then there are 
also other nodes where there is an impact.  The translation/tunneling/steering 
may very well happen on some router connected to the service cloud/core (on 
N6),  or at some exit router where there is no 3GPP UPF function and there is 
no N4.


So, there are two key questions here:

1.) Is the UPF only node that is impacted here? Is the assumption that these 
protocols are doing some translation/tunneling only on UPF node? Or, we can 
introduce a two types of IP forwarding nodes, one collocated with UPF and 
another without UPF. I know how this discussion will go in 3GPP; they will 
insist and say they we will never recognize any other node other what they 
created.

2.) Is N4 the only interface to these two types of node variants. Or we will 
have N4' to these both types of nodes from some AF (which can interwork with 
the service bus), and we don't' touch N4.

Marco's point is to keep this generic and not make this very UPF specific, as 
it will be too restrictive.



Sri




From: "Bogineni, Kalyani" 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Date: Tuesday, February 6, 2018 at 1:23 PM
To: Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>, 
Sri Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>, Dino Farinacci 
<farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: "i...@ietf.org<mailto:i...@ietf.org>" 
<i...@ietf.org<mailto:i...@ietf.org>>, dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Marco, Sri:



Here is the services based 5G architecture.



[cid:image001.png@01D3A0C7.8ED4C080]



SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.



[cid:image002.png@01D3A0C7.8ED4C080]



Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.



[cid:image003.png@01D3A0C7.8ED4C080]



The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a c

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

Kalyani, even with Option 1 I see much impact on the control plane as it 
implies that SMF offers/uses service to/from the Mapping DB utilizing the 
service-based interfaces.
My comment was more about whether we need or should introduce a new building 
block into the control plane at all.

marco


From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Mittwoch, 7. Februar 2018 03:56
To: Marco Liebsch
Cc: Sri Gundavelli (sgundave); Dino Farinacci; i...@ietf.org; dmm
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Marco:

Response Inline

From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Tuesday, February 6, 2018 5:10 PM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>; 
i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Kalyani,

my current take is to keep the data plane independent of a specific mapping 
base. Even if it comes with an extended control plane per the two options that 
you draw, I personally don't think that SMF and UPF/Data Plane should 
communicate through the service-based architecture.
[KB] Does this mean you prefer option 1 because option 2 shows APIs from both 
UPFs and Mapping DB to the services based interfaces?


marco


On 6. Feb 2018, at 22:30, Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
 wrote:

Marco, Sri:



Here is the services based 5G architecture.







SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.







Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.







The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a control plane / mapping system. For these the N4 needs 
to disseminate complete forwarding states (an more, e.g. for chargeable event 
monitoring, device dormancy support etc.) to all relevant data plane nodes, 
means the ones that hold a state for the mobile.



Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a dedicated role. We may investigate 
options to push forwarding and further policies from the (nextgen) control 
plane to other data plane nodes which don't terminate N4.



marco



-Original Message-

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)

Sent: Dienstag, 6. Februar 2018 04:07

To: Dino Farinacci

Cc: dmm; i...@ietf.org<mailto:i...@ietf.org>

Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



> The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.



Sure, that LISP control plane packet is an IP packet. But, every message that 
is going between CP and UP will be named and numbered in 3GPP specs, and so 
said in my first mail that its probably a new interface specific to LISP.



With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these 
are IP packets. But, we should note that there is interworking needed with the 
3GPP authentication infrastructure, and the protocol specific control plane. 
Note that these protocols are not doing MN identity establishment. May be I 
could be wrong here on the assumptions you have around LISP MN capabilities, 
but to me MN is a standard 3GPP UE with no special capabilities suc

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

Hi Kalyani,

my current take is to keep the data plane independent of a specific mapping 
base. Even if it comes with an extended control plane per the two options that 
you draw, I personally don’t think that SMF and UPF/Data Plane should 
communicate through the service-based architecture.

marco


On 6. Feb 2018, at 22:30, Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>
 wrote:


Marco, Sri:



Here is the services based 5G architecture.







SMF is a control plane entity and talks to the User plane functions (UPF) 
through N4 interface as specified in 3GPP TS 29.244.



Here are two variants:



Option 1: Mapping DB talks to the UPFs using a variant of N4 possibly.







Option 2: Here there is no direct interface between Mapping Db and UPFs. UPFs 
also support APIs like the control plane functions.







The architecture is extensible and additional control plane or user plane 
functions can be added.



Is this what you had in mind?



Kalyani



-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, February 6, 2018 12:09 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Dino Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and take a common N4 to update the mapping 
DB in case of mobility. But I think that clashes with the clear data plane / 
control plane separation in nextgen. And: there may be data plane solutions 
which don't come with a control plane / mapping system. For these the N4 needs 
to disseminate complete forwarding states (an more, e.g. for chargeable event 
monitoring, device dormancy support etc.) to all relevant data plane nodes, 
means the ones that hold a state for the mobile.



Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a dedicated role. We may investigate 
options to push forwarding and further policies from the (nextgen) control 
plane to other data plane nodes which don't terminate N4.



marco



-Original Message-

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)

Sent: Dienstag, 6. Februar 2018 04:07

To: Dino Farinacci

Cc: dmm; i...@ietf.org<mailto:i...@ietf.org>

Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt



> The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.



Sure, that LISP control plane packet is an IP packet. But, every message that 
is going between CP and UP will be named and numbered in 3GPP specs, and so 
said in my first mail that its probably a new interface specific to LISP.



With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these 
are IP packets. But, we should note that there is interworking needed with the 
3GPP authentication infrastructure, and the protocol specific control plane. 
Note that these protocols are not doing MN identity establishment. May be I 
could be wrong here on the assumptions you have around LISP MN capabilities, 
but to me MN is a standard 3GPP UE with no special capabilities such as 
MIPv6/LISP MN stack.







Sri













On 2/5/18, 6:52 PM, "Dino Farinacci" 
<farina...@gmail.com<mailto:farina...@gmail.com>> wrote:



>> Sure, but I assume the mapping table/DB is some where else in some

>>central  location and not on the UPF?

>

>True.

>

>> The question is how does the UPF fetch that entry and if the

>>interface for  that query is built on some 3GPP interface, or its

>>internal to LISP with  no bearing on the access technology.

>

>The UPF sends IP packets. The UPF is part of the NGC core, right? So

>the packets from the UPF get to a map-resolver and map-server via IP.

>It's pretty simple. At least it should be.

>

>Dino

>

>>

>> Sri

>>

>>

>>

>> On 2/5/18, 6:42 PM, "Dino Farinacci" 
>> <farina...@gmail.com<mailto:farina...@gmail.com>> wrote:

>>

>>> I don't know what you mean. If you put the xTR function on an UPF,

>>> then by LISP spec definition, Map-Request, Map-Reply, and

>>> Map-Register functionality is part of the UPF.

>>>

>>> Dino

>>>

>>>> On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave)

>>>> <sgund...@cisco.com<

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

It could be a nice option to keep the data plane specific control (the mapping 
DB you refer to) in the user plane and
take a common N4 to update the mapping DB in case of mobility. But I think that 
clashes with the clear data plane / control plane
separation in nextgen. And: there may be data plane solutions which don't come 
with a control plane / mapping system. For these
the N4 needs to disseminate complete forwarding states (an more, e.g. for 
chargeable event monitoring, device dormancy support etc.)
to all relevant data plane nodes, means the ones that hold a state for the 
mobile. 

Btw, in terms of compatibility with nextgen, so far N4 is terminated only in 
few types of core data plane nodes with a
dedicated role. We may investigate options to push forwarding and further 
policies from the (nextgen) control plane to other
data plane nodes which don't terminate N4. 

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Dienstag, 6. Februar 2018 04:07
To: Dino Farinacci
Cc: dmm; i...@ietf.org
Subject: Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

> The UPF sends IP packets. The UPF is part of the NGC core, right? So 
>the packets from the UPF get to a map-resolver and map-server via IP. 
>It's pretty simple. At least it should be.

Sure, that LISP control plane packet is an IP packet. But, every message that 
is going between CP and UP will be named and numbered in 3GPP specs, and so 
said in my first mail that its probably a new interface specific to LISP.

With any of the IETF protocols, PMIPv6/LISP/ILA, it can be argued that these 
are IP packets. But, we should note that there is interworking needed with the 
3GPP authentication infrastructure, and the protocol specific control plane. 
Note that these protocols are not doing MN identity establishment. May be I 
could be wrong here on the assumptions you have around LISP MN capabilities, 
but to me MN is a standard 3GPP UE with no special capabilities such as 
MIPv6/LISP MN stack.



Sri
  
 




On 2/5/18, 6:52 PM, "Dino Farinacci"  wrote:

>> Sure, but I assume the mapping table/DB is some where else in some 
>>central  location and not on the UPF?
>
>True.
>
>> The question is how does the UPF fetch that entry and if the 
>>interface for  that query is built on some 3GPP interface, or its 
>>internal to LISP with  no bearing on the access technology.
>
>The UPF sends IP packets. The UPF is part of the NGC core, right? So 
>the packets from the UPF get to a map-resolver and map-server via IP. 
>It's pretty simple. At least it should be.
>
>Dino
>
>> 
>> Sri
>> 
>> 
>> 
>> On 2/5/18, 6:42 PM, "Dino Farinacci"  wrote:
>> 
>>> I don't know what you mean. If you put the xTR function on an UPF, 
>>> then by LISP spec definition, Map-Request, Map-Reply, and 
>>> Map-Register functionality is part of the UPF.
>>> 
>>> Dino
>>> 
 On Feb 5, 2018, at 5:27 PM, Sri Gundavelli (sgundave) 
  wrote:
 
 I suspect there might be a need for a new interface.
 
 Assuming the LISP mapping system stays in the control plane, next 
to  SMF/AMF, and the xTR functions on the UPF, there needs to be 
probably a  new interface along the lines of the N4, for managing 
the LISP MAP  operations (Reg/Req/Reply/Notify..).  But, off course 
if the mapping  system stays in the user-plane, may be there is just 
interworking with  the  3GPP authentication interfaces.
 
 Sri
 
 
 
 
 
 
 
 
 
 
 
 
 
 On 2/5/18, 5:15 PM, "Bogineni, Kalyani"
  wrote:
 
> Dino:
> 
> Please look at 3GPP TS 23.501 to understand the architecture of NGC.
>We
> tried to explain that in the White paper.
> TS 23.502 has the procedures for the NGC. TS 23.503 specifies the  
>policy  and charging control framework for NGC.
> CT4 has a technical report on protocol aspects for NGC in TR 29.891.
> 
> Your draft needs to describe how it fits in the 5G architecture, 
>right  now it only addresses 4G.
> 
> Kalyani
> 
> 
> 
> -Original Message-
> From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino 
>Farinacci
> Sent: Monday, February 5, 2018 7:32 PM
> To: Bogineni, Kalyani 
> Cc: Tom Herbert ; i...@ietf.org; dmm 
>;  Sri Gundavelli (sgundave) 
> Subject: Re: [Ila] [E] Re: [DMM] Fwd: New Version Notification for  
>draft-herbert-ila-mobile-00.txt
> 
>> On Feb 6, 2018, at 5:04 AM, Bogineni, Kalyani 
>>  wrote:
>> 
>> Dino:
>> 
>> Can you add a section to show how this proposal would fit in 5G 
>> architecture?
> 
> 

Re: [DMM] [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Marco Liebsch]

I think we should rather relax the dependency between control and data plane. 
If we treat the data plane as nodes which enforce policies (encap, recap, 
re-write, etc), any c plane may suit and enforce suitable policies in the 
selected data plane nodes, e.g.  by utilizing the DMM group’s FPC models. Any 
solution that binds the data plane to a particular control plane may constrain 
its deployment, no?

marco



On 2. Feb 2018, at 01:39, Sri Gundavelli (sgundave)  wrote:

>> One thing to add. LISP has a more mature control-plane mapping system.
>> ILA has a recent proposal for its control-plane.
> 
> Mobility architectures started with a unified CP/UP approach, then the
> industry thought its a great idea to move the Control-plane out, and
> reduce the state in the User-plane, and eliminate tunnels. Now, we want to
> eliminate the tunnels, but we need a new control protocol to manage the
> binding tables, and manage the complex cache states. Wondering, what¹s
> wrong with this picture?  What de we name this new CUPS architecture?
> 
> 
> Sri
> 
> 
> (with no chair hat)
> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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

[DMM] FPC draft - scheduled call

[Marco Liebsch]

We collected a few items in the context of the FPC draft update and want to 
discuss and converge on them in a telco.

Hence, we scheduled the call for tomorrow, Wednesday, 2017/12/20, at 08:30 PDT 
/ 17:30 CET.

The call is open and in case you plan to attend, please give us a note so we 
can send you the link
to the webmeeting resources.

Also, in case you have comments to the current version of the draft, please 
post them on the DMM ML.
https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/

Current rough agenda for the call is as follows:


/ Status of revision

/ Few items for clarification

/ Confirmation of model substructure for descriptor/action values

/ next steps and action points

Best regards,
marco



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

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

[Marco Liebsch]

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<mailto:lyle.t.be...@sprint.com>>; 
dmm@ietf.org<mailto: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-

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

[Marco Liebsch]

Hi Lyle,

I see the analysis you brought, thanks for that. My proposal #2 is not my 
preference as it was
only an attempt to extend and match what Satoru had in mind without losing the 
value in current
descriptors/actions. Maybe it did not help ;-)

I just see that an action value belongs to an actions type. Clearly there are 
types which don't require
a value, e.g. drop. Here value is void and re-usability is ensured, IMO.
But moving the value entirely out of action / descriptor I just saw 
shortcomings.

So, you brought examples and arguments against proposal #1 and proposal #2.
But I could not conclude if there are any preferences or alternative? Do we 
leave it as it is now?

marco


From: Bertz, Lyle T [CTO] [mailto:lyle.t.be...@sprint.com]
Sent: Montag, 20. November 2017 15:15
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPC: Move Descriptor-/Action-Value into Rule

Marco,

Thank you for the write up of both proposals.  Forgive the length of the 
response but I wanted to provide concrete examples based upon the existing data 
types.

Summary, see below for examples and details:

-  Satoru's Proposal (Proposal 1) - the use of only ID/Type could be 
replaced by making the Type a U-Key (similar to a registry or identity in 
YANG). In any arrangement though only the Type could be use.  The downside for 
Proposal 1 is reusability.

-  Marco's Proposal (Proposal 2) - To make sense the setting MUST not 
be in any of the existing Settings, i.e. it is a setting that MUST NOT be tied 
to the Mobility-Context, DPN Interface or the fact that a DPN was assigned to 
enforce a Rule.  Does such an example exist?

>>>>>>>>>> My Opinion <<<<<<<<<<<<<

I would not pursue Proposal 1 due to the loss of reusability which is a key 
benefit of entities under the Policy Model.
I would not pursue Proposal 2 if we cannot find clear examples that the 
settings can be placed in other settings locations.  I cannot think of an 
example at this time but I am just one person and hope the team can provide 
such examples.

Lyle

>>>>>>>>>> Detail <<<<<<<<<<<


Let's take a step back.   Consider the IPFilterRule (RFC 6733) to block inbound 
port 22 traffic (even from itself)
"deny in ip from any to assigned 22"



Recall that from 6733, "The keyword "assigned" is the address or set of 
addresses assigned to the terminal."

If I use a 'IPFilterRule' Descriptor Type (it is not in the spec; I am making 
up a new type here) and provide a value of descriptor "in ip from any to 
assigned 22"  you will note the only Setting to deal with here is 'assigned'.

In Satoru's proposal, we will call it Proposal 1, we could see a Descriptor 
example as
Descriptor-Definition
Descriptor-Id = 22
Descriptor-Type = IPFilterRule
Action-Definition
Action-Id = 11
Action-Type = deny (or drop)
Rule-Definition
Rule-Id = 21231
Descriptor-Match-Type = AND
Descriptor-Reference

Descriptor-Id-Reference = 22
Descriptor-Value = in ip from any to assigned 22
Action-Reference
Action-Id-Reference = 11

We see the tradeoffs clearly in this example, when the value is directly 
determined by the type as in the deny Action-Type, the Action Reference is 
quite small.  In the case of the Descriptor we see the value is still 
incomplete and the setting 'assigned' is applied.

For Marco's 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 be

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

[Marco Liebsch]

Another proposal:

To not disrupt descriptors and actions by removing attributes that belong 
together (ID-Type-Value), what about keeping the current format and apply a new 
attribute 'x-value-settings' to Descriptor-Reference and Action-Reference 
respectively?

This should follow define once- use many paradigm.



Ending up in this:



  +-[Policy]

  |  +-[Policy-Definition] 

  |  | +-[Policy-Id]  (M)

  |  | +-[Rule-Reference] Set (M)

  |  | +-[Precedence]  (M)

  |  | +-[Rule-Id-Reference] (M)

  |  +-[Rule-Definition] 

  |  | +-[Rule-Id]  (M)

  |  | +-[Descriptor-Match-Type] (M)

  |  | +-[Descriptor-Reference] 

  |  | |+-[Descriptor-Id-Reference]

  |  | |+-[Direction] (O)

  |  | |+-[Descriptor-Value-Settings] (O)

  |  | +-[Action-Reference] 

  |  |  +-[Action-Id-Reference]

  |  |  +-[Action-Order]

  |  |  +-[Action-Value-Settings] (O)

  |  +-[Descriptor-Definition] 

  |  | +-[Descriptor -Id]  (M)

  |  | +-[Descriptor-Type]

  |  | +-[Descriptor-Value]

  |  +-[Action-Definition] 

  |+-[Action-Id]  (M)

  |+-[Action-Type]

  |+-[Action-Value]



marco




From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Donnerstag, 16. November 2017 16:33
To: dmm@ietf.org
Subject: [DMM] FPC: Move Descriptor-/Action-Value into Rule

Proposal from Satoru: Move Action-Value to 
[Rule-Definition]->[Action-Reference]. Same for Descriptor-Value, which may go 
to [Rule-Definition]->[Action-Definition].

Reason: To make sure "Define once, use many" throughout the models.

What to change:

Current Policy substructure looks as follows:


  +-[Policy]

  |  +-[Policy-Definition] 

  |  | +-[Policy-Id]  (M)

  |  | +-[Rule-Reference] Set (M)

  |  | +-[Precedence]  (M)

  |  | +-[Rule-Id-Reference] (M)

  |  +-[Rule-Definition] 

  |  | +-[Rule-Id]  (M)

  |  | +-[Descriptor-Match-Type] (M)

  |  | +-[Descriptor-Reference] 

  |  | |+-[Descriptor-Id-Reference]

  |  | |+-[Direction] (O)

  |  | +-[Action-Reference] 

  |  |  +-[Action-Id-Reference]

  |  |  +-[Action-Order]

  |  +-[Descriptor-Definition] 

  |  | +-[Descriptor -Id]  (M)

  |  | +-[Descriptor-Type]

  |  | +-[Descriptor-Value]

  |  +-[Action-Definition] 

  |+-[Action-Id]  (M)

  |+-[Action-Type]

  |+-[Action-Value]







Proposed updated Policy substructure:



  +-[Policy]

  |  +-[Policy-Definition] 

  |  | +-[Policy-Id]  (M)

  |  | +-[Rule-Reference] Set (M)

  |  | +-[Precedence]  (M)

  |  | +-[Rule-Id-Reference] (M)

 |  +-[Rule-Definition] 

  |  | +-[Rule-Id]  (M)

  |  | +-[Descriptor-Match-Type] (M)

  |  | +-[Descriptor-Reference] 

  |  | |+-[Descriptor-Id-Reference]

  |  | |+-[Direction] (O)

  |  | |+-[Descriptor-Value]

  |  | |

  |  | +-[Action-Reference] 

  |  |  +-[Action-Id-Reference]

  |  |  +-[Action-Order]

  |  |  +-[Action-Value]

  |  |

  |  +-[Descriptor-Definition] 

  |  | +-[Descriptor -Id]  (M)

  |  | +-[Descriptor-Type]

  |  +-[Action-Definition] 

  |+-[Action-Id]  (M)

  |+-[Action-Type]




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

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

[Marco Liebsch]

Proposal from Satoru: Move Action-Value to 
[Rule-Definition]->[Action-Reference]. Same for Descriptor-Value, which may go 
to [Rule-Definition]->[Action-Definition].

Reason: To make sure "Define once, use many" throughout the models.

What to change:

Current Policy substructure looks as follows:


  +-[Policy]

  |  +-[Policy-Definition] 

  |  | +-[Policy-Id]  (M)

  |  | +-[Rule-Reference] Set (M)

  |  | +-[Precedence]  (M)

  |  | +-[Rule-Id-Reference] (M)

  |  +-[Rule-Definition] 

  |  | +-[Rule-Id]  (M)

  |  | +-[Descriptor-Match-Type] (M)

  |  | +-[Descriptor-Reference] 

  |  | |+-[Descriptor-Id-Reference]

  |  | |+-[Direction] (O)

  |  | +-[Action-Reference] 

  |  |  +-[Action-Id-Reference]

  |  |  +-[Action-Order]

  |  +-[Descriptor-Definition] 

  |  | +-[Descriptor -Id]  (M)

  |  | +-[Descriptor-Type]

  |  | +-[Descriptor-Value]

  |  +-[Action-Definition] 

  |+-[Action-Id]  (M)

  |+-[Action-Type]

  |+-[Action-Value]







Proposed updated Policy substructure:



  +-[Policy]

  |  +-[Policy-Definition] 

  |  | +-[Policy-Id]  (M)

  |  | +-[Rule-Reference] Set (M)

  |  | +-[Precedence]  (M)

  |  | +-[Rule-Id-Reference] (M)

 |  +-[Rule-Definition] 

  |  | +-[Rule-Id]  (M)

  |  | +-[Descriptor-Match-Type] (M)

  |  | +-[Descriptor-Reference] 

  |  | |+-[Descriptor-Id-Reference]

  |  | |+-[Direction] (O)

  |  | |+-[Descriptor-Value]

  |  | |

  |  | +-[Action-Reference] 

  |  |  +-[Action-Id-Reference]

  |  |  +-[Action-Order]

  |  |  +-[Action-Value]

  |  |

  |  +-[Descriptor-Definition] 

  |  | +-[Descriptor -Id]  (M)

  |  | +-[Descriptor-Type]

  |  +-[Action-Definition] 

  |+-[Action-Id]  (M)

  |+-[Action-Type]


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

[DMM] some notes from today's FPC discussion round

[Marco Liebsch]

Please find below a few notes from an FPC side discussion today.
We will set up the issue tracker tool to track and resolve raised items.
Some items for discussion are in the notes below and will be taken to the
list.

marco


-- FPC discussion 2017-11-16
--
Danny: Current Policy structure is ok as it is. Charlie fine as well.

--
FPC deployment examples: Discuss on DMM ML. Decide to move them into the draft 
after the WG went through,
not publish at all or move them to the deployment draft.

--
Sri: Big document with Yang included. Separate documents vs. single document to 
be decided.

--
Charlie: Some flaws with consistency and clear definition of -Reference and -ID.
Example: Page 17 top level: Rule-Id-Reference Identifies a rule
Or: "Policy Definition - A set of Policy Definitions"

Charlie to take the name/Id discussion on the list.

--
Charlie: DPN should be an opaque object.

Satoru: DPN resources reference, fine to be optional (o)

--
Progressing the draft:
We start using the issues tracker.
Charlie plans to provide 1st round of proposed editorial tweaks by 8th Dec.

--
Charlie: Issue with 'namespace'. Call it 'space of identifiers'.
Will be addressed by comments due 8th Dec.

--
Marco: Make clear support for multi-tenancy and Slicing, goes to sect 3.
Marco to add text.

--
Policy structure:

Charlie: Policy-Definition has both, Rule-Reference and Rule-Id-Reference. 
Latter to be removed. To be fixed.

Satoru: Proposal to move Action-Value to [Rule-Definition]-[Action-Reference]. 
Same for Descriptor-Value, which may go to 
[Rule-Definition]-[Action-Definition].





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

Re: [DMM] Distributed Mobility Anchoring - Draft Review Request

[Marco Liebsch]

Maybe I did not capture the name of the third reviewer right, but there were 
three volunteers.
Marco



On 6 Apr 2017, at 08:42, Seil Jeon 
<seilj...@gmail.com<mailto:seilj...@gmail.com>> wrote:

Hi Sri,

It seems adding me there was miscounted. I didn’t raise my hands, as I’ve 
participated as a co-author in this draft.

Regards,
Seil Jeon

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Thursday, April 6, 2017 12:15 AM
To: dmm
Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Carlos Jesús Bernardos Cano; 
Suresh Krishnan; Byju Pularikkal (byjupg)
Subject: Distributed Mobility Anchoring - Draft Review Request

Hi Marco, Carlos, Seil & Biju,

I believe you have all kindly agreed to review the below draft and post your 
feedback to the list.  Will be great if you can do that in the next 2 weeks 
(COB: 19th of April, 2017).

We want to wrap up this work soon, but want to make sure the draft is 
technically correct.  Editorial issues can be fixed, but minimally the draft 
should be technically correct and we want to hear that from the group.

 https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03

Any other experts, please review and post your feedback.

Anthony – Please work with the reviewers.




 ——-



10:00   Title: Distributed Mobility Anchoring

Presenter: H Anthony Chan

Time: 10 minutes

Draft: 
https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-03





Anthony summarizes update.

Comment from Alex about nemo missed.

Different modes, move to new network and keep/give up old IP address. Rest of 
work for WG to review and comment.



Sri: we need good reviews on this document. Editorial but also technically.



Volunteers: Reviews: Marco, Carlos, Seil





——-
___
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]

[Marco Liebsch]

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 
<charles.perk...@earthlink.net<mailto:charles.perk...@earthlink.net>> 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<mailto: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<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm


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

Re: [DMM] WG Adoption call for draft-chan-dmm-distributed-mobility-anchoring-08

[Marco Liebsch]

I support the adoption of the draft as base for a WG document for the 
associated chartered item.

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni
Sent: Sonntag, 24. Juli 2016 06:57
To: dmm@ietf.org
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WG Adoption call for 
draft-chan-dmm-distributed-mobility-anchoring-08

Folks,

As already supported in IETF96 Berlin meeting we are ratifying the adoption of 
draft-chan-dmm-distributed-mobility-anchoring-08 as a WG Item. The WG adoption 
call ends 8/7/2016. Voice you support or opposition (with a reason why) on the 
mailing list.

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

Re: [DMM] Copying Traffic in FPC

[Marco Liebsch]

You think about something like flow sampling, correct? From FPC protocol point 
of view, I don’t see
issues with adding such properties. AFAIK there is even some support from data 
plane nodes, so
enforcement of these properties should work.

Now, I understand you’re requesting control on which traffic should be probed. 
In that case a
new property should be added. The associated attribute should then also 
indicate how often
packets should be probed (Every 1min, ever 1000th packet, whatever).
Since the forwarding of the copy packet is different than for the actual data 
packet, the
probe property should also indicate a destination, where the copy should be 
sent to.
That’s the protocol part and it should be feasible if wanted.

Is it the C-Plane function that is aware of policies for packet probes? To 
exploit such extension,
it should be, otherwise the probe configuration may be accomplished via a 
different interface.

Thanks,
Marco



From: Lyle Bertz [mailto:lyleb551...@gmail.com]
Sent: Dienstag, 6. Oktober 2015 17:38
To: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org
Subject: Copying Traffic in FPC

When looking at the latest draft I was curious about how copying for the 
purpose of troubleshooting / probes would be supported?

My thought would be some sort of property on a port that copies the traffic and 
notes the PRT that it could be forwarded to.

Could we support this use case (I am not married to the suggestion above) in 
the specification given its importance to trouble management?   This is easy 
enough to support in underlying DPN technologies such as SDN and I see no 
reason to not specify it in FPC and avoid using yet another protocol for 
forwarding.

Comments / Thoughts would be appreciated on this matter.

Thank you.

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

Re: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans

[Marco Liebsch]

Please find the WebEx information for the call on Wednesday below.

This is on the agenda so far:

( ) Brief summary and confirmation of open items
( ) Missing attributes and format
( ) Revision of existing attributes
( ) Modelling vs. concrete protocol design

Please let me know about further items you'd like to address.

Best regards,
Marco









DMM - CP/DP Draft discussion

Wednesday, July 1, 2015

7:00 am  |  Pacific Daylight Time (San Francisco, GMT-07:00)  |  1 hr 30 mins





Join WebEx 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=md608133416ce2fa85e7ac5dbdd128a81


Meeting number:

201 675 355

Meeting password:

dmm





Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 201 675 355

Global call-in 
numbershttps://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=317850987tollFree=1
  |  Toll-free calling 
restrictionshttp://www.webex.com/pdf/tollfree_restrictions.pdf





Add this 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=mbb855ecede44f9d2ebe95fe7bd2919f1
 to your calendar.





Can't join the meeting? Contact support.https://cisco.webex.com/ciscosales/mc





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. You should inform all meeting attendees prior to recording 
if you intend to record the meeting.






































From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 26. Juni 2015 10:48
To: dmm@ietf.org
Subject: Re: [DMM] Planning WebEx about FPC draft update /RE: 
draft-ietf-dmm-fpc-cpdp-00 - update plans

Folks, the WebEx about progressing the FPC draft will be on

Wednesday, 1st July 2015,
Time: 16:00 CEST,
Duration: 90 min.

I'll send WebEx details and an agenda around in a separate eMail.

marco


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Montag, 22. Juni 2015 22:04
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] Planning WebEx about FPC draft update /RE: 
draft-ietf-dmm-fpc-cpdp-00 - update plans

Please find a link to a doodle below to find a suitable date for a WebEx where 
we
can discuss and agree on the FPC draft update.

Please also think about the open items I addressed in my previous eMails or any 
additional
item you have in mind and which we need to consider for a draft update. Please 
use the mailing
list or the issue tracker to address these items for discussion.


http://doodle.com/5s9dhzcy6w8ds6ae

Thanks,
Marco



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 19. Juni 2015 15:36
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receive any 
serious issue to address, which is good.
Driving the draft towards a more mature state, I see the following main items 
to address:



(1)Completion of properties and attributes

(2)Adoption of a standard conform modelling

In terms of (1), the importance to include QoS attributes has been raised from 
different sides.
I'll make a proposal how to cover this in an update on the DMM ML using a 
separate eMail.
Other attributes we may need to cover are about monitoring/reporting.

In terms of (2) we heard different opinions about keeping this document at the 
level of information models
or be more specific by adopting data modeling. So far the document is pretty 
hybrid ;-), core part is more about
clear definition and description of messages and information to apply between 
Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

Please state your opinion here to see what the WG expects from the document. If 
we adopt information modeling,
this seems straightforward from a version which is complete in terms of 
messages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing 
formats, alignment, etc.

Hope we can discuss on the ML. I'd also like to schedule a WebExt before the 
draft deadline. Will send a
doodle around for that.

marco


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

Re: [DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans

[Marco Liebsch]

Folks, the WebEx about progressing the FPC draft will be on

Wednesday, 1st July 2015,
Time: 16:00 CEST,
Duration: 90 min.

I'll send WebEx details and an agenda around in a separate eMail.

marco


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Montag, 22. Juni 2015 22:04
To: dmm@ietf.org
Subject: [DMM] Planning WebEx about FPC draft update /RE: 
draft-ietf-dmm-fpc-cpdp-00 - update plans

Please find a link to a doodle below to find a suitable date for a WebEx where 
we
can discuss and agree on the FPC draft update.

Please also think about the open items I addressed in my previous eMails or any 
additional
item you have in mind and which we need to consider for a draft update. Please 
use the mailing
list or the issue tracker to address these items for discussion.


http://doodle.com/5s9dhzcy6w8ds6ae

Thanks,
Marco



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 19. Juni 2015 15:36
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receive any 
serious issue to address, which is good.
Driving the draft towards a more mature state, I see the following main items 
to address:



(1)Completion of properties and attributes

(2)Adoption of a standard conform modelling

In terms of (1), the importance to include QoS attributes has been raised from 
different sides.
I'll make a proposal how to cover this in an update on the DMM ML using a 
separate eMail.
Other attributes we may need to cover are about monitoring/reporting.

In terms of (2) we heard different opinions about keeping this document at the 
level of information models
or be more specific by adopting data modeling. So far the document is pretty 
hybrid ;-), core part is more about
clear definition and description of messages and information to apply between 
Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

Please state your opinion here to see what the WG expects from the document. If 
we adopt information modeling,
this seems straightforward from a version which is complete in terms of 
messages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing 
formats, alignment, etc.

Hope we can discuss on the ML. I'd also like to schedule a WebExt before the 
draft deadline. Will send a
doodle around for that.

marco


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

[DMM] Planning WebEx about FPC draft update /RE: draft-ietf-dmm-fpc-cpdp-00 - update plans

[Marco Liebsch]

Please find a link to a doodle below to find a suitable date for a WebEx where 
we
can discuss and agree on the FPC draft update.

Please also think about the open items I addressed in my previous eMails or any 
additional
item you have in mind and which we need to consider for a draft update. Please 
use the mailing
list or the issue tracker to address these items for discussion.


http://doodle.com/5s9dhzcy6w8ds6ae

Thanks,
Marco



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 19. Juni 2015 15:36
To: dmm@ietf.org
Subject: [DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receive any 
serious issue to address, which is good.
Driving the draft towards a more mature state, I see the following main items 
to address:



(1)Completion of properties and attributes

(2)Adoption of a standard conform modelling

In terms of (1), the importance to include QoS attributes has been raised from 
different sides.
I'll make a proposal how to cover this in an update on the DMM ML using a 
separate eMail.
Other attributes we may need to cover are about monitoring/reporting.

In terms of (2) we heard different opinions about keeping this document at the 
level of information models
or be more specific by adopting data modeling. So far the document is pretty 
hybrid ;-), core part is more about
clear definition and description of messages and information to apply between 
Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

Please state your opinion here to see what the WG expects from the document. If 
we adopt information modeling,
this seems straightforward from a version which is complete in terms of 
messages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing 
formats, alignment, etc.

Hope we can discuss on the ML. I'd also like to schedule a WebExt before the 
draft deadline. Will send a
doodle around for that.

marco


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

[DMM] draft-ietf-dmm-fpc-cpdp-00 - update plans

[Marco Liebsch]

Folks,

draft-ietf-dmm-fpc-cpdp-00  is out since May. So far we did not receive any 
serious issue to address, which is good.
Driving the draft towards a more mature state, I see the following main items 
to address:



(1)Completion of properties and attributes

(2)Adoption of a standard conform modelling

In terms of (1), the importance to include QoS attributes has been raised from 
different sides.
I'll make a proposal how to cover this in an update on the DMM ML using a 
separate eMail.
Other attributes we may need to cover are about monitoring/reporting.

In terms of (2) we heard different opinions about keeping this document at the 
level of information models
or be more specific by adopting data modeling. So far the document is pretty 
hybrid ;-), core part is more about
clear definition and description of messages and information to apply between 
Client and Agent. In the appendix
the draft includes a (so far experimental) YANG model.

Please state your opinion here to see what the WG expects from the document. If 
we adopt information modeling,
this seems straightforward from a version which is complete in terms of 
messages/attributes.
If we adopt data modeling, we may need to spend more cycles in agreeing 
formats, alignment, etc.

Hope we can discuss on the ML. I'd also like to schedule a WebExt before the 
draft deadline. Will send a
doodle around for that.

marco


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

[DMM] How to cover QoS in draft-ietf-dmm-fpc-cpdp-00

[Marco Liebsch]

Folks,

as announced in my previous eMail, please find below a proposal how to address 
QoS in
draft-ietf-dmm-fpc-cpdp-00.

The draft adopts a model to abstract forwarding and policy configuration for 
DMM using
logical ports which bind properties. This can be applied at Agents to any 
Data-Plane Node (DPN)
configuration, routers, network controllers, switches.

Adding QoS properties per port should be in-line with RFC7222 in case of GBR 
and MBR.
More needs to be considered for aggregates, such as per-MN-AMBR, 
per-Session-AMBR.
Here, the Control-Plane logic may accomplish configuration of the Data-Plane 
for an
MN or Session using a single port or multiple ports.

This can be tackled by permitting a Client to bind an AMBR attribute/value to a 
single port or
to a group of ports. Whether the aggregate applies per-MN or per Session, 
should be kept
in the application logic and be kept transparent to the Data-Plane.

Information coming with an AMBR attribute needs to comprise a list
of port identifies (PRT_ID) to which the aggregate applies, like:

QOS_AMBR_CONF:
  Aggregate Bitrate  //gives the maximum aggregate value
  List of Port-IDs   //defines the group of ports where metering applies

Please let me know if anything is missing.

marco







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

Re: [DMM] FPC carrier ID and network ID question

[Marco Liebsch]

Hi Larry,

thanks for your feedback and valid doubts, as you pointed out an important 
point to discuss.
First of all, the space for a certain field in the ID can be increased. We may 
have a preceding
discussion about how the identifier format should look like; as proposed in 
this version of
the draft or differently.

The rationale behind the Client-ID, Agent-ID and DPN-ID to allow unambiguous 
identification
of a function instance associated with FPC and its location. 'Location' means 
to identify the
network, e.g. a certain datacenter, where a function is instantiated and 
operational.

Example: An IP switch, which can serve as Data Plane Node for mobility 
management, is
located in a local POP/datacenter. The datacenter can be identified in the 
Network ID field of
the complete identifier and should be unique within the carrier's network 
topology. In the example
you brought, the Network Code (MNC) identifies rather the carrier instead of a 
certain
spot of a single carrier's network topology.

In terms of FPC deployment, we may omit the Carrier-ID field in identifiers in 
case
we do not expose and use these identifiers outside of a single carrier. But it 
may be
useful to identify the carrier as well in case, for example, a Client of 
carrier 1 connects to an Agent
of Carrier 2. In case we need to keep a Carrier-ID field, it may comprise the 
complete
tuple of MCC/MNC as you refer to.

I hope that clarifies your question and we can follow up on that thread to find 
a suitable
format for the complete identifier.

Thanks,
Marco



From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Laporte, Laurent [CTO]
Sent: Donnerstag, 28. Mai 2015 18:33
To: dmm@ietf.org
Subject: [DMM] FPC carrier ID and network ID question

Hello,

I have a question regarding the Carrier ID and Network ID elements proposed in 
the DMM FPC protocol.  I am trying to  a) understand the meaning intended for 
Carrier and Network; and, b) reconcile these names with what is familiar to me 
as someone who works for a mobile service provider.  The problem that I'm 
basically running into is that there are only 8 bits assigned each for Carrier 
ID and Network ID.  I am accustomed to utilizing a PLMN, which is composed of 
an MCC and MNC, each having allowed values up to 999.  With only eight bits, 
there are fewer values than required for either MCC or MNC.  Eight bits for 
Carrier ID and Network ID seems to be quite constrained to me.

I suspect that something else is meant, but I cannot readily surmise what it 
might be.

Thanks,

Larry Laporte




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: draft-wt-dmm-fpc-cpdp-00

[Marco Liebsch]

Same here, I support the adoption of this draft as WG document.

marco

From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Mittwoch, 15. April 2015 03:46
To: dmm@ietf.org
Cc: Dapeng Liu; draft-wt-dmm-fpc-c...@tools.ietf.org; Jouni Korhonen
Subject: Re: [DMM] Call for adoption: draft-wt-dmm-fpc-cpdp-00

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

Regards,
--satoru

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

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

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



- Jouni  Dapeng

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

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

Re: [DMM] FPSM work team draft

[Marco Liebsch]

Dear Dirk,

thanks a lot for the feedback and the spotted typos.
We'll take them into account for the next revision. Hope we can continue
discussion during f2f meeting in Dallas.

marco


From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
Sent: Freitag, 13. März 2015 13:08
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPSM work team draft

Dear Marco and WT,
Thanks for all the work! IMO the draft is quite clearly written and covers many 
details on messages and attributes for node configuration according to policies 
- I didn't find missing ones so far ... ;-)
I only have few comments / nits detected so far:
P.3:
These
   requirements are met by various transport network components, such as
   IP switches and routers, though configuration semantics differs
   between them.
=
These
   requirements are met by various transport network components, such as
   IP switches and routers, though configuration semantics differ
   between them.

P.6:
or multiple DPA(s) according
=  should this be DPN(s) or is the Data-Plane Anchor (DPA) meant?

P.7:
o  Build, modify or delete logical ports as needed
= in Fig. 4 only messages for add and delete of ports are listed - modify here 
refers only to the attributes i.e. properties and rules, right?

p.10:
   o  PRT_ADD - Issued by a Client to add a new logical port at an
  Agent, to which traffic can be directed.
= AFAIU the port is added at the DPN (where any traffic is directed to), so 
should it read:
   o  PRT_ADD - Issued by a Client to an Agent to add a new logical port at a
  DPN, to which traffic can be directed. (?)

P.11:
The Agent receiving such message should delete the rules from its
= The Agent receiving such message should delete the rule from its

p.13:
LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN
= LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN

For the Appendix I am too little of a YANG Dr. so I only detected on
P.22:
   container trafic-descriptor {
=   container traffic-descriptor {




Thanks and best regards - and have a nice weekend
Dirk

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 10. März 2015 13:59
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] FPSM work team draft

Folks,
the FPSM work team published a first draft about a solution and information 
model for DMM Forwarding Policy Configuration.
The draft should pretty much convey the approach but it's not yet complete.

It would be good to receive some feedback, constructive comments and foster 
discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.

marco



A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully 
submitted by Marco Liebsch and posted to the IETF repository.



Name:  draft-wt-dmm-fpc-cpdp

Revision:  00

Title:  Protocol for Forwarding Policy Configuration (FPC) 
in DMM

Document date:   2015-03-09

Group:  Individual Submission

Pages:   26

URL:http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-00.txt

Status: https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized:   http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00



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

[DMM] FPSM work team draft

[Marco Liebsch]

Folks,

the FPSM work team published a first draft about a solution and information 
model for DMM Forwarding Policy Configuration.
The draft should pretty much convey the approach but it's not yet complete.

It would be good to receive some feedback, constructive comments and foster 
discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.

marco



A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully 
submitted by Marco Liebsch and posted to the IETF repository.



Name:  draft-wt-dmm-fpc-cpdp

Revision:  00

Title:  Protocol for Forwarding Policy Configuration (FPC) 
in DMM

Document date:   2015-03-09

Group:  Individual Submission

Pages:   26

URL:http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-00.txt

Status: https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized:   http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00



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

Re: [DMM] [FPSM] next WebEx call

[Marco Liebsch]

For tomorrow's discussion, please use the WebEx information below to connect.

Best regards,
Marco



==


FPSM

Thursday, March 5, 2015

2:30 pm  |  Pacific Standard Time (San Francisco, GMT-08:00)  |  1 hr





Join WebEx 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=m30abe4f3cd68e0713ff52368a6900220


Meeting number:

200 642 348

Meeting password:

dmm





Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 200 642 348

Global call-in 
numbershttps://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=304228257tollFree=1
  |  Toll-free calling 
restrictionshttp://www.webex.com/pdf/tollfree_restrictions.pdf





Add this 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=m9348dab60263fe1d0b555ce5da0363e1
 to your calendar.





Can't join the meeting? Contact support.https://cisco.webex.com/ciscosales/mc





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.








From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 3. März 2015 11:34
To: dmm@ietf.org
Subject: [DMM] [FPSM] next WebEx call

We'll have another WebEx call this week to discuss and resolve some open issues 
associated with
a solution draft for DMM Forwarding Path Configuration.

The call will be on Thursday, 05th March 2015
Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in Asia)
Duration: max 90min.

Best regards,
marco



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

[DMM] [FPSM] next WebEx call

[Marco Liebsch]

We'll have another WebEx call this week to discuss and resolve some open issues 
associated with
a solution draft for DMM Forwarding Path Configuration.

The call will be on Thursday, 05th March 2015
Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in Asia)
Duration: max 90min.

Best regards,
marco



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

[DMM] [FPSM] telco notes

[Marco Liebsch]

Please find below the main outcome of the last DMM FPSM telco from 28th January 
2015.

Best regards,
Marco

---

Confirmation of items from IETF91 and previous telco:

Adopt DPN (data plane node) term for any node in the data plane which offers 
data-plane functions
to the controlling application and receives policies from the controlling 
application.

Whether a DPN functions as anchor or access specific gateway is up to the 
deployment and
the rules which it enforces.

Single flow can traverse multiple DPNs, each enforcing policies as per the 
control application's
policies.

First draft with a solution to be circulated for discussion (distributed on 
21st January 2015).

Results from discussion about first solution draft:

Agreed reference architecture comprises Clients and Agents. Clients are used by 
application control functions
(e.g. LMA Control-Plane), Agents are co-located with network control functions, 
e.g. an SDN controller.
The FPSM protocol operates between a Client and an Agent and utilizes a general 
model
for policy configuration. The Agent maps the FPSM protocol to DPN technology 
specific control to enforce
the policies in the data-plane though the SDN control function.

Agreed model for policy configuration; based on logical ports to which 
properties (tunnel type, QoS, etc.)
are bound. Forwarding rules specify which traffic is directed to which logical 
port. All traffic being directed to a
logical port experiences the same policies (QoS, encapsulation rules, tunnel 
endpoint, etc.)

First set of protocol messages and protocol attributes discussed.

Next steps:

Reflect ongoing eMail discussion and contributions in an update of the draft.
Publish first draft asap to solicit feedback. Plan for first upload to IETF 
repository: week of
16th Feb 2015.









From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Mittwoch, 28. Januar 2015 12:51
To: dmm@ietf.org
Subject: Re: [DMM] [FPSM] next telco

Please find the WebEx pointer for today's call below.

Time: 16:00 CET / 07:00 PST
Duration: 90 min

Agenda items:


* Brief summary of main points from last telco

* Discussion of solution

* Progress solution drafts towards mature state

Best regards,
marco

--






DMM Discussion - FPSM

Wednesday, January 28, 2015

7:00 am  |  Pacific Standard Time (San Francisco, GMT-08:00)  |  1 hr 30 min





Join WebEx 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=m1181e0f5020cf73dacd69619ab20ef9e


Meeting number:

208 634 647

Meeting password:

dmm





Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 208 634 647

Global call-in 
numbershttps://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=300421147tollFree=1
  |  Toll-free calling 
restrictionshttp://www.webex.com/pdf/tollfree_restrictions.pdf





Add this 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=m4d67fb38489a392c852cbd1f1d4127f4
 to your calendar.





Can't join the meeting? Contact support.https://cisco.webex.com/ciscosales/mc





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. You should inform all meeting attendees prior to recording 
if you intend to record the meeting.










































From: Marco Liebsch
Sent: Montag, 26. Januar 2015 11:39
To: Marco Liebsch; dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [FPSM] next telco

Let's schedule the WebEx call for the FPSM topic to this week Wednesday, 28th 
Jan 2015, 16:00 CET / 07:00 PST.
I'll send WebEx info before the call.

Best regards,
marco

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 23. Januar 2015 18:07
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] [FPSM] next telco

Please enter your availability for a 90min WebEx call next week by this week 
Saturday.

http://doodle.com/mber264giigc7a2k

marco



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

Re: [DMM] [FPSM] next telco

[Marco Liebsch]

Please find the WebEx pointer for today's call below.

Time: 16:00 CET / 07:00 PST
Duration: 90 min

Agenda items:


* Brief summary of main points from last telco

* Discussion of solution

* Progress solution drafts towards mature state

Best regards,
marco

--






DMM Discussion - FPSM

Wednesday, January 28, 2015

7:00 am  |  Pacific Standard Time (San Francisco, GMT-08:00)  |  1 hr 30 min





Join WebEx 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=m1181e0f5020cf73dacd69619ab20ef9e


Meeting number:

208 634 647

Meeting password:

dmm





Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 208 634 647

Global call-in 
numbershttps://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=300421147tollFree=1
  |  Toll-free calling 
restrictionshttp://www.webex.com/pdf/tollfree_restrictions.pdf





Add this 
meetinghttps://cisco.webex.com/ciscosales/j.php?MTID=m4d67fb38489a392c852cbd1f1d4127f4
 to your calendar.





Can't join the meeting? Contact support.https://cisco.webex.com/ciscosales/mc





IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. You should inform all meeting attendees prior to recording 
if you intend to record the meeting.










































From: Marco Liebsch
Sent: Montag, 26. Januar 2015 11:39
To: Marco Liebsch; dmm@ietf.org
Subject: RE: [FPSM] next telco

Let's schedule the WebEx call for the FPSM topic to this week Wednesday, 28th 
Jan 2015, 16:00 CET / 07:00 PST.
I'll send WebEx info before the call.

Best regards,
marco

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 23. Januar 2015 18:07
To: dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] [FPSM] next telco

Please enter your availability for a 90min WebEx call next week by this week 
Saturday.

http://doodle.com/mber264giigc7a2k

marco



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

Re: [DMM] [FPSM] next telco

[Marco Liebsch]

Let's schedule the WebEx call for the FPSM topic to this week Wednesday, 28th 
Jan 2015, 16:00 CET / 07:00 PST.
I'll send WebEx info before the call.

Best regards,
marco

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 23. Januar 2015 18:07
To: dmm@ietf.org
Subject: [DMM] [FPSM] next telco

Please enter your availability for a 90min WebEx call next week by this week 
Saturday.

http://doodle.com/mber264giigc7a2k

marco



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

[DMM] [FPSM] Friday's WebEx call

[Marco Liebsch]

Please find below the WebEx info for tomorrow's FPSM call.
I put the following items on the agenda:

() Confirmation of IETF91 discussion and received advice
() Synergies with other IETF activity
() FPSM data model
() Next steps
() Chat about.. Expectation from concrete protocol implementations (if time 
permits)
() Chat about.. Deployment models (if time permits)
() Usual AoB for the year's end.. :)

marco





Topic: DMM

Date: Friday, December 19, 2014

Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00)

Meeting Number: 200 916 187

Password: dmm



---

To join the meeting online(Now from mobile devices!)

---

1. Go to

https://cisco.webex.com/ciscosales/j.php?MTID=mc842327a99d63e82b748e4dfebed

a664

2. If requested, enter your name and email address.

3. If a password is required, enter the meeting password: dmm

4. Click Join.

5. If the meeting includes a teleconference, follow the instructions that

appear on your screen.



---

To join the audio conference only

---

To receive a call back, provide your phone number when you join the

meeting, or call the number below and enter the access code.

Call-in toll number (US/Canada): +1-408-525-6800

Call-in toll-free number (US/Canada): +1-866-432-9903



Having trouble dialing in? Try these backup numbers:

Call-in toll-free number (US/Canada): +1-866-432-9903

Call-in toll number (US/Canada): +1-408-525-6800



Access code:200 916 187

Global call-in numbers:

https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=29675

6737tollFree=1

Toll-free dialing restrictions:

http://www.webex.com/pdf/tollfree_restrictions.pdf









CCP:+14085256800x200916187#



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio

and any documents and other materials exchanged or viewed during the

session to be recorded. By joining this session, you automatically consent

to such recordings. If you do not consent to the recording, discuss your

concerns with the meeting host prior to the start of the recording or do

not join the session. Please note that any such recordings may be subject

to discovery in the event of litigation.





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

Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment

[Marco Liebsch]

Hi Pierrick,

thanks for the feedback. Agree that we can avoid the anchor term, since there 
is always some
expectation on such node. DPE is good, or simply Data-Plane Node (DPN), as we
where using it in the past discussion. No strong opinion here.

The WG may still need to converge on a definition of the term 'anchor', though 
it
depends solely on the policies being configured and enforced by a data-plane 
node.
The work team on Advanced Anchor selection started to investigate on this.
Point for the FPSM work is that it's the deployment and configuration which can 
make
an anchor out of a data-plane node, not a specification and the architecture 
behind.

marco

From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
Sent: Donnerstag, 18. Dezember 2014 15:10
To: dmm@ietf.org; Marco Liebsch
Subject: Re: [DMM] Data-Plane anchors in a control-/data-plane separated 
deyploment


Hi Marco,



I definitely agree that a DP node can play different role; quoting the PMIP 
example, a node can play either à MAG or LMA role, or even both rôles. A single 
name thus makes sense. However, the term anchor is à bit confusing since it 
refers implicitely to HA/ LMA. So, i suggest to use DPE node, standing for data 
plane enfoncement node. The DPE can support different functions: tunnel 
termination, encap, etc



Pierrick



Envoyé depuis mon Sony Xperia SP d'Orange



 Marco Liebsch a écrit 


Folks,

at IETF91 we received the valid comment to converge on a definition of the term 
'anchor'.
In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), 
traditionally a downlink encap function,
Data-Plane Node (DPN), which is more located in the access to terminate 
tunnels, and regular transport nodes.
Another comment was about a scenario where a single flow may traverse multiple 
DPAs on its way to the
MN.

I'd like to propose and discuss the following:
In a decentralized data-plane and a control-/data-plane separated deployment, I 
consider it a reasonable
assumption that each of the so far unambiguously named data-plane nodes can 
take the role of the other.
So, we may solely refer to a single type of function, e.g. Data-Plane Anchor 
(DPA), which receives policies
from the Control-Plane.
For a certain deployment, it's the Control-Plane that determines the role and 
associated policies for each involved
DPA.

Data-Plane nodes are agnostic to the role they play in mobility management.
Control-Plane determines the role of each DPA according to the preferred 
deployment and configures the
policies accordingly.

I think such assumption allows flexible deployment and eases description in our 
specifications.

I am not good in drawing ASCII, but I gave it a try (for downlink operation 
only).
Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, 
left DPA as MAG,
right DPA (one or multiple) may enforce per-host rules for traffic steering.

Would be happy to get your opinion on this proposal.

marco


   +--+
   |  Control-Plane   |
   +--+
| | |
| | |
| | |
 \ /V V V
+--+ -o-  +---+ +---+ +---+   +--+
|MN|  |---|DPA||DPA||DPA|--|CN|
+--+  |   +---+ +---+ +---+   +--+
  Rules:   Rules: Rules:
  Decap,   Encap, host-route
  Forward  Forward,
  qos




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment

[Marco Liebsch]

Sri,

I agree that some of the discussion is related to the deployment document. On 
the other hand,
for the specs about the interface between Control-/Data-Plane, which is what 
the FPSM topic is about,
the differentiation of data-plane functional entities does not matter, since 
the characteristics associated
with the functional entity comes with the policy configuration. Assuming a 
single type of data-plane node
simplifies the FPSM specification, IMO.

marco



From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Donnerstag, 18. Dezember 2014 18:11
To: Marco Liebsch; dmm@ietf.org
Subject: Re: [DMM] Data-Plane anchors in a control-/data-plane separated 
deyploment

Marco,

Should some of this discussion on terminology be part of the other 
arch/deployment spec ? We should use a consist terminology across all of these 
4 documents. I think the discussions we have had early this year on the DMM 
functional entities, terminology and the deployment models should still be 
applicable here.


Regards
Sri


From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu
Date: Thursday, December 18, 2014 3:03 AM
To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment

Folks,

at IETF91 we received the valid comment to converge on a definition of the term 
'anchor'.
In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), 
traditionally a downlink encap function,
Data-Plane Node (DPN), which is more located in the access to terminate 
tunnels, and regular transport nodes.
Another comment was about a scenario where a single flow may traverse multiple 
DPAs on its way to the
MN.

I'd like to propose and discuss the following:
In a decentralized data-plane and a control-/data-plane separated deployment, I 
consider it a reasonable
assumption that each of the so far unambiguously named data-plane nodes can 
take the role of the other.
So, we may solely refer to a single type of function, e.g. Data-Plane Anchor 
(DPA), which receives policies
from the Control-Plane.


For a certain deployment, it's the Control-Plane that determines the role and 
associated policies for each involved
DPA.

Data-Plane nodes are agnostic to the role they play in mobility management.
Control-Plane determines the role of each DPA according to the preferred 
deployment and configures the
policies accordingly.

I think such assumption allows flexible deployment and eases description in our 
specifications.

I am not good in drawing ASCII, but I gave it a try (for downlink operation 
only).


Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, 
left DPA as MAG,
right DPA (one or multiple) may enforce per-host rules for traffic steering.

Would be happy to get your opinion on this proposal.

marco


   +--+
   |  Control-Plane   |
   +--+
| | |
| | |
| | |
 \ /V V V
+--+ -o-  +---+ +---+ +---+   +--+
|MN|  |---|DPA||DPA||DPA|--|CN|
+--+  |   +---+ +---+ +---+   +--+
  Rules:   Rules: Rules:
  Decap,   Encap, host-route
  Forward  Forward,
  qos



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

Re: [DMM] [FPSM] next WT call

[Marco Liebsch]

The FPSM work team telco will start on this Friday, 19th December 2014, at 
16:00 CET.
Duration: 90 min

I will send an agenda and a WebEx pointer in a separate eMail.

Best regards,
marco


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Freitag, 12. Dezember 2014 14:54
To: dmm@ietf.org
Subject: [DMM] [FPSM] next WT call

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

Best regards,
Marco

http://doodle.com/5ax4qr3zrtms3t94


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

Re: [DMM] [FPSM] next WT call

[Marco Liebsch]

Hi Satoru,

it is Central European Time, CET.  Tried to propose some slots
which are also convenient to Asia and other timezones.

marco

From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Montag, 15. Dezember 2014 02:20
To: Marco Liebsch
Cc: dmm@ietf.org
Subject: Re: [DMM] [FPSM] next WT call

Hi Marco,

Is the timezone in the doodle CST?

cheers,
--satoru

On Fri, Dec 12, 2014 at 10:53 PM, Marco Liebsch 
marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu wrote:
Folks,
as follow-up of two good work team side meetings during IETF91, I’d like to 
schedule
this year’s last telco. Please participate in the doodle poll (pointer below in 
this eMail)
if you plan to attend.

Best regards,
Marco

http://doodle.com/5ax4qr3zrtms3t94



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

[DMM] [FPSM] next WT call

[Marco Liebsch]

Folks,

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

Best regards,
Marco

http://doodle.com/5ax4qr3zrtms3t94


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

[DMM] [FPSM] Work Item call#2 agenda and WebEx info

[Marco Liebsch]

Please find below the WebEx details for the 2nd work item call on Forwarding 
Path and Signaling Management.
Thanks to Sri for providing the WebEx communications platform.
The call is scheduled on Monday, 3rd Nov 2014 from 16:00 CET / 07:00am PST. 
Duration is 90 min.

Below are the proposed items for the call's agenda. Please let me know if you 
have additional
agenda items in mind which we should discuss during this call.

--- Draft agenda FPSM WI call#2 ---


-  Tools: platform for slides/document sharing, WebEx

-  Discussion of categories and associated use cases

o   Tunnel Management

o   Routing Policy Management

o   IP Route Management

o   Traffic Steering Policies

o   QoS Policies

o   Queries

o   Notifications

-  Need for session awareness at DPA/DPN?







Topic: DMM - CP/DP Interface Meeting #2
Date: Monday, November 3, 2014
Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 207 634 298
Password: dmm

---
To join the meeting online(Now from mobile devices!)
---
1. Go to 
https://cisco.webex.com/ciscosales/j.php?MTID=m090408bb558e6f1f68e9cf58643b15bd
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: dmm
4. Click Join.
5. If the meeting includes a teleconference, follow the instructions that 
appear on your screen.

---
To join the audio conference only
---
To receive a call back, provide your phone number when you join the meeting, or 
call the number below and enter the access code.
Call-in toll number (US/Canada): +1-408-525-6800
Call-in toll-free number (US/Canada): +1-866-432-9903

Having trouble dialing in? Try these backup numbers:
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800

Access code:207 634 298
Global call-in numbers: 
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MCED=290960577tollFree=1
Toll-free dialing restrictions: 
http://www.webex.com/pdf/tollfree_restrictions.pdf



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

[DMM] [FPSM] work item call#2

[Marco Liebsch]

Folks,

the clear winner for our next telco on the work item about Forwarding Path and 
Signaling Management
is Monday, 3rd November 2014, 16:00 CET.

Duration: 90min.

I will send an agenda around before the meeting.

If you would like to see a particular item on the agenda, please let me know.

Best regards,
marco

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

[DMM] [FPSM] notes from call#1

[Marco Liebsch]

Please find below some notes from last telco about the DMM work item Forwarding 
Path and Signaling Management.

Best regards,
marco


--- notes from telco 2014-10-19: ---


Check if everybody is on the same page w.r.t. objectives.
Associated charter item has been read and focus of work item (WI) has been 
summarized and agreed upon:

-- This work item is about the specification of the C-/D-Plane reference 
interface and semantics without being specific to a particular protocol

Discussion about illustration  of WI scope.

Figure
[cid:image003.jpg@01CFED4F.7807A540]

Comments and conclusions from discussion:

Provide examples for a Controller: LMA-C, MAG-C, OpenFlow-C
Example for multiple-controller space: MAG-C and LMA-C, can use PMIPv6 as 
inter-controller protocol.

Type of controller should not matter for the generic specification in this WI.

Controller, which is responsible for a particular D-Plane function, must be 
unambiguous.

Multiple controllers must be synchronized (prerequisite). (marco's note: Maybe 
we should look at this again, as we
may not mandate this in any case)

Agreement that roaming should be addressed. May imply inter-controller 
communication (Home-Foreign network controller).
However, specification of the inter-controller interface is out of scope.
Focus is the interface between controller(s) and Data Plane Node (DPN).

This work assumes that each entity, which requires mobility management, knows 
how to contact a controller.

? Need to differentiate DPA, DPN and other transport nodes, such as routers and 
switches, which terminate
the specified interface?
! So far yes

Need to provide a clear definition of terms 'DPA' and 'DPN' in the 
specification.
Proposals:
DPA owns IP address (?)
DPN just performs routing.
Discussion about IP address 'ownership' at DPA. No need that IP address fits 
into the DPA's network.
Better:
DPA must receive traffic from a foreign network

Discussion about special role of BGP Speakers on control and data plane node, 
in case BGP is used as protocol base to implement
this specification. No clear 'policy control' and 'policy enforcement' roles. 
No concerns with this, just an observation.

? Is this work tailored to a specific solution?
! No, it's a utility. May be used to enable any deployment where Control- and 
Data-Plane are separated.

Agreed procedure: Progress the specification and description of the generic 
protocol interface. Authors of existing and new
solution drafts should confirm that this specification supports their protocol.

Another WI telco before IETF91? Supported!
Find suitable date/time through doodle.

--- end of telco ---

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

Re: [DMM] Forwarding Path Signaling Management discussion

[Marco Liebsch]

Please see inline for my opinion about your questions to slide 6-8.


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Donnerstag, 16. Oktober 2014 10:58
To: Alper Yegin; dmm@ietf.org
Subject: Re: [DMM] Forwarding Path  Signaling Management discussion

..




- Slide 8: Is this simply showing how BGP-based solutions can be
covered here? Or something else?


[Sri] The interface can be realized using multiple approaches, one being the
BGP-based approach, other explicit signaling based interface



- What is the relationship between Slides 6-7-8?


[Sri] I though we had some discussion on this in the last IETF. In the context 
of
Forwarding path, the key point is the interface between a control plane entity
and a data plane entity.
May be Marco has a better explanation


[marco] slides 6 and 7 show the enforcement of policies on data plane anchor
and data plane node, whereas slide 8 shows that policies can also be enforced
at regular transport network functions to steer forwarding of (downlink) traffic
to the MN's anchor.
This can lead to the following discussion point: If we keep mobility- or 
session states away
from the data plane functions, but hold them solely in the control functions, 
the
question is whether we need to differentiate data plane anchor and data plane 
node 
from these transport network routers or switches.

marco








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

[DMM] FPSM: Proposed agenda for tomorrow's WT call#1

[Marco Liebsch]

Below you can find some proposed agenda items for tomorrow's WT call on
Forwarding Path  Signaling Management (FPSM). For participation, please refer 
to
the WebEx details which Sri posted on the DMM mailing list some days ago.

Agenda WT call:

q  Check if everybody is on the same page w.r.t. objectives
q  Identify past/available work which falls into this work item
q  Technical summary and assessment of identified past/available work
q  Agree on next steps
q  Another WT telco before IETF91 ?!

Best regards,
marco




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

[DMM] work team call - Forwarding Path Signaling Management

[Marco Liebsch]

To progress the technical work item discussion about Forwarding Path and 
Signaling Management,
let's find a suitable date for a 90min WebEx call during next week.

Please enter your availability in the following doodle by this week Thursday at 
the latest.

http://doodle.com/mdiyzcgsafumqyfn

Best regards,
marco





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

Re: [DMM] regarding the re-chartering..

[Marco Liebsch]

No issue with logical vs. physical ID. But I am wondering about two things:

Operation is clear to me in case a single MNID is present in a message and I 
see the value in being
flexible to choose from different sub-types. If multiple MNIDs with different 
sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup.. No big 
problem to solve, but
to be considered in implementations. 

If the reason for multiple present MNIDs with different sub-types is to do 
other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would not be 
more appropriate
to go for a different container option to carry such information. Something 
like a complementary
identifier option.

marco

-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It does 
not
require the identifier to be bound to a physical device or a interface 
identity.
But, we have clearly seen requirements where the need is for generating
identifiers based on some physical identifiers. Those physical identifiers 
include
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the source
and the rules for generating MN-ID based using those sources, the sender and
receiver will have clear guidance on how to use the spec. Some pointers,
explanation and examples for each of those identifiers will greatly help avoid
inter-op issues.


Regards
Sri







On 9/10/14 3:21 PM, Charlie Perkins charles.perk...@earthlink.net
wrote:


Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical
identifier or a physical identifier.  If the former, then somewhere
(perhaps below the network layer) the logical identifier has been bound
to something in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty, so
I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all looked like NAIs (which, themselves, look like
FQDNs).

Regards,
Charlie P.



On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:
 Yes. Currently, the MNID is if the nai format and is overloaded. The
MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
IMSI. Ex:
 IMSI@epc.mncMNC.mccMCC.3gppnetwork.org²

 We also have MAC48@REALM;

 We also have approaches to transform MAC to Pseudo IMSI, and then
 carry IMSI-NAI as the MN-ID.


 So, we need unique sub-types for each of the types/sources.

 MN-Id based on IMSI, MSISDN, IMEI, MAC ..

 Also, do we need to distinguish between IMSI and IMSI-NAI ?

 Sri



 On 9/10/14 6:29 AM, Marco Liebsch marco.lieb...@neclab.eu wrote:

 It seems the MNID is somehow overloaded to carry both, node-specific
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
 There may be value in adding the IMEI to the list of possible types
of  node-specific IDs.

 marco

 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
 (sgundave)
 Sent: Dienstag, 9. September 2014 23:30
 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
 Cc: Vijay Devarapalli
 Subject: Re: [DMM] regarding the re-chartering..

 Two more comments.



 4.) I'd also use sub-type value of (2) for IMSI. Just to align with
the  sub-types  defined for MN Id defined for ICMP. I suspect there
are some  implementations  already using sub-type (2). Please see
the other thread.


 5.) For each of the sub-types, we need text including examples and
some
 explanation on how they are used.


 Sri



 On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com
 wrote:

 Hi Charlie,

 This is good. Thanks.


 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2
 address, why do we need to two sub-types ? Why not have just one
 sub-type for mac based identifiers ?

 2.) Sub type value (1) is currently used. Its currently overloaded
for
 IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
 definition of new sub-types, we need some text explaining the
 motivation

 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is
 this ? Are these CGA-based IPv6 addresses ?




  New Mobile Node Identifier Types

+-++
| Identifier Type | Identifier Type Number |
+-++
| IPv6 Address| 2  |
| ||
| IMSI| 3

Re: [DMM] regarding the re-chartering..

[Marco Liebsch]

It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. 
MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types of 
node-specific IDs. 

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.



4.) I'd also use sub-type value of (2) for IMSI. Just to align with the 
sub-types
defined for MN Id defined for ICMP. I suspect there are some implementations
already using sub-type (2). Please see the other thread.


5.) For each of the sub-types, we need text including examples and some
explanation on how they are used.


Sri



On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote:

Hi Charlie,

This is good. Thanks.


1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is
this ? Are these CGA-based IPv6 addresses ?




 New Mobile Node Identifier Types

   +-++
   | Identifier Type | Identifier Type Number |
   +-++
   | IPv6 Address| 2  |
   | ||
   | IMSI| 3  |
   | ||
   | P-TMSI  | 4  |
   | ||
   | EUI-48 address  | 5  |
   | ||
   | EUI-64 address  | 6  |
   | ||
   | GUTI| 7  |
   +-++







Regards
Sri
PS: Good to see Vijay back


On 9/9/14 1:28 PM, Charlie Perkins charles.perk...@earthlink.net
wrote:


Hello folks,

Here's the last Internet Draft that we did, long ago expired:
http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.

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

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

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

Re: [DMM] re-chartering telce #1

[Marco Liebsch]

Advantages of deviating from the original proposal are to meet the IETF rules
and to give more time for preparation. Disadvantage is that the call will be 
mid of August
then where many may be off, including me.

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Dienstag, 29. Juli 2014 11:59
To: Alper Yegin
Cc: dmm@ietf.org
Subject: Re: [DMM] re-chartering telce #1


so be it then.


7/29/2014 12:54 PM, Alper Yegin kirjoitti:
 Actually, according to IETF rules, we even need a 2-week notice.

 http://www.ietf.org/iesg/statement/interim-meetings.html

 Conference calls and jabber sessions must be announced at least two
 weeks prior to the event. 

 Alper



 On Jul 28, 2014, at 4:56 PM, Alper Yegin wrote:


 Wow, these are fast, lightning fast!
 But too soon as well. Practically it leaves no time for preparation.
 Can we at least push these to a week later?



 On Jul 28, 2014, at 3:18 PM, Jouni Korhonen wrote:

 Hello,

 As discussed during the IETF90 WG meeting, we are going to have
 these telcos to complete the charter text. This is the call #1.

 - Jouni  Dapeng

 Topic: DMM Re-chartering
 Date: Tuesday 29 July 2014
 Time: 19:30, Northern Europe Summer Time (Helsinki, GMT+03:00)
 Meeting Number: 641 429 385 Meeting Password: dmm1234


 ---
 To join the online meeting (Now from mobile devices!)
 ---
 1. Go to
 https://ietf.webex.com/ietf/j.php?MTID=m136353e83c1affa3548c666c378c
 a2b7 2. If requested, enter your name and email address.
 3. If a password is required, enter the meeting password: dmm1234 4.
 Click Join.

 To view in other time zones or languages, please click the link:
 https://ietf.webex.com/ietf/j.php?MTID=m951da0816d33f90904849b81ebf9
 8fdc

 ---
 To join the audio conference only
 ---
 Call-in toll number (US/Canada): 1-650-479-3208

 Access code:641 429 385

 ---
 For assistance
 ---
 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation
 bar, click Support.

 You can contact me at:
 dime-cha...@tools.ietf.org mailto:dime-cha...@tools.ietf.org


 To add this meeting to your calendar program (for example Microsoft
 Outlook), click this link:
 https://ietf.webex.com/ietf/j.php?MTID=m31ae19ec0aece68a44a84fd9a4a4
 383d

 The playback of UCF (Universal Communications Format) rich media
 files requires appropriate players. To view this type of rich media
 files in the meeting, please check whether you have the players
 installed on your computer by going to
 https://ietf.webex.com/ietf/systemdiagnosis.php.

 Sign up for a free trial of WebEx
 http://www.webex.com/go/mcemfreetrial

 http://www.webex.com

 CCP:+16504793208x641429385#

 IMPORTANT NOTICE: This WebEx service includes a feature that allows
 audio and any documents and other materials exchanged or viewed
 during the session to be recorded. By joining this session, you
 automatically consent to such recordings. If you do not consent to
 the recording, discuss your concerns with the meeting host prior to
 the start of the recording or do not join the session. Please note
 that any such recordings may be subject to discovery in the event of
 litigation.

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

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


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

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

Re: [DMM] demand for DMM traffic steering

[Marco Liebsch]

I am only about functions, not picky about terms. But with certain terms there 
is some expectation of
the function behind. We need to be clear about the roles of both, access and 
home DPA for
mobility management and assess their role in driving the different DMM 
scenarios.

marco

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Donnerstag, 17. Juli 2014 06:37
To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
Cc: dmm@ietf.org
Subject: Re: [DMM] demand for DMM traffic steering

Hi Marco,

If there should be the use of word, Anchor in access DPA term is  a minor 
issue, IMO.  We can always fix that and come up with a better term. The key 
point is the distinction in roles and functionalities of these two entities and 
which we seem to agree. Home DPA is clearly the routing anchor and access DPA 
is entity that is providing some mobility support and it is also the first-hop 
router.  We also need to highlight that the functional role is always in the 
context of a mobility session. The Access DPA may assume the role of Home DPA 
for one specific MN's session, while it may offer the Access DPA function to 
another mobility session.

 If we bring in offload at an Access DPA, the Access DPA provides a different 
 IP address to the MN and becomes the Home DPA for traffic using that IP. The 
 role of the original Home DPA may be solely to determine which traffic to 
 offload at the Access DPA.

When we discuss offload at the Access DPA, we should qualify this and state 
that this  offload is for certain IP flows for a session anchored on a remote 
Home DPA. While there may be another session anchored on the same Access DPA 
for that MN (with the access DPA acting as a Home DPA for that local session), 
but that session will have not relation to the Home DPA of the first session 
and so making sure your last sentence above did not suggest that. Its strictly 
the UE choice on address selection for local offload.

On the aspect of session migration across Home DPA's you had a comment in one 
of your earlier emails.  I see session migration as a tool used in very 
specific scenarios. When we migrate a session from Home-DPA-1 to Home-DPA-2, 
truly the session is completely migrated to the new Home DPA; even the routing 
infra is updated and that allows us to completely forget the previous Home-DPA 
where the session was previously hosted. For a mobility session, at a point of 
time, we have states in the Controller, Home DPA and Access DPA (optionally) 
and that's about it. Home DPA may have been changed, Access DPA may have been 
changed as well, but the state is always present in these three entities.


Regards
Sri






From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu
Date: Wednesday, July 16, 2014 2:31 PM
To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, Hirschman, 
Brent B [CTO] brent.hirsch...@sprint.commailto:brent.hirsch...@sprint.com, 
Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org
Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org
Subject: RE: [DMM] demand for DMM traffic steering

Sri,
please see inline.

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Mittwoch, 16. Juli 2014 15:32
To: Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin
Cc: dmm@ietf.orgmailto:dmm@ietf.org
Subject: Re: [DMM] demand for DMM traffic steering

Marco,

If the idea is DP anchor relocation after every L3 mobility event, you have a 
single-node DPA model. The MN attach point at every location will take the Home 
DPA Role after each Relocation trigger. Any time you cannot relocate a Home 
DPA, you end with a two node Access/Home DPA model, which IMO offers nice 
flexibility with respect to when to initiate DP relocation and when to go with 
a two-node DPA model.

Yes, that's close to the model I had in mind. Remain anchored at the DPA, which 
preforms mobility
management. Then, at some point when it makes sense (not every L3 handover, but 
when e.g. the routing path
can be optimized), relocate the DPA. The new DPA may provide a new, 
topologically correct IP to the MN,
or may import and bind the previous IP if IP address continuity is required. In 
the latter case tailored routing
rules for traffic steering are required.

The role of the Access DPA in case the Home DPA performs mobility management I 
left aside so far, as it serves
more as locator (access gateway). It's not necessarily an anchor in terms of 
mobility management, unless we talk
about a hierarchy of mobility anchors.
If we bring in offload at an Access DPA, the Access DPA provides a different IP 
address to the MN
and becomes the Home DPA for traffic using that IP. The role of the original 
Home DPA may be solely to determine
which traffic to offload at the Access DPA.

With all this (the Access DPA becoming a Home DPA..) I am wondering if the 
Access DPA deserves the
term Anchor. Also according to your description we only have Home DPAs, which 
bind

Re: [DMM] demand for DMM traffic steering

[Marco Liebsch]

Hi Sri,
Thanks for your prompt response. please see inline.

From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Freitag, 11. Juli 2014 19:46
To: Marco Liebsch; dmm@ietf.org
Subject: Re: [DMM] demand for DMM traffic steering

Hi Marco,

I think we may have to qualify the term anchor. In our conf calls we used the 
terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access 
prefix tags.

I thought that gets clear from my description, but you are right. This thread 
focuses on the
data/user plane anchor.


At the start of a session, the selected anchor assigns a topologically correct 
address.

I guess you're referring to the mobility session, not the data session. Yes, 
that's
today's procedure: Select (data-plane) anchor first, then assign an IP address 
which
fits to the anchor's network.

 The HoA/HNP for a mobile node's session is always topologically anchored on 
that node. That anchor is the Home CPA/DPA (Integrated case) and for the 
controller scenario, those functions are split across two nodes.  However, once 
the MN changes its point of attachment, then the selected anchor for that 
attachment can be the Acces-CPA/Access-DPA in relation to the home CPA/DPA. The 
session is still anchored on the home CPA/DPA, but the access CPA/DPA is 
providing the CoA (pardon me,  its your locator per the LISP terminology, or 
our classic CoA) and the routing state.  However, this access CPN/DPN is also a 
Home CPN/DPN as the MN can create a new session and may obtain a new HoA/MNP.

I think it can be even the same CPA that controls multiple DPAs, whether it's 
the home or the access.

About the terms: I like the identifier/locator terms as they apply to any 
mobility solution without
taking a particular one (e.g. PMIP) as base line for a discussion. This is not 
LISP-specific.
See, MIP maps an identifier (HoA) to a locator (CoA). Northbound to the HA, the 
HoA serves as
both, identifier and locator assuming a topologically correct HoA at that 
anchor. Same for
PMIP; or even Cellular IP, where the locator is an output port, or BGP, where 
the locator is
a hext hop :) So I think this is suitable terminology to discuss DMM, in 
particular if we still
differentiate the northbound and the southbound operation from a distributed 
data plane anchor
viewpoint. Questions to answer are then how are packet routed to selected DPA 
in particular if
the assigned HoA is topologically incorrect at the used DPA. The protocol 
southbound
to the DPA may use any mobility specific transport, e.g. tunnel (to the locator 
:)) .

The aspect of session relocation is relevant for the initial session and at 
that point your case#2 comes into picture.

Yes, that was the rationale behind.

At this point, we have a choice to keep both Access CPN/DPN  and Home CPN/DPN 
and apply traditional schemes for forwarding traffic, or relocate the session 
to the new Access CPA/DPA and make that as the Home CPA/DPN for the initial 
session. But, the access CPA/DPA is always a local gateway (typically first-hop 
router) and so not sure how the gateway selection can be relevant in this 
context.

Moving a mobile's mobility state (binding a HoA to a locator) from a previous 
DPA to a new DPA
is gateway relocation. Well, relocation of the data plane anchor. The control 
plane anchor
will/may stay the same.

Gateway selection is relevant in a two node architecture with access and home 
anchors, and selection being about the home anchor.

Selection is an orthogonal problem. Of course an initial DPA and a target DPA 
must be
selected during DPA relocation. But the mechanism to transfer binding context 
and to
steer traffic to the new anchor is a different technology compared to selection.

Then: If we think about the case 2b below, that implies that the initially 
selected
DPA (is it the home DPA in your model?) binds a HoA which is topologically
not correct from the very beginning. Here, traffic steering may be required from
the first registration already. I am just wondering if there is a reasonable 
use case
behind this. PI address binding?

marco

Regards
Sri






From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu
Date: Friday, July 11, 2014 8:59 AM
To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] demand for DMM traffic steering

Folks, I would like to discuss the demand for DMM traffic steering as 
preparation for
Toronto.

DMM enables smart deployment and selection of network components serving as 
User-Plane
anchor to the mobile node. The MN's IP address or prefix (HNP/HoA) is assigned 
to the selected
anchor and bound to the MN's locator (CoA, pCoA, ..)

Now, there are two cases:

(1) Selected anchor is in the network of the MN's HoA/HNP (topologically 
correct address)
(2) Selected anchor is not in the network of the MN's HoA/HNP (topologically 
incorrect address)

Case (1) is what IP mobility assumed so far. Default routes in the transport 
network deliver

Re: [DMM] demand for DMM traffic steering

[Marco Liebsch]

Hi Alper,

the discussed procedures were always on the table in the context of
decentralized anchors. There are expired drafts but also active ones,
which address the use case to change a data plane anchor while keeping
the previously assigned HoA in use. Also our ID about a DMM framework addresses
these use cases in the context of traffic steering above data plane anchor 
level.
Hope that helps.

marco


From: Alper Yegin [mailto:alper.ye...@yegin.org]
Sent: Samstag, 12. Juli 2014 09:36
To: Sri Gundavelli (sgundave)
Cc: Marco Liebsch; dmm@ietf.org
Subject: Re: [DMM] demand for DMM traffic steering

Sri and Marco,

Is any of what you are describing captured in the existing drafts? If so, 
please provide the pointers.

Alper




On Jul 11, 2014, at 8:45 PM, Sri Gundavelli (sgundave) wrote:


Hi Marco,

I think we may have to qualify the term anchor. In our conf calls we used the 
terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access 
prefix tags.

At the start of a session, the selected anchor assigns a topologically correct 
address. The HoA/HNP for a mobile node's session is always topologically 
anchored on that node. That anchor is the Home CPA/DPA (Integrated case) and 
for the controller scenario, those functions are split across two nodes.  
However, once the MN changes its point of attachment, then the selected anchor 
for that attachment can be the Acces-CPA/Access-DPA in relation to the home 
CPA/DPA. The session is still anchored on the home CPA/DPA, but the access 
CPA/DPA is providing the CoA (pardon me,  its your locator per the LISP 
terminology, or our classic CoA) and the routing state.  However, this access 
CPN/DPN is also a Home CPN/DPN as the MN can create a new session and may 
obtain a new HoA/MNP.

The aspect of session relocation is relevant for the initial session and at 
that point your case#2 comes into picture. At this point, we have a choice to 
keep both Access CPN/DPN  and Home CPN/DPN and apply traditional schemes for 
forwarding traffic, or relocate the session to the new Access CPA/DPA and make 
that as the Home CPA/DPN for the initial session. But, the access CPA/DPA is 
always a local gateway (typically first-hop router) and so not sure how the 
gateway selection can be relevant in this context. Gateway selection is 
relevant in a two node architecture with access and home anchors, and selection 
being about the home anchor.

Regards
Sri






From: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu
Date: Friday, July 11, 2014 8:59 AM
To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org
Subject: [DMM] demand for DMM traffic steering

Folks, I would like to discuss the demand for DMM traffic steering as 
preparation for
Toronto.

DMM enables smart deployment and selection of network components serving as 
User-Plane
anchor to the mobile node. The MN's IP address or prefix (HNP/HoA) is assigned 
to the selected
anchor and bound to the MN's locator (CoA, pCoA, ..)

Now, there are two cases:

(1) Selected anchor is in the network of the MN's HoA/HNP (topologically 
correct address)
(2) Selected anchor is not in the network of the MN's HoA/HNP (topologically 
incorrect address)

Case (1) is what IP mobility assumed so far. Default routes in the transport 
network deliver the
packet into the network which hosts the MN's assigned anchor.

Case (2) can happen in 2 cases:
(a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. 
That's what has been
called so far anchor re-location
(b) MN has a stable IP address (e.g. profile-bound) but the network wants to 
select an anchor
according to the requested service, i.e. anchor should be close to a local 
server or CDN cache.
In that case the MN's IP address will be topologically incorrect from the very 
beginning of its
attachment.

All cases (a) and (b) may require steering the MN's traffic according to a host 
policy, as the
route deviates from the default.

First questions we may rise:

I)Are we on the same page regarding the above cases?

II)  What comes first in DMM: IP address configuration or 
anchor selection?

Hope we can discuss some opinions ahead of the meeting.
marco





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

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

[DMM] demand for DMM traffic steering

[Marco Liebsch]

Folks, I would like to discuss the demand for DMM traffic steering as 
preparation for
Toronto.

DMM enables smart deployment and selection of network components serving as 
User-Plane
anchor to the mobile node. The MN's IP address or prefix (HNP/HoA) is assigned 
to the selected
anchor and bound to the MN's locator (CoA, pCoA, ..)

Now, there are two cases:

(1) Selected anchor is in the network of the MN's HoA/HNP (topologically 
correct address)
(2) Selected anchor is not in the network of the MN's HoA/HNP (topologically 
incorrect address)

Case (1) is what IP mobility assumed so far. Default routes in the transport 
network deliver the
packet into the network which hosts the MN's assigned anchor.

Case (2) can happen in 2 cases:
(a) MN gets assigned a new anchor mid-session but wants to keep its HoA/HNP. 
That's what has been
called so far anchor re-location
(b) MN has a stable IP address (e.g. profile-bound) but the network wants to 
select an anchor
according to the requested service, i.e. anchor should be close to a local 
server or CDN cache.
In that case the MN's IP address will be topologically incorrect from the very 
beginning of its
attachment.

All cases (a) and (b) may require steering the MN's traffic according to a host 
policy, as the
route deviates from the default.

First questions we may rise:

I)Are we on the same page regarding the above cases?

II)  What comes first in DMM: IP address configuration or 
anchor selection?

Hope we can discuss some opinions ahead of the meeting.
marco





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

Re: [DMM] draft charter text updates in github..

[Marco Liebsch]

As posted earlier in an email, I propose to keep the anchor (re)selection 
decoupled from
mid-session or between-session aspects. I think we should have one solution for
anchor selection, that can be used also to select a new one during runtime if 
needed.

How to treat bindings in case of mid-session re-selection, is a different thing.
It's about importing mobility states into the new selected anchor. Associated
Traffic steering I see in a separate document, which is currently named 
'forwarding
path and signaling management'.

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni
Sent: Freitag, 6. Juni 2014 17:06
To: Alper Yegin
Cc: dmm@ietf.org
Subject: Re: [DMM] draft charter text updates in github..

Good point Alper. Lets hash that anchor reselection details out shortly.

--
Jouni Korhonen
Broadcom

(Sent from my mobile..)

 Alper Yegin alper.ye...@yegin.org kirjoitti 6.6.2014 kello 17.37:

 Hello Jouni, DMM folks,

 We better clarify what anchor re-selection stands for.
 If it is about selecting different anchors for different IP flows, that's 
 one thing.
 If it is about changing the IP anchor in the middle of an IP flow, that's 
 another
thing. And that other thing needs to be scoped out. A basic understanding of a
use case would be appreciated (just an explanation for discussion, I'm not 
asking
for another I-D!), and identification of various aspects of that scenario which
translate to work items for DMM WG.

 I won't be in the call today. So, consider this for a discussion. Follow up 
 on the
mailing list afterwards would be good.

 Cheers,

 Alper



 On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote:

 Folks,

 Minor changes..

 https://github.com/jounikor/dmm-re-
charter/blob/master/recharter_draft.txt

 IMHO..the charter as it is today, would allow pretty much any solution from
legacy anchoring to herd of pigeons carrying IP.. ;-)

 I have put in editorial changes of my own and clear text proposals received
from others.

 - Jouni

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


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

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

Re: [DMM] rechartering

[Marco Liebsch]

Jouni,

-Original Message-
From: Jouni Korhonen [mailto:jouni.nos...@gmail.com]
Sent: Mittwoch, 28. Mai 2014 19:55
To: Marco Liebsch; dmm@ietf.org
Subject: Re: [DMM] rechartering

Marco,


5/28/2014 3:35 PM, Marco Liebsch kirjoitti:
 Hi Jouni, all,

 let me pick up some comments again, which we should clarify.

 About anchor selection:

 Referring to the milestones, having the anchor re-selection document
 separated from the advanced anchor selection only by 3 months does not
 seem to be useful, even if you consider re-selection to be used only
 for advanced DMM deployment and operation, whereas basic anchor
 selection is required for any DMM deployment with decentralized data plane
anchors.

 I understand this document treats solely selection and runtime
 re-selection, not the associated establishment of routing/tunnel
 states according to the

Actually, I was in an opinion that re-selection would also cover the needed 
parts
for possible re-routing of traffic.. whatever the mechanisms is.

Ok, if we are clear about this, I am fine. To confirm your understanding: the 
milestone
about anchor selection is solely about the selection process, while the 
milestone about
anchor re-selection is about runtime selection of a new anchor plus traffic 
routing. Correct?

Then I still believe it would make sense to cover that in a single document. If 
we want to
separate documents, then we may address anchor selection and runtime 
re-selection (just the selection)
in a single document, as the same algorithms and protocol components should 
apply to find a
suitable anchor, whereas a separate document treats the traffic routing to the 
selected anchor.

No too strong opinion here and no push to change wording as long as the listed 
milestones
allow all required work to be done.



Does anyone else share the same view?

 selected anchor. So, I think both aspects, selection and re-selection,
 should go into a single document. Unless the WG decides that
 re-selection is too advanced, then it may go into a separate document
 when the base selection spec is almost ready, as it will depend on it.

 About forwarding path and signaling management:

 In particular if the support of runtime/mid-session anchor change is
 considered for the first set of DMM solution documents, the described
 work item about 'forwarding path and signaling management' should be
 given a milestone, as this is essential if anchors are changed
 mid-session and IP address continuation is expected. So far there is
 no document about this work item in the charter list.

Right, any suggestions for the actual document name and time lines?

That one I understand is associated with the traffic routing in the above
documents, no?

marco



 Inter-working between mobility functions and network nodes, e.g.
 routers, requires the use of some non-mobility protocol. DMM should at
 least describe which states (identifiers, locator addresses/IDs, ..)
 to expose through these protocols. That's what I understood behind
 mobility state exposure, whereas the text in the work items list reads
 more like this is about announcements from the network to an MN about
 the characteristics of an IP address to support the MN in picking the
 right address for an application. I know it's more a terms issue, but we need
clarification what we expect from a work item.

The latter is what I had in mind.. mainly the MN-network communication.

 Hope the above makes sense and we can easily clarify.

Sure.

- Jouni



 marco




 -Original Message-
 From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
 Sent: Dienstag, 27. Mai 2014 10:51
 To: dmm@ietf.org
 Subject: Re: [DMM] rechartering


 Now that the gap analysis I-D is almost on the stage of leaving the
 WG and the requirements I-D has almost completed IESG, it would be
 time to return to the rechartering topic.

 First, the latest revision can be found at:
 https://github.com/jounikor/dmm-re-charter

 Second, have a look at it. There are few changes proposed by Alper
 eons ago and corrected milestones pointed by Behcet.

 Third, let us get this finally done..

 - Jouni

 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti:
 Folks,

 Sorry for letting this topic to rot in a dark for the couple of last
 weeks. I'll crank out a revision shortly..

 - Jouni  Dapeng

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

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

Re: [DMM] rechartering

[Marco Liebsch]

Hi Jouni, all,

let me pick up some comments again, which we should clarify. 

About anchor selection:

Referring to the milestones, having the anchor re-selection document
separated from the advanced anchor selection only by 3 months does not
seem to be useful, even if you consider re-selection to be used only for 
advanced
DMM deployment and operation, whereas basic anchor selection is required for
any DMM deployment with decentralized data plane anchors. 

I understand this document treats solely selection and runtime re-selection,
not the associated establishment of routing/tunnel states according to the
selected anchor. So, I think both aspects, selection and re-selection, should
go into a single document. Unless the WG decides that re-selection is too 
advanced,
then it may go into a separate document when the base selection spec is almost 
ready,
as it will depend on it.

About forwarding path and signaling management:

In particular if the support of runtime/mid-session anchor change is considered 
for the first
set of DMM solution documents, the described work item about 'forwarding
path and signaling management' should be given a milestone, as this is
essential if anchors are changed mid-session and IP address continuation
is expected. So far there is no document about this work item in the
charter list.

Inter-working between mobility functions and network nodes, e.g. routers,
requires the use of some non-mobility protocol. DMM should at least describe
which states (identifiers, locator addresses/IDs, ..) to expose through these
protocols. That's what I understood behind mobility state exposure, whereas
the text in the work items list reads more like this is about announcements
from the network to an MN about the characteristics of an IP address to support
the MN in picking the right address for an application. I know it's more a 
terms issue,
but we need clarification what we expect from a work item.

Hope the above makes sense and we can easily clarify.

marco


 

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Dienstag, 27. Mai 2014 10:51
To: dmm@ietf.org
Subject: Re: [DMM] rechartering


Now that the gap analysis I-D is almost on the stage of leaving the WG and the
requirements I-D has almost completed IESG, it would be time to return to the
rechartering topic.

First, the latest revision can be found at:
https://github.com/jounikor/dmm-re-charter

Second, have a look at it. There are few changes proposed by Alper eons ago
and corrected milestones pointed by Behcet.

Third, let us get this finally done..

- Jouni

4/22/2014 3:55 PM, Jouni Korhonen kirjoitti:
 Folks,

 Sorry for letting this topic to rot in a dark for the couple of last
 weeks. I'll crank out a revision shortly..

 - Jouni  Dapeng

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

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

Re: [DMM] Preparing for DMM future steps and rechartering

[Marco Liebsch]

Hi Sri,

-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Donnerstag, 14. November 2013 06:22
To: Marco Liebsch; Peter McCann
Cc: dmm@ietf.org
Subject: Re: Preparing for DMM future steps and rechartering

Hi Marco,



My intention is not to eliminate a tunnel that exists in any of the
tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
primarily distributes topological anchor point for the MN's IP
address(es). Forget about the C-plane for now.
Tunnels apply solely below (well, towards access) such anchor.
If we distribute them to an extreme, they are placed on radio access
points and the tunnel disappears. Then we arrive at Pete's model. If
anchor points are somewhere above, say in the backhaul, the tunnel
remains at least between the anchor and some node in the access
(network based mobility mgmnt) or the MN (host based mobility mgmnt).


Ok.

Distributing topological anchor points at the access edge can be done today
without any new standards extensions. This is more about deployment and
selection of a gateway at the access edge. But, any time the MN moves and
attaches to a different point in the network, that tunnel and the CP is 
expected
to be there between the previous home-anchor and the current access-anchor.
But, here, the proposals hide the tunnel (at the initial attachment point and 
what
can be argued as a home link and which is fine), but when the MN moves the
session is re-anchored to a different gateway with a churn in the routing
infrastructure and with major impact to policy plane. So, there is no tunnel 
and
there is no CP in this model.

Depends. I assume that the session you describe is a mobility session (binding 
ID-Locator),
not a data session. If the mobility session remains anchored at the previous 
attachment point,
there will be a tunnel towards the new attachment point, which may serve
as MAG. Optionally, the new attachment point may provide a new anchor and an 
additional
mobility session, hence an additional HoA, which depend on the MN to handle 
multiple
IPs. Other approach would imply moving the MN's mobility session from the 
previous anchor/point of attachment
to the new one. Then there is at least no tunnel needed to forward packets from 
the previous
anchor to the new one. But the anchored HoA or HNP at the new anchor is 
topologically
incorrect. That means the routing plane above anchors can take care about 
delivering
downlink packets to the MN's current anchor. Agree that that's an impact to the 
routing policy
plane, but a valid approach to achieve more optimal routes. 




I think none of the proposals wants to discuss away the tunnels as per
MIP/PMIP. But above anchor level, regular routing applies to plain data
packets of the U-Plane.
A key component for DMM, IMO, is how to accomplish that routing towards
the MN's current anchor point, even if the anchored IP address is
topologically incorrect.
To accomplish this, my intent is to not introduce tunnels above anchor
level.
So, it's not about eliminating tunnels, but it is about not introducing
tunnels where never have been tunnels before :-)


:) If you can show this working without re-anchoring the session to a different
gateway, then I will agree. You see this from the point of view of IP routing, 
but
I'm looking for that subscriber session which I'm not able to find.

Without re-anchoring the previous mobility session at the new anchor means
the previous anchor remains involved in the packet delivery. I was talking about
the case where the previous mobility session will be transferred and anchored 
at the new
mobility anchor. Only that enables short delivery paths, as the anchor points 
of the
MN's IP address is close to the MN. But in that case the routing plane needs
to support packet delivery for that MN. So, either by introducing tunnels in the
routing plane (e.g. according to LISP), which I'd like to avoid. Or by using 
per-host routes.
Or by using address translation to a routable address, which delivers the packet
to the mobile's current anchor. 


Tunnels hide the topology and make that reachability work; it gives me a stable
anchor point that my operator can manage my session.

Sure, anchors as well as tunnels from that anchor to a locator should be kept. 
After
anchor relocation, the new anchor takes care about tunnel management to
deliver packets to the current MN's location. However, the routing plane above
anchor level may take care about delivering packets to the current anchor, which
is a prerequisite to allow the new anchor doing his job.

Greetings,
marco



Regards
Sri


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

Re: [DMM] Preparing for DMM future steps and rechartering

[Marco Liebsch]

Please see inline, Carlos.

-Original Message-
From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es]
Sent: Mittwoch, 13. November 2013 12:48
To: Marco Liebsch
Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org
Subject: Re: [DMM] Preparing for DMM future steps and rechartering

Hi Marco,

On Wed, 2013-11-13 at 11:23 +, Marco Liebsch wrote:
 Carlos,

 just to clarify my view here: I do not see them as different
 approaches, but in a way that the routing approach can complement
 mobility anchor-based approaches (MIP-like protocols). And such
 routing support is needed only in certain deployments, i.e. in case of
 a runtime change of the MN's anchor while the new anchor imports the
 MN's IP address (binding) context to enable IP address continuity. To
 enable routing the MN's downlink data to its current anchor in the transport
network above anchor level, e.g. host routes can be used.

I'm not sure I agree on this. To me this seem to already assume a certain
solution. And I'm biased because I also have some solutions in mind :D

Not a solution, but a deployment model. The solution would dig into the
protocol bits of a selected protocol e.g. BGP to solve that. That's not what
I am writing about. I write this only to abstract the available solutions to
deployment models and see where the DMM group can do some work to
enable a variety of them.


For example, I think we should not limit only to downlink, unless the ingress
filtering is not considered an issue (if it is not, this also kind-of assumes 
a certain
type of solution).


For sure not. I refrained from describing the complete sequence, as it's not
relevant for this discussion. Just trying to draw some models and see which
gaps DMM can close.



 We end up in a routing-only approach if these anchors will be
 distributed to an extreme and placed e.g. on radio access points and
 the approach uses something else than MIP protocols to transfer IP
 address context between these access points. Then we have Pete's DMM
deployment model.

Agree, but a routing approach could also be applied even if the anchors are not
placed on the radio access points. That's why I see routing as an alternative
solution to IP mobility protocols.

Sure. But I am not sure that it should be the DMM group that builds a new
alternative to IP mobility. What's the gap analysis then about?
Interesting to research about, though.



 Do you agree to that view?

 I think there is common understanding that DMM is a lot about deployment.
 Any of those deployment models are valid. Whereas the DMM WG cannot
 work on all extensions needed to enable all models, we should converge
 on a reasonable set of first work items to allow operators to enable DMM in
their network.

I agree. It would be helpful to get some feedback from operators on which
deployments they have more interest on.


Good.

Thanks,
marco


Thanks,

Carlos


 marco


 -Original Message-
 From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es]
 Sent: Mittwoch, 13. November 2013 11:51
 To: Marco Liebsch
 Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org
 Subject: Re: [DMM] Preparing for DMM future steps and rechartering
 
 Hi,
 
 I'm also jumping into the discussion a bit late.
 
 Without going into all the detailed discussions that have taken place
 recently, I just want to share my view on the MIP-based vs routing-based
approach.
 
 IMHO, we probably need to further look at both approaches in this
 group, but with enough energy level (otherwise we risk to end up with
 nothing after several years). I personally have my doubts that a
 distributed routing-based approach scales in a moderately large
 domain (we also saw many years ago proposals of doing mobility with
 routing that did not take off because of convergence, scalability and
administrative issues).
 I think a MIP-based approach (network or host based) would work,
 though it would imply keeping multiple anchors active for a given MN.
 
 We believe this routing-based vs MIP-based comparison is quite
 interesting, and we are actually working at UC3M on experimentally
 evaluating both, so we can make a more educated statement on pros and
cons of each of them.
 
 My two cents,
 
 Carlos
 
 On Wed, 2013-11-13 at 10:10 +, Marco Liebsch wrote:
  Hi Sri, all,
  let me step in here (with some delay..) to clarify one point you raised.
  Please see inline.
 
  -Original Message-
  From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf
  Of Sri Gundavelli (sgundave)
  Sent: Montag, 11. November 2013 16:30
  To: Peter McCann
  Cc: dmm@ietf.org
  Subject: Re: [DMM] Preparing for DMM future steps and rechartering
  
  Hi Pete,
  
  I'm not sure, I agree with this, or understand this to be precise.
  I do not know know CP (in the form of PMIP, GTP or some other
  protocol
  XYZ) can be completely eliminated. There needs to be some
  interface between the access gateway and the mobility anchor. I
  assumed your's, Marco's

Re: [DMM] DMM framework

[Marco Liebsch]

Dear Dirk,

thanks a lot for your review and for your comments. Please see inline for my 
response.

-Original Message-
From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
Sent: Donnerstag, 31. Oktober 2013 16:59
To: Marco Liebsch; dmm@ietf.org
Subject: RE: DMM framework

Dear Marco, all,

I think the idea of describing mobility management functions in a generic and
modular way can help to allow for fair comparison of different existing
approaches and new extensions towards fulfillment of DMM requirements. As
your draft shows also routing-protocol based approaches as LISP can be
described by this nomenclature.  With the new functional entities - and the
defined reference points in between - and the abstraction of the mobility 
related
ones it thus should help to analyse general network architectures and 
functional
decompositions for both fixed and mobile sessions - in a similar fashion as
SDN/NFV (Software Defined Networks/Network Function Virtualization) concepts
proceed.

That was a key idea behind the framework to allow building a DMM solution
that allows exposing relevant states to the dataplane, e.g. routers, SDN 
controllers, etc,
and to enable inter-working, aiming at an optimized routing path to the MN's 
current anchor
The specifications of the DMM group could take such framework to specify the 
hooks between the
mobility control plane and e.g. a transport network control plane without 
interfering
with other WGs or SDOs.  



As usually the network analysis will focus on the performance parameters
denoted below.  I think therefore the framework activities are valuable work
from an operators point of view which we should intensify - thus perhaps 
helping
the resulting protocol proposals to be deployed in reality one day.

Yes, support for building a DMM solution that integrates well with an operator's
architecture is a valid point.
The framework could also be used to identify gaps in available protocols and 
architectures,
not only mobility protocols, but also transport network related components, 
e.g. BGP, SDN technology, LISP, MPLS, etc.
Closing these gaps and interfacing the mobility control plane with the 
transport network control plane
enables suitable solutions for DMM.


Perhaps one could add in sect. 4.1/4.2 that within MN in Fig. 2 and Fig.3 the
corresponding FEs FE_MU_U and FE_MU_C are not included since for PMIP6
they reside in MAG ... this surely will become clear from the appendices A1/A2
later on.

True, the mobile host components have not been captured in these two figures
as the focus was on the placement of the DMM-specific functions. But you have
a point here, we should at least clarify this in the test. Thanks for spotting 
this.


If I remember correctly it was agreed that both framework documents (i.e.
compared to http://tools.ietf.org/id/draft-chan-dmm-framework-03.txt) with
their different way of abstraction can complement each other and should
continue, right?

Yes, they can be considered complementary. Hope both can be useful and support
the specifications of the DMM group by identifying required protocol functions 
and
interfaces for both, mobility protocols and transport network technology. 

Thanks again for your feedback,
marco


Thanks!

Best regards
Dirk

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Marco Liebsch
Sent: Sonntag, 27. Oktober 2013 22:02
To: dmm@ietf.org
Subject: [DMM] DMM framework

Folks,

during my presentation at last IETF about http://www.ietf.org/id/draft-liebsch-
dmm-framework-analysis-02.txt,
around 20 people indicated interest in working on a framework.

We think this framework, the described functional entities and associated
reference points to enable unicast DMM is mature. The original idea of this
framework was to be mobility protocol-agnostic and identify components of
available transport network technology, including SDN technology, to
complement mobility protocols and enable optimized DMM operation. Such
optimization we see in terms of transport costs, routing path, latency, etc.

We'd appreciate any comments and contributions to the framework. Please also
refer to the slides from last meeting to recall the status of the work.

http://www.ietf.org/proceedings/87/slides/slides-87-dmm-11.pdf

marco



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

Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03

[Marco Liebsch]

I do not have a strong opinion on 4.7, but adding such requirement
came from Multimob. Now you propose removing this requirement again.
Does it mean you do not want to have it in at all? If yes, why?

Another option is that the Multimob group proposes alternative text
to be more concrete about a multicast requirement according to the
Multimob group's view how this should be covered.

marco

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Behcet Sarikaya
Sent: Mittwoch, 3. April 2013 21:59
To: Jouni Korhonen
Cc: dmm@ietf.org; dmm-cha...@tools.ietf.org
Subject: Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03

Hi all,

If Section 4.7 is removed, I am willing to support this call.

The reason: it is immature to say anything on this issue even as a should.

Regards,

Behcet



On Tue, Apr 2, 2013 at 1:55 AM, Jouni Korhonen jouni.nos...@gmail.com
wrote:



   Just a reminder. There has been zero WGLC reviews so far..

   - Jouni



   On Mar 20, 2013, at 7:06 AM, Jouni Korhonen
jouni.nos...@gmail.com wrote:

Folks,
   
This mail starts a two week WGLC for draft-ietf-dmm-requirements-
03.
The issues, even editorials, should be recorded into the Issue Tracker
for a control tracking whether everything has been addressed. We
require minimum three reviews. The more the better, though.
   
The WGLC ends on Wednesday 3rd April.
   
- Jouni  Julien

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



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

[DMM] DMM framework vs architecture

[Marco Liebsch]

Julien, all,

let me comment to your statement in Orlando about the DMM framework
draft-liebsch-dmm-framework-analysis:

You commented that the framework assumes an architecture. Well, yes, a
'functional' architecture as it's always done by a functional framework.
We identify functional entities and dependencies between these functions.
Dependencies are coordinated via reference points/interfaces between
these functions. Functions can be co-located to a single protocol architecture
component or distributed. Functions and reference points may apply to a solution
or may not, dependent on the targeted protocol support and requirements.
So, the draft does not go beyond what a framework should do.
It simply supports building any protocol solution without being dependent
on the underlaying protocols. 

Please see e.g. RFC 3154, which did the same for Dormant Mode Host Alerting.
The approach applies to many other frameworks.

Hope you can agree to this approach.

marco

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

Re: [DMM] DMM and the framework discussion

[Marco Liebsch]

Hi Jouni, all,

to complement what has been written already, I think once we agreed on a
framework it helps doing a comprehensive gap analysis. Based on a common
understanding of how DMM scenarios work, the framework defines functions
that can add to a basic set of assumed mobility/tunnel management functions.
If a certain mobility protocol supports one or more DMM function intrinsically,
fine. If not, the available protocol may be extended to enable that function. Or
an external protocol can be considered to provide that functionality.

My impression from past DMM meetings is that there is a common understanding
of DMM in general, but folks still have different expectation from DMM support 
and
associated IP address continuity. Also assumptions on hosts are different (e.g. 
multi-anchor
capability, maintenance of associated uplink routes, etc.).

A framework could classify DMM functions as mandatory or optional, dependent
on the target scenario and level of path optimization that should be supported.
Some functions according to draft-liebsch-dmm-framework-analysis could be
placed even on the host to see if host mobility protocols can contribute to DMM 
operation.

I see the framework as required portion of the top-down gap analysis and design
approach. Last but not least it allows building a DMM architecture and 
deployment of
associated protocols beyond mobility protocol scope, e.g. by contributions from 
the routing plane
above mobility anchor level. I understand that the DMM WG may focus mainly on 
mobility protocols
first, but the framework can document DMM solutions in a broader scope, which 
may attract
readers beyond the DMM WG.  

marco 

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Jouni Korhonen
Sent: Donnerstag, 20. Dezember 2012 14:50
To: dmm@ietf.org
Subject: [DMM] DMM and the framework discussion

Folks,

During the last meeting we had a presentation(s) on DMM framework
approaches. The discussion was somewhat left unfinished during and after the
meeting. It might be useful to have the discussion on the mailing list now and
not to postpone in to the next f2f meeting :)

Have a read e.g. on draft-liebsch-dmm-framework-analysis and say what you
have to say about DMM frameworks. I keep hearing we lack the framework and
at least I need to understand the possible need for one..

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

Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

[Marco Liebsch]

Hi Pete,
please see inline. Sorry for the delay in continuing the discussion.

-Original Message-
From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Donnerstag, 8. November 2012 19:43
To: Marco Liebsch; dmm@ietf.org
Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00

Hi, Marco,

Thanks for the response.  See below.

Marco Liebsch wrote:
 Hi Pete,
 please see inline for my response.

 -Original Message-
 From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
 Peter McCann
 Sent: Mittwoch, 7. November 2012 20:41
 To: dmm@ietf.org
 Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

 Let me ask a question to make sure I understand the approach this
 document takes to analyzing the problem space.  In the Introduction,
 you state:
   The initial version of this draft introduces a basic set of FEs and
   interfaces between these FEs to support IP address continuity in DMM,
   without being specific to the used mobility management protocol,
   which operates below the mobility anchor.
 And later, you introduce the FE_MA to represent this mobility anchor.
 I
 *think* you are trying to define DMM as something that runs above
 another mobility management protocol.

 That would imply a solution and that is not intended. The four defined
 DMM FEs can be mapped to components of existing protocols. My
 intention is to define DMM FEs, which enable DMM use cases but are not
 dependent on a mobility protocol. So, some functions can be applied to
 existing components of, say, iBGP in a route reflector, or a LISP
 resolver. But some components can be placed on a Mobile IP Home Agent
 or even a Mobile Node. Then we can analyze if the function of the DMM
 FE is implicitly supported by the existing protocol or if an extension
 is needed. That's the rationale behind these FEs. The FE_MA is
 mentioned as existing component and assumed as topological anchor of
 the MN's IP address. Some or all DMM FEs may apply to the existing MA.
 Depends on the analysis we want to perform.

Ok I understand that you want to put some of your components in the existing
mobility anchor (and at least the FE_MA would be there) but you also seem to
be distinguishing between a DMM protocol that runs *above* the FE_MA and
another mobility protocol that runs *below* the FE_MA.  Is that a correct
interpretation?

The draft is not a solution, but a functional framework. As you write, some
functions can be placed on an existing mobility anchor (which may be even
co-located with an access router). Typically, the Egress Function is at the
MN's topological anchor after anchor relocation. To analyze if a mobility
protocol supports one or more of the required functions to enable DMM 
implicitly,
some of the other identified DMM functional entities could be placed
on the mobility anchor, or even on a MAG or a MN in case of host mobility.
See, this is solely for the analysis. But also for the identification and 
specification
of extensions. If we place the FE_IEC to an iBGP router, maybe the defined
DMM function is implicitly supported by the iBGP protocol. That's the
rationale behind the framework. And that was my intention to allow
enabling DMM with support from non-mobility protocols, e.g. being deployed
in the transport network. This can be in your example iBGP, or MPLS or OpenFlow.



   Would it be legal to set the FE_MA equal to the access router, and
 the other mobility management protocol to NULL? That is, would it be
 allowed in your framework to use *only* the DMM protocol to get
 packets to an AR, to which the MN is currently attached?

 Yes, legal from my perspective  :-)

Good.  It seems to me that designating the leaf node in your architecture as
containing FE_MA is confusing because there may in fact be no mobility protocol
running between FE_MA and AR (they may be one and the same entity).

Yes, then it's local IPC of a function call ;-) FE_MA is just a general naming 
of
the MN's topological anchor or, maybe better, point of attachment. The DMM
framework simply assumes that packets arriving at that point of attachment
can be forwarded to the MN without any help of the functional entities
of the DMM framework. If this is the Access Router or a Base Station, that
requirement is met.



 Section 3 states:
   Imported HoA/HNP
   of a mobile node will be treated as identifier and non-routable IP
   address (prefix), as it probably does not match the new mobility
   anchor's location in the topology.
 I disagree.  The old address (prefix) will need to be routable at
 least inside the new anchor point.  If this anchor point is directly
 connected to the MN (i.e., it is the AR) then the route will be to a
 local link address.  If this new anchor point uses a tunnel to get
 the packets to the MN, then the old address will be routable to the
 tunnel interface.

 The assumption is of course that below a mobility anchor (FE_MA) the
 mobility protocol performs location tracking and tunnel

Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

[Marco Liebsch]

..small correction in the figure below: Packets should arrive
at the FE_E of the iBGP router, then the next hop state is checked,
then packets are transmitted via FE_I. So please swap FE_I and FE_E in the 
figure.

marco

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Marco Liebsch
Sent: Dienstag, 20. November 2012 10:59
To: Peter McCann; dmm@ietf.org
Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

Hi Pete,
please see inline. Sorry for the delay in continuing the discussion.

-Original Message-
From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Donnerstag, 8. November 2012 19:43
To: Marco Liebsch; dmm@ietf.org
Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00

Hi, Marco,

Thanks for the response.  See below.

Marco Liebsch wrote:
 Hi Pete,
 please see inline for my response.

 -Original Message-
 From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf
 Of Peter McCann
 Sent: Mittwoch, 7. November 2012 20:41
 To: dmm@ietf.org
 Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

 Let me ask a question to make sure I understand the approach this
 document takes to analyzing the problem space.  In the Introduction,
 you state:
   The initial version of this draft introduces a basic set of FEs and
   interfaces between these FEs to support IP address continuity in DMM,
   without being specific to the used mobility management protocol,
   which operates below the mobility anchor.
 And later, you introduce the FE_MA to represent this mobility anchor.
 I
 *think* you are trying to define DMM as something that runs above
 another mobility management protocol.

 That would imply a solution and that is not intended. The four
 defined DMM FEs can be mapped to components of existing protocols. My
 intention is to define DMM FEs, which enable DMM use cases but are
 not dependent on a mobility protocol. So, some functions can be
 applied to existing components of, say, iBGP in a route reflector, or
 a LISP resolver. But some components can be placed on a Mobile IP
 Home Agent or even a Mobile Node. Then we can analyze if the function
 of the DMM FE is implicitly supported by the existing protocol or if
 an extension is needed. That's the rationale behind these FEs. The
 FE_MA is mentioned as existing component and assumed as topological
 anchor of the MN's IP address. Some or all DMM FEs may apply to the
existing MA.
 Depends on the analysis we want to perform.

Ok I understand that you want to put some of your components in the
existing mobility anchor (and at least the FE_MA would be there) but
you also seem to be distinguishing between a DMM protocol that runs
*above* the FE_MA and another mobility protocol that runs *below* the
FE_MA.  Is that a correct interpretation?

The draft is not a solution, but a functional framework. As you write, some
functions can be placed on an existing mobility anchor (which may be even co-
located with an access router). Typically, the Egress Function is at the MN's
topological anchor after anchor relocation. To analyze if a mobility protocol
supports one or more of the required functions to enable DMM implicitly, some
of the other identified DMM functional entities could be placed on the mobility
anchor, or even on a MAG or a MN in case of host mobility.
See, this is solely for the analysis. But also for the identification and 
specification
of extensions. If we place the FE_IEC to an iBGP router, maybe the defined DMM
function is implicitly supported by the iBGP protocol. That's the rationale 
behind
the framework. And that was my intention to allow enabling DMM with support
from non-mobility protocols, e.g. being deployed in the transport network. This
can be in your example iBGP, or MPLS or OpenFlow.



   Would it be legal to set the FE_MA equal to the access router, and
 the other mobility management protocol to NULL? That is, would it be
 allowed in your framework to use *only* the DMM protocol to get
 packets to an AR, to which the MN is currently attached?

 Yes, legal from my perspective  :-)

Good.  It seems to me that designating the leaf node in your
architecture as containing FE_MA is confusing because there may in fact
be no mobility protocol running between FE_MA and AR (they may be one and
the same entity).

Yes, then it's local IPC of a function call ;-) FE_MA is just a general naming 
of the
MN's topological anchor or, maybe better, point of attachment. The DMM
framework simply assumes that packets arriving at that point of attachment can
be forwarded to the MN without any help of the functional entities of the DMM
framework. If this is the Access Router or a Base Station, that requirement is
met.



 Section 3 states:
   Imported HoA/HNP
   of a mobile node will be treated as identifier and non-routable IP
   address (prefix), as it probably does not match the new mobility
   anchor's location in the topology.
 I disagree

Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

[Marco Liebsch]

Hi Pete,
please see inline for my response.

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Peter McCann
Sent: Mittwoch, 7. November 2012 20:41
To: dmm@ietf.org
Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00

Let me ask a question to make sure I understand the approach this document
takes to analyzing the problem space.  In the Introduction, you state:
   The initial version of this draft introduces a basic set of FEs and
   interfaces between these FEs to support IP address continuity in DMM,
   without being specific to the used mobility management protocol,
   which operates below the mobility anchor.
And later, you introduce the FE_MA to represent this mobility anchor.
I *think* you are trying to define DMM as something that runs above another
mobility management protocol.

That would imply a solution and that is not intended. The four defined DMM FEs
can be mapped to components of existing protocols. My intention is to define
DMM FEs, which enable DMM use cases but are not dependent on a
mobility protocol. So, some functions can be applied to existing components
of, say, iBGP in a route reflector, or a LISP resolver. But some components
can be placed on a Mobile IP Home Agent or even a Mobile Node. Then
we can analyze if the function of the DMM FE is implicitly supported by the
existing protocol or if an extension is needed. That's the rationale behind 
these
FEs. 
The FE_MA is mentioned as existing component and assumed as topological anchor
of the MN's IP address. Some or all DMM FEs may apply to the existing MA. 
Depends
on the analysis we want to perform.

   Would it be legal to set the FE_MA equal to the
access router, and the other mobility management protocol to NULL?  That is,
would it be allowed in your framework to use *only* the DMM protocol to get
packets to an AR, to which the MN is currently attached?

Yes, legal from my perspective  :-)



Section 3 states:
   Imported HoA/HNP
   of a mobile node will be treated as identifier and non-routable IP
   address (prefix), as it probably does not match the new mobility
   anchor's location in the topology.
I disagree.  The old address (prefix) will need to be routable at least inside 
the
new anchor point.  If this anchor point is directly connected to the MN (i.e., 
it is
the AR) then the route will be to a local link address.  If this new anchor 
point
uses a tunnel to get the packets to the MN, then the old address will be 
routable
to the tunnel interface.

The assumption is of course that below a mobility anchor (FE_MA) the mobility
protocol performs location tracking and tunnel management or whatever.
The defined DMM FEs enable the required level of indirection above or at the
mobility anchor. 



Elsewhere in Section 3:
   Forwarding can be for example accomplished by an IP tunnel to the
   egress function, address translation to a routable IP address or
   other means.
I hope that other means can include installing an actual route for the
destination IP on routers between the ingress and egress.

Yes.


I'd be happy to provide a diagram and text to show how draft-mccann-dmm-
flatarch can fit into this functional framework.  In the language of your 
draft, I
think that the FE_MAs are integrated with the ARs, the FE_MCTX is the DNS
server that stores the UE's current address, FE_E is co-located on the 
currently
serving AR, and FE_I and FE_IEC are made up of a distributed network of routers
running BGP (there is no single point of failure for FE_I).

I have that picture in mind, just lack of time caused mapping examples
to be weak in version 00. I received other feedback and version 01 is
actually there. I'd be happy if you contribute to the draft with our
picture and text. By the way, the main motivation of the DMM FEs
was to allow analysis beyond mobility protocols, hence including
your solution proposal. I see the iBGP solution as hop-by-hop
solution where each transport network router gets a per-host state
when indirection is required. Each iBGP router hence implements
an FE_I and FE_E at the same time. But let's discuss details
tomorrow.

marco


--
Peter J. McCann
Huawei Technologies (USA)
peter.mcc...@huawei.com
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA


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

[DMM] comments about draft-zuniga-dmm-gap-analysis

[Marco Liebsch]

Please find some comments about version 2 of draft-zuniga-dmm-gap-analysis 
below.

General comments:

I think the draft addresses a good set of available mobility protocols, even 
though I still believe
that support from non-mobility protocols should be considered to solve DMM.

Maybe protocols for anchor selection and reselection should be included to the 
analysis? Depends
on whether the selection of anchors during initial attach and relocation of a 
mobility anchor is in
scope of the solution to be specified.

I think it's very valuable to analyze how each protocol can contribute to DMM 
and the draft
matches the available protocol components against the defined requirements. 
What's not clear
from the chosen bottom-up approach is whether such contribution is needed in a 
solution and
how the contribution fits into the overall DMM scenario. The WG never converged 
on any
design constraints and design goals so far. That's a major weak point, IMHO. I 
think we need
to go bottom-up as well as top-down.  On the very top, we may agree and define 
design constraints
and the associated scenarios (role of the MN in DMM; capability to handle 
multiple IP addresses,
one for continued use after anchor relocation, another one, which is 
topologically correct at the
MN's current anchor). Maybe such design constraints can be anchored in the 
requirements draft.

Some concrete comments:

Why does the draft refer sometimes to 3GPP analogies, e.g. in Sect. 2.2.2? Is 
it to x-check applicability
in the evolved packet core? Well, personally I think it makes sense to consider 
hooks to the DMM
solution to enable inter-working with and support from external components. But 
this is not
really related to the analysis of gaps with available IP mobility protocols.

Section 3.1.2, HA switch
Isn't it a gap to enable IP address continuity at the relocated HA? So, MIPv6 
could provide means
for the MN to convey HoA context from the previous HA. An appropriate extension 
to MIPv6
could close that gap. Correct? Such information may be provided with the 
analysis draft as well.

Section 3.1.6, LMA runtime assignment
The draft says '..not clear how the technology can be used to achieve DMM..' 
well, the document
should go beyond a suitability analysis. From the spec of LMA runtime 
assignment I understand
that it's meant to be used solely at the MN's attach. So a loaded LMA can refer 
to a different
one. A gap is to perform the operation at any time. Further gap is that it's 
the current anchor
that initiates relocation. Maybe not a gap, but at least a limitation. Another 
gap, since out of scope
of the specification, is the transfer of registration context between LMAs. 

The analysis should try to assess suitability of a protocol component to 
support DMM and
identify the functional components that need to be added to enable re-use of 
the existing
protocol. Such missing functional component can be added either to the existing 
protocol,
or provided by other protocols.

Section 4.
I think in general it's useful to summarize all findings in a table, but in 
this case I have
difficulties to conclude how each protocol can find itself in the DMM solution. 
Here,
according to my opinion, a parallel top-down approach can help. Knowing about 
design
goals and constraints, we can have a common picture of a solution in mind.
Then it's easier to understand how each of these protocols contribute to that 
picture.

Hope it helps.

marco


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

Re: [DMM] Comments on DMM Gap Analysis.

[Marco Liebsch]

Hi,

of course the gap analysis can be limited to a study and assessment of solely 
available
IP mobility protocols. The question is against which template these gaps are 
assessed.
To tackle and address the complete space of DMM problems (and some of them are
very specific to DMM) I doubt that relying only on mobility extensions is 
sufficient.
Simply because the nature of DMM moves some problems out of the IP mobility
space. Squeezing them to fit into a mobility problem and solving them by 
mobility extension
may work functionally, but..

In the past, backend protocols played always role in solving the complete 
problem.
IMHO, some non-mobility protocols should be included in the analysis and the
solution space. If the WG wants to start with analyzing solely mobility 
protocols first
and extend the scope in a next step, fine. But I just worry that the limited 
gap analysis
will be taken as base to solve DMM completely as mobility protocol extension. 
That'll
help only to be fast, nothing else.

marco


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
liu dapeng
Sent: Donnerstag, 20. September 2012 05:47
To: pierrick.se...@orange.com; jouni.nospam; Julien Laganier
Cc: dmm@ietf.org; dmm-cha...@tools.ietf.org
Subject: Re: [DMM] Comments on DMM Gap Analysis.

Hello All,

I also have the similar thinking that we should first document and agree on the
practices for the deployment of existing mobility protocols in a distributed
mobility management environment.  After that, if we find that there indeed
some gap existing, we can then move to gap analysis.

Best Regards,
Dapeng

2012/9/19, pierrick.se...@orange.com pierrick.se...@orange.com:
 Hi Jouni and Julien,


 Sorry for jumping into the discussion but I'm a little bit confused
 with recent discussions in DMM. So, let me ask for clarifications
 about the scope of the gap analysis...

 The WG is now tackling with the work item 'Practices and Gap Analysis'
 and, in my understanding, we are expected to provide a gap analysis
 regarding the use of  mobility protocols in a distributed mobility
management environment.
 However, it seems that the scope of discussions on gap analysis is
 different and I'm confused :-)

 Actually, in the charter, we agreed to firstly document practices for
 the deployment of existing mobility protocols in a distributed
 mobility management environment and, then, to make the gap analysis.
 However, considering current discussions on gap analysis: the
 document on practices has been omitted and discussions are about
 vanilla mobility protocols and architectures with respect to DMM
 requirements. So, maybe, such considerations are interesting in the
 scope of the problem statement, but it seems to me that it is not the
 goal of the gap analysis, as initially intended in the charter. Am I missing
something?

 If I refer to previous DMM charter (because current DMM charter is
empty...
 BTW, is there a reason for an empty charter?), one Work item was:
 Document practices for the deployment of existing mobility protocols
 in a distributed mobility management  environment. Is this document
 still in DMM stuff? If yes, shouldn't we document practices before going into
the gap analysis?

 BR,
 Pierrick

 -Message d'origine-
 De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de
 karag...@cs.utwente.nl Envoyé : mercredi 19 septembre 2012 13:11 À :
 jouni.nos...@gmail.com; dmm@ietf.org; h.anthony.c...@huawei.com;
 juancarlos.zun...@interdigital.com
 Cc : dmm-cha...@tools.ietf.org
 Objet : Re: [DMM] Comments on DMM Gap Analysis.

 Hi Jouni, Hi all,

 After discussing this issue with Carlos Jesús Bernardos and Juan
 Carlos Zuniga, we concluded that the following set of possible
 technologies could be included in the Gap analysis draft:

 = Shim6: Level 3 Multihoming Shim Protocol for IPv6 http://www.rfc-
 editor.org/rfc/rfc5533.txt


 = LISP Mobile Node
 http://www.ietf.org/id/draft-meyer-lisp-mn-07.txt
 Locator/ID Separation Protocol (LISP)
 http://www.ietf.org/id/draft-ietf-lisp-23.txt

 = Mobile IPv6 Fast Handovers
 http://tools.ietf.org/id/draft-ietf-mipshop-rfc5268bis-01.txt
 This is the draft that became then RFC5568, so no need to mention it.
 http://www.rfc-editor.org/rfc/rfc5568.txt


 = Fast Handovers for Proxy Mobile IPv6
 http://www.rfc-editor.org/rfc/rfc5949.txt

 = Host Identity Protocol
 http://www.rfc-editor.org/rfc/rfc4423.txt
 http://www.rfc-editor.org/rfc/rfc5201.txt
 http://www.rfc-editor.org/rfc/rfc6253.txt
 http://www.rfc-editor.org/rfc/rfc5206.txt



 = IKEv2 Mobility and Multihoming Protocol (MOBIKE)
 http://www.rfc-editor.org/rfc/rfc4555.txt


 = GTPv2-C: 3rd Generation Partnership Project; Technical
 Specification Group Core Network and Terminals; 3GPP Evolved Packet
 System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling
 Protocol for Control plane (GTPv2-C); Stage 3 (Release 11)
 

Re: [DMM] draft requirement REQ-1: Distributed deployment (single-operator and cross-operator?)

[Marco Liebsch]

Hi Jouni, Georgios,

please see inline.

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Jouni
Sent: Samstag, 26. Mai 2012 16:13
To: karag...@cs.utwente.nl
Cc: dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment (single-
operator and cross-operator?)


Hi,

On May 25, 2012, at 3:57 PM, karag...@cs.utwente.nl
karag...@cs.utwente.nl wrote:

 Hi Jouni,

 Answering to your question(s):

 At least we need to make a
 distinction what cross administrative domain would mean: a) is it the
 MN moving across administrative domains or b) possibly (current) IP
 level anchor changing across administrative domains.

 Georgios: Please note that I was referring to both cases!

Since I have difficulties believing b) would be a successful requirement
without slicing it into different use cases, I would ask you to list up what 
use
cases you think b) is needed for and what assumptions there are for IP
anchoring  possible tunnel state.

I think it helps if that request is moved to a lower level and discussed
on the basis of handover between administrative domains versus
roaming. Roaming does not imply any requirement on IP
address continuity, I think the only requirement here is about
authentication and authorization when the MN gets assigned
an anchor in the visited network (along with a local IP address).
Handover may imply some demand for IP address continuity,
which should be handled by signaling according to the DMM solution.
Again, more an issue of available trust and security associations
to protect signaling.
..Unless inter-domain handling requires a dedicated functional
entity for DMM, which I don't hope.

If needed at all, what about placing a requirement just like: 
'The DMM solution must not break when being deployed between trusted
administrative domains and should allow inter-working with the security
measures deployed between these domains.'

marco






- Jouni






 Best regards,
 Georgios




 -Original Message-
 From: Jouni [mailto:jouni.nos...@gmail.com]
 Sent: vrijdag 25 mei 2012 14:49
 To: Karagiannis, G. (EWI)
 Cc: pierrick.se...@orange.com; h.anthony.c...@huawei.com;
 dmm@ietf.org
 Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment
 (single-operator and cross-operator?)


 On May 25, 2012, at 3:21 PM, karag...@cs.utwente.nl
 karag...@cs.utwente.nl wrote:

 Hi Pierrick,

 Please see in line!


 -Original Message-
 From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
 Sent: vrijdag 25 mei 2012 14:00
 To: Karagiannis, G. (EWI); h.anthony.c...@huawei.com
 Cc: dmm@ietf.org
 Subject: RE: [DMM] draft requirement REQ-1: Distributed deployment
 (single-operator and cross-operator?)

 Hi,

 As an operator guy, I will not dispute a use-case dealing with roaming 
 :-).
 However I think that it is out of the scope of our considerations
 here (I mean, from the IETF standpoint). IMU, the goal of DMM is
 not to specify a full system architecture (to which statement (1)
 below seems to refer); the goal of DMM is, in a first stage, to
 assess the use of legacy protocols in a distributed anchoring
deployment.

 Georgios: Not really defining a system architecture, but more the
 protocol
 framework! The definition of the distribution anchoring deployment
 borders is part of that!

 From my point of view, the protocol solutions (even what we have
 today in mobility area) do not prohibit cross administrative domain
 mobility. It is more a deployment decision loaded with non-techninal far
from trivial issues.

 I do not like seeing this as a requirement. At least we need to make
 a distinction what cross administrative domain would mean: a) is it
 the MN moving across administrative domains or b) possibly (current)
 IP level anchor changing across administrative domains.

 - Jouni





 Moreover, statement (2) below, is more a solution hints than a
 requirement.
 Typically, (2) is about HA/LMA relocation which may be, or not, a
 solution to meet Anthony's req#1. So, IMHO, req#1 addresses your
 concern.

 Georgios: I think that the current description of REQ-1 is not
 really
 addressing my concern!

 Best regards,
 Georgios


 That's only my opinion; let's see what others think.

 BR,
 Pierrick

 -Message d'origine-
 De : karag...@cs.utwente.nl [mailto:karag...@cs.utwente.nl] Envoyé :
 vendredi 25 mai 2012 12:28 À : SEITE Pierrick RD-RESA-REN;
 h.anthony.c...@huawei.com Cc : dmm@ietf.org Objet : RE: [DMM]
 draft
 requirement REQ-1: Distributed deployment (single-operator and
 cross-operator?)

 Hi Pierrick,

 The goal of such a requirement is to emphasize that the DMM
 protocol(s) that will be designed/specified by the DMM WG should
 be agnostic to whether users are roaming/moving into wireless
 coverage
 area(s) managed by either one single operator or by more than one
 operators.
 I think that this will have an impact on some of  the requirements
 listed already by Anthony!
 Security association 

Re: [DMM] New DMM draft: draft-bernardos-dmm-distributed-anchoring-00.txt

[Marco Liebsch]

Carlos, please see inline.

 -Original Message-
 From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es]
 Sent: Sonntag, 18. März 2012 20:59
 To: Marco Liebsch
 Cc: dmm@ietf.org
 Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed-
 anchoring-00.txt
 
 Hi Marco,
 
 Thanks for your comment. Please see inline below.
 
 On Fri, 2012-03-16 at 10:00 +, Marco Liebsch wrote:
  Carlos,
  thanks for your feedback. Please see inline.
 
   -Original Message-
   From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es]
   Sent: Freitag, 16. März 2012 09:51
   To: Marco Liebsch
   Cc: dmm@ietf.org
   Subject: RE: [DMM] New DMM draft: draft-bernardos-dmm-distributed-
   anchoring-00.txt
  
   Hi Marco,
  
   Apologies for the late reply. Thanks for reading the draft. Please
   see some answers to your questions/comments inline below.
  
   On Fri, 2012-03-09 at 11:51 +, Marco Liebsch wrote:
Hi Carlos,
   
I have a few clarifying questions to your new draft. The draft
proposes the distributed logical interface. I don't really get the
advantage of virtualizing the previous LMA on the MN's current LMA
if packets are routed through the previous LMA anyway. Why not
using the current LMA to serve simply as MAG for forwarded traffic
(which remains anchored at previous LMA) and using the new LMA to
anchor the
   new address/prefix?
  
   What you just mention is exactly what the draft does. Additionally,
   the logical interface simplifies the interface between the MN and
   the access router that behaves as LMA/MAG. It does so because by
   interacting with the MN as different logical routers (one per
   anchoring LMA), you can make full use of the ND based features (e.g.,
 RFC4191) in a very easy way.
  
   
The draft writes that the idea hides the change of the anchor from
the mobile node. The DGW2IF on the new LMA does not pretend to be
LMA1,
   or?
I don't see how the anchor change is kept transparent to the MN.
  
   The point is that from the point of view of the MN, it always sees
   as directly connected (1-hop away) each of the anchor LMAs. Every
   time the MN moves and attaches to a new access router, the only
   thing it notices is that a new
   (logical) router appears on the link, advertising a new prefix
   (and, in most use cases, the others start advertising the prefixes
   with lifetime=0 to deprecate them).
 
  The LMA function should be transparent to the MN anyway, so it does
  not matter whether the LMA, which serves as anchor, is on the previous
  AR or on the current one. Invalidating the previous HNP and validating
  the new HNP can be done independently of whether the responsible LMA
  instance is co-located with the local AR or the previous AR. But I
  must admit that I probably have to check that part of your draft again.
 
 If it just invalidating the prefix, this can be done, true. But the point is 
 that
 the DLIF concept enables to do more that just invalidating a prefix. Besides, 
 it
 makes easier to implement this prefix deprecation.

Ok, I'll check the description to better understand the DLIF function.

 
 
 
  
   
I somehow agree also to Pete's opinion that solving the packet
routing after anchor relocation above the anchors is a good
option. It simply allows more optimal routes.
  
   I have to read his draft, but unless you have control on the routing
   infrastructure (and this is not always possible, and it takes time
   to converge), I don't see many other options to ensure address
 continuity.
 
  I don't expect this to take long time, as the routing states are not
  to be enforced in all routers, at least not in our proposal.
  Intention is to keep the routing plane as it is and update states only
  is one dedicated router per data session, which translates the MN's IP
  address into a routable one to ensure that remaining routers in the
  network forward the downlink packet to the MN's current anchor point.
  The previous anchor point is released from any forwarding tasks. Further
 advantage is that routes are potentially more optimal compared to
 forwarding from a previous anchor.
  Which does not mean that both approaches cannot co-exist. A DMM
  solution could rely on forwarding while the state in the routing plane is
 established.
 
 I have to admit I haven't checked your proposal yet.

No problem ;-)

 What you mention
 seems like a NAT-based approach, is it true?

We propose NAT to save per-packet overhead and use the prefix/IP address
being assigned and anchored at the new anchor as locator, which intrinsically
has identifier information. So, reverse NAT on the new anchor is easily 
possible.
But that's not the key of the approach, as NAT can be easily replaced by IP 
tunnels.
The key approach is to solve DMM in the routing plane above anchors while using
the existing routing plane.

 and if there is a dedicated
 router, isn't it a centralized entity?

It's exactly

Re: [DMM] New DMM draft:draft-bernardos-dmm-distributed-anchoring-00.txt

[Marco Liebsch]

Hi Pierrick,

I agree that this is an interesting approach from research point of view. The 
question
is how practical this is. Intelligence on the MN is ok, but to take a decision 
about which
IP address to use, the MN needs information. If information is solely a binding 
between the prefix
and the level of the associated anchor in a hierarchy of anchors, then the
MN may select a prefix/address according to the expected IP session duration to 
avoid
a change in the topological anchor of the used IP address. Taking such decision 
requires also
some information about the topology, which I doubt operators will reveal. 
Important
here is the location of the anchor and the location of the used serving point. 
Latter could
be a public Internet service, hence knowledge of the operator's IX peering 
points may
be relevant. If the serving point is operator CDN-like, typically the MN is 
served
by transparent caching, hence, the location of the cache is not known to the MN.

A different and pragmatic approach is to select the closest anchor point to 
serve any IP session
of the UE and to provide a good solution to handle routing after anchor 
relocation plus
renewal of the MN's IP address from time to time. IMO, such approach enables 
short
routing paths between any source and the MN while offloading traffic from the 
core
network as its best.

marco




 -Original Message-
 From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
 Sent: Montag, 19. März 2012 11:17
 To: jouni.nos...@gmail.com; c...@it.uc3m.es; Marco Liebsch
 Cc: dmm@ietf.org
 Subject: RE: [DMM] New DMM draft:draft-bernardos-dmm-distributed-
 anchoring-00.txt
 
 I think it is worth to work on solution providing more information on the type
 of address. IMHO, it is a requirement for the UE to play with more than one
 IP address and select the more appropriate source address according the
 topological anchor point. DMM is clearly one use-case but, this feature is 
 also
 required for offload purpose in current centralized network based mobility.
 The ongoing proposals for RA extensions, that allow to distinguish anchored
 from local prefix, are interesting. Now, the UE shall have the intelligence to
 make the source address selection according to prefix properties; at least
 extensions to RFC3484 may be defined but more sophisticated selection
 behavior may be required, typically, policies based selection, e.g. offload
 policies.
 
 Pierrick
 
  -Message d'origine-
  De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de
  jouni korhonen Envoyé : dimanche 18 mars 2012 21:47 À : Carlos Jesús
  Bernardos Cano; Marco Liebsch Cc : dmm@ietf.org Objet : Re: [DMM] New
  DMM draft:draft-bernardos-dmm-distributed-
  anchoring-00.txt
 
 
  
   So you think that the UE should receive multiple IP addresses and
  treat them
   differently according to the associated topological anchor point?
  Hmm, yes, possible.
   What about real time streaming and other IP data sessions, which
  could have a
   longer lifetime, they should be anchored than at a central point as
  well, right?
   If the MN had such intelligence and information, it could treat the
  HNPs differently, true.
  
   I think thank kind of approaches make sense.
 
  There are a couple proposals on table that go into this direction. We
  put those under addressing enhancements slot. Basically piggybacking
  anchoring properties of a prefix along with address configuration.
 
  - Jouni
 
 
 
  
   Carlos
  
  
   marco
 
  ___
  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