Subject: [DMM] DMM Interim telco #3 materials uploaded

From: Jouni Korhonen <[email-masked]>
Date: Tue, 07 Oct 2014 23:55:45 +0300

Go here:
o 
http://www.ietf.org/proceedings/interim/2014/10/07/dmm/agenda/agenda-interim-2014-dmm-3
o 
http://www.ietf.org/proceedings/interim/2014/10/07/dmm/minutes/minutes-interim-2014-dmm-3
o http://www.ietf.org/proceedings/interim/2014/10/07/dmm/proceedings.html

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2014 11:32:11 +0300

Hello folks,

Here are few clarification questions and comments on the Forwarding Path & Signaling Management WT discussion material (oh, maybe it's time we start numbering these WTs :-)
http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-interim-2014-dmm-3-1.pdf

- Are we not going to support roaming? Or, even w/o roaming, I'd think there'd be inter-domain signaling, e.g., DPA and DPN belonging to two different networks.

- What is the difference between DPA and DPN? We need definitions for these terms.

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

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

- What is a controller "type"?

- Should QoS really be part of this work? I think not…

- Why would DP be querying CP? 

- Slide 13: It's not immediately clear why we need these identifiers, and how they are used. Maybe there's a solution behind them, but the reader cannot get the picture.

Thanks.

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 16 Oct 2014 08:58:00 +0000

Alper,

Inline Š

On 10/16/14 1:32 AM, "Alper Yegin" <[email-masked]> wrote:

>Hello folks,
>
>Here are few clarification questions and comments on the Forwarding Path
>& Signaling Management WT discussion material (oh, maybe it's time we
>start numbering these WTs :-)
>- Are we not going to support roaming? Or, even w/o roaming, I'd think
>there'd be inter-domain signaling, e.g., DPA and DPN belonging to two
>different networks.

[Sri] I agree, Roaming should be supported. That's a good point. That is a
intra-controller interface.

>- What is the difference between DPA and DPN? We need definitions for

[Sri] 
Data Plane Anchor
Data Plane Node

We had some definitions in the IETF slides that we discussed in the last
meeting 

>- Slide 8: Is this simply showing how BGP-based solutions can be covered

[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

>- What is a controller "type"?

[Sri] In deployments there could be controller entities on function basis;
Ex: Mobility Controller, Routing controller ..etc. I agree with you we
should not decompose the controller, but should look at this as one single
entity. 

>
>- Should QoS really be part of this work? I think notŠ

[Sri] There is QoS support in all mobility architecture. QoS is tied to
subscription and a key function of the mobility gateway. The CP entity
should be able to provide the QoS parameters to the DP entity

>- Why would DP be querying CP?

[Sri] Keeping the interface between CP and DP flexible allows us to
support all types of scenarios. Lets take a simple example of a DP node
loosing state, there should be mechanism to make a query to the CP entity.

>
>- Slide 13: It's not immediately clear why we need these identifiers, and
>how they are used. Maybe there's a solution behind them, but the reader
>cannot get the picture.

[Sri] These are described at a high-level; Subject to change. The draft
should have some details on the semantics and structure.

>
>Thanks.
>
>Alper
>
>
>
>
>
>
>
>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

---

From: <[email-masked]>
Date: Thu, 16 Oct 2014 09:16:34 +0000

Hi,

On roaming: 

Sri, I guess you meant "inter-controller interface", right? IMU, roaming is about coordination between controller belonging to different administrative (or routing?) domain.

Sri already clarified this, but I think it is important to insist on the fact that the wort item shall specified a protocol agnostic CP/DP interface .Then, this generic interface  can be implemented using different protocols (among them is BGP), but this is out of scope of the work item.

BR,
Pierrick

>-----Message d'origine-----
>De : dmm [mailto:[email-masked]] De la part de Sri Gundavelli
>(sgundave)
>Envoyé : jeudi 16 octobre 2014 10:58
>À : Alper Yegin; [email-masked]
>Objet : Re: [DMM] Forwarding Path & Signaling Management discussion
>
>Alper,
>
>Inline Š
>
>
>>Here are few clarification questions and comments on the Forwarding
>>Path & Signaling Management WT discussion material (oh, maybe it's time
>>we start numbering these WTs :-)
>>http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-in
>>ter
>>im-2014-dmm-3-1.pdf
>>
>>
>[Sri] I agree, Roaming should be supported. That's a good point. That is a intra-
>controller interface.
>
>
>>
>[Sri] The interface can be realized using multiple approaches, one being the
>BGP-based approach, other explicit signaling based interface
>
>
>>
>[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.
>Ex: Mobility Controller, Routing controller ..etc. I agree with you we should not
>decompose the controller, but should look at this as one single entity.
>
>
>
>>
>subscription and a key function of the mobility gateway. The CP entity should
>be able to provide the QoS parameters to the DP entity
>
>
>>
>[Sri] Keeping the interface between CP and DP flexible allows us to support all
>types of scenarios. Lets take a simple example of a DP node loosing state,
>there should be mechanism to make a query to the CP entity.
>
>>
>>- Slide 13: It's not immediately clear why we need these identifiers,
>>and how they are used. Maybe there's a solution behind them, but the
>>reader cannot get the picture.
>
>[Sri] These are described at a high-level; Subject to change. The draft should
>have some details on the semantics and structure.
>
>
>>
>>Thanks.
>>
>>Alper
>>
>>
>>
>>
>>
>>
>>

_________________________________________________________________________________________________________________________

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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 16 Oct 2014 10:08:08 +0000

Hi Pierrick,

Yes; Typo. Its inter-controller interface.

We have to look at DMM as a mobility domain and the interactions/protocol
interfaces are between the entities within that domain. The roaming is
more about a business relation and about security agreements. I do not
believe we need to model business relations into protocol definitions.
That's more about sharing security credential and authorization. Its
possible administrative boundaries are at a domain level and the
controllers of each domain may have security relation with other
controllers. A controller of one domain may not interface with the Data
Plane entities managed by another controller, but it may interface with
the controller of other domain, so that controller can interface with the
Data Plane entities under its control.

In this context of this work, its simply a interface between Control-Plane
and User-plane entity. The focus of the discussion is more about the
semantics of the interface; its about operations, information elements and
the expected state changes.

Sri

On 10/16/14 2:16 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi,
>
>On roaming: 
>
>Sri, I guess you meant "inter-controller interface", right? IMU, roaming
>is about coordination between controller belonging to different
>administrative (or routing?) domain.
>
>Sri already clarified this, but I think it is important to insist on the
>fact that the wort item shall specified a protocol agnostic CP/DP
>interface .Then, this generic interface  can be implemented using
>different protocols (among them is BGP), but this is out of scope of the
>work item.
>
>BR,
>Pierrick
>
>>the
>>context of
>>should not
>>should
>>support all
>>should
>__________________________________________________________________________
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 16 Oct 2014 10:41:40 +0000

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

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

..

>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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Oct 2014 08:32:52 +0300

Sri,

> should be able to provide the QoS parameters to the DP entity

I'd say let's not deal with it in DMM WG. Or at the least, let's not tackle it in the first phase of DMM work.
Otherwise we are making our life an order of magnitude harder from very beginning.

Alper

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 17 Oct 2014 05:59:39 +0000

Alper,

Fair point on the complexity involved in getting this right. I agree with
that assessment.

Not having it as part of the baseline also carries the risk of getting
this interface tagged as an incomplete-interface and
not-ready-for-deployment.

Lets see how the interface shapes up, based on that we can decide.

Regards
Sri

On 10/16/14 10:32 PM, "Alper Yegin" <[email-masked]> wrote:

>I'd say let's not deal with it in DMM WG. Or at the least, let's not
>tackle it in the first phase of DMM work.
>>>Path
>>>http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-int
>>>er
>>> im-2014-dmm-3-1.pdf
>>> 
>>> 
>>> - Slide 8: Is this simply showing how BGP-based solutions can be
>>>covered
>>> here? Or something else?
>> 
>> 
>>>and