Re: [i2rs] [yang-doctors] Yangdoctors early review of draft-ietf-i2rs-yang-l3-topology-10

[Kent Watsen <[e-mail]>]

Lada, did you link the right article?  The linked article is entitled  “Getting involved with M”...

PS: please excuse my company’s URL mangler  ;)
K.

Sent from my iPhone

On Nov 14, 2017, at 10:58 PM, Ladislav Lhotka <[e-mail]<mailto:[e-mail]>> wrote:

Hi Sue,

please see my responses inline.

Susan Hares <[e-mail]<mailto:[e-mail]>> writes:

Lada:

During your review of the draft-ietf-i2rs-yang-l3-topology-10.txt, you
raised the following issues.  As part of the shepherd's review of
draft-ietf-i2rs-network-topo-14, I have investigated the resolution.
I found that these comments have not be resolved.  Could  you review this
email to see if it resolves the questions on
draft-ietf-i2rs-network-topo-14?   The current draft is
draft-ietf-i2rs-network-topo-14.txt.

The suggest changes below would go into draft-ietf-i2rs-network-topo-17.

Thank you, Susan Hares



*** Comments to draft-ietf-i2rs-yang-network-topo-14:

1. With YANG 1.1, the network type information looks like a perfect
  candidate for identities (with multiple inheritance). Instead, it
  is modelled with presence containers, which is cumbersome and
  redundant. I don't see any reasons for doing so, if there are any,
  then they should be explained in sec. 4.4.8.

Suggested text:
[This topology model utilizes presence containers in order to support
correlated topologies.
While identities (with multiple inheritance), might be used to support these
network
topologies - it would prevent the support of network topologies.]

I don't know exactly what "correlated topologies" mean but multiple
inheritance of identities should allow for representing multiple
orthogonal aspects in the same identity. In fact, the creative use of
containers in the I2RS topology draft motivated me to propose multiple
inheritance of identities for YANG 1.1. On the other hand, there is
nothing wrong with using the containers, it is just more verbose.


Question: Do you agree with Robert's comment below, and this resolution to
the text.

2. The document defines "supporting network" and then says "A
  supporting network is in effect an underlay network." In the
  subsequent text "underlay network" is used almost exclusively. So
  perhaps the term "supporting network" should be dropped altogether?

Response:  These terms have specific in the body of work that the TEAS WG
has.
See section 2 and section 5.8 in draft-ietf-teas-yang-te-topo-13.txt for the
use of overlay/underlay
terminology.  Your comment points out that we have a common understanding
in the I2RS and the routing-area's understanding of TEAS topology.

Suggested text addition:
[draft-ietf-teas-yang-te-topo-13.txt] provides a description of supporting
network
and underlay network in sections 2 and section 5.8 for traffic engineering
topology. ]

OK, I didn't know the context.



3. The text should be better aligned with the terminology of
  draft-ietf-netmod-revised-datastores. In particular,
  "system-controlled" should be used instead of "server-provided".

"server-provider has been removed" by version 17.

Good.


4. Is it necessary to use URIs for identifying all objects in the
  data model. URIs are difficult to use, so applications are likely
  to introduce some abbreviations and keep an internal mapping, which
  could cause problems, e.g. when matching objects in notifications
  with a GUI representation. In my view, it should be sufficient to
  use URIs for network-id and plain strings for other IDs, because
  all other objects are encapsulated inside a network, so their name
  conflicts shouldn't matter.

Response: Lada - Robert Wilton feels this choice is a design preference
as do the authors.  Please review the message below, and determine if
you wish to discuss this further.

URIs are no silver bullet for unique naming, and quite often thay can be
substituted by simpler means, perhaps using DNS information, if it is
available.

