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 se
ernet-dra...@ietf.org]
Sent: Dienstag, 13. März 2012 00:45
To: lieb...@neclab.eu
Subject: New Version Notification for draft-liebsch-mext-dmm-nat-phl-01.txt
A new version of I-D, draft-liebsch-mext-dmm-nat-phl-01.txt has been
successfully submitted by Marco Liebsch and posted to the IETF repos
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-bernard
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
ntag, 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
> o
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 (si
I support adopting the document as base for a WG document.
marco
>-Original Message-
>From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
>jouni korhonen
>Sent: Mittwoch, 20. Juni 2012 10:52
>To: dmm@ietf.org
>Cc: dmm-cha...@tools.ietf.org
>Subject: [DMM] WG Call for ado
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 rel
fully submitted by Marco Liebsch and posted to the IETF
repository.
Filename:draft-liebsch-dmm-framework-analysis
Revision:00
Title: Distributed Mobility Management - Framework & Analysis
Creation date: 2012-10-15
WG ID: Individual Submission
Number of page
Hi Georgios,
thanks for your comments. Please see inline for my response.
>-Original Message-
>From: karag...@cs.utwente.nl [mailto:karag...@cs.utwente.nl]
>Sent: Sonntag, 4. November 2012 21:02
>To: Marco Liebsch; dmm@ietf.org
>Subject: RE: DMM functional framework pos
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
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 fo
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-fra
m-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
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 managemen
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 an
t can help the WG to
progress does not seem to be a bad idea, IMHO. And there was some support
from the WG for having a framework.
marco
>-Original Message-
>From: Julien Laganier [mailto:julien.i...@gmail.com]
>Sent: Freitag, 29. März 2013 18:17
>To: Behcet Sarikaya
>Cc
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 mu
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 i
Please find below some comments about
draft-ietf-dmm-best-practices-gap-analysis-02.
Authors did a good job in merging two BCP and gap analysis drafts. I have some
comments
though which may help to improve readability and gaining advantage from such
document.
General notes:
I think it's import
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
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@i
rco
>-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 recharteri
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 DM
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,
>
&g
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
I don't have a problem with the anchor term if we treat it as a function in the
network which knows
how to further forward packets to an MN's location. That can be any tunnel
management protocol,
aka (P)MIPv6, and should be orthogonal to the DMM solutions. That function can
be also a router/swit
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 J
I think both options are good and added my entry to the doodle.
Thanks,
marco
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dapeng Liu
Sent: Donnerstag, 5. Juni 2014 10:31
To: Hidetoshi Yokota
Cc: dmm@ietf.org
Subject: [DMM] 回复： 回复： 回复： Teleconference
Hi Yokota-san, Alper and all,
It see
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-sess
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 t
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 "a
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
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&qu
You may add the framework draft to that category as well.
draft-liebsch-dmm-framework
Marco
On 20.07.2014, at 15:11, "Jouni Korhonen" wrote:
> And then there is the "Distributed mobility management deployment models and
> scenarios":
>
> draft-liu-dmm-deployment-scenario
>
> Forgot that..
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 Joun
Hi Alper,
thanks for posting the update. One clarifying question on the following service
requirement:
'The 3GPP system shall minimize the number of connections of a UE without
disrupting the
UE's services, e.g. to ensure economical use of network resources'
Can this be understood as the numbe
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]
;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 physi
Hi Sri, please see inline.
>-Original Message-
>From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
>Sent: Donnerstag, 11. September 2014 15:58
>To: Marco Liebsch; Charlie Perkins; dmm@ietf.org
>Cc: Vijay Devarapalli
>Subject: Re: [DMM] regarding the re-charte
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
Folks,
the clear winner for the telco date, where we should further investigate the
DMM work item
about forwarding path & signaling management, is as follows:
Date: Thursday, 16th October 2014
Time: 16:00 CEST / 07:00 PDT
Duration: 90min
I'll send an agenda proposal and WebEx information around
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. obj
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
Folks,
as per the conclusion of first telco about Forwarding Path and Signaling
Management (FPSM),
we considered to schedule a 2nd call before IETF91. Please fill the following
doodle if you're interested
in attending the call. Let's see if we can bring most people together.
http://doodle.com/px
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.
B
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) h
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
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
__
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
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
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
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
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 separa
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
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
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: dm
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.
h 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
Ag
Hi Alper,
I could join only the last 5min of the call and could not participate in the
discussion, nor in the
draft selection, which does not mean I disagree with the agreement.
One clarifying question. The scope of WI1-4 has been clearly described and the
selected
draft is about extending sock
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
n, 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]
ssion 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
Rev
r {
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.org<mailto:dmm@ietf.org>
Subject: [DMM] FPSM work team draft
Folks,
the FPSM work team published a first draft about
I support the adoption of this Internet draft as DMM WG document.
marco
>-Original Message-
>From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
>Sent: Mittwoch, 1. April 2015 17:02
>To: dmm@ietf.org; Jouni; Dapeng Liu; draft-perkins-dmm-
>4283mn...@tools.ietf.org
>Subject
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
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
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 c
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 N
. 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
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 20
o 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 p
Hi Lyle,
thanks for your position and good comments to the current version of the draft.
First of all, the draft is not complete and for sure needs feedback on required
control. So, your proposal is more than welcome.
My understanding of your comment is that you’re looking for control on a rule,
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 tra
added.
Others’ opinion on this?
marco
From: Lyle Bertz [mailto:lyleb551...@gmail.com]
Sent: Donnerstag, 8. Oktober 2015 17:02
To: Marco Liebsch
Cc: draft-ietf-dmm-fpc-c...@ietf.org; dmm@ietf.org
Subject: Re: Copying Traffic in FPC
Marco,
wrt
> You think about something like flow sampl
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
draf
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 mobil
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 evolu
n 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 Anc
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
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:
ction-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
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
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 lef
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
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 mode
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 pla
ontrol 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) mailto:sgund...@cisco.com>>;
Di
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
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
..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
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-il
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.or
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
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 の
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 Herber
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,
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
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 a
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 f
1 - 100 of 107 matches
Mail list logo
