Subject: Re: [nsc] inter-domain case (was RE: Service chaining architecture question)

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 14 Oct 2013 22:09:29 +0000

Hi,

I know this reply comes very very late. I left this message (and everything around SFC) to deal with it after my holidays in August, and I am afraid I found an enormous pile of urgent matters to deal with. I thought the whole inter-domain issue outdated, but the recent message from Christian has brought it back to my mind. And I think I have to make my case for inter-domain chaining. Some replies inlined below...

On 29 Jul 2013, at 10:35 , <[email-masked]> wrote:

> Hi Diego,
>
> Thank you for the answer. I still don't understand well the inter-domain use case you are referring to and why this is a requirements. In order to understand better the case and to make sure there is no terminology confusion, below some questions for you:
>
> * Do you have two administrative entities involved in your case?

DRL> Yes. Without leaving our corporate group, very often what you have are several companies (with different management obligations and administratively independent) cooperating to provide a certain E2E service. Today this is achieved by direct human coordination and complete functional (and even physical) separation. If you can dynamically chain services this would translate into much agile and elastic provision and operation. And I don't see why this would not involve in the near future completely independent companies providing coordinated services by means of collaboration agreements.

> * Are both domains managed by one single administrative entity?

DRL> As I said, even in the cases that I see in our group's environment, that's not the case. To give you an example, we have separate companies for the basic network services (and therefore network firewalling) and content distribution platforms (and therefore content caching and the like)

> * Who decide on the inter-domain function chains?

DRL> That would be part of the collaboration agreement: you can go from a very loose arrangement (in which you expose only your ingress and egress service points) to a tight integration, with a coordinated element taking care of everything, where the coordination can be made by a trusted third party (a federation operator), by one of the parties (a subordinated relationship) or by means of particular SLAs (a SFaaS, we could say)

> * Who is responsible for ensuring the overall consistency?

DRL> Again, that would be part of the collaboration agreement, and you'll have similar options.

> * Why the chaining policies are to be exposed to an external domain? Why each domain need to reveal its intra policies with regards to the way a network is engineered?

DRL> You don't need to expose *all* your policies (as you don't expose *all* your topology) but just the relevant information for the collaboration to take place. Again different models, from pure P2P exchange to a centralized clearinghouse, can be applied.

> * Why not each of the domain enforces its policies without requiring any involvement of functions located in another external domain?

DRL> Because having some knowledge of what and how can be applied by the other domain can help both domains in providing a better service to their end users, optimize their infrastructure, and address additional business models.

> * Why chaining will modify the way networks managed by two distinct administrative entities will be interconnected?

DRL>I don't think this would change the ways they interconnect, but the way they build services, announce them, account for them, and apply control on service function chaining.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 14 Oct 2013 22:30:56 +0000

Hi Diego,

Is it fair to say, at least theoretically, that services might extend from
the WAN edge into the DC, and in that case the WAN and DC *may* be
separately managed, and therefore by definition the service becomes an
inter-domain chain? Further, in order to setup such a chain a subset of
information needs to be exchanged between the two; this need not be a full
policy exchange but rather an aggregate of availability.

On 10/14/13 6:09 PM, "Diego R. Lopez" <[email-masked]> wrote:

>Hi,
>
>I know this reply comes very very late. I left this message (and
>everything around SFC) to deal with it after my holidays in August, and I
>am afraid I found an enormous pile of urgent matters to deal with. I
>thought the whole inter-domain issue outdated, but the recent message
>from Christian has brought it back to my mind. And I think I have to make
>my case for inter-domain chaining. Some replies inlined below...
>
>> Thank you for the answer. I still don't understand well the
>>inter-domain use case you are referring to and why this is a
>>requirements. In order to understand better the case and to make sure
>>there is no terminology confusion, below some questions for you:
>>
>DRL> Yes. Without leaving our corporate group, very often what you have
>are several companies (with different management obligations and
>administratively independent) cooperating to provide a certain E2E
>service. Today this is achieved by direct human coordination and complete
>functional (and even physical) separation. If you can dynamically chain
>services this would translate into much agile and elastic provision and
>operation. And I don't see why this would not involve in the near future
>completely independent companies providing coordinated services by means
>of collaboration agreements.
>
>DRL> As I said, even in the cases that I see in our group's environment,
>that's not the case. To give you an example, we have separate companies
>for the basic network services (and therefore network firewalling) and
>content distribution platforms (and therefore content caching and the
>like)
>
>DRL> That would be part of the collaboration agreement: you can go from a
>very loose arrangement (in which you expose only your ingress and egress
>service points) to a tight integration, with a coordinated element taking
>care of everything, where the coordination can be made by a trusted third
>party (a federation operator), by one of the parties (a subordinated
>relationship) or by means of particular SLAs (a SFaaS, we could say)
>
>> * Why the chaining policies are to be exposed to an external domain?
>>Why each domain need to reveal its intra policies with regards to the
>>way a network is engineered?
>
>DRL> You don't need to expose *all* your policies (as you don't expose
>*all* your topology) but just the relevant information for the
>collaboration to take place. Again different models, from pure P2P
>exchange to a centralized clearinghouse, can be applied.
>
>> * Why not each of the domain enforces its policies without requiring
>>any involvement of functions located in another external domain?
>
>DRL> Because having some knowledge of what and how can be applied by the
>other domain can help both domains in providing a better service to their
>end users, optimize their infrastructure, and address additional business
>models.
>
>> * Why chaining will modify the way networks managed by two distinct
>>administrative entities will be interconnected?
>
>DRL>I don't think this would change the ways they interconnect, but the
>way they build services, announce them, account for them, and apply
>control on service function chaining.
>
>Be goode,
>
>--
>Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>nuestra política de envío y recepción de correo electrónico en el enlace
>situado más abajo.
>This message is intended exclusively for its addressee. We only send and
>receive email on the basis of the terms set out at:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 16 Oct 2013 00:08:37 +0000

Hi Jim,

This situation you describe is precisely what I had in mind when mentioning what can (or I'd say "will") happen even within a single provider. And, yes, the need for exchanging of information between domains was what made me think about getting back to this, looking at a few slides from Christian on the edge nodes removing any SFC headers.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091