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

[Benjamin Kaduk <[e-mail]>]

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.)


> 
> > 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.

Thanks,

Benjamin