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

Leeyoung <leeyoung@huawei.com> Mon, 02 February 2015 16:56 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: actn@ietfa.amsl.com
Delivered-To: actn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A49C1A82E2 for <actn@ietfa.amsl.com>; Mon, 2 Feb 2015 08:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5le_m7Yfx2P for <actn@ietfa.amsl.com>; Mon, 2 Feb 2015 08:56:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19511A8708 for <actn@ietf.org>; Mon, 2 Feb 2015 08:56:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOR63168; Mon, 02 Feb 2015 16:56:04 +0000 (GMT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 16:54:07 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 08:53:57 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Arashmid Akhavain <arashmid.akhavain@huawei.com>, Igor Bryskin <IBryskin@advaoptical.com>, John E Drake <jdrake@juniper.net>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, Dave Hood <dave.hood@ericsson.com>, Zhenghaomian <zhenghaomian@huawei.com>
Thread-Topic: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
Thread-Index: AdA1RvbUZNk3Q1u79UOVo8mWRIiPGAASBs6gAAMnrRAAAbZnoAATe+yAAABCKoAAEFY10P//j9wAgAMPUQCAAAr4gIAAEI4AgAAJm4CAAA26gP/3gZKQgBNaGQCAAIF20IADWOcA///hi6A=
Date: Mon, 02 Feb 2015 16:53:57 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7FFE2@dfweml706-chm>
References: <8pcj1x0dsckeejuher04iu0x.1421823207267@email.android.com> <D57109449177B54F8B9C093953AC5BCD4607A274@SZXEML508-MBX.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812847E3A@ESESSMB301.ericsson.se>, <7AEB3D6833318045B4AE71C2C87E8E1729C7C80D@dfweml706-chm>, <da187aad5fb14b51b9a8e4b0b526c35e@ATL-SRV-MBX1.advaoptical.com> <9a6bdad5cc0446f487a32eed8db99d61@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7D8BB@dfweml706-chm> <2b64f681e38149ccbe0d0bcd99fa92ea@ATL-SRV-MBX1.advaoptical.com> <D57109449177B54F8B9C093953AC5BCD46082DD7@SZXEML508-MBS.china.huawei.com> <f17f96c8b5d44bf9b481a869e6b74236@ATL-SRV-MBX1.advaoptical.com> <D57109449177B54F8B9C093953AC5BCD46083E4C@SZXEML508-MBS.china.huawei.com> <BLUPR05MB5629B7E14D09E5A0EB7A196C7360@BLUPR05MB562.namprd05.prod.outlook.com> <ea813b1a744c4462b755d7e039605973@ATL-SRV-MBX1.advaoptical.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7F4A8@dfweml706-chm> <D57109449177B54F8B9C093953AC5BCD46097588@SZXEML508-MBX.china.huawei.com>, <7AEB3D6833318045B4AE71C2C87E8E1729C7FADB@dfweml706-chm> <upnbt8itwrq5xjksx9gq6gfa.1422859527276@email.android.com>
In-Reply-To: <upnbt8itwrq5xjksx9gq6gfa.1422859527276@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.186]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C7FFE2dfweml706chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/actn/54gSrte-y84i4mqKU6JZasqcDxQ>
Cc: "actn@ietf.org" <actn@ietf.org>
Subject: Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
X-BeenThere: actn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Abstraction and Control of Transport Networks \(ACTN\)" <actn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/actn>, <mailto:actn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/actn/>
List-Post: <mailto:actn@ietf.org>
List-Help: <mailto:actn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/actn>, <mailto:actn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 16:56:19 -0000

Hi Daniele,

Please see inline for my comment.

Thanks,
Young

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Monday, February 02, 2015 12:46 AM
To: Leeyoung; Arashmid Akhavain; Igor Bryskin; John E Drake; BELOTTI, SERGIO (SERGIO); Dave Hood; Zhenghaomian
Cc: actn@ietf.org
Subject: R: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)

Hi Young,

I agree with you. Just 2 comments for clarification.


1.      What do you mean by cross-over of controllers? Exchange of info between peering controller?

YOUNG>>  In a context of hierarchy of the MDSCs, say, we have one parent MDSC and a number of child MDSCs, cross-over communication is meant to communication (signaling and direct info exchange, etc) between child MDSCs on a peer level. The reason for this restriction (i.e., no cross-over communication between child MDSCs) is to empower the parent MDSC to coordinate communication flows with each of the MDSC, respectively.



2.      On the 1:n , m:1 relationship between MDSC and PNC  I think the discussion we had in a separate thread led to the  conclusion that m:n does not add complexity under the conditions of hard resource separation and no preemption of resource owned by different controllers.  I think we can allow for m:n with this disclaimer (at least as starting point).

YOUNG>>  Yes, I agree. We can make this disclaimer although this is a corner case as you noted before.

