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

[Adrian Farrel <[e-mail]>]

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