Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Qin Wu]

+1, in addition, I am wondering whether this is something related to overlay 
topology model, if yes, how it is different from DC Fabric topology model 
defined in RFC8542?

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Robert Varga
发送时间: 2019年8月28日 7:44
收件人: Dmytro Shytyi ; netmod 
主题: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group 
document.

On 27/08/2019 18:03, Dmytro Shytyi wrote:
> Dear All,
> 
> I am one of the authors of ID VYSM and I would like to draw your 
> attention to the evolution of the draft 
> https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt.
> Recently we produced (but did not submitted yet) a new version of ID
> (02) and I beleive it fits the netmod working group.
> 
> We would be gratefull if you could suggest if the new version(02) of 
> the document  could become an official work item of the WG?
>       If yes, could you please indicate which modifications must be 
> done in the document before submition.

Hmm, looking over the model, it would seem there is quite a bit of overlap with 
RFC8345 -- to the point I believe the model could be formulated in terms of 
RFC8345 specialization:

virtualization -> networks/network

device/links/interfaces/switches/vms are probably a mix of 
node/termmination-point/link extensions with conjunction with 
supporting-{topology,node,link}.

How would the draft relate to RFC8345? Should it perhaps call out it is a 
different take on the similar problem, specialized to a particular use-case?

Regards,
Robert (with RFC8345 co-author hat on)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Robert Varga]

On 27/08/2019 18:03, Dmytro Shytyi wrote:
> Dear All,
> 
> I am one of the authors of ID VYSM and I would like to draw your
> attention to the evolution of the
> draft https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt.
> Recently we produced (but did not submitted yet) a new version of ID
> (02) and I beleive it fits the netmod working group.
> 
> We would be gratefull if you could suggest if the new version(02) of the
> document  could become an official work item of the WG?
>       If yes, could you please indicate which modifications must be done
> in the document before submition.

Hmm, looking over the model, it would seem there is quite a bit of
overlap with RFC8345 -- to the point I believe the model could be
formulated in terms of RFC8345 specialization:

virtualization -> networks/network

device/links/interfaces/switches/vms are probably a mix of
node/termmination-point/link extensions with conjunction with
supporting-{topology,node,link}.

How would the draft relate to RFC8345? Should it perhaps call out it is
a different take on the similar problem, specialized to a particular
use-case?

Regards,
Robert (with RFC8345 co-author hat on)



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

[Dmytro Shytyi]

Dear All,



I am one of the authors of ID VYSM and I would like to draw your attention to 
the evolution of the draft 
https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt.

Recently we produced (but did not submitted yet) a new version of ID (02) and I 
beleive it fits the netmod working group.



We would be gratefull if you could suggest if the new version(02) of the 
document  could become an official work item of the WG?

      If yes, could you please indicate which modifications must be done in the 
document before submition.



After reading the https://tools.ietf.org/html/rfc2026 it seems the document may 
fit multiple different "Intended statuses". Currentry it has "Informational" 
intended status. Could you please express your suggestion: which intended 
status is more appropriate for the current document? Shoult it be Experimental 
or BCP?



Thank you for your time.



Best Regards,

__
Dmytro SHYTYI









 Forwarded message 
From:  
To: "Dmytro Shytyi"
Date: Thu, 28 Mar 2019 12:24:35 +0100
Subject: New Version Notification for draft-shytyi-netmod-vysm-01.txt
 Forwarded message ==







A new version of I-D, draft-shytyi-netmod-vysm-01.txt 
has been successfully submitted by Dmytro Shytyi and posted to the 
IETF repository. 
 
Name:draft-shytyi-netmod-vysm 
Revision:01 
Title:Virtualization YANG Servise Model (VYSM) 
Document date:2019-03-27 
Group:Individual Submission 
Pages:9 
URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt 
Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/ 
Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-01 
Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm 
Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-01 
 
Abstract: 
 This document provides a specification of the Virtual Network 
 Functions YANG Service Model (VYSM).  The VNF YANG Service Model 
 serves as a base framework for managing an universal Customer- 
 Premises Equipment (uCPE) NFV subsystem from the Orchestrator.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Vladimir Vassilev]

