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

Benjamin Kaduk <kaduk@mit.edu> Wed, 04 July 2018 02:22 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5060130E31; Tue, 3 Jul 2018 19:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdjyjSzOf3Ab; Tue, 3 Jul 2018 19:22:49 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81092127598; Tue, 3 Jul 2018 19:22:48 -0700 (PDT)
X-AuditID: 1209190c-ecdff70000003cc8-45-5b3c2f76efc7
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 28.40.15560.67F2C3B5; Tue, 3 Jul 2018 22:22:46 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w642Mjrb012448; Tue, 3 Jul 2018 22:22:45 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w642MekP012913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2018 22:22:43 -0400
Date: Tue, 3 Jul 2018 21:22:40 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: iesg@ietf.org, draft-ietf-teas-yang-te-topo@ietf.org, Lou Berger <lberger@labn.net>, TEAS WG Chairs <teas-chairs@ietf.org>, TEAS WG <teas@ietf.org>
Message-ID: <20180704022237.GC60996@kduck.kaduk.org>
References: <152831756015.6220.551593327209091162.idtracker@ietfa.amsl.com> <CAEz6PPSTAPUnupwpG8GvVx3tsY2MdneHYQB6t_j9TZg+1OfvYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAEz6PPSTAPUnupwpG8GvVx3tsY2MdneHYQB6t_j9TZg+1OfvYg@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixG6nrlumbxNt8PG1usXPXf+YLWb8mchs 0dH8lsWiae4uJovWHztYLK4c/8PkwOaxc9Zddo8lS34yeXzY1MwWwBzFZZOSmpNZllqkb5fA lXHx7Rr2gnkGFTc3n2dpYNyn1sXIySEhYCIxY/l/li5GLg4hgcVMEr9Wn2WDcDYwSnyed4Md wrnCJDGlYwczSAuLgIrE10ndbCA2G5Dd0H0ZLC4ioCXxr3MD2ChmgZWMEi9+7GAESQgLxEt8 nnWGqYuRg4MXaF/D5gKIoZMYJVa8fMEOUsMrIChxcuYTFhCbWUBd4s+8S8wg9cwC0hLL/3FA hOUlmrfOBtvFKRAose7vabByUQFlib19h9gnMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3c xMyc4tRk3eLkxLy81CJdQ73czBK91JTSTYygWOCU5NnBeOaN1yFGAQ5GJR5ehgrraCHWxLLi ytxDjJIcTEqivPIbgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO/9AsrxpiRWVqUW5cOkpDlY lMR5sxcxRgsJpCeWpGanphakFsFkZTg4lCR4PfRsooUEi1LTUyvSMnNKENJMHJwgw3mAhqfo AtXwFhck5hZnpkPkTzHqcvx5P3USsxBLXn5eqpQ4rzvIIAGQoozSPLg5oBQmkb2/5hWjONBb wrwrQKp4gOkPbtIroCVMQEt6tlmCLClJREhJNTAqLmPIbXsr3vNMvd75eoPmrDv/XzU4bWFb 5fPr3f7Am3Ouis5Tfbt65b6PHmeyvTXmCiX9WW6tcKVw3Wn38D6FGvNtWmsMN/MLdi8wXC93 zmzDQ2/xCR/7AiPzfLPObRe7kcL7LmFiuKDmrmK39V3ez3ZH50d8Wqx/6SHfnLd/9nKGG9y9 mfZYiaU4I9FQi7moOBEAlTfEfTwDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/oj13i5YMV6Lgp4N32m_IjzRw4xs>
Subject: Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-yang-te-topo-16: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 02:22:52 -0000

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 <kaduk@mit.edu> 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