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

[Dhruv Dhody <[e-mail]>]

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

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


> Thanks,
> Adrian
>
>