Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-yang-te-topo-16: (with COMMENT)

[Xufeng Liu <[e-mail]>]

Hi Benjamin,

Thanks for providing valuable comments, and pointing out several errors in
the draft.  We have posted an undated version
*https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-17
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-17>*. Please check
the updated draft.

Best regards,
- Xufeng

On Wed, Jun 6, 2018 at 4:39 PM Benjamin Kaduk <[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-teas-yang-te-topo-16: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to Alvaro for pointing out the specific considerations on the
> geolocation variables.
>
> This document has a large number (6) of authors;
> https://www.rfc-editor.org/policy.html#policy.authlist implies that
> justification is needed for more than 5 authors.
>
> Section 3.4
>
> I'm confused why the transitional TE link disappears once a normal
> TE link abstracting away the layer transition appears -- is there no
> longer potential to do layer transition at that node (e.g., to take
> a different path in the server layer network) once a layer
> transition is in use?
>
[Xufeng]: Right. That is the case.


> Section 8
>
> I'm not sure I understand why the te:templates tree is not called
> out as "sensitive" -- is it just the "template" nature?  Lots of
> these look like things that could have detrimental impact if
> modified in an actual live instance -- ID, bandwidth, type, etc., so
> I mostly assume that it's just the templatey-ness, but don't quite
> understand how that works.
>
[Xufeng]: You are right. The templates tree is “sensitive”. Because
the templates are located together under /nw:networks/tet:te, we do
not list each template separately. They are mentioned in the section
of /nw:networks/tet:te, which contains all templates.


> There are a number of places where editorial attention would be
> beneficial; I
> only noted a small subset of them.  One recurring theme is "<foo> is
> assigned
> with the <bar>  unique ID", which might be more clearly phrased as "A
> <foo> is
> assigned a unique ID within the scope of <bar>".  Some other specific items
> follow.

[Xufeng]: Edited these occurrences.


> Section 1
>
>    [...] There could be one or more TE Topologies present in a given
>    Traffic Engineered system. The TE Topology is the topology on which
>    path computational algorithms are run to compute Traffic Engineered
>    Paths (TE Paths).
>
> nit: If there could be more than one, it seems grammatically
> improper to use the definite article "the" (without further
> qualification) to refer to them.
>
[Xufeng]: Changed “the” to “a”.


> Section 1.1
>
>    Customized TE Topology: Customized TE Topology is a custom topology
>    that is produced by a provider for a given Client. This topology
>    typically augments the Client's Native TE Topology. Path
>    computational algorithms aren't typically run on the Customized TE
>    Topology; they are run on the Client's augmented Native TE Topology.
>
> This text doesn't really help me tell the difference between the
> "Client's augmented Native TE Topology" and the "Customized TE
> Topology", which is the Client's Native TE Topology plus some
> unspecified augmentation (that is apparently different from the one
> used for path computation).
>
> [Xufeng]: Reworded this section to clarify. We also use another document, *https://tools.ietf.org/pdf/draft-ietf-teas-te-topo-and-tunnel-modeling <https://tools.ietf.org/pdf/draft-ietf-teas-te-topo-and-tunnel-modeling>*, to describe such terminologies, model usages, and examples in more details.

Section 2
>
>    - Each TE Topological element has an information source associated
>      with it. In some scenarios, there could be more than one
>      information source associated with each topological element.
>
> editorial: I'd suggest replacing the last "each" with "any given",
> and maybe "has an" with "has at least one".
>
> [Xufeng]: Edited as suggested.

Section 3.3
>
>    TE link is an element of a TE topology (presented as an edge on TE
>    graph, arrows indicate one or both directions of the TE link).
>
> (I don't see any arrows in Figure 1.)
>
[Xufeng]: Clarified that an edge without arrows indicates a pair of
links of opposite directions.



>    [...] TE link
>    is connected to TE node, terminating the TE link via exactly one TE
>    link termination point (LTP).
>
> Even unidirectional links have a source and destination; presumably
> both of those are attributes of the TE link?  Perhaps "for any given
> node" should be more explicit?
>
[Xufeng]: According to the model defined in RFC8345, the link
termination point is not an attribute of the link, but a separate
entity on the node. When a link is specified, the source node, source
termination point, destination node, and destination termination point
are associated with the link. The model in this document augments the
model in RFC8345, and therefore inherits the same characteristics.


> Section 3.8
>
>    [...] From the point of view of
>    a potential TE path LLCL provides a list of valid TE links the TE
>    path needs to start/stop on for the connection, taking the TE path,
>    to be successfully terminated on the TTP in question.
>
> nit: this could probably be reworded to be more clear, maybe:
>
> %  From the point of view of usability in creating a TE path, the LLCL
> %  provides a list of the TE links that would be valid path components
> %  for paths involving the TTP in question.
>
> [Xufeng]: “From the point of view of a potential TE path” is meant to say that an LLCL can be viewed as a potential path. We don’t let user to create a TE path here, and the usability would not be relevant. From this perspective, a potential TE path  is from the TTP to one TE link. Since the TTP can potentially connects to many such TE links, there is a list of such entries, each of them is a link that can be potentially connected. The document *https://tools.ietf.org/pdf/draft-ietf-teas-te-topo-and-tunnel-modeling <https://tools.ietf.org/pdf/draft-ietf-teas-te-topo-and-tunnel-modeling>* describes some such examples.

Section 3.10
>
>    is unique across all TE topologies provided by the same provider.  The
>    client layer LIPs and the server layer TTPs associated within a given
>
> Should that be "LTPs" instead of "LIPs"?
>
[Xufeng]: Yes. Thanks for noticing. Fixed.


> Section 4.4
>
>    [...] maintain. For example, in addition to the merged TE topology
> depicted
>    in the upper part of Figure 1, the client may merge the abstract TE
>
> Figure 1 was long ago and does not seem relevant.  Was this supposed
> to be Figure 9 or Figure 10?
>
[Xufeng]: Right. It should be Figure 9. Fixed


> Section 7
>
>      grouping connectivity-label-restriction-list {
>        description
>          "List of abel restrictions specifying what labels may or may
>           not be used on a link connectivity.";
>        list label-restriction {
>          key "index";
>          description
>            "List of abel restrictions specifying what labels may or may
>             not be used on a link connectivity.";
>
> presumably "label" rather than "abel" (twice)?
>
[Xufeng]: We have removed this grouping in this model, and re-used an
equivalent grouping in te-types, specified in
*https://tools.ietf.org/html/draft-ietf-teas-yang-te-15
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-15>*. The typo
has been fixed there.


> Another typo -- "speficied" for "specified" (also twice).
> And "souruce" for "source" (twice)
>
[Xufeng]: Fixed.


> Appendix C
>
> Are there really supposed to be 63 occurrences of the string
> "Attribute 11 for example technology" (i.e., with no "Attribute 1",
> "Attribute 2", etc.)?
>
[Xufeng]: These should be either “Bancwidth 1”, or “Label 1”. Fixed.