Subject: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

From: [email-masked]
Date: Wed, 23 Aug 2017 17:29:14 +0200

Hi all,

these days I have gone through both draft-ietf-teas-actn-framework. The 
multi-domain case is one of the scenarios covered by the draft, however 
I think it requires further elaboration in certain aspects, basically 
having in mind the case of interconnecting different administrative 
domains.

As per Figure 2, a Customer can request to a Service Provider a Virtual 
Network Service (VNS). The Service Provider can satisfy such request by 
its own if it has Access to a number of Network Providers as reflected 
in the figure. The scenario I'm referring to would be the one in which 
the Service Provider (let's call it SP1) cannot honor the Customer 
request by its own but requires some capabilities offered by another 
Service Provider (SP2 in this case).

Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture) 
we have the Customer Network Controller (CNC) in the Customer side, the 
Multi Domain Service Coordinator (MDSC) in the Service Provider side, 
and the Physical Network Controller (PNC) in the Network Provider side. 
The interfaces used are CMI between CNC and MDSC, and MPI between MDSC 
and PNC. CMI conveys service related information, while MPI conveys more 
detailed network/technology related information.

As it is described now in the draft, the MDSC is the one in charged of 
the multi-domain Coordination by coordinating the PNCs of the Network 
Providers below. However there is no detail about the potential 
Coordination with another Service Provider that could be necessary for 
providing the VNS to the Customer.

Section 5.1 describes a hierarchical connection of MDSCs that could be 
interpreted as a way of resolving such SP interconnection. However, for 
the interconnection of administrative domains interface MPI could not be 
sufficient. Probably something in between MPI and CMI could be required.

So my proposal here would be the definition of a new interface, MMI, 
between MDSCs pertaining to different administrative domains. That 
interface conveys in principle service related information, and to some 
extent it could have as well network/technology related information, 
depending on the level of trustiness between SP1 and SP2.

What do you think?

Best regards

Luis

-- 
___________________________________________

Luis M. Contreras
[email-masked]
[email-masked]

---

From: Leeyoung <[email-masked]>
Date: Wed, 23 Aug 2017 16:11:28 +0000

Hi Miguel,

Thanks for sharing your thought. As you pointed out, Section 5.1 describes an advanced case of a hierarchy of MDSCs. We did not intend to describe the case where two different/independent SPs are interconnected with the top MDSC. This advanced form of MDSC hierarchy is intended  for one network provider to scale their networks. If the two SPs are trusted entities to each other constituting multi-domain under the same administration forming the MDSC hierarchy, this can be supported with the current model. As pointed out in Figure 3, CMI is the business boundary that separates customer and the network provider and anything under the MDSC is assumed to be under one the same business entity (i.e., trusted domain under the same administration). 

In any case, we regard MDSC-MDSC as a special case of MPI rather than defining a separate interface called MMI (although we originally considered this interface).  

Hope this helps. 

Best regards,
Young

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 23, 2017 10:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi all,

these days I have gone through both draft-ietf-teas-actn-framework. The multi-domain case is one of the scenarios covered by the draft, however I think it requires further elaboration in certain aspects, basically having in mind the case of interconnecting different administrative domains.

As per Figure 2, a Customer can request to a Service Provider a Virtual Network Service (VNS). The Service Provider can satisfy such request by its own if it has Access to a number of Network Providers as reflected in the figure. The scenario I'm referring to would be the one in which the Service Provider (let's call it SP1) cannot honor the Customer request by its own but requires some capabilities offered by another Service Provider (SP2 in this case).

Mapping Figure 2 to Figure 3 (functional view of the ACTN architecture) we have the Customer Network Controller (CNC) in the Customer side, the Multi Domain Service Coordinator (MDSC) in the Service Provider side, and the Physical Network Controller (PNC) in the Network Provider side. 
The interfaces used are CMI between CNC and MDSC, and MPI between MDSC and PNC. CMI conveys service related information, while MPI conveys more detailed network/technology related information.

As it is described now in the draft, the MDSC is the one in charged of the multi-domain Coordination by coordinating the PNCs of the Network Providers below. However there is no detail about the potential Coordination with another Service Provider that could be necessary for providing the VNS to the Customer.

Section 5.1 describes a hierarchical connection of MDSCs that could be interpreted as a way of resolving such SP interconnection. However, for the interconnection of administrative domains interface MPI could not be sufficient. Probably something in between MPI and CMI could be required.

So my proposal here would be the definition of a new interface, MMI, between MDSCs pertaining to different administrative domains. That interface conveys in principle service related information, and to some extent it could have as well network/technology related information, depending on the level of trustiness between SP1 and SP2.

