[Actn] R: MSDC-PNC m:n (was R: ACTN progress)

[Daniele Ceccarelli <[e-mail]>]

Hi Sergio,

My point of disagreement is simply that m:1 and m:n IMO don't have the same degree of complexity :)

They do have the same degree of complexity only in particular cases.

Cheers
Daniele

Sent from a mobile device, please forgive spelling mistakes and short replies

-------- Messaggio originale --------
Da: "BELOTTI, SERGIO (SERGIO)"
Data:20/01/2015 18:27 (GMT+01:00)
A: Daniele Ceccarelli ,Leeyoung ,Igor Bryskin ,Dave Hood ,Zhenghaomian
Cc: [e-mail]
Oggetto: RE: MSDC-PNC m:n (was R: [Actn] ACTN progress)

Hi Daniele,

what is your point of disagreement? About the child responsibility in general or the complexity?
the important point is to permit parent of looking at resources as they would be the only one acting on these.
As David said “A parent is not expected to know whether it is sharing resources with peers.”
So , how you want to complicate your level of policy and confidentiality it is another story. But you’re right that the case you mentioned has to be addressed

Thanks
Ciao
Sergio

Belotti Sergio - System Architect
ALCATEL-LUCENT  IP Routing&Transport
via Trento 30 Vimercate (MB) - Italy
phone [phone]

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: martedì 20 gennaio 2015 18:11
To: BELOTTI, SERGIO (SERGIO); Leeyoung; Igor Bryskin; Dave Hood; Zhenghaomian
Cc: [e-mail]
Subject: MSDC-PNC m:n (was R: [Actn] ACTN progress)

Hi all,

Changing the subject as there are multiple threads ongoing with the same subject.

This time I have to disagree guys. It is possible to keep the complexity limited to the child only in some cases I. E. Hard separation of resources and no preemption.

If resources of a PNC are shared between MDSC1 e MDSC2, assigned to MSDC1 and then preempted by a new LSP or a restoration of an LSP of  MSDC2 the PNC must be able to tell MDSC1 : "I'm sorry, your resources were stolen".
If we don't want to support this, that's fine with me but we must clearly state what is supported and what is not.
That said I'm fine with the m:n with limitations or extra complexity.
Cheers,
Daniele


Sent from a mobile device, please forgive spelling mistakes and short replies
-------- Messaggio originale --------
Da: "BELOTTI, SERGIO (SERGIO)"
Data:20/01/2015 11:28 (GMT+01:00)
A: Leeyoung ,Igor Bryskin ,Dave Hood ,Daniele Ceccarelli ,Zhenghaomian
Cc: [e-mail]<mailto:[e-mail]>
Oggetto: RE: [Actn] ACTN progress

Hi Young,
I share completely Dave's point about child responsibility, and yes, you got it my previous thought: independently of the number of parents MSDC , while in the relationship with his parent child is expecting to deal with confidentiality and isolation, this does not happen to be the case for cross-over relation. Any reference in the original picture from Adrian's.

Thanks
Sergio


Belotti Sergio - System Architect
ALCATEL-LUCENT  IP Routing&Transport
via Trento 30 Vimercate (MB) - Italy
phone [phone]


-----Original Message-----
From: Leeyoung [mailto:[e-mail]]
Sent: lunedì 19 gennaio 2015 21:45
To: Igor Bryskin; Dave Hood; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Zhenghaomian
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] ACTN progress

Hi,

I agree with Dave and Igor, m:n does not add any overhead and we can start with m (=1) and n (>1).

Dave's points on "the child's responsibility to ensure isolation amongst the parents" (and "a parent is not expected to know whether it is sharing resources with peers") are important to grasp. This mean there would be no cross-over control flows between MDSCs in the same peer level, observing the "isolation" rule. I believe this what Sergio was talking about in one of the previous emails.

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]
Sent: Monday, January 19, 2015 12:37 PM
To: Dave Hood; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] ACTN progress

Exactly right.
________________________________________
From: Dave Hood [[e-mail]]
Sent: Monday, January 19, 2015 12:08 PM
To: Igor Bryskin; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] ACTN progress

