Subject: Re: [Teas] Status update on draft-ietf-teas-yang-l3-te-topo

From: Xufeng Liu <[email-masked]>
Date: Fri, 20 Nov 2020 18:02:39 -0500

Hi Tom,
Thank you much for your further comments. We have posted
https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-09,
hoping to address some of your comments below.

Thanks,
- Xufeng

On Tue, Jul 14, 2020 at 7:34 AM tom petch <[email-masked]> wrote:

> From: Xufeng Liu <[email-masked]>
> Sent: 13 July 2020 15:29
>
> Hi Tom,
>
> Thanks for further reviewing. We have posted an updated version
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-08.
> Some rewording has been made, with the hope of making the document more
> comprehensible. Please let us know for anything that is still confusing
> (for such an unconventional modeling approach).
>
> <tp>
> I still find some of the terminology in this a challenge.
>
> 2.1   o  The multiplicity of such an association is: 0..1 to 0..1.
> the following sentence suggests it is '1 to 0..1'
>
[Xufeng]: The next sentence describes the relation on an object, but such a
description is relevant only if such an object exists. When such an object
has not been created in the ietf-l3-te-topology, the corresponding layer 3
TE topology may already contain an object that can be potentially
associated with the to-be-created object. In this case, 0 in
ietf-l3-te-topology, and 1 in ietf-te-topology. Therefore, I’d say that
multiplicity is still 0..1 to 0..1.

>
> 'associated to the objects in a coresponding TE topology'
> 'a' suggests there can be more than one which the YANG does not seem to
> and 2.2.1 has 'the' not 'a'
>
[Xufeng]: Changed ‘a’ to ‘one’, hoping that “associated to the objects in
one corresponding TE topology" would avoid the possibility of “more than
one”.

>
> in passing 'associated with' and 'corresponding'
>
> '   Since ietf-te-topology augments ietf-network-topology defined in
> [RFC8345] [I-D.ietf-teas-yang-te-topo], the referenced leaf
>    /nw:networks/network/network-id identifies an instance of TE topology
>    by inheritance. '
> No and no!  ietf-network-topology is in one document so there should be
> only one reference or else the module name is wrong or ....
> And the referenced leaf does not identify an instance of TE Topology -
> it identifies a network of any type.  As the next sentence makes clear,
> this module has to ensure it is of the correct type and does so.
>
[Xufeng]: Reworded the section, trying to clarify the leafref relationship.
Please let us know if it is better.

>
> '   If the TE topology is congruent to the layer 3 unicast topology, the
>    above reference can still be used to specified TE parameters defined
>    in the TE topology model.
> I do not understand.  What parameters? I do not see any and if they were
> to be defined in TE Topology then they should not be specified here or
> anywhere else.
>
[Xufeng]: One example of the TE parameters is te-delay-metric. Such
parameters are defined in the TE Topology model. They are not specified in
l3-te-topology, but they can be configured in the corresponding te-topology
instance.

> s.2.2.2
> 'a node in the layer 3 TE topology may have a reference to the
> corresponding TE node.'
> perhaps clearer as
> 'a node in the layer  3 TE topology may have a reference to the
> corresponding node in the TE Topology.'
>
[Xufeng]: Yes. Reworded as suggested.

>
> s.2.2.3 s.2.2.4 ditto mutatis mutandi
>
[Xufeng]: Fixed too.

>
> More technically this I-D seems confused about prefix and inconsistent
> elsewhere
> .
> module
>      namespace "urn:ietf:params:xml:ns:yang:ietf-l3-te-topology";
>      prefix "l3tet";
> IANA
>    name:         ietf-l3-te-topology
>    namespace:    urn:ietf:params:xml:ns:yang:ietf-l3-te-topology
>    prefix:       l3te
>
[Xufeng]: Fixed the IANA section.

