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

From: Leeyoung <[email-masked]>
Date: Tue, 18 Sep 2018 18:55:37 +0000

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Sep 2018 16:32:04 -0400

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:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 25 Sep 2018 21:57:40 +0000

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?)

Thanks,
Lou

On 9/18/2018 2:55 PM, Leeyoung wrote:
> 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
>
>

Subject: R: New Version Notification for draft-lee-teas-te-service-mapping-yang-07.txt
From: Fioccola Giuseppe <[email-masked]>
To: Lou Berger <[email-masked]>, Leeyoung <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>, Jeff Tantsura <[email-masked]>, Daniele Ceccarelli <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 4 May 2018 08:19:14 +0000

Hi Lou, Young,

This is an interesting point. The augmentation for LxSM is possible but, in this case, it could not be the right way because it is a less flexible approach. In addition te-topology-ids and te-tp-ids are probably only optional information for the interface between Customer and Service Provider. So, in my opinion, it would be convenient to have a Service Mapping Yang Model.

Thanks,

Giuseppe

Da: Lou Berger [mailto:[email-masked]]
Inviato: martedì 1 maggio 2018 15:05
A: Leeyoung; Vishnu Pavan Beeram; [email-masked]
Cc: Dhruv Dhody; Fioccola Giuseppe; Jeff Tantsura; Daniele Ceccarelli
Oggetto: Re: New Version Notification for draft-lee-teas-te-service-mapping-yang-07.txt

Hi Young,

see below.

On 4/5/2018 10:57 AM, Leeyoung wrote:

Hi Pavan and Lou,

We have updated the draft to incorporate Pavan's comment (during London meeting) to generalize the model for TE.

Regarding the mapping, we have added options for all three:

-              VN (ACTN VN model)

-              Single abstract node in TE topology (TE-topology model)

-              List of tunnels (TE-tunnel model)

See the changes as follows:

         +---------+          +-------------+         +----------+

         |  L3SM   | <------> |             | <-----> | ACTN VN  |

         +---------+          |             |         |  Model   |

                              |             |         +----------+

                              |             |

         +---------+          | TE-Service  |         +----------+

         |  L2SM   | <------> |Mapping Model| <-----> | TE-Topo  |

         +---------+          |             |         |   Model  |

                              |             |         +----------+

                              |             |

         +---------+          |             |         +----------+

         |  L1CSM  | <------> |             | <-----> | TE-Tunnel|

         +---------+          |             |         |   Model  |

                              +-------------+         +----------+

Let us know what you think.

I think having a way to map from the LxSMs to  te topology makes a lot of sense.  Although, personally I would have looked at augmenting the existing models with te-topology-ids and te-tp-ids before defining a new module.  This said, what's really important is the opinion of WG contributors.  So I'd be more interested in hearing what others think of the approach.

Lou

Best regards,

Young & Dhruv

-----------------------------------------------------------------------------------------------

4. YANG Data Tree

module: ietf-te-service-mapping

    +--rw te-service-mapping

       +--rw service-mapping

       |  +--rw mapping-list* [map-id]

       |     +--rw map-id            uint32

       |     +--rw map-type?         map-type

       |     +--rw (service)?

       |     |  +--:(l3vpn)

       |     |  |  +--rw l3vpn-ref?        -> /l3:l3vpn-svc/vpn-services/vpn-

service/vpn-id

       |     |  +--:(l2vpn)

       |     |  |  +--rw l2vpn-ref?        -> /l2:l2vpn-svc/vpn-services/vpn-

service/vpn-id

       |     |  +--:(l1vpn)

       |     |     +--rw l1vpn-ref?        -> /l1:l1cs/service/service-

list/subscriber-l1vc-id

       |     +--rw (te)?

       |        +--:(actn-vn)

       |        |  +--rw actn-vn-ref?      -> /vn:actn/vn/vn-list/vn-id

       |        +--:(te-topo)

       |        |  +--rw vn-topology-id?   te-types:te-topology-id

       |        |  +--rw abstract-node?    -> /nw:networks/network/node/node-

id

       |        +--:(te-tunnel)

       |           +--rw te-tunnel-list*   te:tunnel-ref

       +--rw site-mapping

          +--rw mapping-list* [map-id]

             +--rw map-id         uint32

             +--rw (service)?

             |  +--:(l3vpn)

             |  |  +--rw l3vpn-ref?     -> /l3:l3vpn-svc/sites/site/site-id

             |  +--:(l2vpn)

             |  |  +--rw l2vpn-ref?     -> /l2:l2vpn-svc/sites/site/site-id

             |  +--:(l1vpn)

             |     +--rw l1vpn-ref?     -> /l1:l1cs/access/uni-list/UNI-ID

             +--rw (te)?

                +--:(actn-vn)

                |  +--rw actn-vn-ref?   -> /vn:actn/ap/access-point-

list/access-point-id

                +--:(te)

                   +--rw ltp?           te-types:te-tp-id

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 05, 2018 9:43 AM
To: Dhruv Dhody <[email-masked]><mailto:[email-masked]>; Giuseppe Fioccola <[email-masked]><mailto:[email-masked]>; Jeff Tantsura <[email-masked]><mailto:[email-masked]>; Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>; Leeyoung <[email-masked]><mailto:[email-masked]>
Subject: New Version Notification for draft-lee-teas-te-service-mapping-yang-07.txt

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

Revision:              07

Document date: 2018-04-05

Pages:                  19

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

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

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

Abstract:

   This document provides a YANG data model to map service model (e.g.,

   L3SM) and Traffic Engineering model (e.g., TE Tunnel or ACTN VN

   model). This model is referred to as TE service Mapping Model. This

   model is applicable to the operation's need for a seamless control

   and management of their VPN services with TE tunnel support.

The IETF Secretariat

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Sep 2018 19:05:20 -0400

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