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

[Adrian Farrel <[e-mail]>]

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

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

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.

> So, we need to solve several problems
> 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:
>     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)

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
>      is needed

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.

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

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

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.

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

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.

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

Good. You and I are in agreement.

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

Excellent. Clarity of purpose Will help.
 
>>> 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
> 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.

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

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.

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

That is my point about the cooked topology.

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

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

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

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.

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

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