BR
Daniele




Sent from a mobile device, please forgive spelling mistakes and short replies
-------- Messaggio originale --------
Da: Leeyoung
Data:30/01/2015 22:21 (GMT+01:00)
A: Arashmid Akhavain ,Igor Bryskin ,John E Drake ,Daniele Ceccarelli ,"BELOTTI, SERGIO (SERGIO)" ,Dave Hood ,Zhenghaomian
Cc: actn@ietf.org
Oggetto: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)

Hi Arashmid,

I think your five points make sense to me. But introducing another term, SC, would be a bit a challenge. Let me elaborate with the following:

I think we should be clear on what is "domain" first.

Domain is used to connote a transport network domain in which a PNC is solely responsible. For instance, this domain would be access transport network, metro, core, etc. It can also be layer-specific transport network domain such as Ethernet, OTN and WSON domain. All these transport network domains belong to the same operator's control. For instance, China Mobile told us that they have several MPLS-TP mobile backhaul networks, MPLS-core transport network, OTN/WSON core network and each one of which is controlled by a PNC (EMS, NMS, control plane, OF controller, etc.) In this example, we have several transport network domains and each domain is controlled by a PNC.

The domain in "multi-domain" Service Coordinator (MDSC) is basically the entity that coordinates the multiple number of domains (transport network domains). So a multi-domain service coordinator is essentially a multi transport network domain service coordinator and it should provide all the four functions we defined in the framework. The operators' requirement is to have a centralized controller that can coordinate different services and different transport network domains to be able to seamlessly and dynamically create/modify/delete connectivity. To support this requirement, there should be one top level MDSC that can encompass all its transport network domains (and therefore all PNCs under its tree) and all service requests of various types.

If an operator has one single transport network domain, then there would be one PNC (there is no need for MDSC). PNC would then interface CNC directly.

This "multi-domain" in MDSC is to be distinguished from "multiple administrative" domains. "Administrative domain" has been used to connote one operator's control domain. Operators are like AT&T, Verizon, China Mobile, etc. and they have their administrative domain in which their policy is applied. We have not really dealt with multiple administrative domains in ACTN discussions.

With this definition of the ACTN terms, it is hard for me to see multiple MDSCs have relationships with a single PNC with an exception that the PNC is in control of all layered networks (L2.5, L2, L1 and L0). I think this is a point you made on n:1 for MDSCs:PNC (also Igor's case).

You suggested the five point (all of them make sense to me with SC term)

1. There is a 1:1 correspondence between a CNC and a MDCS.
2- MDSC is an SC with multi-domain coordination function.
3- There is no hierarchy between MDSCs (i.e. there is a single MDSC per domain). I think this would cover your 3 bullet talking about cross-over.
4- Hierarchy can exist between MDSC and SCs and between SCs themselves.
5- MDSC and SCs relationship to PNCs can follow either of 1:N or N:1 model.

If we relax SC (without introducing SC), we still can say the following:

1. There is a 1:1 correspondence between a CNC and a MDCS.
2- There could be a hierarchy between MDSCs with no cross-over between MDSCs (there is one top-level MDSC per administrative domain with possible child MDSCs)
3- MDSCs to PNCs can follow either of 1:N or N:1 model. (N:1 model support for a single transport network domain case, i.e., single PNC case)

I think either model works.

Thanks,
Young

-----Original Message-----
From: Arashmid Akhavain
Sent: Friday, January 30, 2015 1:55 PM
To: Leeyoung; Igor Bryskin; John E Drake; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Dave Hood; Zhenghaomian
Cc: actn@ietf.org
Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)

Hi Young,

The figure seems to be enforcing a 1:N relationship between MDSC and PNC.
As Igor mentioned, it makes sense to have multiple service coordinators communicating
with the same PNC in a single domain. The key point here though is that all these SCs
belong to a single domain.

In multi domain scenarios, the top level SC (MDSC) follows the 1:N relationship shown in the diagram. Not so in a single domain.
I guess, the multi-domain part of MDSC is somewhat confusing. That's why I used the term "SC" instead.
MDSC is a subclass of SC(It implements the multi-domain coordination function). A single domain has one MDSC but can have many SCs.

Building on your 3 points we can say:

1. There is a 1:1 correspondence between a CNC and a MDCS.
2- MDSC is an SC with multi-domain coordination function.
3- There is no hierarchy between MDSCs (i.e. there is a single MDSC per domain). I think this would cover your 3 bullet talking about cross-over.
4- Hierarchy can exist between MDSC and SCs and between SCs themselves.
5- MDSC and SCs relationship to PNCs can follow either of 1:N or N:1 model.


Does this fit the bill?

Best regards,
Arashmid



