Re: [i2rs] WG Adoption call for draft-hares-i2rs-service-topo-dm-04 (1/26 to 2/9/2015)

["Susan Hares" <[e-mail]>]

Michael: 

 

Thank you for your patience in responding.  Your comments were very helpful.
I have responded inline, and revised the draft.  I would appreciate your
comments on the draft.   In future drafts, may I acknowledge your helpful
comments by including you in the "acknowledgement" section. 

 

The new draft is at: 

     https://datatracker.ietf.org/doc/draft-hares-i2rs-service-topo-dm/

 

Sue 

 

From: i2rs [ <mailto:[e-mail]> mailto:[e-mail]] On
Behalf Of Scharf, Michael (Nokia - DE)
Sent: Monday, February 01, 2016 7:30 AM
To: EXT Susan Hares;  <mailto:[e-mail]> [e-mail]
Cc: 'Jeffrey Haas'; 'Alia Atlas'
Subject: Re: [i2rs] WG Adoption call for draft-hares-i2rs-service-topo-dm-04
(1/26 to 2/9/2015)

 

I think there are major open issues in this I-D . As a result, IMHO further
work would be needed prior to WG acceptance.

 

A summary of my comments are listed below. Sorry if I should have missed
something.

 

Michael

 

 

 

General comments

 

* To me the scope of the document is unclear. The abstract uses the term
"composite layer", but that term is neither defined nor referenced. It is
unclear what a "buttons-up" approach would imply, e.g., for a L3VPN, and the
document also does not describe what "node", "link", and "termination
points" actually shall refer to according to this I-D. Based on the current
I-D, it is not clear to how this document relates e.g. to the L3SM WG.

 

==============

Sue's Response: 

Scope: The scope of this document is a "bottoms-up" composite of several
L3VPN, L2VPN, EVPNs, and other IP-VPNs.   Each of these will eventually have
other service modules: L2SM, EVPN-SM, and SFC service models.   

 

You need the bottom up topology parts (links, support) in order to combine
the topologies which can then support indicates of: 

a)      L3SM topology type (any-to-any, hub-spoke, hub-spoke disjoint) that
overlay on the topology link 

b)      Cloud ID  + Sites* [id] within Clouds: specific topologies and
access points. 

c)       Multicast trees

d)      Transport 

 

If you look at the L3SM, it has at the top levels, it does not have a level
which easily fits on top of L1, L2, and L3 levels to support combining L3
Topology levels: 

 

The L3SM high level yang is: 

 

+--rw vpn-svc* [vpn-id] 

|  +--rw customer-name? 

|  +--rw topology identityref   [any-to-any, hub-spoke,  hub-spoke-disjoint]

|  +--rw cloud-access

|  |  +--rw sites 

|  | . 

|  +--rw multicast 

|  | . 

|  +--rw mpls

|  +--rw transport-constraints 

+--rw sites 

|   +--

+--rw site-templates 

 

The vpn-svc, cloud-access and sites provide topology at a high layer.  

 

This topology will have attributes of: topology (any-to-any, hub-spoke,
hub-spoke disjoint), multicast, mpls, and transport constraints as a service
topology attribute, you can create a high-level service. 

It's nodes (sites) will link to the bottoms-up composite service topology
nodes (overlapping on the L3VPN topology).  Therefore, using the generic
model - you can link the higher level service topology (L3SM) to the
composite bottoms up service topology by considering the composite service
topology as supporting links.

 

You can link these to a composite bottoms-up service topology (e.g. L3VPN
topology) by understanding which of the bottoms-up topology can support the
attributes required.  I added attributes that will help the upper L3SM
topology know which parts of the composite "bottoms up" service topology can
support the L3SM topology. 

 

  L3SM-topology 

     | (not there) 

=========  

  [socket] 

  I2RS Bottoms up 

Service Topology

 

To make this clearly, I've released -06.  

 

=======================

 

* At least one application example would be needed to actually understand
the use of the proposed model. The document claims to be applicable to
"L3VPN, L2VPN, EVPN, E-Tree, and others". I think the document should have
examples that show how to apply the YANG model to one or more of those
services.

 

Good point.  I've added the L3SM and the L3VPN example.  

 

* The YANG model spec and documentation is inconsistent and partly confuses
me. I struggle with understanding how key objects would actually have to be
implemented. One key problem is that the high-level introduction in Section
2 is not consistent with the actual YANG data model. For instance, Section 2
introduces an object "flag" that is not used elsewhere. Also, the intended
use of the object "composite-flags" is not consistently explained. Instead
of just listing the YANG tree representation, I think this I-D would require
a more comprehensive introduction of how "services" shall really be modeled
according to this I-D. In addition, in several cases the specific YANG
modeling design choices are not motivated. Examples: Why is "node-count"
really needed? What is an "unnumbered link address"? Unfortunately, the
actual descriptions of objects in the YANG data model often so not provide
much further insight. Further examples for such issues can be found below.

 

