Subject: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

From: Qin Wu <[email-masked]>
Date: Wed, 3 Jul 2019 06:12:13 +0000

-----邮件原件-----
发件人: Young Lee [mailto:[email-masked]] 
发送时间: 2019年7月2日 0:27
收件人: Lou Berger <[email-masked]>; Qin Wu <[email-masked]>; [email-masked]
主题: RE: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

Hi WG, 

Per Lou's request, let me repeat the comments raised by Qin in the github: 

Comment 1: 

I think AP definition in VN model should be clarified or refined, since I believe An AP is a logical identifier shared between the customer and the operator used to identify not only an access link but also a network attachment point or an endpoint. This can be proved by some of text described in the draft,e g.., "Characteristics of Access Points (APs) that describe customer's end point characteristics; ".
Another example is
"
If we were to create a VN where we have four VN-members as follows:

              VN-Member 1       L1-L4
              VN-Member 2       L1-L7
              VN-Member 3       L2-L4
              VN-Member 4       L3-L8

      Where L1, L2, L3, L4, L7 and L8 correspond to a Customer
      End-Point, respectively.
"
I think we should make text consistent in the document.

Response (by YL): 

Can you suggest where to put the suggested text in the draft and give the exact text you'd like to add in the draft? Thanks.

[Qin]: I re-read the section 2 of this draft, I can see we can use ltp under vn-ap list to distinguish two abstract links from the same L1 end point to different destination edge endpoint, but it is not clear how to distinguish two abstract link from the same source endpoint to the same destination endpoint, let's say both two abstract links from L1 to L4, I think ltp should play the role again to distinguish these two abstract links. If this is correct, my suggested changes in section 2 are as follows:
OLD TEXT:
"
If we were to create a VN where we have four VN-members as follows:

              VN-Member 1       L1-L4
              VN-Member 2       L1-L7
              VN-Member 3       L2-L4
              VN-Member 4       L3-L8

      Where L1, L2, L3, L4, L7 and L8 correspond to a Customer
      End-Point, respectively.
"
NEW TEXT:
"
If we were to create a VN where we have four VN-members as follows:

              VN-Member 1       L1-L4
              VN-Member 2       L1-L7
              VN-Member 3       L2-L4
              VN-Member 4       L3-L8

      Where L1, L2, L3, L4, L7 and L8 correspond to a termination point of the Edge
      End-Point or Edge End-point and termination point pair, respectively.
      L1, L2, L3, L4, L7 and L8 can be represented by (access-point-id, ltp) or (access-point-name, ltp)
"
In this way, you will cover all the cases. Similar change is applied to section 3.1.

Comment 2: 

In some cases, we need to use LxSM to describe SLA or service requirements on specific connectivity service, typical scenario is to describe bandwidth requirement, latency requirement on connectivity service between two sites. And then we can translate LxSM model into VN model and use VN model to describe connectivity service between any two VPN sites or any two endpoints. In addition, we can use VN model to provide lifecycle management of VN and provide service assurance and network visibility to the upper layer.

I want to see this case can be supported by VN model.

Response (by YL):

VN model is intended to be on CMI, but you'd want to use VN model to be used in MPI (which is NNI in your term). Currently VN model is used in collaboration with TE-topo Connectivity Matrix. Since VN model keeps the reference ID (via leafref) to connectivity matrix, the life cycle management can be maintained by the current VN model while making use of connectivity matrix module of TE-topology to achieve the same goal that you are describing. In case you don't want to make use of connectivity matrix for connectivity service between two sites, the VN model can be used over MPI, if you wish. I think this is an implementation issue. What do you think?

[Qin]: I am not against to use connectivity matrix module of TE-topology to provide life cycle management, my suggestion is just make sure VN model is generic enough, it is still a CMI model, I am not proposed to move it to MPI interface. End to end connectivity start from access point or the touch point to attach to the VN end at another touch point. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Monday, July 1, 2019 11:13 AM
To: Young Lee <[email-masked]>; Qin Wu <[email-masked]>; [email-masked]
Subject: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

Folks, please keep WG discussions on the WG list or within a WG repo.  - and recall that the WG list is the place where consensus is evaluated/demonstrated.

Thanks,

Lou