-----Original Message-----
From: Leeyoung
Sent: 29 January 2015 11:55
To: Igor Bryskin; John E Drake; Arashmid Akhavain; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Dave Hood; Zhenghaomian
Cc: actn@ietf.org
Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)

Hi,

I think we are mixing up with specific implementations with a reference architecture. As long as we have an agreement in the reference architecture and have the interface to support overarching functions, we should allow some specific implementations.

Ideally, one MDSC per domain (here domain means virtualization domain that belongs to one administrator) would work for most cases. On the other hand, there may be some benefit to allow a hierarchical MDSCs with a parent MSDC with several child MDSCs for some reasons like scaling, function separation, etc. As long as the interface design between MDSCs (parent-child) support common functionality with some added application hook, this can be worked out. This is not to say we should have a separate MDSC for VPN. With a well structured architecture, we can support Igor's case. But again that is an implementation choice to make such judgment but that is beyond our scope.

Would the following architecture work to support all cases we have discussed so far?


                 CNC
                  |
                  |
                  |
                  |
                 MDSC
                // \\
              //     \\
             /         \
          MDSC        MDSC
          //|         / \
        //  |        /   \
       /    |       /     \
     PNC   PNC    PNC    PNC


This is a single virtualization domain figure. There are a number of things we need to agree:

1. There is a 1:1 correspondence between a CNC and a MDCS and if there is no need for a hierarchy of MDSCs, then it will reduce to a single MDSC.

2. As to where certain functions are located, that is an implementation choice and the ACTN does not concern that. As long as CNC and PNCs are concerned, that is transparent.

3. There is no cross-over between MDSCs (children).

Would this be workable?

Thanks,
Young

Thanks,
Young

-----Original Message-----
From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Friday, January 23, 2015 4:06 PM
To: John E Drake; Arashmid Akhavain; Leeyoung; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Dave Hood; Zhenghaomian
Cc: actn@ietf.org
Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)

John,
I learned from your previous email that you tend to "leave elegance to tailors and cobblers" ;+) Multiple MDSCs do not preclude using common code. The important question is how many parents  the child MDSCs /PNCs are talking to  - one or many?.
My point is that because children should be prepared to serve multiple independent  clients anyway they might as well serve multiple clients from the same domain. Furthermore, the discussion is whether it makes sense to have more than one MDSC per domain. My answer : Yes it does. Having MDSC per VPN is just one example. There could be an MDSC that is only concerned with handling failure restorations, which could be different from   an MDSC handling client service manipulation requests, which is different from MDSC performing global optimization, bandwidth fragmentation removal, etc.

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, January 23, 2015 4:17 PM
To: Arashmid Akhavain; Igor Bryskin; Leeyoung; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Dave Hood; Zhenghaomian
Cc: actn@ietf.org
Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)

Igor,

Most VPNs of which I am aware maintain per VPN instance state and common code, and support an abundance of VPN instances.

Yours Irrespectively,

John

