Re: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

[Adrian Farrel <[e-mail]>]

Hi Kenichi,

Thanks for your input.

[snip]

> But
> what was NOT included in the draft is any detail on a) how the network 
> is “traffic engineered” b) which charateristics must this traffic 
> engineering have and c) which traffic of the VPN goes into which 
> tunnel…. One of the main reasons to leave that out was to avoid the “boiling the ocean”
> problem and limit the scope to opsawg. TE… would be dealt of course in 
> TEAS ☺

OK, and those three objectives (a, b, c) are reasonable things to put into the network model. Just not, IMHO, into the customer service model.

[KO] As Adrian described below, when VN is a service and our customer uses the VN as a service, why is the VN put into the network model reasonable? Am I something misunderstanding?
 "In this case, in my opinion, the cooked topology delivered to the customer is in the form of a service already. It might be a VN or it might be a set of connectivity services (i.e., tunnels). In this case, the delivery of a service over a service is highly ambiguous and I don’t think it falls within the operator’s capabilities to achieve it. The cooked topology is for the customer to use as they see fit."

[AF] I think the key here is to understand the layering. So when you say *the* network model I think there may be some ambiguity.

I see...

VPN
------- LxSM model -- Customer ask for a VPN operated over the VN
------- LxNM model -- VN orchestrator plans and provisions the VPN over the VN
VN
------- VN service model -- Customer asks for a VN over the operator network
------- VN network model -- Operator's network orchestrator provisions the VN

In this case, the LxNM is operating in the customer's management space. The operator is unaware of the VPN and is unaware of how the VN is being used by the customer.

We must be careful to not think that the LxSM is the interface between customer and operator. It is the interface between consumer and provider which, in this case, are both within the customer's control.

Similarly, we must be careful to not think that the LxNM is an internal interface in the operator's domain. It is an internal interface for orchestrating a network, but in this case that network is the VN and is owned and managed by the customer.

[snip]

>>> I have a top-level question that is puzzling me quite a bit. It 
>>> concerns the purpose of the YANG model (and so the purpose of the 
>>> draft). The question is which of these cases applies:
>>>
>>> 1. The user of the LxSM models have the option to control which TE
>>>   tunnels are used to support the VPN service. The user can use the 
>>>   model at the service interface to write this information.
>
> [Oscar] If by TE tunnel you mean the real tunnels deployed in the 
> operator network, I would say that as a general rule NO. Precisely the 
> goal of the Service model is to provide an abstraction and capture the 
> requirements without needing the customer to know the internals of the 
> operator network.

So far so good.

> If by TE tunnel you mean an abstraction of a topology “cooked” and exposed
> to the customer, the answer is yes….   

OK. Here we have some disagreement.

In this case, in my opinion, the cooked topology delivered to the customer is in the form of a service already. It might be a VN or it might be a set of connectivity services (i.e., tunnels). In this case, the delivery of a service over a service is highly ambiguous and I don’t think it falls within the operator’s capabilities to achieve it. The cooked topology is for the customer to use as they see fit.

So how would this work? Well, the cooked topology has a cooked-topology-orchestrator that is able to control and provision services over the cooked topology using, for example, an LxNM to realise a VPN service over the cooked topology. In this case, the LxSM is unchanged, and the LxNM for the cooked topology refers to the tunnels etc. in the cooked topology.

[KO] When the cooked topology is VN, then MDSC should be a cooked-topology-orchestrator and the cooked-topology is provided by CMI. In my understanding, CMI is a kind of LxSM.

[AF] Yes, that it (IMHO). As noted in the ACTN work, the MDSCs can be stacked recursively. There is an MDSC for managing the deployment of services in the VN, and there is another MDSC for manging the deployment of the VN in the operator's network.

[snip] 

>>> Now, perhaps we should consider the ACTN use case where a VN has 
>>> been built for and delivered to the customer. In this case, the 
>>> question arises as to whether the LxVPN is supported over the VN or 
>>> supported over the provider's network using the resources of the VN. 
>>> In my view of this, the LxVPN is supported over the VN: it is the 
>>> VN's management system that realises the VPN using TE tunnels in the 
>>> VN, and the VN with it's management system and TE tunnels is treated 
>>> just like a real network.

[KO] I think this might be technically correct, but VN service and VN's management system have never commercially existed yet, and there are only LxVPN's management systems. Under this situation, operators should desire the existing LxVPN's management systems to utilize/map VN resources for the existing LxVPN service, when the VN service has emerged. Thus, I believe te-service-mapping-yang should exist.

[AF] I'm having trouble following this.
I think you are saying that (today) no one sells a VN, and (in consequence) there is no such thing as a management system for a VN. I can believe that.
But then you say that it is important to be able to map the VPN onto the VN resources. This I can't understand because a VN is a service, and you have said that service doesn't exist. In particular, the customer will not be aware of the VN resources because they are not aware of the VN service.

I wonder whether what is going on is that the ACTN VN is being used (or thought about) as a way for the operator to partition the operator's network resources to make different pools of resources available for different customers. This is similar to network slicing, but it is being done privately by the operator in order that they can guarantee the services requested by the customer. 

I'm guessing about that, but it would make good sense. However, in that case, the customer is still not aware of the VN, and it is for the LxNM to include the mapping to TE tunnels.

[snip]

> [Oscar] Don’t forget the missing piece. We have focused on tunnels and 
> how they map to the service. BUT, we need to steer the traffic into 
> the tunnels. So, we still have the problem or where to indicate the 
> policies that tell
> - The customer traffic matching the charactericts A,B,C (a ToS field, 
> coming from a prefix or any kind of hint by the customer) goes into which tunnel.

Oh, this looks remarkably like the same problem we have for:
- MPLS LSPs (see also draft-ietf-pce-pcep-flowspec)
- BGP flows (see also RFC 8955)
- SFC classification (RFC 7665)
- Service mapping (per VPN+ and network slicing)

This looks like a generic problem that needs a YANG model that can be used at a number of layers to describe flows and provider a pointer to their disposition

[KO] We have had the same requirements and requested to te-service-mapping-yang, and then Dhruv already put them in the following thread.
https://mailarchive.ietf.org/arch/msg/teas/R6HH4w6pr2V205aPCScCGbw0Mjs/

[AF] Yes. I read that thread (thanks for reminding me) to be about how you might support different flow characteristics within one VPN by mapping the different flows to different VNs or different TE tunnels to meet the different quality demands.

Best,
Adrian