Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-te-service-mapping-yang-11.txt

From: Leeyoung <[email-masked]>
Date: Thu, 4 Oct 2018 14:29:09 +0000

Hi Lou,

I think we can do the augmentation approach.

If we were to augment LxSM models, we have two choices:

·       First choice: To have three separate augmented LxSM models so that each LxSM would augment independently from one another.

·       Second choice: To have one YANG model where three augmentations take place there, which means all three LxSM models are augmented at the same time.

I would think the first choice is what you meant.

Thanks.

Young

-----Original Message-----

From: Lou Berger [mailto:[email-masked]]

Sent: Tuesday, September 25, 2018 6:05 PM

To: Leeyoung <[email-masked]>; [email-masked]; [email-masked]

Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-te-service-mapping-yang-11.txt

Young,

    There was one comment on the list other than my question, right? Giuseppe's comment basically says it is provider information, right? So isn't this what NACM is all about, i.e., limiting information based on who is asking for it. So I still am unconvinced that the complexity of a new module yields any benefit.

Just think of it from a transaction processing perspective.  With the proposed approach, a client that wants to understand the mapping has to

(1) read the service module), (2) search the service module for a mapping, and then (3) read the related TE information.  With the augmentation approach (2) is eliminated and during processing (1) it's possible to see if the TE information even exists.  This reduces processing on both clients and servers.

While not a major point, I do think the added complexity should be more strongly justified.

Lou

On 9/25/2018 5:57 PM, Leeyoung wrote:

> Hi Lou,

> I think this has been discussed in the mailing list when you asked the opinion on this issue. Please see the attachment.

> Please also refer to the IETF 102 slides (in particular page 3) for further information on this model and why the co-authors think it is beneficial to have a separate model than augmenting three separate service models.

> Thanks.

> Young

> -----Original Message-----

> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger

> Sent: Tuesday, September 25, 2018 3:32 PM

> To: [email-masked]; [email-masked]

> Subject: Re: [Teas] FW: New Version Notification for

> draft-lee-teas-te-service-mapping-yang-11.txt

> Hi Young/authors,

>       Thanks for the update.  I remain a bit confused/concerned that

> this document adds a new standalone model rather than taking the

> simpler approach of just augmenting the existing service/connectivity

> modules with the pointers to the TE/VN/tunnel information (perhaps

> using

> groupings?)

> Can you elaborate on your thinking here?

> Thanks,

> Lou

> On 9/18/2018 2:55 PM, Leeyoung wrote:

>> Hi,

>> The revision is to fix YANG errors caused by the L1CSM YANG update. No content changes.

>> Thanks.

>> Young

>> -----Original Message-----

>> From: [email-masked] [mailto:[email-masked]]

>> Sent: Tuesday, September 18, 2018 1:54 PM

>> To: Daniele Ceccarelli <[email-masked]>; Giuseppe

>> Fioccola <[email-masked]>; Dhruv Dhody

>> <[email-masked]>; Jeff Tantsura <[email-masked]>; Leeyoung

>> <[email-masked]>; Qin Wu <[email-masked]>

>> Subject: New Version Notification for

>> draft-lee-teas-te-service-mapping-yang-11.txt

>> A new version of I-D, draft-lee-teas-te-service-mapping-yang-11.txt

>> has been successfully submitted by Young Lee and posted to the IETF repository.

>> Name:                          draft-lee-teas-te-service-mapping-yang

>> Revision:       11

>> Title:                             Traffic Engineering and Service Mapping Yang Model

>> Document date:         2018-09-18

>> Group:                         Individual Submission

>> Pages:                          22

>> URL:            https://www.ietf.org/internet-drafts/draft-lee-teas-te-service-mapping-yang-11.txt

>> Status:         https://datatracker.ietf.org/doc/draft-lee-teas-te-service-mapping-yang/

>> Htmlized:       https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-11

>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lee-teas-te-service-mapping-yang

>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lee-teas-te-service-mapping-yang-11

>> Abstract:

>>      This document provides a YANG data model to map customer service

>>      models (e.g., the L3VPM Service Model) to Traffic Engineering (TE)

>>      models (e.g., the TE Tunnel or the Abstraction and Control of

>>      Traffic Engineered Networks Virtual Network model). This model is

>>      referred to as TE Service Mapping Model and is applicable to the

>>      operator's need for seamless control and management of their VPN

