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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Apr 2021 22:27:36 +0100

Hi authors, all,

As the L3NM draft is going through last call in OPSAWG, now seemed like
a good time to give this document a bit of a review.

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.

2. The user of the LxSM models have an interest in which TE tunnels are
   used and the operator can report the relationship. The user can use
   model at the service interface to read this information.

3. The information about the tunnels is not exposed at the service 
   interface, but is important for service realisation. In this case the
   model augments the LxNM models but not the LxSM models.

This needs to be made super-clear in the Abstract and Introduction so 
that the reader can understand the purpose of the work. The text in the
document is currently somewhat unclear about this, but as I worked 
through the document (and especially once I reached the tree diagrams)
it seems clear that all three of these bullets are intended to be
supported.

Now, I wonder whether the document is conflating several objectives:

a. Provide some additional service characteristics for the LxSM models 
   in order to support the sort of service features that might be
   included in a request for an enhanced VPN. I can see why this would
   be done as an augmentation of the LxSM models, and it is a fine thing
   to do.

b. Provide some additional service characteristics for the LxNM models
   in order to assist with the realisation of the LxVPN services. Again,
   I see why this would be done as an augmentation (in this case of the 
   LxNM models), and it is also a fine thing to do.

c. Provide a mapping to assist in realisation of the LxVPN services by
   identifying which TE tunnels are used (and how). To me, this feels 
   like an augmentation of the LxNM models as it allows the operator's
   management software to make the association for control purposes and
   also allows the mapping to be visible to the operator for diagnostic
   purposes. 

d. Provide a mapping so that the customer can control/see which TE 
   tunnels are used to realise the LxVPN services. This would be an
   augmentation of the LxSM models but I don't understand the required
   function here. Surely the customer cannot control which TE tunnels
   are used to operate an LxVPN service: the tunnels are the property of
   the operator, and the customer can neither specify that the be used
   nor control how they are used. It is true that the customer may want
   certain service characteristics that will dictate how the provider
   operates the TE tunnels, but these characteristics (see point a.) are
   specified as service features not as implementation/deployment 
   behaviors. I can also see that the customer may be interested to know
   which tunnels are in use to support the service, but the chances are
   that the customer would not know what these TE tunnels are.

There is one further comment about point d. It is quite possible that 
the customer has requested that TE tunnels be set up as services for the
customer to use. But these would not be available for support of the 
LxVPN service as they are already services in their own right.

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.

And, on top of all this, now that ietf-vpn-common has been created, I am
wondering whether that is the sweet spot for augmentation, not the 
LxS/NM models.

This all leaves me thinking:
A. You want an augmentation to LxSM for enabling enhanced VPN service
   requests.
B. You want an augmentation to LxNM for realising enhanced VPN service
   requests.
C. You want an augmentation to LxNM to show how TE tunnels are used to
   realise the VPNs.

A. and B. can probably be done as a common augmentation of
ietf-vpn-common and should be in a separate document. C. is what this 
document is about. And there is deliberately no D. because exposing the
TE tunnels in the LxSM is neither meaningful nor possible.

Thanks,
Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 9 Apr 2021 11:58:18 +0530

Hi Adrian,

Thanks for your review and clear explanation. I will try to build this
description into the draft.

> it seems clear that all three of these bullets are intended to be
I will work on adding this upfront.

> it's management system and TE tunnels is treated just like a real
Yes, at the high level, the mapping could be made to either (1) VN, or (2)
TE topology abstract node (and its connectivity matrix), or (3) set of
tunnels.

The key idea here was to have full flexibility from the YANG point of view
with the use of a 'choice'. As highlighted by you, in the case of LxSM
model, (3) may not be common and in the case of LxNM, (1) would not be
commonly used. There were some discussions on limiting the scope but it was
seen as useful for the YANG to allow various mapping combinations. We could
check if that has changed and in which case we might limit the choice.

> TE tunnels in the LxSM is neither meaningful nor possible.
I am not sure I understand how a common augmentation of ietf-vpn-common can
help.

ietf-vpn-common has a set of groupings that are meant to be used by LxNM
(and future update of LxSM) model.