On 22/08/2019 12.13, Rob Wilton (rwilton) wrote:


Hi Vladimir,

Thanks for your detailed review.  Sorry for the slow reply, I've been away.  
I'm also about to be away again for a couple of days.

Please see my comments inline ...

I'll also track these issues to closure on 
https://github.com/netmod-wg/interface-extensions-yang/issues


-Original Message-
From: netmod  On Behalf Of Vladimir Vassilev
Sent: 13 August 2019 17:05
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

I have reviewed the draft. I have the following (19) IMO useful proposals:

1. Dedicated module (ietf-if-oper-status-debounce.yang) for the oper-
status debouncing/dampening functionality currently in ietf-interfaces-
common.yang.

I don't think that we want a proliferation of too many separate YANG modules 
for small features.  Each of the areas of different functionality within this 
module are already conditional on if-feature, so I don't think that there is a 
strong justification to separating this out as a separate module.


I still think that especially the "dampening" mechanism is not common 
enough and is quite complex to be added to ietf-interfaces-common. If a 
feature is not common or does not enable the use of generic modeling 
mechanism (like sub-interfaces etc.) it should not be in 
ietf-interfaces-common. I do not think "dampening" (maybe at some point 
we should go back to damping instead e.g. rfc2439 ... seems there is 
difference between dampening and damping and damping seems to be the 
correct one) is that common to deserve a place in ietf-interfaces-common.





2. In sec "3.1 Carrier delay" use of the under-defined "Carrier"
definition can be replaced with direct reference to the oper-status leaf
(which is what is actually targeted by the algorithm) "Operational status
transition debouncing".

I think that different vendors have different names for this technology.  I've 
just used the one that our products use.  I think that this is just a name, 
rather than something that has to be defined.  I could add a comment that this 
feature is sometimes called hold time?


I looked for precedents -  "carrier-delay" leaf Cisco, 
"debouncing-interval" leaf Juniper, "interface-phys-holdtime-config" 
leaf OpenConfig.


I think "Carrier" is confusing since what is delayed actually is the 
transition of the oper-status.



3. "timer-running" and "suppressed" leafs are both "config false" and have
"default" statements. Although this is valid YANG I do not think the
"default" statements are intended.

I think that this is a more general question that needs a bit more discussion.  
Here, I am using defaults for the config false node to document what the normal 
value is expected.

Well not a real issue but I thought it was an unusual use of default.




4. Dedicated module (ietf-if-loopback.yang) for the loopback functionality
currently in ietf-interfaces-common.yang.

Same answer as for 1. I don't think that we should have too many really small 
modules.
If the loopback was modeled as a boolean leaf (as in OpenConfig) I would 
have agreed. However even small modules that define base identities 
benefit from dedicated namespace. For me ietf-if-loopback.yang will pay 
off since loopback='internal' is better then 
loopback='loopback-internal' and there are going to be many test cases 
that use that line. An last but not least I never had problems with too 
much modularity.



5. Less verbose loopback identities. With dedicated module the
(loopback-* identities can be shortened skipping the prefix).

I think that it is normal to bind the identity names to the common base 
identity.  I don't see that the length of the identities should really be an 
issue.
For me the length of identities does matter since I often use command 
line tools. But it is mostly the irritation caused by the tautology 
loopback='loopback-internal' that everyone writing network interconnect 
testcases is going to be stuck with forever if we leave the loopback 
control model as part of ietf-interfaces-common and not separate 
ietf-if-loopback. What do others think?



6. The draft introduces "loopback-internal", "loopback-line" and
"loopback-connector" loopback identities. What is confusing is that
"internal loopback" is historically the opposite of "external loopback"
which is a loopback with a connector. I think terminology already in use
like "near-end" and "far-end" is less confusing.

The internal/line loopback configuration has been used in parts of the industry 
for at least 20 years, so this terminology is already in use.

I'm not sure that "near-end" and "far-end" would be less confusing.  Assuming that "loopback 
far-end" was equivalent to "loopback-line" then it would be somewhat of a misnomer since it acts on the 
near end, not the far end.

I.e. both loopback internal, and loopback line act on the local interface, the only 
difference is in which direction they reflect the