Hello Jurgen,
Thank you for your comment,
Yeap I think it is a great idea to explain why do we need the adjustments of
RFC 8343 in the case of draft-shytyi-opsawg-vysm-04.
What do you think about this:
1. uCPE phy interface has "vPorts" to witch "vLinks are assigned". "vLinks
"connect" the phy interface with "vPort" of vswitch. Thus we may add to the
derieved from RFC 8343 module the list of "vPorts" for each phy interface.
example with 1 phy interface:
+-------------------------------------
| UCPE
+------------+
| |------vPort
1---vlink---(vport_sw)vswitch(vport_sw)--vlink---.....----WAN
LAN----| Phy |------vPort 2
| interface |
+-------------+
|
+----------------------------------------------
2. If we include the yang module from the RFC 8343 to the set of yang models by
default it goes in the root of config mode. i.e:
EXAMPLE:
config t
interfaces interface....
When we have a parent module we need to place the RFC 8343 module to under the
parent module (like in the draft draft-shytyi-opsawg-vysm-04).
Hence the RFC8343 may be modified to add the augment statement(as it is dome
in draft-shytyi-opsawg-vysm-04) to put the "interfaces interface" under the
parent module like
EXAMPLE:
conifg t
ucpe "ucpe X" interfaces interface...
Best,
Dmytro
---- On Tue, 22 Oct 2019 20:08:59 +0200 Schönwälder, Jürgen
<mailto:j.schoenwael...@jacobs-university.de>
<mailto:j.schoenwael...@jacobs-university.de> wrote ----
I think you need to explain each and every change you make to the
ietf-interfaces definitions. Ideally, semantic changes would be
limited (or not even needed at all). But nobody can tell unless
you clearly document the changes (and why they are needed).
/js
On Tue, Oct 22, 2019 at 07:57:18PM +0200, Dmytro Shytyi wrote:
> Hello Tom,
>
> I can imagine your birraze. And I would like to add the next thing: the model
> from RFC 8343 has some code that we are interested in ( not all, but part)
> IMHO it is impossible/wrong for me to take the code from another ietf rfc and
> not to give a reference at least somewhere in the yang model , for example
> module description ( i also will update the references in the bottom if id
> document).
>
> Therefore I assume it is a nice to separate things in modules to show what
> yang models are new and what parts are taken from another RFC and modified.
>
>
> This module " ietf interfaces" is derived from RFC 8343 but the draft module
> has at least another module name and namespace. Thus I may modify the
> description to add that we use base module defined in RFC 8343 and further
> modify it according to our needs?
>
>
> Can the yang module description ( ucpe-interfaces) change the feeling about
> the set of yang models?
>
> Best regards,
> Dmytro.
> Get BlueMail for Android
>
> On Oct 19, 2019, 21:29, at 21:29, tom petch <mailto:ie...@btconnect.com>
> wrote:
> >Um no!
> >
> > module ietf-interfaces
> >
> >exists; it is defined in RFC8343. You cannot create another one!
> >
> >and when I look at pp15-16 of your I-D, it looks like a copy of the
> >text
> >of RFC8343, text which is right for RFC8343 but is wrong for something
> >which you are creating, regardless of what it is that you are
> >augmenting
> >be that ietf-interfaces or anything else..
> >
> >Hence my 'bizarre'.
> >
> >Tom Petch
> >
> >
> >----- Original Message -----
> >From: "Dmytro Shytyi" <mailto:ietf.dmy...@shytyi.net>
> >To: "tom petch" <mailto:ie...@btconnect.com>
> >Cc: "opsawg" <mailto:opsawg@ietf.org>
> >Sent: Saturday, October 19, 2019 1:22 PM
> >
> >
> >Hello Tom,
> >
> >
> >
> >>import tailf-ncs {
> >
> >>which looks inappropriate for an ietf module.
> >
> >
> >WIll be fixed. Notice: the yang validator did not throw any errors
> >regarding importing this module.
> >
> >
> >
> >Indeed there is <CODE BEGINS> missing for 2 yang modules.
> >
> >Actually there are 3 yang modules. where:
> >
> >1.yang module "ietf-vysm-interfaces" autgments "ietf-interfaces"
> >
> >2. yang module "ietf-interfaces" augments "ietf-vysm-service".
> >
> >The idea is to use standard module "ietf-interfaces" and add an
> >extension leaf: connect interface to virtuali link.
> >
> >
> >
> >1. module ietf-vysm-service{
> >
> >....
> >
> >list ucpe {
> >
> >...
> >
> >}
> >
> >}
> >
> >
> >
> >2. module ietf-interfaces {
> >
> >import ietf-vysm-service {
> > prefix ietf-vysm;
> > }
> >
> >
> >...
> >
> >augment "/ietf-vysm:ucpe"{
> >
> >container interfaces {
> >
> >description
> > "Interface parameters.";
> >
> >list interface {
> >
> >...
> >
> >}
> >
> >}
> >
> >}
> >
> >
> >
> >3.module ietf-vysm-interfaces {
> >
> >import ietf-vysm-service {
> > prefix ietf-nfv;
> > }
> >
> >import ietf-interfaces {
> > prefix ietf-if;
> > }
> >
> >....
> >
> >augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {
> >
> >
> >
> >}
> >
> >}
> >
> >I think it is a nice idea to add this shot desctiption to the draft.
> >
> >____________
> >Dmytro SHYTYI
> >
> >
> >
> >
> >
> >---- On Sat, 19 Oct 2019 13:51:19 +0200 tom petch
> ><mailto:ie...@btconnect.com>
> >wrote ----
> >
> >
> >
> >----- Original Message -----
> >From: "Dmytro Shytyi" <mailto:mailto:ietf.dmy...@shytyi.net>
> >Sent: Friday, October 18, 2019 3:30 PM
> >
> >Hello all,
> >
> >We updated the draft to version draft-shytyi-opsawg-vysm-03.txt with
> >the
> >new information.
> >
> ><tp>
> >
> >and you do not yet have IANA Considerations or Security Considerations
> >as per RFC8407. And you import
> > import tailf-ncs {
> >which looks inappropriate for an ietf module.
> >
> >But as a whole, this looks so bizarre that I went back to the web site
> >and downloaded it all over again to try and see what had happened; the
> >result remains bizarre.
> >
> >You have
> >
> > <CODE ENDS>
> > module ietf-vysm-interfaces {
> >
> >which is wrong - no CODE BEGINS - and then
> >
> > <CODE ENDS>
> >
> > module ietf-interfaces {
> >
> >which is ........ words fail me. What are you trying to do?
> >
> >Tom Petch
> >
> >ps draft-shytyi-netmod-vysm looked like a good start before the switch
> >to opsawg.
> >
> >
> >We added a section that describes what could be done with uCPE,
> >precisely the advantages that uCPE introduces.
> >
> >Tehre are sevaral nice figures that describe how we could take an
> >advantage of uCPE.
> >
> >
> >
> >If needed, we also can introduce the layered architecture of the YANG
> >models that are in stacked orchestrators.
> >
> >
> >
> >Dear chairs of the wg, I will attend the next IETF meeting and I would
> >like to have a 'brief' slot to present the draft.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >A new version of I-D, draft-shytyi-opsawg-vysm-03.txt
> >
> >has been successfully submitted by Dmytro Shytyi and posted to the
> >
> >IETF repository.
> >
> >
> >
> >Name: draft-shytyi-opsawg-vysm
> >
> >Revision: 03
> >
> >Title: A YANG Module for uCPE management.
> >
> >Document date: 2019-10-18
> >
> >Group: Individual Submission
> >
> >Pages: 41
> >
> >URL:
> >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-03.txt
> >
> >Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/
> >
> >Htmlized: https://tools.ietf.org/html/draft-shytyi-opsawg-vysm-03
> >
> >Htmlized:
> >https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm
> >
> >Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-03
> >
> >
> >
> >Abstract:
> >
> >This document provides a YANG data model for uCPE management (VYSM)
> >
> >and definition of the uCPE equipment. The YANG Service Model serves
> >
> >as a base framework for managing an universal Customer-Premises
> >
> >Equipment (uCPE) subsystem. The model can be used by a Network
> >
> >Service Orchestrator.
> >
> >
> >
> >______________
> >Dmytro SHYTYI,
> >SFR.
> >
> >
> >
> >
> >
> >
> >---- On Tue, 08 Oct 2019 18:33:13 +0200 Dmytro Shytyi
> ><mailto:mailto:mailto:ietf.dmy...@shytyi.net> wrote ----
> >
> >
> >
> >Hello Joe,
> >
> >Thank you for your comment.
> >
> >
> >
> >In the new version:
> >
> >We updated the existing yang model according to your suggestions(now
> >the
> >nits and validation logs seem to be clear).
> >
> >We expanded the uCPE management yang model with interface model from
> >RFC
> >8343( A YANG Data Model for Interface Management)
> >
> >Now there are 3 yang files that you may strip from I-D:
> >
> >vsym-service.yang
> >
> >modified ietf-interfaces.yang (augments vsym-service.yang)
> >
> >ietf-vsym-interfaces.yang (augments vsum-service.yang and has ref to
> >"vLinks" from vsym-service).
> >
> >
> >
> >
> >
> >
> >
> >
> >A new version of I-D, draft-shytyi-opsawg-vysm-02.txt
> >
> >has been successfully submitted by Dmytro Shytyi and posted to the
> >
> >IETF repository.
> >
> >
> >
> >Name: draft-shytyi-opsawg-vysm
> >
> >Revision: 02
> >
> >Title: A YANG Module for uCPE management.
> >
> >Document date: 2019-10-08
> >
> >Group: Individual Submission
> >
> >Pages: 40
> >
> >URL:
> >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-02.txt
> >
> >Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/
> >
> >Htmlized: https://tools.ietf.org/html/draft-shytyi-opsawg-vysm-02
> >
> >Htmlized:
> >https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm
> >
> >Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-02
> >
> >
> >
> >Abstract:
> >
> >This document provides a YANG data model for uCPE management (VYSM)
> >
> >and definition of the uCPE equipment. The YANG Service Model serves
> >
> >as a base framework for managing an universal Customer-Premises
> >
> >Equipment (uCPE) subsystem. The model can be used by a Network
> >
> >Service Orchestrator.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >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
> >
> >
> >
> >---- On Mon, 07 Oct 2019 15:50:40 +0200 Joe Clarke (jclarke)
> ><mailto:mailto:mailto:jcla...@cisco.com> wrote ----
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >
> >OPSAWG mailing list
> >
> >mailto:mailto:mailto:OPSAWG@ietf.org
> >
> >https://www.ietf.org/mailman/listinfo/opsawg
> >
> >
> >
> >
> >
> >On Sep 30, 2019, at 17:17, Dmytro Shytyi
> ><mailto:mailto:mailto:ietf.dmy...@shytyi.net>
> >wrote:
> >
> >
> >
> >Dear members of opsawg,
> >
> >
> >
> >Recently we uploaded a draft about uCPE management.
> >
> >
> >You are invited to answer few questions regarding the draft
> >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-01.txt.
> >
> >
> >
> >
> >
> >
> >One thing that would help with reviews is if you cleaned up this YANG
> >module. Consider using pyang -f yang --keep-comments to generate
> >something well-formatted, and —canonical to check ordering. In
> >particular, your
> > revisions are out of order.
> >
> >
> >
> >
> >
> >Question1: Do you find a difinition of uCPE is well explained? If no
> >what could be improved?
> >
> >
> >
> >
> >
> >
> >
> >I think it is, but as a vendor that makes such a device, I may not be
> >the right person to ask. What I mean is that I inherently understand
> >the
> >concept.
> >
> >
> >
> >It would be good if others perhaps that use such devices could weigh
> >in.
> >
> >
> >
> >Joe
> >
> >
> >
> >You may answer: I agree with definition. OR I think it could be
> >modified...
> >
> >Question2: Do you think there is enough examples of internal uCPE
> >service and usecases that are well depicted.
> >
> >
> >
> >
> >
> >You may answer: The examples and usecases are well explained. OR The
> >usecases need improvements.
> >
> >Question3: Do you find that yang model should stay unchanged regarding
> >the phy interfaces. Maybe one may think about "ietf interface" instead
> >of "phyInterface".
> >
> >You may answer: The yang model looks good for me. OR The yang model
> >needs more improvements(which improvements).
> >
> >
> >______________
> >
> >Best Regards,
> >
> >Dmytro SHYTYI
> >
> >
> >
> >
> >
> >
> >---- On Thu, 26 Sep 2019 18:01:14 +0200
> ><mailto:mailto:mailto:internet-dra...@ietf.org> wrote ----
> >
> >
> >
> >
> >A new version of I-D, draft-shytyi-opsawg-vysm-01.txt
> > has been successfully submitted by Dmytro Shytyi and posted to the
> > IETF repository.
> >
> > Name: draft-shytyi-opsawg-vysm
> > Revision: 01
> > Title: A YANG Module for uCPE management.
> > Document date: 2019-09-26
> > Group: Individual Submission
> > Pages: 15
> > URL:
> >https://www.ietf.org/internet-drafts/draft-shytyi-opsawg-vysm-01.txt
> > Status: https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/
> > Htmlized: https://tools.ietf..org/html/draft-shytyi-opsawg-vysm-01
> > Htmlized:
> >https://datatracker.ietf.org/doc/html/draft-shytyi-opsawg-vysm
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-opsawg-vysm-01
> >
> > Abstract:
> > This document provides a YANG data model for uCPE management (VYSM)
> > and definition of the uCPE equipment. The YANG Service Model serves
> > as a base framework for managing an universal Customer-Premises
> > Equipment (uCPE) subsystem. The model can be used by a Network
> > Service Orchestrator.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> >submission
> > until the htmlized version and diff are available at
> >http://tools.ietf.org..
> >
> > The IETF Secretariat
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >
> >OPSAWG mailing list
> >
> >mailto:mailto:mailto:OPSAWG@ietf.org
> >
> >https://www.ietf.org/mailman/listinfo/opsawg
> >
> >
> >------------------------------------------------------------------------
> >--------
> >
> >
> >> _______________________________________________
> >> OPSAWG mailing list
> >> mailto:mailto:OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> _______________________________________________
> OPSAWG mailing list
> mailto:OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