>
> YANG
>        container l3-te {
>          presence "Indicates L3 TE Topology";
>
>    augment /nw:networks/nw:network/nw:network-types
>              /l3t:l3-unicast-topology:
>      +--rw l3-te!
>
[Xufeng]: Is there anything wrong here? l3-te is the name of a container
and is not the prefix.

>
> In passing, 'congruent with' in many places (at least in English
> English)
>
[Xufeng]: Is it not correct? Or “congruent to” is preferred? Did a brief
search, it seems that “congruent with” is more popular.

>
> s.3
> The YANG data  model defined in this document ...
> This document specifies two YANG modules ..
> actually three!
>
[Xufeng]: Is the above paragraph in Sec 2: “Modeling Considerations for L3
TE Topologies”? If so, the the description is intended to be scoped to Sec 2.
We have two modules for L3 TE Topologies, and the other two modules are for
Packet Switching Technology Extensions.

>
> Tom Petch
>
>
> Best regards,
> - Xufeng
>
> On Fri, May 8, 2020 at 6:06 AM tom petch <[email-masked]<mailto:
> [email-masked]>> wrote:
> From: Xufeng Liu <[email-masked]<mailto:
> [email-masked]>>
> Sent: 07 May 2020 00:22
>
> Hi Tom,
>
> Thanks for reviewing and sorry about the errors. We have posted an updated
> version https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-07,
> to fix the errors about the augmentation description and to rephrase a
> couple of sections to explain the relations between the related models and
> their objects. Please let us know for anything that is not clear enough.
>
> <tp>
> Thanks for the update.  I now find s.2 s.2.1 clear but still struggle
> thereafter.  When you use layer 3 topology I find it ambiguous.  Is it
> layer 3 unicast topology or layer 3 te topology?  Thus in s.2.2.1
> "When TE is enabled on a layer 3 topology .. " implies unicast
> "congruent to the layer 3 topology .."
> implies unicast
> " the layer 3 topology will have a reference.."
>  ah, no, must be layer 3 te topology
> and this is the case throughout the rest of s.2.  I would like to see
> those references to layer 3 topology clarified, unicast or te.  You may
> want to say that layer 3 topology means ... while layer 3 ... topology will
> be spelt out in full or some such, I am easy, but do think that you need to
> use two distinct terms.
> [Xufeng]: Reworded. Please let us know if anything is confusing.
>
> As you may infer, I like to work top down, start with Abstract, then
> Introduction, then s.2 s.3 making sense of them before seeing if the module
> does what these sections say, so when I get stuck in s.2, I do not make it
> to details of the YANG module.
> [Xufeng]: Thank you much for looking at it. We are striving to get your
> review unstuck.
>
> Tom Petch
>
> Thanks,
> - Xufeng
>
> On Fri, May 1, 2020 at 6:56 AM tom petch <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> wrote:
> From: Teas <[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>> on behalf of Xufeng
> Liu <[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>
> Sent: 21 April 2020 21:09
>
>
> Status update on draft-ietf-teas-yang-l3-te-topo
>
> Current Status:
>
>   *  The updated revision -06 was posted on March 8, 2020:
>      - Editorial changes.
>   *  Corordinated with ietf-eth-te-topology and ietf-te-mpls-tp-topo
>      for the augmentation of ietf-te-topology
>      - ietf-te-topology does not need to be changed.
>   *  Answered YANG doctor's review comments.
>
> Open Issues:
>
>   *   None.
>
> <tp>
>
> I started  to review this and have given up,  I cannot make sense of
> section 2, which I see as fundamental to understanding the I-D.
>  Thus
> The YANG modulues  ietf-l3-te-topology ...
> These two modules augment ietf-l3-te topology
> No they don't!  This augments
> ietf-l3-unicast-topology
> which is quite different and I find this confusion elsewhere in section
> two. Thus
> Relationship  between Layer 3 Topology and TE Topology
> Is that Layer 3 TE Topology or ietf-network-topology?  I think that many
> if not most  references to TE Topology are ambiguous and need clarifying -
> is the reference to Layer 3 TE Topology to  ietf-network-topology?
>
> Some of the words are quirky and this website is determined not to let me
> put them into an e-mail but here goes.
>
> modulues
> topoology
> moducment
> Local ink
>
> Tom Petch
> Next Steps:
>
>
>   *  Update the model to sync with the referenced models like
> draft-ietf-teas-yang-te-types if there are any changes.
>   *  Welcome further reviews and suggestions.
>   *  Working Group Last Call after completing the above.
>
> Thanks,
> - Xufeng
>

---

From: tom petch <[email-masked]>
Date: Wed, 25 Nov 2020 12:23:18 +0000

Top posting a more general TEAS issue I see when looking at teas-yang-l3-te-topo

A model that introduces a new network type must define a new network type, as a presence container, as defined in RFC8345.

I assumed that this would be a flat namespace but no, it is a tree structure which means that to reference it, as happens many times with YANG when statements, you must know where in the tree it is defined.  Thus
teas-sf-aware- topo-model places it under
/network-types/te-topology
while
teas-yang-sr-te-topo places it under
/network-types/l3-unicast-topology
while
teas-l3-te-topology does both!

This seems unfortunate and likely to cause confusion, errors, over time.  Doubtless there is a logic behind the different placements but I see consistency as better.

Tom Petch
________________________________________
From: Xufeng Liu <[email-masked]>
Sent: 20 November 2020 23:02

Hi Tom,
Thank you much for your further comments. We have posted https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-09, hoping to address some of your comments below.

Thanks,
- Xufeng

On Tue, Jul 14, 2020 at 7:34 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Sent: 13 July 2020 15:29

---

From: tom petch <[email-masked]>
Date: Wed, 25 Nov 2020 12:37:46 +0000

Hi Tom,

<tp>
I have had a second go at -09 and have some more thoughts.

Figure 3 I like, especially as you have achieved it in ASCII.

s.2.2.3
Can a termination point be reference with tp-id or do you have to use node+link as here?

s.2 talks of two YANG modules when there are four; ok two are PSC but I think that that might be spelt out here in this section.

congruent is 'with' something not 'to' something, I believe

between the one modeling element in the layer 3 unicast topology /to/and/

This YANG data model /allows/supports/ both cases.

associated /to/with/ the objects in one /corresponding/corresponding
[corresponding is what adulterers do!]

Tom Petch

Thanks,
- Xufeng

Hi Tom,

Thanks for further reviewing. We have posted an updated version https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-08. Some rewording has been made, with the hope of making the document more comprehensible. Please let us know for anything that is still confusing (for such an unconventional modeling approach).

<tp>

[Xufeng]: The next sentence describes the relation on an object, but such a description is relevant only if such an object exists. When such an object has not been created in the ietf-l3-te-topology, the corresponding layer 3 TE topology may already contain an object that can be potentially associated with the to-be-created object. In this case, 0 in ietf-l3-te-topology, and 1 in ietf-te-topology. Therefore, I’d say that multiplicity is still 0..1 to 0..1.

[Xufeng]: Changed ‘a’ to ‘one’, hoping that “associated to the objects in one corresponding TE topology" would avoid the possibility of “more than one”.

[Xufeng]: Reworded the section, trying to clarify the leafref relationship. Please let us know if it is better.

[Xufeng]: One example of the TE parameters is te-delay-metric. Such parameters are defined in the TE Topology model. They are not specified in l3-te-topology, but they can be configured in the corresponding te-topology instance.

s.2.2.2

[Xufeng]: Fixed too.

YANG
       container l3-te {

[Xufeng]: Is there anything wrong here? l3-te is the name of a container and is not the prefix.

[Xufeng]: Is it not correct? Or “congruent to” is preferred? Did a brief search, it seems that “congruent with” is more popular.

s.3

[Xufeng]: Is the above paragraph in Sec 2: “Modeling Considerations for L3 TE Topologies”? If so, the the description is intended to be scoped to Sec 2. We have two modules for L3 TE Topologies, and the other two modules are for Packet Switching Technology Extensions.

Tom Petch

Best regards,
- Xufeng

On Fri, May 8, 2020 at 6:06 AM tom petch <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
From: Xufeng Liu <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Sent: 07 May 2020 00:22

Hi Tom,

Thanks for reviewing and sorry about the errors. We have posted an updated version https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-07, to fix the errors about the augmentation description and to rephrase a couple of sections to explain the relations between the related models and their objects. Please let us know for anything that is not clear enough.

<tp>
Thanks for the update.  I now find s.2 s.2.1 clear but still struggle thereafter.  When you use layer 3 topology I find it ambiguous.  Is it layer 3 unicast topology or layer 3 te topology?  Thus in s.2.2.1
"When TE is enabled on a layer 3 topology .. " implies unicast
"congruent to the layer 3 topology .."
implies unicast
" the layer 3 topology will have a reference.."
 ah, no, must be layer 3 te topology
and this is the case throughout the rest of s.2.  I would like to see those references to layer 3 topology clarified, unicast or te.  You may want to say that layer 3 topology means ... while layer 3 ... topology will be spelt out in full or some such, I am easy, but do think that you need to use two distinct terms.
[Xufeng]: Reworded. Please let us know if anything is confusing.

As you may infer, I like to work top down, start with Abstract, then Introduction, then s.2 s.3 making sense of them before seeing if the module does what these sections say, so when I get stuck in s.2, I do not make it to details of the YANG module.
[Xufeng]: Thank you much for looking at it. We are striving to get your review unstuck.

Tom Petch

Thanks,
- Xufeng

On Fri, May 1, 2020 at 6:56 AM tom petch <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
From: Teas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> on behalf of Xufeng Liu <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>>
Sent: 21 April 2020 21:09

Current Status:

Open Issues:

  *   None.

<tp>

I started  to review this and have given up,  I cannot make sense of section 2, which I see as fundamental to understanding the I-D.
 Thus
The YANG modulues  ietf-l3-te-topology ...
These two modules augment ietf-l3-te topology
No they don't!  This augments
ietf-l3-unicast-topology
which is quite different and I find this confusion elsewhere in section two. Thus
Relationship  between Layer 3 Topology and TE Topology
Is that Layer 3 TE Topology or ietf-network-topology?  I think that many if not most  references to TE Topology are ambiguous and need clarifying - is the reference to Layer 3 TE Topology to  ietf-network-topology?

Some of the words are quirky and this website is determined not to let me put them into an e-mail but here goes.

modulues
topoology
moducment
Local ink

Tom Petch
Next Steps:

  *  Update the model to sync with the referenced models like draft-ietf-teas-yang-te-types if there are any changes.
  *  Welcome further reviews and suggestions.
  *  Working Group Last Call after completing the above.

Thanks,
- Xufeng

---

From: Italo Busi <[email-masked]>
Date: Thu, 26 Nov 2020 10:50:59 +0000

Hi Tom,

I think there is valid logic in the way network-types have been defined up to now. See some comments in line below.

My 2 cents

Italo

-----Original Message-----
From: tom petch [mailto:[email-masked]]
Sent: mercoledì 25 novembre 2020 13:23
To: Xufeng Liu <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo

I assumed that this would be a flat namespace but no, it is a tree structure which means that to reference it, as happens many times with YANG when statements, you must know where in the tree it is defined.

[[Italo Busi] ] I think that the text in section 4.1 of RFC8345 clearly explains that the network-types are intended to be used in a hierarchical fashion:

   When a network is of a certain type, it will contain a corresponding
   data node.  Network types SHOULD always be represented using presence
   containers, not leafs of type "empty".  This allows the
   representation of hierarchies of network subtypes within the instance
   information.  For example, an instance of an OSPF network (which, at
   the same time, is a Layer 3 unicast IGP network) would contain
   underneath "network-types" another presence container
   "l3-unicast-igp-network", which in turn would contain a presence
   container "ospf-network".  Actual examples of this pattern can be
   found in [RFC8346<https://tools.ietf.org/html/rfc8346>].

Thus
teas-sf-aware- topo-model places it under /network-types/te-topology

[[Italo Busi] ] I think it makes sense since the teas-sf-aware- topo-model requires to be implemented together with the te-topology

while teas-yang-sr-te-topo places it under /network-types/l3-unicast-topology

[[Italo Busi] ] I guess you mean teas-l3-te-topology. I think that for L3-TE the approach makes sense since the l3-te-topo-model requires to be implemented together with the l3-unicast-topology-topology

while

[[Italo Busi] ] I guess you mean the teas-yang-sr-te-topo. I think that for SR-TE the approach makes sense sine the L3-TE and SR-MPLS topologies can be used either independently or, in case of SR-TE, together.

Tom Petch

Hi Tom,

Thanks,
- Xufeng

On Tue, Jul 14, 2020 at 7:34 AM tom petch <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>> wrote:
From: Xufeng Liu <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
Sent: 13 July 2020 15:29

---

From: tom petch <[email-masked]>
Date: Thu, 26 Nov 2020 12:29:13 +0000

From: Italo Busi <[email-masked]>
Sent: 26 November 2020 10:50

Hi Tom,

<tp
Italo

I thought that you would:-)  Yes, 8345 does allow it and is more explicit about a tree sturcture than I had remembered.  I think that my view of network subtypes is more limited than yours:-(  You are saying that the tree structure of the network-types should be the same as the tree structure of the augments for the data nodes.  Well, yes, logical but not a logic I am keen on.   As with the data, I see us ending up with a te-topology monolith plus a few outliers. Anyhow, having raised it I will shut up about it.

In passing, I checked my references, where you say you guess I mean, and I really do mean what I first wrote and not your emendations. I have repeated that inline below.   Curious that you did not think that I meant them.

Tom Petch

My 2 cents

Italo

-----Original Message-----
From: tom petch [mailto:[email-masked]]
Sent: mercoledì 25 novembre 2020 13:23

Thus

No I really do mean teas-sr-te-topo and l3-unicast-topology which is what it augments
</tp>

while

<tp>
No I really do mean teas-l3-te-topology
</tp>

Tom Petch

Hi Tom,

Thanks,
- Xufeng