Currently, the ietf-te-service-mapping-types model contains groupings and a
container for configuration of the te-mapping-templates.
Then ietf-lxsm-te-service-mapping augments LxSM
and ietf-lxnm-te-service-mapping augments LxNM models using the common
groupings.

Even if we make the ietf-te-service-mapping-types to augment ietf-vpn-common,
it would not automatically lead to augmentation of LxSM and LxNM models. Am
I missing something regarding your point on common augmentation?

We did discuss in TEAS and OPSAWG about the best home for LxNM
augmentation, and at that time the preference was for this draft. We could
check if that has changed.

I will work on updating the initial section to better describe the scope of
the I-D.

Thanks!
Dhruv

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 9 Apr 2021 08:10:13 +0000

Hi Dhuv, Adrian,

                Thanks for the review. You brought very good valid points.

                Sorry if it is a “detour”, but let me first explain the “rationale” of the use case and from there, the requirements, which apply at different levels of abstractions.

                As mentioned, first, the use cases

A) I want a VPN service with a given optimization criteria for all the VPN
A.1) For example, minimum latency
B) I want a VPN service with two (or more) sets of optimization criteria for all the VPN
A.1) For example I want a set of minimum latency paths and a set of low loss paths.
C) I want a VPN service with a given optimization criteria for some source -destination pairs (PE to PE)
A.1) For example I want that from PE XX to PE YY a minimum latency path
D) In adition to an optimization criteria include:
D.1) A constraint. For example less latency than 20 ms.
D.2) A resilience property. For example, create 1+1 paths, create restorable paths, etc.
D.3) Exclude some area/node/link/srlg from the paths asigned to the VPN. Example, enterprise VPN customers don’t want their traffic to cross certain countries or certain trans-ocean links (yes… this happens, customers are picky).
E) Instead of binding the paths to the whole VPN, explicitly indicate which traffic goes to each type of path
E.1. The input can come from the user. E.g. the enterprise customer can tell, hey, the traffic I sent marked with XX, from IP xxx, please go with delay less than YY. These needs to be passed to the VPN creation.
F) Calendaring. We have received request from our business units to be able to calendar certain paths for time periods only, and schedule them in advance. E.G. enable a XX Gbps path between 3 am and 6 am.

                So, the requirements start high level from the customer and they are “de-abstracted” and materialized into the network. Well… in some cases you see the customer requirements are not so abstract, the “less than X ms” is pretty clear. Or the “I want to avoid passing this country or this link”… (This comes from real life examples of today’s requests that have had to be solved with a lot of manual and careful planning).

                What tools do we have to express and create all this? When we started the journey we had just the customer service models…

                The “general” idea that we had about the use of customer service models is that the customer uses the service models, which don’t provide details of the inside of the network. That was the reason to create the Network models in between to decouple the service orchestration part (which involved many steps and decisions before jumping into instantiating the service in the network and involve business logic).
                So, the first work of the network models, the one is in last call in opswag, addresses precisely how an operator has chosen to create a VPN service, in which network nodes to instantiate the VRFs (vpn_nodes in the model), which interfaces are attached, which protocols are used between PE-CEs, etc. The model allows to indicate an ordered preference on  the underlay transport, that is, how the packets are sent from one PE to other PE. So, for example, the operator has decided that the VPN service  is implemented with a best effort underlay transport using LDP, then that would be indicated in the model. Or, the operator can choose to prefer Traffic Engineered tunnels, and if it is not possible, fall back to LDP. 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 enginnering 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 ☺

                So, we need to solve several problems

1)      How to express the customer requirements in the service models

2)      Once the customer requirements are known by the service orchestration, be able to express the operator’s choice to satisfy that requirements in terms of traffic enginnering:

a.       Create a new set of tunnels

b.       Reuse existing tunnels

c.       Which technology to use in the tunnels (do I use RSVP-TE or I prefer to use segment routing)

3)      Now that the operator’s preference is know, create the necessary tunnels is needed

4)      Explictly associate those tunnels to the VPN service

5)      Create the necessary policies to drive the traffic into the tunnels (this allows to cover the cases in which the customer traffic has different requirements).