>>      services with TE tunnel support.

>>      The model is principally used to allow monitoring and diagnostics of

>>      the management systems to show how the service requests are mapped

>>      onto underlying network resource and TE models.

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

>> The IETF Secretariat

>> _______________________________________________

>> Teas mailing list

>> [email-masked]

>> https://www.ietf.org/mailman/listinfo/teas

> _______________________________________________

> Teas mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/teas

> _______________________________________________

> Teas mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Fri, 5 Oct 2018 14:08:27 -0400

Hi Young,

On 10/4/2018 10:29 AM, Leeyoung wrote:
> ·First choice: To have three separate augmented LxSM models so that 
> each LxSM would augment independently from one another.
>
> ·Second choice: To have one YANG model where three augmentations take 
> place there, which means all three LxSM models are augmented at the 
> same time.
>

There's certainly room for identifying what is the best approach . This 
said, I actually don't understand the second choice and unsure if it can 
be legally supported (what does it mean for an implementation to support 
of module that includes an augmentation to a non-supported module? maybe 
it works with deviations?) While not sure about this, it sounds / looks 
like you took the first choice.

Lou

> To: Leeyoung <[email-masked]>; 
> [email-masked]; [email-masked]
>
>     There was one comment on the list other than my question, right? 
> Giuseppe's comment basically says it is provider information, right? 
> So isn't this what NACM is all about, i.e., limiting information based 
> on who is asking for it. So I still am unconvinced that the complexity 
> of a new module yields any benefit.
>
> Just think of it from a transaction processing perspective.  With the 
> proposed approach, a client that wants to understand the mapping has to
>
> (1) read the service module), (2) search the service module for a 
> mapping, and then (3) read the related TE information.  With the 
> augmentation approach (2) is eliminated and during processing (1) it's 
> possible to see if the TE information even exists.  This reduces 
> processing on both clients and servers.
>
> > I think this has been discussed in the mailing list when you asked 
> the opinion on this issue. Please see the attachment.
>
> >
>
> > Please also refer to the IETF 102 slides (in particular page 3) for 
> further information on this model and why the co-authors think it is 
> beneficial to have a separate model than augmenting three separate 
> service models.
>
> >
>
> > Thanks.
>
> > Young
>
> >
>
> >> URL: 
> https://www.ietf.org/internet-drafts/draft-lee-teas-te-service-mapping-yang-11.txt
>
> >> Status: 
> https://datatracker.ietf.org/doc/draft-lee-teas-te-service-mapping-yang/
>
> >> Htmlized: 
> https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-11
>
> >> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-lee-teas-te-service-mapping-yang
>
> >> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-lee-teas-te-service-mapping-yang-11
>
> >>
>
> >> Abstract:
>
> >> 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.
>
> >>
>
> >> The IETF Secretariat
>
> >>
>

---

From: Leeyoung <[email-masked]>
Date: Fri, 5 Oct 2018 18:47:19 +0000

Hi Lou,

Yes, you are correct, the first option is what we have taken. I agree with you that the second option does not make much sense. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, October 5, 2018 1:08 PM
To: Leeyoung <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-te-service-mapping-yang-11.txt

Hi Young,

> I would think the first choice is what you meant.

There's certainly room for identifying what is the best approach . This said, I actually don't understand the second choice and unsure if it can be legally supported (what does it mean for an implementation to support of module that includes an augmentation to a non-supported module? maybe it works with deviations?) While not sure about this, it sounds / looks like you took the first choice.

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Oct 2018 13:21:23 +0100

So does that mean we're all aligned and on board with this document?
Well, at least as far as agreeing it's a good starting point for bridging the gap between service models (which I love) and ACTN (which Young loves, and which the WG seems to be backing).

Adrian

> From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
> Sent: 05 October 2018 19:47
> To: Lou Berger; [email-masked]; [email-masked]
> Yes, you are correct, the first option is what we have taken. I agree with you that
> the second option does not make much sense.
> 
> Thanks.
> Young
> 
> There's certainly room for identifying what is the best approach . This said, I
> actually don't understand the second choice and unsure if it can be legally
> supported (what does it mean for an implementation to support of module that
> includes an augmentation to a non-supported module? maybe it works with
> deviations?) While not sure about this, it sounds / looks like you took the first
> choice.
> 
> Lou
> 
> > Thanks.
> >
> > Young
> >