If the child exports an interface to more than one parent, it is the child’s responsibility to ensure isolation amongst the parents, either through hard partitioning of resources or through contractually understood sharing arrangements, for example best-efforts bandwidth or first-come-first-served access.

A parent is not expected to know whether it is sharing resources with peers.

Dave

From: ACTN [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: Monday, January 19, 2015 6:18 AM
To: Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] ACTN progress

Hi Danielle,
First, this simplification does not give you anything, because the parent MDSC never knows who else the child MDSC is talking to, i.e. the parent always assumes that it has the child’s undivided attention.
Second, what if the child MDSC (such as ADVA) actually needs to serve more than one client ?
Third, m:n also includes 1:1 and m:1 with no overhead,

Igor

From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Monday, January 19, 2015 9:07 AM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] ACTN progress

Hi Igor,

This is for sure a desirable scenario but I see it pretty complex to manage. I would prefer to start with the assumption of 1 parent MDSC (let me call it so) connecting to M child MDSCs, but each child speaking to a single parent. It should be M:1 in your terminology.
We might then consider extending to M:N but I’d fly down at the beginning ☺

Cheers
Daniele



From: ACTN [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: lunedì 19 gennaio 2015 14:37
To: BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Actn] ACTN progress

The cardinality of two adjacent  in ACTN hierarchy MDSCs is M:N, i.e. the upper MDSC can talk to any number m of lower (serving) MDSCs, each of which can serve any number n of client MDSCs. Numbers m and n are independent of each other. Furthermore, the ACTN interface between the two adjacent MDSCs is oblivious of numbers m and n, i.e. each MDSC “believes” that the other one talks only to him.
I also hope that we have agreed that an MDSC represents the entire set of functionalities of a transport SDN controller supported by the ACTN architecture, which in practice could be limited to CNC, PNC, “partial” MDSC, etc., which, however, at any time can enable more or disable some of supported features. Actual set of supported features is known to a given pair of adjacent  in ACTN hierarchy MDSCs and is dynamically (re-)learnt via the capability auto-discovery supported by the ACTN interface and is known only to the pair but no other MDSCs

Cheers,
Igor

From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
Sent: Monday, January 19, 2015 3:19 AM
To: Zhenghaomian; Leeyoung
Cc: Igor Bryskin; [e-mail]<mailto:[e-mail]>
Subject: RE: [Actn] ACTN progress

Hi Haomian,

Reading your original comment my understanding is that you’re referring to g-h piece of interface in the original Adrian’s picture, this would preclude the “1:1” relationship between a PNC and MSDC . The relationship between different MSDC is not at the moment first priority in ACTN context, but nothing preclude to think about “distributed implementation” of MSDC, maintaining the logical 1:1 relation between PNC and his own MSDC. This would be my view.

Thanks a lot

Sergio


From: Zhenghaomian [mailto:[e-mail]]
Sent: lunedì 19 gennaio 2015 02:29
To: BELOTTI, SERGIO (SERGIO); Leeyoung
Cc: Igor Bryskin; [e-mail]<mailto:[e-mail]>
Subject: 答复: [Actn] ACTN progress

Thanks Sergio and Young.

My understanding for the term ‘cross-over’ is only talking about inter-connections of MDSCs. I don’t think there should be any kinds of cross-over on CNC or PNC level. It is still quite clean hierarchy, i.e., we have CMI and MPI on the ‘vertical’ direction, and allow some inter-MDSC interface on the ‘horizontal’ direction. In my opinion this structure is rather simple, unless there are thousands of MDSC interconnections☺

I also agree on Young’s suggestion on ‘advanced case’, at the moment let’s try to keep it simple and solve it first.

Best wishes,
Haomian

发件人: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
发送时间: 2015年1月17日 1:41
收件人: Leeyoung; Zhenghaomian
抄送: Igor Bryskin; [e-mail]<mailto:[e-mail]>
主题: RE: [Actn] ACTN progress

Hi Young, Haomian,

“I agree with you in general that cross-over makes things complicated.”
I think that  cross-over would be in contrast with the hierarchical view of controllers, so absolutely to avoid.

Thanks
Sergio