With this in mind….. answering you questions inline I would say (from my humble point of view)

De: Teas <[email-masked]> En nombre de Dhruv Dhody
Enviado el: viernes, 9 de abril de 2021 8:28
Para: Farrel Adrian <[email-masked]>
CC: [email-masked]; TEAS WG ([email-masked]) <[email-masked]>
Asunto: Re: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

Hi Adrian,

Thanks for your review and clear explanation. I will try to build this description into the draft.

On Fri, Apr 9, 2021 at 2:57 AM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors, all,

[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.
If by TE tunnel you mean an abstraction of a topology “cooked” and exposed to the customer, the answer is yes….

2. The user of the LxSM models have an interest in which TE tunnels are
   used and the operator can report the relationship. The user can use
   model at the service interface to read this information.
[Oscar] Same as before, I see really unlikely to report the full details. Said that, some cooked information is needed for some use cases (remember the case where the customer wanted to know which countries did his traffic go though..)

3. The information about the tunnels is not exposed at the service
   interface, but is important for service realisation. In this case the
   model augments the LxNM models but not the LxSM models.
[Oscar] Yes, this is the case where we are more interested. The customer requirements are executed by resusing or creating a new set of tunnels.

[Oscar] Fully agree.

[Oscar] Here we have TWO use cases for the LXNM models. In one of them, the explicit binding to tunnels is required. That is the “finer” level of granulariy. However, we can also use the network model one step behind, in which the operator has just made the preference (use tunnel, reuse tunnel) and passes this requirements via the network model and then a PCE/Controller/whateverfancynameyouwanttocallit calculates the paths, creates the tunnels, reserves the necessary resources, etc…

[Oscar] Fully agree. That is one of the main needs.

[Oscar] I would refer to my comment bellow. I would expose those tunnels on a “cooked” topology for the customer. The customer sees a “simplified” view focusing on their needs or concerns.

[Oscar] Precisely VN or an abstract topology fulfil this purpose.

Yes, at the high level, the mapping could be made to either (1) VN, or (2) TE topology abstract node (and its connectivity matrix), or (3) set of tunnels.

The key idea here was to have full flexibility from the YANG point of view with the use of a 'choice'. As highlighted by you, in the case of LxSM model, (3) may not be common and in the case of LxNM, (1) would not be commonly used. There were some discussions on limiting the scope but it was seen as useful for the YANG to allow various mapping combinations. We could check if that has changed and in which case we might limit the choice.

[Oscar] Yes to all

I am not sure I understand how a common augmentation of ietf-vpn-common can help.

ietf-vpn-common has a set of groupings that are meant to be used by LxNM (and future update of LxSM) model.

Currently, the ietf-te-service-mapping-types model contains groupings and a container for configuration of the te-mapping-templates. Then ietf-lxsm-te-service-mapping augments LxSM
and ietf-lxnm-te-service-mapping augments LxNM models using the common groupings.

Even if we make the ietf-te-service-mapping-types to augment ietf-vpn-common, it would not automatically lead to augmentation of LxSM and LxNM models. Am I missing something regarding your point on common augmentation?

[Oscar] I tend to agree with Dhruv. The vpn-common is just a bunch of common types to be reused. So. What we need here is the “service-mapping” common to be reused among models … Now as you see is everything related to the service mapping in a single draft…

We did discuss in TEAS and OPSAWG about the best home for LxNM augmentation, and at that time the preference was for this draft. We could check if that has changed.
[Oscar] That was the discussion at that point. However, of course, a guidance on which is the best way to organize the augments is really welcomed.

I will work on updating the initial section to better describe the scope of the I-D.

Thanks!
Dhruv

Thanks,
Adrian
[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.

Best Regards,

           Oscar

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 9 Apr 2021 13:53:34 +0100

Hi again.

Thanks for the comprehensive replies.

I summarise this as: Oscar pretty much agreeing with me, and Dhruv wanting to keep options open.

The thread is in danger of getting horribly nested, but I’ll try to convert to ASCII and reply in line.
Triple quote: me
Double quote: Dhruv
Single quote: Oscar

> Sorry if it is a “detour”, but let me first explain the “rationale” of the use case and
> from there, the requirements, which apply at different levels of abstractions.

Not a detour at all! My question is very heavily vested in the use cases (with a touch of practical possibilities for implementation).

>     B.1) For example I want a set of minimum latency paths and a set of low loss paths.
> C) I want a VPN service with a given optimization criteria for some source-destination
>     pairs (PE to PE)
>     C.1) For example I want that from PE XX to PE YY a minimum latency path
> D) In addition to an optimization criteria include:
>     D.3) Exclude some area/node/link/srlg from the paths asigned to the VPN. Example,
>             enterprise VPN customers don’t want their traffic to cross certain countries or
>             certain trans-ocean links (yes… this happens, customers are picky).
>     E.1) The input can come from the user. E.g. the enterprise customer can tell, hey,
>             the traffic I sent marked with XX, from IP xxx, please go with delay less than YY.
>             These needs to be passed to the VPN creation. 