> -----Original Message-----
> From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Arashmid
> Akhavain
> Sent: Friday, January 23, 2015 3:43 PM
> To: Igor Bryskin; Leeyoung; Daniele Ceccarelli; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> Subject: Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
>
> Thanks for your reply Igor. Yes, I see your point and agree with your view.
>
>
> Thanks again,
> Arashmid
>
> -----Original Message-----
> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> Sent: 23 January 2015 14:44
> To: Arashmid Akhavain; Leeyoung; Daniele Ceccarelli; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
>
> Arashmid,
> Each VPN is likely to have separate:
> a) address/naming space;
> b) set of abstract topologies;
> c) set of policies wrt transport service manipulation
> d) ...
> Considering that child MDSCs/PNCs are responsible anyway for resource
> separation/sharing, it is reasonable to replace a single complex MDSC
> with multiple simpler ones (one per VPN). In other words, this means
> breaking a complex problem into multiple simpler ones.
>
> Cheers,
> Igpr
>
> -----Original Message-----
> From: Arashmid Akhavain [mailto:arashmid.akhavain@huawei.com]
> Sent: Friday, January 23, 2015 2:04 PM
> To: Igor Bryskin; Leeyoung; Daniele Ceccarelli; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
>
> Hi Igore,
>
> Given that MDSC provides customer mapping function, wouldn't a single
> MDSC be able to support multiple VPNs?
> If so, what do you see as the advantage of single MDSC per VPN?
>
> Thanks,
> Arashmid
>
>
> -----Original Message-----
> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> Sent: 21 January 2015 15:21
> To: Leeyoung; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> Subject: RE: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
>
> Young,
> Please see in-line.
>
> -----Original Message-----
> From: Leeyoung [mailto:leeyoung@huawei.com]
> Sent: Wednesday, January 21, 2015 2:34 PM
> To: Igor Bryskin; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI,
> SERGIO (SERGIO); Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> 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
> IB>> 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
> IB>> 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:IBryskin@advaoptical.com]
> Sent: Wednesday, January 21, 2015 1:14 PM
> To: Leeyoung; Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO
> (SERGIO); Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> 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 [actn-bounces@ietf.org] 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: actn@ietf.org
> 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 [leeyoung@huawei.com]
> Sent: Wednesday, January 21, 2015 12:58 PM
> To: Daniele Ceccarelli; Arashmid Akhavain; BELOTTI, SERGIO (SERGIO);
> Igor Bryskin; Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> 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:daniele.ceccarelli@ericsson.com]
> Sent: Wednesday, January 21, 2015 11:11 AM
> To: Arashmid Akhavain; BELOTTI, SERGIO (SERGIO); Leeyoung; Igor
> Bryskin; Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> 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:arashmid.akhavain@huawei.com]
> Sent: mercoledì 21 gennaio 2015 17:27
> To: Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Leeyoung; Igor
> Bryskin; Dave Hood; Zhenghaomian
> Cc: actn@ietf.org
> 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:actn-bounces@ietf.org] On Behalf Of Daniele
> Ceccarelli
> Sent: 21 January 2015 01:53
> To: Arashmid Akhavain; BELOTTI, SERGIO (SERGIO); Leeyoung; Igor
> Bryskin; Dave Hood; Zhenghaomian
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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: actn@ietf.org<mailto:actn@ietf.org>
> 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:actn-bounces@ietf.org] On Behalf Of Daniele
> Ceccarelli
> Sent: 20 January 2015 12:11
> To: BELOTTI, SERGIO (SERGIO); Leeyoung; Igor Bryskin; Dave Hood;
> Zhenghaomian
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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: actn@ietf.org<mailto:actn@ietf.org>
> 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 +39 (039) 6863033
>
>
> -----Original Message-----
> From: Leeyoung [mailto:leeyoung@huawei.com]
> Sent: lunedì 19 gennaio 2015 21:45
> To: Igor Bryskin; Dave Hood; Daniele Ceccarelli; BELOTTI, SERGIO
> (SERGIO); Zhenghaomian
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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:IBryskin@advaoptical.com]
> Sent: Monday, January 19, 2015 12:37 PM
> To: Dave Hood; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO);
> Zhenghaomian; Leeyoung
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> Subject: RE: [Actn] ACTN progress
>
> Exactly right.
> ________________________________________
> From: Dave Hood [dave.hood@ericsson.com]
> Sent: Monday, January 19, 2015 12:08 PM
> To: Igor Bryskin; Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO);
> Zhenghaomian; Leeyoung
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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:actn-bounces@ietf.org] On Behalf Of Igor Bryskin
> Sent: Monday, January 19, 2015 6:18 AM
> To: Daniele Ceccarelli; BELOTTI, SERGIO (SERGIO); Zhenghaomian;
> Leeyoung
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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:daniele.ceccarelli@ericsson.com]
> Sent: Monday, January 19, 2015 9:07 AM
> To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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:actn-bounces@ietf.org] On Behalf Of Igor Bryskin
> Sent: lunedì 19 gennaio 2015 14:37
> To: BELOTTI, SERGIO (SERGIO); Zhenghaomian; Leeyoung
> Cc: actn@ietf.org<mailto:actn@ietf.org>
> 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:sergio.belotti@alcatel-lucent.com]
> Sent: Monday, January 19, 2015 3:19 AM
> To: Zhenghaomian; Leeyoung
> Cc: Igor Bryskin; actn@ietf.org<mailto:actn@ietf.org>
> 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:zhenghaomian@huawei.com]
> Sent: lunedì 19 gennaio 2015 02:29
> To: BELOTTI, SERGIO (SERGIO); Leeyoung
> Cc: Igor Bryskin; actn@ietf.org<mailto:actn@ietf.org>
> 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; actn@ietf.org<mailto:actn@ietf.org>
> 主题: 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:actn-bounces@ietf.org] On Behalf Of Leeyoung
> Sent: giovedì 15 gennaio 2015 21:21
> To: Zhenghaomian; actn@ietf.org<mailto:actn@ietf.org>
> 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; actn@ietf.org<mailto:actn@ietf.org>
> 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; actn@ietf.org<mailto:actn@ietf.org>
> 抄送: 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; actn@ietf.org<mailto:actn@ietf.org>
> 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:leeyoung@huawei.com]
> 发送时间: 2015年1月15日 3:12
> 收件人: actn@ietf.org<mailto:actn@ietf.org>
> 主题: [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:IBryskin@advaoptical.com]
> 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:leeyoung@huawei.com]
> 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
> ACTN@ietf.org
> https://www.ietf.org/mailman/listinfo/actn
> _______________________________________________
> ACTN mailing list
> ACTN@ietf.org
> https://www.ietf.org/mailman/listinfo/actn