On 7/1/2019 11:50 AM, Young Lee wrote:
> Hi Qin,
>
> Sorry for my late response to your comment. I was on vacation last week. Please see the github for my response to your comments.
>
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fyounglee-ietf%2Factn-cmi%2Fissues&amp;data=02%7C01%7Cleeyoung
> %40futurewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff2a3b24018
> 9c753a1d5591fedc%7C1%7C0%7C636975943625461888&amp;sdata=n5uCsgab7vQoQH
> 9p8mZGZgntwJoVJk2jf%2B4zWmX8lgg%3D&amp;reserved=0
>
> Best regards,
> Young
>
> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Tuesday, June 25, 2019 8:46 PM
> To: Young Lee <[email-masked]>; [email-masked]
> Subject: RE: [Teas] FW: I-D Action: 
> draft-ietf-teas-actn-vn-yang-05.txt
>
> Hi, Young:
> I raise two minor issues on github issue tracker. Thanks!
>
> -Qin
> -----邮件原件-----
> 发件人: Teas [mailto:[email-masked]] 代表 Young Lee
> 发送时间: 2019年6月15日 2:47
> 收件人: [email-masked]
> 主题: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt
>
> Hi WG,
>
> One more thing, please make use of github for raising issues and providing comments on VN Yang model:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fyounglee-ietf%2Factn-cmi&amp;data=02%7C01%7Cleeyoung%40future
> wei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff2a3b240189c753a1d5
> 591fedc%7C1%7C0%7C636975943625461888&amp;sdata=78x%2F%2B9Ju703Ux6C6YWl
> B90ETbaRhydAb8xLEVEdwMYg%3D&amp;reserved=0
>
> Thanks.
> Young
>
> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Young Lee
> Sent: Friday, June 14, 2019 1:44 PM
> To: [email-masked]
> Subject: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt
>
> Hi WG,
>
> The changes for this revision are as follows:
>
> - Added in Introduction Section on how the VN model can support 5G transport context.
> - in Section 3.2: case 2 --- clarified how VN model is used along with 
> TE-topo Connectivity matrices construct and added a paragraph to 
> introduce the JSON example of the models (in Section 7)
> - For YANG model: converted "ltp" from configurable parameter to leafref type; added references for imported modules.
> - Editorial: affiliation changes for a co-author; Compliant with five front page authors' list.
>
> Thanks.
> Young & Dhruv
>
> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, June 14, 2019 1:28 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Teas] I-D Action: draft-ietf-teas-actn-vn-yang-05.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.
>
>          Title           : A Yang Data Model for VN Operation
>          Authors         : Young Lee
>                            Dhruv Dhody
>                            Daniele Ceccarelli
>                            Igor Bryskin
>                            Bin Yeong Yoon
> 	Filename        : draft-ietf-teas-actn-vn-yang-05.txt
> 	Pages           : 56
> 	Date            : 2019-06-14
>
> Abstract:
>     This document provides a YANG data model generally applicable to any
>     mode of Virtual Network (VN) operation.
>
>
>
>
> The IETF datatracker status page for this draft is:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-actn-vn-yang%2F&amp;data=02%7
> C01%7Cleeyoung%40futurewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0f
> ee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636975943625461888&amp;sdata=
> mbMDzO98QYkGKhKMQ%2BsKTlyqIuQNsOwAn21nb9LOrl8%3D&amp;reserved=0
>
> There are also htmlized versions available at:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-ietf-teas-actn-vn-yang-05&amp;data=02%7C01%7
> Cleeyoung%40futurewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff
> 2a3b240189c753a1d5591fedc%7C1%7C0%7C636975943625461888&amp;sdata=kUJOZ
> wg%2F0uxeWAwi4EaxKd8SgX1UNbdlbb05y6FJuNw%3D&amp;reserved=0
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teas-actn-vn-yang-05&amp;da
> ta=02%7C01%7Cleeyoung%40futurewei.com%7C8713803728344b5d3efd08d6fe3ef1
> 5e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636975943625461888&amp
> ;sdata=8KuwU9VdOfnosH8KSSn8MNM03yjXMZCktDd%2Bp29TaK8%3D&amp;reserved=0
>
> A diff from the previous version is available at:
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-teas-actn-vn-yang-05&amp;data=0
> 2%7C01%7Cleeyoung%40futurewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7
> C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636975943625461888&amp;sda
> ta=E04rFcktXEVk4E6CoW9ARjHVglaJmNEXfKXZCJeDwE0%3D&amp;reserved=0
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Cleeyoung%40fut
> urewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C636975943625461888&amp;sdata=HkWwAIQIX%2FuQvoSXSp
> L58OaiiQuT3KHv6CXE7aLjL60%3D&amp;reserved=0
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Cleeyoung%40fut
> urewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C636975943625461888&amp;sdata=HkWwAIQIX%2FuQvoSXSp
> L58OaiiQuT3KHv6CXE7aLjL60%3D&amp;reserved=0
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Cleeyoung%40fut
> urewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C636975943625461888&amp;sdata=HkWwAIQIX%2FuQvoSXSp
> L58OaiiQuT3KHv6CXE7aLjL60%3D&amp;reserved=0
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Cleeyoung%40fut
> urewei.com%7C8713803728344b5d3efd08d6fe3ef15e%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C636975943625471888&amp;sdata=1i1AujVr71%2FtqaEQL6
> kHramSlG%2B2oITk0yrqxgmlsVk%3D&amp;reserved=0