Up to this point, this looks and feels very much like “enhanced VPN as a service”. All well and good, and makes sense to augment the LxSM models. (Although note that the service requirements here are also ferociously similar to those for a network slice – maybe not such a coincidence.)

I have some unease about the term “path”. I think I know what you mean, but it is very easy to mistake your “path” as viewed from the customer’s point of view, for a TE tunnel which *might* be how the service provider realizes the service. It is sometimes helpful to talk about “demands” or “flows” when describing the service.

> F) Calendaring. We have received request from our business units to be able to
>     calendar certain paths for time periods only, and schedule them in advance.
>     E.g. enable a XX Gbps path between 3 am and 6 am.

And why not?
But, again, with my slight reservation about the service talking about “paths”.
RFC 8413 gives some hints about how to support that within the network.

> So, the requirements start high level from the customer and they are 
> “de-abstracted” and materialized into the network. Well… in some cases
> you see the customer requirements are not so abstract, the “less than X
> ms” is pretty clear. Or the “I want to avoid passing this country or this link”
> (This comes from real life examples of today’s requests that have had to be
> solved with a lot of manual and careful planning). 

> What tools do we have to express and create all this? When we started the
> journey we had just the customer service models…

That’s fine and reasonable.

> The “general” idea that we had about the use of customer service models is
> that the customer uses the service models, which don’t provide details of the
> inside of the network. That was the reason to create the Network models in
> between to decouple the service orchestration part (which involved many
> steps and decisions before jumping into instantiating the service in the
> network and involve business logic). 

Right. That’s my understanding of the distinction between LxSM and LxNM.

> So, the first work of the network models, the one is in last call in opswag,
> addresses precisely how an operator has chosen to create a VPN service, in
> which network nodes to instantiate the VRFs (vpn_nodes in the model),
> which interfaces are attached, which protocols are used between PE-CEs,
> etc. The model allows to indicate an ordered preference on  the underlay

A bit of dangerous passive voice here.
I think “The model allows the network orchestrator to indicate…” or “This model allows the network operator to indicator…”
That is, we’re talking about the network models and so it is not the customer making this indication.

> transport, that is, how the packets are sent from one PE to other PE. So,
> for example, the operator has decided that the VPN service  is
> implemented with a best effort underlay transport using LDP, then that
> would be indicated in the model. Or, the operator can choose to prefer
> Traffic Engineered tunnels, and if it is not possible, fall back to LDP.

OK

> 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.

> 1) How to express the customer requirements in the service models

Agreed. But we need to be very careful that we only put the customer requirements in the service models, and don’t “accidentally” slip in stuff that a customer cannot know about or has no business dealing with.

> 2) Once the customer requirements are known by the service orchestration,
>     be able to express the operator’s choice to satisfy that requirements in
>     terms of traffic engineering:

Yes to all that, which seems to belong in the network models.

> 3) Now that the operator’s preference is know, create the necessary tunnels

Right. And hence the need to link the network model into the tunnel models.

> 4) Explicitly associate those tunnels to the VPN service 

Eeek!
I think that maybe this association is indirect. That is, the tunnels are associated to the VPN realization in the network model, and the network model is associated to the VPN service in the service model.

