Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
"Zhangxian (Xian)" <zhang.xian@huawei.com> Fri, 23 January 2015 01:27 UTC
Return-Path: <zhang.xian@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 821D61B2AF4 for <actn@ietfa.amsl.com>; Thu, 22 Jan 2015 17:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 R_3alnMVX-4R for <actn@ietfa.amsl.com>; Thu, 22 Jan 2015 17:27:04 -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 F1BA61A1A90 for <actn@ietf.org>; Thu, 22 Jan 2015 17:27:02 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ42619; Fri, 23 Jan 2015 01:27:01 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 01:27:00 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.61]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 09:26:49 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Leeyoung <leeyoung@huawei.com>, Igor Bryskin <IBryskin@advaoptical.com>
Thread-Topic: [Actn] R: MSDC-PNC m:n (was R: ACTN progress)
Thread-Index: AdA1RvbUZNk3Q1u79UOVo8mWRIiPGAASBs6gAAMnrRAAAbZnoP//j6aAgAACEoCAAAVfgIAADS8AgAAeeoCAAMwDAP/+gOrg
Date: Fri, 23 Jan 2015 01:26:49 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B4716E57F@SZXEMA512-MBS.china.huawei.com>
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> <7AEB3D6833318045B4AE71C2C87E8E1729C7D9EE@dfweml706-chm> <4A1562797D64E44993C5CBF38CF1BE481284872C@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481284872C@ESESSMB301.ericsson.se>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/actn/AuEFygBPeD_ibTJ1djLyqrM3JSY>
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: Fri, 23 Jan 2015 01:27:09 -0000
Hi, Daniele, Igor, all, Thank you for providing your understanding of the drawing. I am trying to use this as a starting point to understand the two cases Igor mentioned why MDSC: PNC = m: 1 is needed to see if I understand correctly. CNC | Parent MDSC / \ / \ MDSC1 MDSC2 \ / \ / PNC ( a side point: this shows a good example of the recursive nature of MDSC, :-).) Quoting The two cases Igor mentioned. Igor's case 1: "MDSC per VPN" The graph would look differently as below: CNC1 CNC2 / \ MDSC1 MDSC2 \ / \ / PNC From MDSC: PNC point of view, it is indeed multiple MDSC for 1 PNC. But from the application point of view (For VPN), it is still 1:1. Right? Igor's case 2: "MDSC per application: original service setup, service replacement, global optimization, failure restoration, etc. all these applications could be supported by a separate MDSC" I think you original drawing fits in this case. But I do not see why this is desired than a single MDSC and how they can coordinate with each other. @Igor, maybe you could share some insights? Regards, Xian -----Original Message----- From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 2015年1月22日 18:20 To: Leeyoung; Igor Bryskin; 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 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:leeyoung@huawei.com] > Sent: mercoledì 21 gennaio 2015 23:10 > 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, > > 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:IBryskin@advaoptical.com] > Sent: Wednesday, January 21, 2015 2:21 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) > > 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 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: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
- Re: [Actn] R: R: MSDC-PNC m:n (was R: ACTN progre… Khuzema Pithewan
- [Actn] 答复: R: R: MSDC-PNC m:n (was R: ACTN progre… Zhenghaomian
- [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Daniele Ceccarelli
- [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Daniele Ceccarelli
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Arashmid Akhavain
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Daniele Ceccarelli
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) BELOTTI, SERGIO (SERGIO)
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Igor Bryskin
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Arashmid Akhavain
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Igor Bryskin
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Igor Bryskin
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Daniele Ceccarelli
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Igor Bryskin
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Zhangxian (Xian)
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Arashmid Akhavain
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Igor Bryskin
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Arashmid Akhavain
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) John E Drake
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Igor Bryskin
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- [Actn] 答复: R: MSDC-PNC m:n (was R: ACTN progress) Zhenghaomian
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Arashmid Akhavain
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- [Actn] R: R: MSDC-PNC m:n (was R: ACTN progress) Daniele Ceccarelli
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) BELOTTI, SERGIO (SERGIO)
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Arashmid Akhavain
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- Re: [Actn] R: MSDC-PNC m:n (was R: ACTN progress) Leeyoung
- [Actn] R: R: MSDC-PNC m:n (was R: ACTN progress) Daniele Ceccarelli