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

[Oscar González de Dios <[e-mail]>]

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 <[e-mail]> En nombre de Dhruv Dhody
Enviado el: viernes, 9 de abril de 2021 8:28
Para: Farrel Adrian <[e-mail]>
CC: [e-mail]; TEAS WG ([e-mail]) <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
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.

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


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.

I will work on adding this upfront.


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.
[Oscar] Fully agree.


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.

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



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.
[Oscar] Fully agree. That is one of the main needs.

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

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.

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


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.
[Oscar] Yes to all


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.

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