In previous versions, I describe these features with SFC, but people felt
the level of details was not appropriate.  I've check all the flags to see
these are used by compiling the service-topology.   I've also removed
node-count, unnumbered link, and anything other than identifying attributes.


 

Selected comments on the YANG model - this list is not comprehensive, as I
gave up at some point

 

* Why do identifiers use the type "uint32"?
draft-ietf-i2rs-yang-network-topo-02 uses type "inet:uri", and it includes a
discussion that "string" might also be appropriate.
draft-ietf-l3sm-l3vpn-service-model-02 uses "string". I really wonder why
yet another ID type is needed. 

 

I've removed any identifiers with type uint32.  I've used "strings" to be
generic. Upon review we can move some of these to inet:uri if it is
appropriate. 

 

* Page 6: It is unclear how existing VPN technologies would be mapped to the
currently defined identities in "l3vpn-svc-topo". For instance, are E-LAN or
E-Pipe mapped to L2VPN? And is E-Tree not a L2VPN? Other identities are not
rigorously defined, e.g., "I2rs-svc-topo".

 

Yes - I agree that the link downward is vague.   I had linked it to specific
XXVPNs, but people wanted me to stay at the high level until these other
yang modules were firmed up.   We can then pick whether L2VPN contains EVPN
and E-LAN and E-PIPE, or if there is a different break-out.  I welcome the
discussion.  The current mechanism were left vague to allow alignment with
the moving MPLS and BESS specification.  If we can agree we will align with
this drafts, I am willing to go on. 

 

* Page 7: There is both an "identity service-topology-types" and a "grouping
service-topology-types", even with exactly the same description. This is
really confusing.

 

Please see the netmod yang 1.1 identity and grouping mechanisms.  These are
means to provide essentially "enums" that support this topology.   I've
added description in the XML draft.  Please let me know if this helps the
confusion. 

 

* Page 8: What is the purpose of "domain-name" in a node? How would this
e.g. be set in a L2VPN?

 

This has been removed. 

 

* Page 9: What is the intended semantics of "metric" in links? Would it not
make sense to refer e.g. to draft-ietf-teas-yang-te-topo?

 

Yes.  I've included text to indicate this is the "metric" at the service
level.  It is not clear if the teas-yang-te-topo really deals with above
L3VPNs and L2VPNs.  I've not included it in -06, but I will ask the TEAS DT.


 

* Page 11: What is the purpose of augmenting node by a "leaf-list next-hop"?

This has been removed.  Other people mentioned this issue. 

 

* Page 11/12: "/nw:networks/nw:network/nw:node" is apparently augmented two
times. This is confusing as the two augmentations even seem to overlap,
e.g., by a leaf "name" and a leaf "domain-name" both of type
"inet:domain-name".

 

Yes, this was in error. 

 

Selected editorial nits

(Thank you for the nits.  I will revise these in the next version. 

 

* Section 1: I cannot parse "The virtual service topology is a composite
summary of the services available services gathered from the lower layer
indications of ..."

 

* There are numerous indention issues in YANG figures, also in Section 2.1
and Section 2.2.

 

* There seem to be various spellings for the same concept: "composite-flag",
"composite_flag", "composite-flags"

 

* Page 6: The identity "Etee-svc-topo" is described as "Seamless MPLS
service type"

 

* Page 7: "leaf service-type" is described as "list of..."

 

* Page 9: s/currewntly/currently/

 

Hopefull, I've caught all these spelling issues. 

 

Thank you for all the comments. 

 

From: i2rs [ <mailto:[e-mail]> mailto:[e-mail]] On
Behalf Of EXT Susan Hares
Sent: Tuesday, January 26, 2016 3:58 PM
To:  <mailto:[e-mail]> [e-mail]
Cc: 'Jeffrey Haas'; 'Alia Atlas'
Subject: [i2rs] WG Adoption call for draft-hares-i2rs-service-topo-dm-04
(1/26 to 2/9/2015)

 

This begins a 2 week WG adoption call for
draft-hares-i2rs-service-topo-04.txt.  

 

https://datatracker.ietf.org/doc/draft-hares-i2rs-service-topo-dm/

 

The service topology model is a bottoms-up protocol independent model 

  model that combines protocol-dependent service layers.  Protocol-dependent
services

   layers include: L3VPN, L2VPN, EVPN, E-Tree, and others.

 

Please indicate in your response if you feel this direction "bottoms-up" is
a good way to approach the service layer rather than the top-down of
attaching this layer to service models (E.g. the L3SM model).  As always,
indicate if this draft is a good start for the service topology yang model. 

 

Sue Hares and Jeff Haas