In my view, URIs would be OK as long as human users are not exposed to
them (I don't know if it is going to be the case or not). Anyway, this
blog post by James Clark about the use of URIs as namespace identifiers
in XML was quite an educative reading for me:

https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.jclark.com_2010_01_xml-2Dnamespaces.html&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=TdVg3bDUmf49jN3l0uRAR_G5EH4FnohUc8FZ0zc05-k&e=

Thanks, Lada


Sue Hares

-----Original Message-----
From: Alexander Clemm [mailto:[e-mail]]
Sent: Monday, November 13, 2017 9:54 PM
To: Róbert Varga; Susan Hares
Cc: Alexander Clemm; [e-mail]<mailto:[e-mail]>; Xufeng Liu; Jan Medved (jmedved);
Hariharan Ananthakrishnan; 'Nitin Bahadur'
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-11.txt

Thanks for your feedback, Robert!
--- Alex

-----Original Message-----
From: Róbert Varga [mailto:[e-mail]]
Sent: Monday, November 13, 2017 7:08 PM
To: Alexander Clemm <[e-mail]<mailto:[e-mail]>>; Susan Hares
<[e-mail]<mailto:[e-mail]>>
Cc: Alexander Clemm <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Xufeng
Liu <[e-mail]<mailto:[e-mail]>>; Jan Medved (jmedved)
<[e-mail]<mailto:[e-mail]>>; Hariharan Ananthakrishnan
<[e-mail]<mailto:[e-mail]>>; 'Nitin Bahadur' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt

Hello,

The first issue is a problem, as it would make it impossible to
construct correlated topologies, which is a major ODL use case: 'I
want to see both OpenFlow and NETCONF view of my device state in one
place.'

The second issue is a matter of design preference -- using strings is
certainly possible, but it has the downside of being a flat namespace,
which does not have any semantic meaning outside of YANG model. With
URIs, the identifier is structured and it has an inherent property
that it is something someone somewhere may be able to resolve -- such
that a node's identifier can be turned into, say, RESTCONF URL to
access the management endpoint... I don't particularly care either
way, as the URI can be added as an augmentation where appropriate.

Regards,
Robert

-----Original Message-----
From: Alexander Clemm [mailto:[e-mail]]
Sent: Monday, November 13, 2017 2:27 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: Alexander Clemm <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
Xufeng
Liu <[e-mail]<mailto:[e-mail]>>; Jan Medved (jmedved)
<[e-mail]<mailto:[e-mail]>>; Róbert Varga <[e-mail]<mailto:[e-mail]>>;
Hariharan Ananthakrishnan <[e-mail]<mailto:[e-mail]>>; 'Nitin Bahadur'
<[e-mail]<mailto:[e-mail]>>
Subject: RE: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt
Importance: High


Hi Sue,

I apparently sent this message one day after Lada posted his review.
I  had thought I had responded earlier.

To my coauthors- Robert, Xufeng, Hari, Jan, Nitin:

There are two issues that Lada brings up:

- A request to move network type from presence containers to identities.
Implication is that this will no longer make it possible to have
topologies that are "hybrid" accommodating different types at the
same point in time.  Would that be an issue?
- A request to move identifiers from type URI to type string.  I
remember we had discussions on this in the past.  I believe having
URIs facilitated consistency/ referential integrity checking.  Any
strong feeling if all identifiers are moved to string?


Sue,

Is there anything else open beyond Lada's comments?

--- Alex

Looking at the items:

1. With YANG 1.1, the network type information looks like a perfect
  candidate for identities (with multiple inheritance). Instead, it
  is modelled with presence containers, which is cumbersome and
  redundant. I don't see any reasons for doing so, if there are any,
  then they should be explained in sec. 4.4.8.
<ALEX>
   .
I am not sure what Lada considers redundant.  The current
implementations are based on presence container, and people at the
time expressed preference for that.  (I have to dig up the
communication, probably quite a while ago.) One advantage of doing
it in the current way is that we could accommodate also "hybrid"
topologies.  I feel presence container is superior and more flexible
because of this reason.  However, I don't really care at this point.
Let me check with my coauthors if they would be okay; if Lada feels
strongly we can accommodate.  But I am really wary of yet more churn.

Here is the explanation we currently have:
Network types SHOULD always be represented using presence
  containers, not leafs of empty type.  This allows representation of
  hierarchies of network subtypes within the instance information.
</ALEX>

2. The document defines "supporting network" and then says "A
  supporting network is in effect an underlay network." In the
  subsequent text "underlay network" is used almost exclusively. So
  perhaps the term "supporting network" should be dropped altogether?

<ALEX>
Is this really an issue?  The wording worked fine so far.  We
certainly don't want to change the model here.
In the text it often talks about underlays in the sense of "underlay
topology".
This is an established term, more so than "supporting".
</ALEX>

3. The text should be better aligned with the terminology of
  draft-ietf-netmod-revised-datastores. In particular,
  "system-controlled" should be used instead of "server-provided".
<ALEX>
This has been addressed
</ALEX>

4. Is it necessary to use URIs for identifying all objects in the
  data model. URIs are difficult to use, so applications are likely
  to introduce some abbreviations and keep an internal mapping, which
  could cause problems, e.g. when matching objects in notifications
  with a GUI representation. In my view, it should be sufficient to
  use URIs for network-id and plain strings for other IDs, because
  all other objects are encapsulated inside a network, so their name
  conflicts shouldn't matter.

<ALEX>
We had various communications on this years ago.  Frankly, I don't
care
either
way.   Let me check with the coauthors.  I am not involved in any
implementation.  If people want string instead of URI, I can change it.
</ALEX>

*** Comments to draft-ietf-i2rs-yang-l3-topology-10

<ALEX> These have been addressed </ALEX>

5. The type of "router-id" should be "yang:dotted-quad" and not
  "inet:ip-address" because the latter means both IPv4 and IPv6
  address, possibly also with a zone index.

6. Both prefix and link attributes include the "metric" parameter. It
  should be explained what they mean. In the context of ietf-routing
  the option of including "metric" as a general route parameter was
  discussed and finally rejected because different routing protocol use
  metrics with different semantics and properties. I wonder if it is
  the same case here.

*** Formal issues and typos

7. Both documents should refer to draft-ietf-netmod-yang-tree-diagrams
  rather than describe the notation of tree diagrams in the text.

8. Sec. 7 in draft-ietf-i2rs-yang-l3-topology-10: s/moodel/model/

<ALEX> These have been addressed </ALEX>

-----Original Message-----
From: Alexander Clemm
Sent: Wednesday, September 27, 2017 1:10 AM
To: 'Susan Hares' <[e-mail]<mailto:[e-mail]>>
Subject: FW: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt

Hi Sue,

What are the next steps - is there anything else we need to do
from our side?

As mentioned, I believe all comments have been addressed,
including Benoit's, Kent's, and Ignas'.  Still hoping we can get
this closed before Singapore

Thanks
--- Alex

-----Original Message-----
From: Alexander Clemm
Sent: Tuesday, September 19, 2017 1:26 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: RE: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt

Hi all,

We posted new revisions to draft-ietf-i2rs-yang-l3-topology and
draft-ietf- i2rs-yang-network-topo today.

The updates to draft-ietf-i2rs-yang-network-topo are very minor
and basically limited to updating the security considerations per
comments from Benoit.

The updates to draft-ietf-i2rs-yang-l3-topology take comments
received from Ignas and others into account.  The OSPF example has
been moved into its own appendix; we have also removed the IS-IS
example as this did not appear really necessary.  In addition,
there are various minor text edits, for example to bring it up to
date with security considerations
templates etc.

--- Alex, Hari, Jan, Xufeng, Nitin, Robert

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of internet-
[e-mail]<mailto:[e-mail]>
Sent: Tuesday, September 19, 2017 12:09 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System
WG of the IETF.

       Title           : A YANG Data Model for Layer 3 Topologies
       Authors         : Alexander Clemm
                         Jan Medved
                         Robert Varga
                         Xufeng Liu
                         Hariharan Ananthakrishnan
                         Nitin Bahadur
   Filename        : draft-ietf-i2rs-yang-l3-topology-11.txt
   Pages           : 31
   Date            : 2017-09-19

Abstract:
  This document defines a YANG data model for layer 3 network
  topologies.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopology_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=e4nhHmx83mz_CfjZixUg_jpTiimD--X5oJQwNigZeRs&e=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopology-2D11&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=R84Hq4KDTeJ0oaup_ZpnQHkE2S3VQhnJmVlZgRR_16M&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopo&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=qQy1xD3vtFLzMj0CEEeejnwLir5jlW69q15MffGej_I&e=
lo
gy
-11

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopology&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=qyMDKPz7n_bVjmefj9AvYAMQ_XWI0bJmJxPI10kPvaA&e=
-1
1


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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=1LSwgdesNm5n9rGxEn9TCcMdUr1ARduyQ1qNLlDRiis&e=

_______________________________________________
i2rs mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2rs&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=j8lGTxKMellmv1ApX87GzFdKuSOrQBcE0xp2W6SIIXQ&e=

_______________________________________________
yang-doctors mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=3brt9jSI9QIP4ytEMqM_W_RvigMmB5gQDzVFEIucm38&e=

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
yang-doctors mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=3brt9jSI9QIP4ytEMqM_W_RvigMmB5gQDzVFEIucm38&e=