Re: [Teas] WG Last Call: draft-ietf-teas-actn-vn-yang-19

[Adrian Farrel <[e-mail]>]

Hi Dhruv,

 

Thanks for taking the time to address my comments and reply.

 

The description of the Type 1 VN in Sections 2.1 and 3.1 bothers me. It

is true that you can represent this model as an abstract node, but in general

it is not wise. Well, unless you talk about "limited cross-connect 

capabilities."

 

The example in this section presents a VN with 6 customer end-points and

4 abstract links (VN members). But, of course, when you represent this

as an abstract node, there are 15 possible cross-connects and no way of

knowing which ones don't apply. 

 

So I would strongly advise you stick with the "VN members"

representation of abstract links, and not venture into the abstract node

way of modeling it. 

 

Dhruv: The abstract node is key to the YANG model for both VN type 1 and 2. The connectivity matrix is how you limit the possibilities. I have added dotted lines to show the VN-members in the figure 2 instead. 

 

[AF] OK. I doubt that I can persuade people to stop talking about Abstract Node representations. The fact that I think they are a poor idea is not going to win out, and I must declare myself in the rough.

 

However, as you note, the connectivity matrix is a fundamental part of the Abstract Node model except in a full mesh scenario. So I think a little more needs to be said about it. And perhaps a little more clarity between the VN (virtual network) and the VN (virtual node). For example, Section 1 had

 

|   *  Characteristics of Virtual Networks (VNs) that describe the

|      customer's VN in terms of multiple VN Members comprising a VN,

|      multi- source and/or multi-destination characteristics of the VN

|      Member, the VN's reference to TE-topology's Abstract Node;

|

|   The actual VN instantiation and computation is performed with

|   Connectivity Matrices sub-module of TE-Topology Model [RFC8795] which

|   provides TE network topology abstraction and management operation.

Section 2.1 doesn’t mention the connectivity matrix. Perhaps, along with the dotted lines, you could add an explanation.

And 3.1 only mentions the connectivity matrix in the message flow figure.

 

I was wondering whether you needed to add a detailed description of the connectivity matrix, but it might be enough to provide a clear pointer to 3.7 of RFC 8795 with the observation that it applies equally to Abstract Nodes.

 

Cheers,

Adrian