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

[[e-mail]]

Hi Benjamin,

Thanks for the further checking. We will take you advice and work with
the RFC Editor to reword the two sections that you mentioned below.

Best regards,
- Xufeng


On Tue, 2018-07-03 at 21:22 -0500, Benjamin Kaduk wrote:
> On Sun, Jun 24, 2018 at 03:39:23PM -0400, Xufeng Liu wrote:
> 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.
> 
> Thanks for the updates, and sorry for the slow response.  I will trim parts
> from the quoted text that are well-resolved.
> 
> Best regards,
> - Xufeng
> 
> On Wed, Jun 6, 2018 at 4:39 PM Benjamin Kaduk <[e-mail]> wrote:
> 
> 
> 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.
> 
> Ah, thanks for the clarification.
> 
> 
> 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.
> 
> Thanks, this helps me a lot.
> 
>    [...] 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.
> 
> RFC 8345 says "Accordingly, a link contains a source and a destination.
> Both source and destination reference a corresponding node, as well as a
> termination point on that node."  That is, the source of the link gets a
> LTP, and the destination of the link gets a (different) LTP.  So a given
> link has two LTPs, one for source and one for destination, right?  What I
> am trying to say here is that a TE link is terminated with exactly one LTP
> on the destination node, and is also terminated with exactly one LTP on the
> source node.  But if I just say that a TE link is terminated with exactly
> one LTP, what does that mean?  Is it talking about the source or the
> destination?  What happens for the other end of the link?  Saying that "A
> TE link is connected to a TE node, terminating the TE link via exactly one
> TE link termination point (LTP) on that node" would resolve these
> questions, for me.  (That is, just adding "on that node" and some grammar
> tweaks.)
> 
[Xufeng]: We will add "on that node" to the sentence. The above paragraph has accurately describes the relationships between nodes, LTPs and links. 
> 
> 
> 
> 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.
> 
> My main concern here is that grammatically, this sentence is just very hard
> for me to parse.  I don't have a strong attachment to any particular
> rewording, but I think there is a lot of improved clarity that could be
> obtained by some rewording.  I now understand, after a lot of thinking
> (well, I think I do; it's been some time since I read this draft) that the
> LLCL is a list of TE links that are terminated by the TTP.  In order for a
> connection to use the TTP-hosting TE node, the TE path needs to start or
> stop on one of the links in the LLCL; if it doesn't, then the TTP in
> question is not usable for that TE path.  I think there are better ways to
> write a sentence to convey that information, and I think it's more likely
> to remain accurate if you supply the rewording than if the RFC Editor
> supplies the rewording.

[Xufeng]: The understanding is accurate. We will reword the section. If
you have suggestions, please let us know.  What about:
   From the point of view of
   a potential TE path, LLCL provides a list of valid TE links for the
TE
   path to pass through. The selected TE link takes the TE path
   to be successfully terminated on the TTP in question.

> 
> Thanks,
> 
> Benjamin
>