> 5) Create the necessary policies to drive the traffic into the tunnels (this
>      allows to cover the cases in which the customer traffic has different
>      requirements). 

Indeed. The “service mapping” (in the terminology of enhanced VPN and network slicing) is an important feature of flow filtering or packet classification that is part of the realization of the VPN service and so lives within the network model.

> [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.

> 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.

> [Oscar] Same as before, I see really unlikely to report the full details. Said
> that, some cooked information is needed for some use cases (remember the
> case where the customer wanted to know which countries did his traffic go
> though..)

Weeeeeell, the cooked tunnels are also a service. The customer probably has no ability to know how they are routed through the underlay.

This user requirement (which I fully accept is a realistic customer request) is not one of those “measurable SLOs” described in the enhanced VPN and network slicing work. It is a contractual thing where the operator is taken on trust that they are delivering what they have promised, but it is notoriously hard to prove without exposing a lot of details about the operator’s network.

> [Oscar] Yes, this is the case where we are more interested. The customer
> requirements are executed by resusing or creating a new set of tunnels.

Good. You and I are in agreement.

>> I will work on adding this upfront. 

Excellent. Clarity of purpose Will help.
 
> [Oscar] Here we have TWO use cases for the LXNM models. In one of them,
> the explicit binding to tunnels is required. That is the “finer” level of
> granularity. However, we can also use the network model one step behind,
> in which the operator has just made the preference (use tunnel, reuse
> tunnel) and passes this requirements via the network model and then a
> PCE/Controller/whateverfancynameyouwanttocallit calculates the paths,
> creates the tunnels, reserves the necessary resources, etc…

Perfect. The finer binding is case c., below. The presence of tunnel identifiers in the LxNM augmentation doesn’t mean they have to be used in all cases.

> [Oscar] I would refer to my comment bellow. I would expose those
> tunnels on a “cooked” topology for the customer. The customer sees
> a “simplified” view focusing on their needs or concerns. 

OK, I can’t see harm (but also can’t see value) in reporting the tunnels that have been used: the customer has no control over their use, and possibly has no understanding of what they are.

But I don’t think this is a priority. As above, I think the relationship with the cooked topology is through the LxNM that applies the VPN service to the cooked topology. That appears to be agreed in your comment about ACTN, below.

>>> LxVPN service as they are already services in their own right.

That is my point about the cooked topology.

> [Oscar] Precisely VN or an abstract topology fulfil this purpose.

Right, and that means it is an LxNM that maps to the VN.

>> Yes, at the high level, the mapping could be made to either (1) VN,
>> or (2) TE topology abstract node (and its connectivity matrix), or (3)
>> set of tunnels.  
>>
>> The key idea here was to have full flexibility from the YANG point of
>> view with the use of a 'choice'. As highlighted by you, in the case of
>> LxSM model, (3) may not be common and in the case of LxNM, (1)
>> would not be commonly used. There were some discussions on
>> limiting the scope but it was seen as useful for the YANG to allow
>> various mapping combinations. We could check if that has changed
>> and in which case we might limit the choice.     

We seem to be in general agreement, but you are saying that there might be people who don’t want to see the scope Limited.
>From your language, I take it that you are not in that group (elsewise you would have said so). So we’re looking to hear specifically from people who want (2) (or, funcitonally, those who want d.)

>> Currently, the ietf-te-service-mapping-types model contains groupings and
>> a container for configuration of the te-mapping-templates. Then ietf-lxsm-
>> te-service-mapping augments LxSM and ietf-lxnm-te-service-mapping augments
>> LxNM models using the common groupings. 
>>
>> it would not automatically lead to augmentation of LxSM and LxNM models. Am I
>> missing something regarding your point on common augmentation? 
>
> [Oscar] I tend to agree with Dhruv. The vpn-common is just a bunch of common types
> to be reused.
>
> So. What we need here is the “service-mapping” common to be reused among models
>
>> … Now as you see is everything related to the service mapping in a single draft…

I should have raised this point in a separate thread. Sorry.
I was probably just observing that you have a number of identical augmentations of different models and that there might be a common way to achieve this.

>> augmentation, and at that time the preference was for this draft. We
>> could check if that has changed. 
>
> [Oscar] That was the discussion at that point. However, of course, a guidance on
> which is the best way to organize the augments is really welcomed. 

No strong feelings at all. Just noting that vpn-common didn’t exist when this work started.
If the authors are comfortable that this is the right way to handle the YANG, I’m happy.

>> I will work on updating the initial section to better describe the scope of the I-D. 

Excellent.

> [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

Best,
Adrian

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 12 Apr 2021 08:14:21 +0000

Hi Alll,

As an operator, I almost agree with Oscar's objective/requirements/usecases.
However, as a contributor(requester) to te-service-mapping-yang, I have some comments about the discussions below

See four comments [KO] inline, please.

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Adrian Farrel
Sent: Friday, April 9, 2021 9:54 PM
To: 'Oscar González de Dios' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>
Cc: [email-masked]; 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

Hi again.

> Sorry if it is a “detour”, but let me first explain the “rationale” of 
> the use case and from there, the requirements, which apply at different levels of abstractions.

And why not?

> you see the customer requirements are not so abstract, the “less than 
> X ms” is pretty clear. Or the “I want to avoid passing this country or this link”
> (This comes from real life examples of today’s requests that have had 
> to be solved with a lot of manual and careful planning).

> What tools do we have to express and create all this? When we started 
> the journey we had just the customer service models…

> The “general” idea that we had about the use of customer service 
> models is that the customer uses the service models, which don’t 
> provide details of the inside of the network. That was the reason to 
> create the Network models in between to decouple the service 
> orchestration part (which involved many steps and decisions before 
> jumping into instantiating the service in the network and involve business logic).

> So, the first work of the network models, the one is in last call in 
> opswag, addresses precisely how an operator has chosen to create a VPN 
> service, in which network nodes to instantiate the VRFs (vpn_nodes in 
> the model), which interfaces are attached, which protocols are used 
> between PE-CEs, etc. The model allows to indicate an ordered 
> preference on  the underlay

> transport, that is, how the packets are sent from one PE to other PE. 
> So, for example, the operator has decided that the VPN service  is 

OK

> 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”

[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."

Eeek!

>>> As the L3NM draft is going through last call in OPSAWG, now seemed 
>>> like a good time to give this document a bit of a review.
>>>
>>> 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:
>>>
> [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.

[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.

> [Oscar] Same as before, I see really unlikely to report the full 
> details. Said that, some cooked information is needed for some use 
> cases (remember the case where the customer wanted to know which 
> countries did his traffic go
> though..)

> [Oscar] Yes, this is the case where we are more interested. The 
> customer requirements are executed by resusing or creating a new set of tunnels.

> that the reader can understand the purpose of the work. The text in 
> the document is currently somewhat unclear about this, but as I worked 

 
> [Oscar] Here we have TWO use cases for the LXNM models. In one of 
> them, the explicit binding to tunnels is required. That is the “finer” 
> level of granularity. However, we can also use the network model one 
> step behind, in which the operator has just made the preference (use 
> tunnel, reuse

> tunnels on a “cooked” topology for the customer. The customer sees a 
> “simplified” view focusing on their needs or concerns.

>>> There is one further comment about point d. It is quite possible 
>>> that the customer has requested that TE tunnels be set up as 
>>> services for the customer to use. But these would not be available 
>>> for support of the LxVPN service as they are already services in their own right.

>>> 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.

>> or (2) TE topology abstract node (and its connectivity matrix), or 
>> (3) set of tunnels.
>>
>> view with the use of a 'choice'. As highlighted by you, in the case 
>> of LxSM model, (3) may not be common and in the case of LxNM, (1) 
>> would not be commonly used. There were some discussions on limiting 
>> the scope but it was seen as useful for the YANG to allow various 
>> mapping combinations. We could check if that has changed

>From your language, I take it that you are not in that group (elsewise 
>you would have said so). So we’re looking to hear specifically from 
>people who want (2) (or, funcitonally, those who want d.)

>>> And, on top of all this, now that ietf-vpn-common has been created, 
>>> I am wondering whether that is the sweet spot for augmentation, not 
>>> the LxS/NM models.
>>>
>>> ietf-vpn-common and should be in a separate document. C. is what 
>>> this document is about. And there is deliberately no D. because 
>>> exposing the TE tunnels in the LxSM is neither meaningful nor possible.
>> Currently, the ietf-te-service-mapping-types model contains groupings 
>> and a container for configuration of the te-mapping-templates. Then 
>> ietf-lxsm- te-service-mapping augments LxSM and 
>> ietf-lxnm-te-service-mapping augments LxNM models using the common groupings.
>>
>> Even if we make the ietf-te-service-mapping-types to augment 
>> ietf-vpn-common, it would not automatically lead to augmentation of 
>> LxSM and LxNM models. Am I missing something regarding your point on common augmentation?
>
> [Oscar] I tend to agree with Dhruv. The vpn-common is just a bunch of 
> common types to be reused.
>

> [Oscar] That was the discussion at that point. However, of course, a 
> guidance on which is the best way to organize the augments is really welcomed.

Excellent.

> [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.

[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/

Best,
Adrian

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 12 Apr 2021 10:22:22 +0100

Hi Kenichi,

Thanks for your input.

[snip]

[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]

So far so good.

[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] 

[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]

[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

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 13 Apr 2021 03:06:17 +0000

Hi Adrian,

Thanks for your reply.

I added responses [KO2], inline.

Thanks,
Kenichi

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: Monday, April 12, 2021 6:22 PM
To: 大垣 健一 <[email-masked]>; 'Oscar González de Dios' <[email-masked]>; 'Dhruv Dhody' <[email-masked]>
Cc: [email-masked]; 'TEAS WG' <[email-masked]>; 宮坂 拓也 <[email-masked]>; 福井 良平 <[email-masked]>
Subject: RE: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

Hi Kenichi,

Thanks for your input.

[snip]

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

[KO2] If this layering is correct, meaning VN as a service is not commonly used by an end-customer like our current VPN users, I agree.

[KO2] What do you mean by "are both within the customer's control"? What "are both within the customer's control"

[snip]

So far so good.

[snip] 

[KO2] You are right. I just indicated a possible next step, not current situation.
I may require a shortcut solution for a) and A,B,C,D), once VN service with actn-vn-yang , for example, emerges.
As you wrote, VN service should exist behind LxNM optimally and not be exposed to any end-customer. However, once we decide that VN service is exposed to an end-customer like a large enterprise user, this becomes a case.

[snip]

Best,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 13 Apr 2021 10:46:05 +0100

Hello again 😊

I see...

VPN

[AF2] When the VN is provided as a service to the consumer, the operation of the VN belongs to the consumer.
If the consumer decides to operate a VPN over the VN then the consumer is responsible for realising the VPN over the VN.
That means that the consumer runs the VN Orchestrator. In this case, the LxNM is present in the consumer's management space, and it is augmented by the mapping model to coordinate with the resources in the VN. But the LxSM is still unaware of the tunnels and network resources.

[AF2]Talking to someone else yesterday, they suggested that the VN may be created by the operator to enable services for a customer, but that the VN is not exposed to the customer. It is a way for the operator to "partition" their network and provide service guarantees to the customer.
I think this is OK, but in this case the consumer is entirely unaware of the VN. When the consumer asks for a VPN service they do not see any difference if there is a VN or no VN. That is, the LxSM model is not augmented by the mapping model.
The operator may need features to map the VPN service onto the VN, and this shows up in the LxNM via the mapping model.

[AF2] I think I still disagree ☹
When the VN is exposed as a service, it is the customer's job to manage that VN. In particular, it is the customer's job to orchestrate the VN to support the VPN service.
The LxSM is how the customer configures and requests a VPN service.
The LxNM is how the orchestrator operates the network to support the VPN service.
That means the LxNM is used by the VN orchestrator to manage the VN. 
In my opinion, that means that the LxSM never has knowledge of the underlying network resources, but the LxNM does have that knowledge.

Best,
Adrian