From: ACTN [mailto:[e-mail]] On Behalf Of Leeyoung
Sent: giovedì 15 gennaio 2015 21:21
To: Zhenghaomian; [e-mail]<mailto:[e-mail]>
Cc: Igor Bryskin
Subject: Re: [Actn] ACTN progress

Hi Haomian,

I think the original figure was only for illustration purpose to illustrate a recursive relationship in a hierarchy. I agree with you in general that cross-over makes things complicated.

In an advanced case, one CNC may interface multiple MDSCs (one MDSC for one operator and the other for another operator). If this is in scope or not, I don’t have a particular opinion about that although I would prefer to defer this case in a later phase.

Thanks,
Young



From: Zhenghaomian
Sent: Thursday, January 15, 2015 1:55 AM
To: Leeyoung; [e-mail]<mailto:[e-mail]>
Cc: Igor Bryskin
Subject: 答复: [Actn] ACTN progress

Hi, Young,

Great to see this figure, very helpful for understanding. I would like to propose two more points for clarification.

Firstly, my understanding was, the relationship between CNC and MDSC is N-to-1 instead of N-to-M, i.e., each CNC should have ONLY one (dedicated) MDSC. From this figure, I am not sure whether there can be potential message flow on the c-d interface, that is another CNC-MDSC connection. Similarly I think the relationship between MDSC and PNC is 1-to-N instead of M-to-N, each PNC should have only one MDSC, instead of cross-over. In your figure for the left-bottom PNC, it seems to me g-h is also a possible interface.

If the relationship are strictly limited to 1-to-N and N-to-1, I convert your figure as follow, which may be equivalent, but more clear on the hierarchy:

        +-----+           +-------+
       | CNC|        |  CNC  |                    Customer level
        +-----+           +-------+
           |a                     | c
           |                       |
           |b                     | e
       +--------+ d     e +----------+ f       h+------------+
      | MDSC|-------- | MDSC |---------|  MDSC  |          Virtual Control level
       +--------+            +----------+           +------------+
                                      |f                        i |
                                      |                           |
                              |                            |
                                     |g                        j |
                            +--------+                 +--------+
                            | PNC |                   | PNC |      Physical level
                            +--------+                 +--------+

Actually there can be more interaction on the Virtual Control level, which means there can be more connections among MDSCs.

Secondly, it is good to make analogy to PCC-PCE. For service provisioning, such customer-provider relationship always exists, we may find something in common on CMI and MPI, but there are certainly extensions.

Best wishes,
Haomian

发件人: Leeyoung
发送时间: 2015年1月15日 12:21
收件人: Zhenghaomian; Leeyoung; [e-mail]<mailto:[e-mail]>
抄送: Igor Bryskin
主题: RE: [Actn] ACTN progress

Haomian,

Thanks for your comment.

First of all, I think I used the term ‘model’ loosely. It really means roles/functions of control entities to perform and it requires data models and protocols to support the data models.

MSDC and PNC are still different components and are to be distinguished. In the ACTN hierarchy, the top level is the CNC and the bottom level is the PNC. And in between of a hierarchy there may be MDSCs and PNCs. Look at the following recursive diagram (thanks to Adrian who first drew this):


                              CNC

                               |a

                               |

                               |b

                CNC          MDSC

                 |c            |d

                 |             |

                  ------+------

                        |

                        |e

                      MDSC

                        |f

                        |

                  ------+------

                 |             |

                 |g            |h

                PNC           MDSC

                               |i

                               |

                              |j

                              PNC

From this figure, for the middle MDSC interfacing a PNC (via f, g interfaces) and a MDSC (via f, h interfaces), efficient data models and protocol design should be able to support both interfaces as if they are the same. That is what it means to “MDSC should not be able to distinguish if it interfaces MDSC or PNCs (i.e., the same interface)”.  This is different from saying the MDSC should not have ability to identify MDSCs or PNCs in its south bound.  Indeed the MDSC would know (in most implementations) who it is and what it interfaces.

I think Dhruv used an analogy from PCEP.  A PCEP interface can mean a PCE-PCC or a PCE-PCE interface.  PCEP has a common model and protocol to support both interfaces. In a similar way, I think ACTN can have a common model and protocol to support all its interfaces.