What do you think?

Best regards

Luis

Luis M. Contreras
[email-masked]

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Aug 2017 16:12:36 +0000

Hi Luis,

You said:
 " Section 5.1 describes a hierarchical connection of MDSCs that could be 
interpreted as a way of resolving such SP interconnection. However, for 
the interconnection of administrative domains interface MPI could not be 
sufficient. Probably something in between MPI and CMI could be required."

1) Why MPI in this hierarchical case may not be sufficient?
2) What would prevent the upper level MDSC from using both MPI and CMI (if necessary)  when talking to a serving MDSC?

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 23, 2017 11:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi all,

What do you think?

Best regards

Luis

Luis M. Contreras
[email-masked]

---

From: [email-masked]
Date: Wed, 23 Aug 2017 23:01:11 +0200

Hi Young,

thanks for the clarification. As you point out, yes, probably this can 
be handled as a special case of MPI. Maybe such details can be 
elaborated later on (I mean, in a separated document) in order to 
identify the specificities of this case where some Business aspects 
could be required to be supported as well.

Best regards

Luis

On 2017-08-23 18:11, Leeyoung wrote:
> Hi Miguel,
> 
> Thanks for sharing your thought. As you pointed out, Section 5.1
> describes an advanced case of a hierarchy of MDSCs. We did not intend
> to describe the case where two different/independent SPs are
> interconnected with the top MDSC. This advanced form of MDSC hierarchy
> is intended  for one network provider to scale their networks. If the
> two SPs are trusted entities to each other constituting multi-domain
> under the same administration forming the MDSC hierarchy, this can be
> supported with the current model. As pointed out in Figure 3, CMI is
> the business boundary that separates customer and the network provider
> and anything under the MDSC is assumed to be under one the same
> business entity (i.e., trusted domain under the same administration).
> 
> In any case, we regard MDSC-MDSC as a special case of MPI rather than
> defining a separate interface called MMI (although we originally
> considered this interface).
> 
> Hope this helps.
> 
> Best regards,
> Young
> 
> these days I have gone through both draft-ietf-teas-actn-framework.
> The multi-domain case is one of the scenarios covered by the draft,
> however I think it requires further elaboration in certain aspects,
> basically having in mind the case of interconnecting different
> administrative domains.
> 
> As per Figure 2, a Customer can request to a Service Provider a
> Virtual Network Service (VNS). The Service Provider can satisfy such
> request by its own if it has Access to a number of Network Providers
> as reflected in the figure. The scenario I'm referring to would be the
> one in which the Service Provider (let's call it SP1) cannot honor the
> Customer request by its own but requires some capabilities offered by
> another Service Provider (SP2 in this case).
> 
> Mapping Figure 2 to Figure 3 (functional view of the ACTN
> architecture) we have the Customer Network Controller (CNC) in the
> Customer side, the Multi Domain Service Coordinator (MDSC) in the
> Service Provider side, and the Physical Network Controller (PNC) in
> the Network Provider side.
> and PNC. CMI conveys service related information, while MPI conveys
> more detailed network/technology related information.
> 
> interpreted as a way of resolving such SP interconnection. However,
> for the interconnection of administrative domains interface MPI could
> not be sufficient. Probably something in between MPI and CMI could be
> required.
> 
> interface conveys in principle service related information, and to
> some extent it could have as well network/technology related
> information, depending on the level of trustiness between SP1 and SP2.
> 
> What do you think?
> 
> Best regards
> 
> 
> Luis
> 
> 
> --

Luis M. Contreras
[email-masked]

---

From: [email-masked]
Date: Wed, 23 Aug 2017 23:06:47 +0200

Hi Igor,

please, see my comments in-line

> 1) Why MPI in this hierarchical case may not be sufficient?

lmcm>> some Business and service related information is probably needed 
in that case, so it could be needed to complement MPI with such kind of 
information

> 2) What would prevent the upper level MDSC from using both MPI and CMI
> (if necessary)  when talking to a serving MDSC?
> 

lmcm>> I acknowledge this could be an option. Probably the details can 
be worked out in a different document either with this option, with the 
option of complementing MPI to some extent with Business and service 
information, or by complementing CMI with network/technology/resource 
information.

In any case, maybe the best is to move forward the framework document 
and explore this alternatives in another document/effort.

Thanks again for the feedback

Best regards

Luis

> more

Luis M. Contreras
[email-masked]

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Aug 2017 21:41:47 +0000

Hi Luis,

