Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-yang-te-topo-16: (with COMMENT) Sat, 07 July 2018 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65EC01274D0; Sat, 7 Jul 2018 11:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yVYfn-d4AStV; Sat, 7 Jul 2018 11:46:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07DF0130E99; Sat, 7 Jul 2018 11:46:48 -0700 (PDT)
Received: by with SMTP id k81-v6so29249429oib.4; Sat, 07 Jul 2018 11:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version; bh=iXeMXrQ7hApsVui77WbQTYchZT2Ghej0+a6aPUYvUu0=; b=YpkuumDuxVCA/K+dlfUY8LQB9xEjOEEABl/+UOMAfyrKJ4kbfBZQeZwxqgcxK/dLn4 vzblt29k9Ydbby7/CU5gBPQPmpdD99ZXa/PQ1LlFNTZztdoNLL4XK8aZFt9nt70/Fq4b 0vqdu2LiHF5rwliwvktrpOWBmHFeXKu5GK00PFczLM26NuY09shhp9VKSDFy3pXn0q3M 9M1EINpFLyqpsRqD9+uzRH4uDZEZBt4H3Vf85VxhKK5lnTyTBosYkDc/yYkkMbCXOGUh tm2APv92X6mQ9zn1Lsv+qbAHLrrUVFGjN6bQ89yEvOkIr52+2z8BK2FMgAKSOeSKUrxt LeXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version; bh=iXeMXrQ7hApsVui77WbQTYchZT2Ghej0+a6aPUYvUu0=; b=ODOvyjrRFU9W729KniPi/a8UV/mUvCT+5Ju498xRS9Ja/vrRAitsnsFLX9eXqVnovm iADlAcF5xjgFIYP7ySLen5MHTioDkY7NbN4QC50I2h+2xO1b9YBUloSniIHXqBYpu8wb jxx8vvz3fbUeCzj1vRWjF3bQ5FG3GI70bwRyGD0L0TfflWA6vCU+9MO04zTvIvlpZYlE TOg6JDVilnPWBwv4Ef54rhKPUvzEk/SjTMIuMu4td7Xvzakgf83ptRM0L34SWCiJIDEe 7YfK2WW7rxOnZ4twvF8fi18P4+DOgM5Bldn2H8hY7Le53RtijjmCfngj6ldBdMmitzdg Zy+Q==
X-Gm-Message-State: APt69E0BXkHctGT8iaWS8M9Z+B3KHQiEFr6F2o4ZdL1j8ESsUCPNa05k b7E/IUVxF9vem/4hJJNSJis=
X-Google-Smtp-Source: AAOMgpfiHotkIO9TPRSg80pqz77IzPT7r2D83SFwyZ/IZazrg0wld+/G0aFmZJ7Vd5djgG9J4Swkwg==
X-Received: by 2002:aca:42:: with SMTP id 63-v6mr15160170oia.154.1530989207177; Sat, 07 Jul 2018 11:46:47 -0700 (PDT)
Received: from tiger ( []) by with ESMTPSA id k133-v6sm7407314oia.36.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 07 Jul 2018 11:46:46 -0700 (PDT)
Message-ID: <>
To: Benjamin Kaduk <>
Cc:,, Lou Berger <>, TEAS WG Chairs <>, TEAS WG <>
Date: Sat, 07 Jul 2018 14:46:44 -0400
In-Reply-To: <>
References: <> <> <>
Content-Type: multipart/alternative; boundary="=-jeQluVe6Bw1bpzMamzSN"
X-Mailer: Evolution 3.28.1-2
Mime-Version: 1.0
Archived-At: <>
Subject: Re: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-yang-te-topo-16: (with COMMENT)
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Jul 2018 18:46:51 -0000

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
> *
> <>*. 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 <> 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, * <>*, 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 * <>* 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
   path to pass through. The selected TE link takes the TE path
   to be successfully terminated on the TTP in question.

> Thanks,
> Benjamin