“CNC interfacing MDSC should be essentially the same interface as MDSC interfacing another MDSC or PNCs” --- I think what this means is that the model and protocol primitives can share the common property between CNC-MDSC and MDSC-PNC/MDSC. The granularity and policy context may differ, but we can develop the common model that encompass all interfaces. We can define objects to allow contextual differences, but still with the same model.

Thanks,
Young

From: Zhenghaomian
Sent: Wednesday, January 14, 2015 9:09 PM
To: Leeyoung; [e-mail]<mailto:[e-mail]>
Cc: Igor Bryskin
Subject: 答复: [Actn] ACTN progress

Hi, Young and Igor,

Thanks for the sharing, great to see a more converged architecture. From my perspective, the model work mentioned are all necessary, but it seems such model should be dependent on protocol works, i.e., we need to complete protocol first and then modeling. Parallel style is also good for protocol and model, but I prefer we turn to protocol if they have some inconsistency between protocol and model. Besides I still have some questions:

In the previous mail, I am a little bit confused with the limitation on MDSC connection. It seems MDSC is not clear with who it is connecting by mentioning “MDSC should not be able to distinguish if it interfaces MDSC or PNCs (i.e., the same interface)”. My opinion is it is not necessary to limit the knowledge of MDSC, i.e., it is fine if a MDSC has the ability to detect whether it is connecting with a PNC or another MDSC. At least, a MDSC MUST have the ability to identify CNC from MDSC/PNCs.  Or maybe you are saying “A PNC can become MDSC if there is recursive hierarchy? ”. I like this due to the dynamic topology growing in the network.

By reading “CNC interfacing MDSC should be essentially the same interface as MDSC interfacing another MDSC or PNCs”, I feel that the functionalities on interface B and C (defined in fwk draft) are becoming similar, which quite confuse me as well. I agree that these interfaces may have similar message flow during service request, provisioning and so on, but they are quite different during OAM, recovery and resource mgmt. I don’t think it is a good idea to consider these two interface “the same as each other”.

Would you please help explain the issue above? Thanks a lot.

Best wishes,
Haomian

发件人: Leeyoung [mailto:[e-mail]]
发送时间: 2015年1月15日 3:12
收件人: [e-mail]<mailto:[e-mail]>
主题: [Actn] ACTN progress

Hi All,

Just wanted to share some private emails exchanged among a limited interested parties in the past week with a permission with Igor.

In a nutshell, I think we are converging with a common view on ACTN interfaces and architecture. Please check the following email thread. Please comment if you have any question.

Thanks,
Young

From: Igor Bryskin [mailto:[e-mail]]
Sent: Thursday, January 08, 2015 2:13 PM
To: Leeyoung; Daniele Ceccarelli
Cc: AshwoodsmithPeter
Subject: RE: Recap this morning's call

Hi Young,
You’ve captured all pretty accurately. I nominate you for the ACTN scribe job :=)

Igor

From: Leeyoung [mailto:[e-mail]]
Sent: Thursday, January 08, 2015 3:09 PM
To: Igor Bryskin; Daniele Ceccarelli
Cc: AshwoodsmithPeter
Subject: Recap this morning's call

Hi Igor,

Thanks for this morning’s call. I just wanted to recap what was agreed upon. Please feel free to correct if anything needs to be corrected.

We have identified several models to be implemented in ACTN control hierarchy (CNC-MDSC-PNC). Among them are, but not limited to:


1.      Topology Model

2.      Provisioning Model

3.      Service Model

4.      OAM Model

5.      Client Mapping/Policy Model

There could be more to the list. We can identify and add later on if we will.

Now, with these models, different components (i.e., different controller type) will implement whatever relevant models and support its interfaces. For instance, PNC may need not support Client mapping/policy model while CNC may not need to support Provisioning model.

We also agree that MDSC can interface another MDSC or PNCs with transparency. MDSC should not be able to distinguish if it interfaces MDSC or PNCs (i.e., the same interface).

And you also said, CNC interfacing MDSC should be essentially the same interface as MDSC interfacing another MDSC or PNCs.

Let us start from here. Then we can discuss further.

Thanks,
Young