Please, see one more comment in-line.
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 23, 2017 5:07 PM
To: Igor Bryskin
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi Igor,

IB>> I agree, but upper level MDSC supposedly makes its decisions based on abstract topologies provided by serving controllers such as lower level MDSC. Why would this lower level MDSC announce, say, an abstract link to the higher level MDSC umless all business related stuff is sorted out between the two (perhaps via CMI), right? 

The other point is that a client of a multi-domain network could be a client of several such networks and hence could carry out the multi-network synchronization at its level without each of the serving MDSCs knowing anything about that.

I'd say that CMI and MPI are independent, and both or either of them could be used regardless of each other. IMHO there is a need for a text in the document elaborating on such scenarios, but there is no need for the special case MPI.

Cheers,
Igor

Best regards

Luis

Luis M. Contreras
[email-masked]

---

From: Leeyoung <[email-masked]>
Date: Wed, 23 Aug 2017 21:45:26 +0000

Hi Luis,

Yes, multiple administrative domains is currently out of the ACTN scope. 

Thanks.
young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 23, 2017 4:01 PM
To: Leeyoung <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi Young,

thanks for the clarification. As you point out, yes, probably this can be handled as a special case of MPI. Maybe such details can be elaborated later on (I mean, in a separated document) in order to identify the specificities of this case where some Business aspects could be required to be supported as well.

Best regards

Luis

Luis M. Contreras
[email-masked]

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 23 Aug 2017 21:54:06 +0000

Young,

A client of a single administrative domain network could be a client of multiple such networks and perform service synchronization across them at its own level using existing ACTN CMI and MPI as they are, right? So what then is missing?

Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Wednesday, August 23, 2017 5:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi Luis,

Thanks.
young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 23, 2017 4:01 PM
To: Leeyoung <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi Young,

Best regards

Luis

Luis M. Contreras
[email-masked]

---

From: [email-masked]
Date: Thu, 24 Aug 2017 00:44:55 +0200

Hi Igor,

please, see in-line:

> IB>> I agree, but upper level MDSC supposedly makes its decisions
> based on abstract topologies provided by serving controllers such as
> lower level MDSC. Why would this lower level MDSC announce, say, an
> abstract link to the higher level MDSC umless all business related
> stuff is sorted out between the two (perhaps via CMI), right?
> 

lmcm>> I agree this is a potential way of proceeding. Maybe just saying 
in 5.1 that the hierarchical connection of MDSCs could require the 
support of CMI in case of connecting different administrative domains. 
On the other hand, as mentioned by Young, if the interconnection of 
multiple administrative domains is not in the scope, maybe such 
clarification about the support of CMI can be skipped by explicitly 
saying that multiple administrative domains are out of scope (then 
keeping just the comment about the recursive usage of MPI at that 
level).

> The other point is that a client of a multi-domain network could be a
> client of several such networks and hence could carry out the
> multi-network synchronization at its level without each of the serving
> MDSCs knowing anything about that.
> 

lmcm>> This is valid when the Customer is aware of the multi-domain 
situation, i.e. it is able to interact with all the administrative 
domains and coordinate the actions, as you mention. However there could 
be other situations where the Customer is not aware of the multiple 
administrative domains, and this is resolved by the Service Provider 
that maintains the commercial relationship with the Customer.

> I'd say that CMI and MPI are independent, and both or either of them
> could be used regardless of each other. IMHO there is a need for a
> text in the document elaborating on such scenarios, but there is no
> need for the special case MPI.
> 

lmcm>> If interconnection of multiple administrative domains is not in 
the scope of the framework document maybe this can be handled apart by a 
different document focusing on this topic. In that case different 
options and pros/cons for them could be considered, like the usage of 
CMI + MPI, or the extension of MPI. I personally like the option of 
exploring this problem leaving the framework document with its current 
scope, so I'm open to work on that.

Best regards

Luis

Luis M. Contreras
[email-masked]

---

From: Leeyoung <[email-masked]>
Date: Wed, 23 Aug 2017 22:46:45 +0000

Hi Igor,

We did not consider this case; but it would just work well if some implementation wants to do that. 

Thanks,
Young

-----Original Message-----
From: Igor Bryskin 
Sent: Wednesday, August 23, 2017 4:54 PM
To: Leeyoung <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Young,

Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Wednesday, August 23, 2017 5:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi Luis,

Thanks.
young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 23, 2017 4:01 PM
To: Leeyoung <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] About interconnecting Multiple Administrative domains in draft-ietf-teas-actn-framework

Hi Young,

Best regards

Luis

Luis M. Contreras
[email-masked]