Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Susan Hares <shares@ndzh.com> Thu, 23 April 2020 18:02 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B83A0DF6; Thu, 23 Apr 2020 11:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yyoj4kGGZ0vJ; Thu, 23 Apr 2020 11:02:21 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348893A0DEC; Thu, 23 Apr 2020 11:02:20 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188;
From: Susan Hares <shares@ndzh.com>
To: "'Rokui, Reza (Nokia - CA/Ottawa)'" <reza.rokui@nokia.com>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>, 'Teas-ns-dt' <teas-ns-dt-bounces@ietf.org>, 'TEAS WG' <teas@ietf.org>
References: <016d01d61986$4cf2a210$e6d7e630$@ndzh.com> <CAB75xn6hRMDoNCy7GX=f=XKb_rSfTb2y7X-=5CWa=1Oda33saw@mail.gmail.com> <831C8348-A787-4B29-BCD8-3307957EE538@nokia.com>
In-Reply-To: <831C8348-A787-4B29-BCD8-3307957EE538@nokia.com>
Date: Thu, 23 Apr 2020 14:02:15 -0400
Message-ID: <01e301d61999$52e0c040$f8a240c0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH5YXvgdLHp66IhkKdwLbcYZMJQ2wHDEd0dASa6yqGoKRSnoA==
Content-Language: en-us
X-Antivirus: AVG (VPS 200423-2, 04/23/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/arAOAE3ApYVNsXqLeII9P08L-L4>
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 18:02:25 -0000

Reza:

Your answer to my request for clarification of your slides seems to have skipped a step. 
 I asked for clarification, and you stated you prepared a clear set of slides 
(smile)
A clarification question indicates your slides were unclear to me. 
Perhaps you would kindly explain a few things to me. 

Sue 
----------------

Question 1)  Your slides stated

Customer level 
    | 
Higher level systems  
  |  (your model is here) 
Transport slide controller
 |
Network controllers

 On slide 2, 
a) who is the customer? 
b) who is running the higher level systems? 
c) who is running transport slide controller 

Your text says in section 3, page 
  "The intention of the transport slice model is to allow the consumers,
   e.g.  A higher level management system, to request and monitor
   transport slices.  In particular, the model allows consumers to
   operate in an abstract, technology-agnostic manner, with
   implementation details hidden. "

Is the end-customer directly running the system? 
Is this directly linked to the certified paying customer? 
Or is the customer really the person on the inside of the 5G provider configuring it. 

Question-2)  If you are using the TS-Endpoint as an entry point (slide  4)
How is this conceptually different that the site endpoints defined by 
RFC8466 (section 5.5), RFC8049 (section 6.5 and 6.6)?  

In the L2SM and l3SM models, you sites with: 
a) end-to-end p2p connectivity 
b) ~logical LANs (multiple connections through a single transport)? 
c) multiple VPNs (translated to multiple Transport slides connectivity) 

Question-3:  Slide 15 -  TS-NBI as Augmenting network model (RFC8345)

The slide makes it appear as you model TS-NBI as a network layer connection.
Is this correct? 

If you are modeling as network connection, Why? 
If you are modeling this as a customer level,  then why is 
this slide (which you claim is "clear") is modeling this as 
dependent on a link rather than connecting as a customer 
connection from an upper logical layer (connecting multiple connections) 
to one of possible links. 

If you are modeling this as a customer level slides,  13 and 14 
also seems to misaligned.  You are on top of these models
utilizing what portions you wish. 

 
Question 4:  Are these models ephemeral? 

Again - thank you for answering these questions. 



-----Original Message-----
From: Rokui, Reza (Nokia - CA/Ottawa) [mailto:reza.rokui@nokia.com] 
Sent: Thursday, April 23, 2020 1:01 PM
To: Dhruv Dhody; Susan Hares; Teas-ns-dt; TEAS WG (teas@ietf.org)
Cc: Rokui, Reza (Nokia - CA/Ottawa)
Subject: Re: [Teas] draft-wd-teas-transport-slice-yang-01 - Mike question

Thanks Sue for you comment and Dhruv for your response. We prepared a good set of slides to capture the rational behind our model and why we did not use VN or RFC 8345 models although we used the design concept from both yang models. 
As Dhruv pointed out, we add them to appendix since they are very important aspects.

Cheers,
Reza


On 2020-04-23, 12:22 PM, "Teas on behalf of Dhruv Dhody" <teas-bounces@ietf.org on behalf of dhruv.ietf@gmail.com> wrote:

    Hi Sue,

    Thanks for your email. Yes, our work for TS-NBI is closer to the
    customer service models and in fact uses the same design philosophy by
    creating an independent model with a customer view (of the slice)
    rather than the network view. The network view would be useful for the
    slice realization by the TS-controller as described in the framework
    draft.

    It would be good idea to capture this discussion in the Appendix of
    our I-D. Further, there are some technical challenges such as modeling
    TS-endoint as an augmentation of a termination point in RFC8345; our
    preference is to maintain TS-endpoint to be a logical identifier with
    either CE-side details or PE-side details or both.

    Thanks!
    Dhruv

    On Thu, Apr 23, 2020 at 9:16 PM Susan Hares <shares@ndzh.com> wrote:
    >
    > Bo Wu, Dhruv, Reza, and Liuyan:
    >
    >
    >
    > Thank you for your presentation in TEAS on the draft-wd-teas-transport-slice-yang-01.    I had hoped to ask this question on the mike:
    >
    >
    >
    > “Would you provide more details on why you felt the base model (RFC8345) was not appropriate to utilize? “
    >
    >
    >
    > It seems to me that you are proposing a customer level model  to monitor and set-up the traffic slicing?    RFC8345 provides a base model with a customer level.   The models L2SM and L3SM provided a customer level for general VPNs.   You seem to be providing the equivalent for a traffic slicing.
    >
    >
    >
    > If you are looking to utilize the base model then providing a customer level model is a good idea.  It is much cleaner than mixing it with the network layer.  When network slicing was starting its work, I prepared this suggestion as part of the first BOF.
    >
    >
    >
    > Would you do me a favor in your presentation of “customer level”,  would you careful distinguish between the following customer levels?
    >
    >
    >
    > End –customer ---
    >
    >         |
    >
    > VPN customer (person/tools configuring)
    >
    > Service
    >
    >     |
    >
    > VPN of network
    >
    >     |
    >
    > Base network
    >
    >
    >
    > Thank you!
    >
    >
    >
    > The I2RS WG (which chair) standardized RFC8345.   Your application was one of the ones that caused us to work through the model and the issues with yang.
    >
    >
    >
    > I’m excited to see your work in TEAS.
    >
    >
    >
    > Sue
    >
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > Teas mailing list
    > Teas@ietf.org
    > https://www.ietf.org/mailman/listinfo/teas

    _______________________________________________
    Teas mailing list
    Teas@ietf.org
    https://www.ietf.org/mailman/listinfo/teas