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

[Daniele Ceccarelli <[e-mail]>]

Hi Young,

I agree with Igor (if I understood what he meant :) ...

I don't see the need for defining a logical MDSC when we can work on hierarchies. I would say that this scenario with the logical MDSC

                    CNC
                       |
      --------------------------
     |  MDSC1        MDSC2 |
       --------------------------
                       |
                       |
                     PNC

Is equal to the this one:
                 
                    CNC
                       |
            Parent MDSC
                   /        \ 
                 /            \
       MDSC1        MDSC2 
                \             /
                  \         /
                     PNC

However I see this scenario reasonable just for corner cases in which different MDSCs are used for the control of different parts of the network under the same PNC.

BR
Daniele 

> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: mercoledì 21 gennaio 2015 23:10
> To: Igor Bryskin; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Hi Igor,
> 
> Oh, great! So let me rephrase what you said.
> 
> - "One MDSC block" can fan out to have a parent MDSC with several child
> MDSCs, each of which is responsible for a layer network (ETH, OTN, WDM,
> etc...).
> - A CNC would interface the parent MDSC as a single point interface and the
> parent MDSC would trigger service request/mapping to a pertinent child
> MDSC (I guess depending on the nature of Customer application and
> connectivity to customer premise, etc)
> 
> In effect, you are saying we need a hierarchy within the MDSC block. In this
> particular example, there are 2-level hierarchy of MDSCs. Which are all good
> so far with me. Now my question is:
> 
> - For the child-level MDSCs (which are on a peer level to each other), do you
> see any reason why you'd really want to physically separate them into ones
> responsible for a layer network? Can that be one logical entity into which
> there are soft-partitions of control and abstraction for each layer network?
> 
> - Are you thinking that these child-level MDSCs are indeed more or less PNCs
> (PNCs are the control entities having direct interfaces with NEs)? If this is yes,
> physical partition makes sense to me.
> 
> And you said, "Also, even when the child provides a single abstract topology,
> the actual service manipulation can be provided by multiple MDSCs, for
> example, there could be a dedicated MDSC that orchestrates service
> restoration, while a separate one takes care of global optimization and
> bandwidth fragmentation removal, etc." Do you think this can be
> modeled/provided as multiple servers within a single control architecture?
> 
> Regards,
> Young
> 
> 
> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Wednesday, January 21, 2015 2:21 PM
> To: Leeyoung; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Young,
> Please see in-line.
> 
> -----Original Message-----
> From: Leeyoung [mailto:[e-mail]]
> Sent: Wednesday, January 21, 2015 2:34 PM
> To: Igor Bryskin; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Hi Igor,
> 
> It looks like there are tons of work to be done in ACTN!
> 
> A couple of question to you:
> 
> - for separate MDSCs (per WDM, OTN, Ethernet, ...), do you envision them
> on a peer level or a hierarchical level? If they are on a peer level, can we
> model as a logical entity?
> 
> IB>> A child ACTN controller can provide multiple abstract topologies to the
> parent ACTN controller in the ACTN hierarchy (e.g. one per layer network).
> The interface between the controllers will be the same, however, service
> requests will be handled by separate MDSCs of the child controller. Note that
> some elements of said abstract topologies may be mapped onto same
> physical resources (that is, shared). Also, even when the child provides a
> single abstract topology, the actual service manipulation can be provided by
> multiple MDSCs, for example, there could be a dedicated MDSC that
> orchestrates service restoration, while a separate one takes care of global
> optimization and bandwidth fragmentation removal, etc.
> 
> BTW,  I like better  *hierarchy of ACTN controllers* than *hierarchy of CSCs/
> MDSCs/PNCs".
> 
> - If they cannot be modeled as one logical entity, how would a CNC know
> which MDSC it should talk to?
> 
> IB>> See above.
> 
> - for your VPN/application case, can we logically separate the partitions
> rather than on a physical level?
> 
> IB>> There is no physical separation, only logical. Each VPN will have its own
> abstract topology with some elements shared (mapped onto the same
> physical resources). What I was saying is that each VPN can be supported by
> a separate MDSC.
> 
> Thanks,
> Young
> 
> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Wednesday, January 21, 2015 1:14 PM
> To: Leeyoung; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Separate MDSC can take care of services in different layer networks WDM,
> OTN, ETHERNET ,,, ________________________________________
> From: ACTN [[e-mail]] on behalf of Igor Bryskin
> Sent: Wednesday, January 21, 2015 2:06 PM
> To: Leeyoung; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: Re: [Actn] R:  MSDC-PNC m:n (was R:  ACTN progress)
> 
> There certainly could be reasons for multiple MDSCs in a single domain:
> 1.MDSC per VPN
> 2. MDSC per application: original service setup, service replacement, global
> optimization, failure restoration, etc.
> all these applications could be supported by a separate MDSC
> 
> 
> ________________________________________
> From: Leeyoung [[e-mail]]
> Sent: Wednesday, January 21, 2015 12:58 PM
> To: Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO (SERGIO); Igor
> Bryskin; Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R:  MSDC-PNC m:n (was R:  ACTN progress)
> 
> Hi Daniele,
> 
> For the first figure, what I said in my previous email with diagram was MDSC1
> and MDSC2 can be modeled as one-logical entity. Please see the following:
> 
>                       --------------------------
>      |   MDSC1        MDSC2 |
>                      --------------------------
>                                       |
>                                        |
>                                      PNC
> 
> For a single administrative domain, I have a couple questions to you:
> 
> 
> 1.       Do you see a compelling reason to have multiple MDSCs?
> 
> 2.       If you do see that, can multiple MDSCs be modeled as one logical entity
> (with logically centralized notion)?
> 
> If the answer for question 2 is yes, then m:n is reduced to 1:n.
> 
> Thanks.
> Young
> 
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: Wednesday, January 21, 2015 11:11 AM
> To: Arashmid Akhavain; BELOTTI, SERGIO (SERGIO); Leeyoung; Igor Bryskin;
> Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Hi Arashmid,
> 
> I guess we are considering different scenarios. The case of preemption is the
> following one:
> 
>    MDSC1        MDSC2
>            \               /
>              \           /
>                 PNC
> 
> Two MDSCs connected to the same PNC (as I said in my reply to Dave there
> are also other scenarios involving CNC-to-MDSC and parentMDSC-to-
> childMDSC connectivity but let’s focus just on MDSC-to-PNC). The PNC is the
> one allowing MDSC1 to pre-empt resources previously assigned to MDSC2.
> I guess what you described is a scenario like:
> 
>            MDSC1               MDSC2
>               /   \                       /  \
>             /       \                   /      \
>      PNC1   PNC2       PNC3    PNC4
>       Domain A             Domain B
> 
> There is no way that in this case MDSC1 pre-empts resources of MDSC2 (or
> at least, this is not what I foresee).
> 
> BR
> Daniele
> 
> From: Arashmid Akhavain [mailto:[e-mail]]
> Sent: mercoledì 21 gennaio 2015 17:27
> To: Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Leeyoung; Igor Bryskin;
> Dave Hood; Zhenghaomian
> Cc: [e-mail]
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Hi Daniele,
> 
> Thank you for your reply. I am not saying we drop the support for pre-
> emption.
> I just don’t see how a MDSC in administrative domain A connected to a set of
> PNCs belonging to the same administrative domain can pre-empt the
> resources under MDSC and PNCs of administrative domain B.
> 
> A high priority connection can pre-empt the lower priority connections based
> on say some parameters such as “setup” and “hold” attributes of itself and
> other connections or other means.
> But if the connection spans multiple domains, shouldn’t the pre-emption be
> done within the administrative domain by the entities belonging to that
> admin domain?
> 
> BR,
> Arashmid
> 
> 
> 
> 
> 
> 
> From: ACTN [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
> Sent: 21 January 2015 01:53
> To: Arashmid Akhavain; BELOTTI, SERGIO (SERGIO); Leeyoung; Igor Bryskin;
> Dave Hood; Zhenghaomian
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
> 
> Hi Arashmid,
> 
> Why would you want to prevent an operator from making more money with
> premium traffic? :)
> 
> Secondarily, preemption is supported by existing control planes. If it was
> standardized I guess there were operators inserted in it. I wouldn't make a
> new solution less powerful of what is already there.
> 
> BR
> Daniele
> 
> 
> 
> 
> Sent from a mobile device, please forgive spelling mistakes and short replies
> -------- Messaggio originale --------
> Da: Arashmid Akhavain
> Data:20/01/2015 20:19 (GMT+01:00)
> A: Daniele Ceccarelli ,"BELOTTI, SERGIO (SERGIO)" ,Leeyoung ,Igor Bryskin
> ,Dave Hood ,Zhenghaomian
> Cc: [e-mail]<mailto:[e-mail]>
> Oggetto: RE: [Actn] MSDC-PNC m:n (was R: ACTN progress)
> 
> Hi Daniele,
> Assuming that the MDSCs belong to different administrative domains, in the
> case of PNC resources being shared among multiple MDSCs, shouldn’t the
> type of pre-emption you mentioned be disallowed by policy?
> 
> BR,
> Arashmid
> 
> From: ACTN [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
> Sent: 20 January 2015 12:11
> To: BELOTTI, SERGIO (SERGIO); Leeyoung; Igor Bryskin; Dave Hood;
> Zhenghaomian
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [Actn] MSDC-PNC m:n (was R: 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:sergio.belotti@alcatel-
> lucent.com]
> 发送时间: 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
> _______________________________________________
> ACTN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/actn