Subject: [CCAMP] Augmenting te-topo wasRe: [Teas] rough notes from meeting

From: tom petch <[email-masked]>
Date: Tue, 22 Sep 2020 11:17:42 +0000

Lou
(borrowing a useful email to raise a fresh topic)

When te-topo is augmented with a new technology, there is a need to specify the new type.  Should this be an augment to 
networks/network/network-types/te-topology
or an augment to 
networks/network/network-types
ie do you see the new technology sitting alongside te-topology or subordinate to it?
wson-yang is in IETF last call and has just been revised and the presence container wson-topology is subordinate to te-topology while the description says augment network types.  What matters I think is that the approach is consistent.  I looked at RFC8795 but could not see any guidance there.

Tom Petch

From: Teas <[email-masked]> on behalf of Lou Berger <[email-masked]>
Sent: 31 July 2020 14:04
To: TEAS WG
Cc: TEAS WG Chairs
Subject: [Teas] rough notes from meeting

All,

Thank you all for participating today! Please visit
https://codimd.ietf.org/notes-ietf-108-teas?both and verify that your
comments/discussions were appropriately captured.

Thank you!

Lou (and Pavan and Matt)

## TEAS Notes For IETF 108

## Session Information

                 TEAS Agenda For IETF 108
                 Version: Jul 26, 2020

                 Session 1: Friday, July 31, 2020 (UTC)
                 11:00-12:40 Friday Session I (UTC)

| |  |
| -------- | -------- |
|  Location:    |
https://datatracker.ietf.org/meeting/108/floor-plan?room=room-6 |
| Materials:    | https://datatracker.ietf.org/meeting/108/session/teas |
| Meetecho:    | http://www.meetecho.com/ietf108/teas |
| Audio stream:    | http://mp3.conf.meetecho.com/ietf/ietf1086.m3u |
| Jabber:    | http://jabber.ietf.org/logs/teas |
| WG  ICS:    |
https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas |
| Session ICS:     |
https://datatracker.ietf.org/meeting/108/session/28181.ics|

## Presentation       Start Time     Duration     Information

## 1    11:00    5    Title:    Administrivia & WG Status
 > Draft:
 > Presenter:    Chairs

## 2    11:05    5    Title:    WG Draft updates
 > Draft:    Many
 > Presenter:    Chairs

Adrian Farrel: draft-king-teas-applicability-actn-slicing has been respoon
Jie Dong: The plan is to move it to other documents (currently individual)
Eric Gray: The scope of the new documents are more narrow than the
original so removal is problematic
Vishnu Beeram: Please discuss the change on the list
Lou Berger: Please discuss with WG before (re)moving text from a WG
document

## 3    11:10    10    Title:    Yang model for requesting Path Computation
 > Draft:
 > https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-10
 > Presenter:    Sergio Belotti

Lou Berger: Suggest discussing/reporting any tool issues with the tool
author -- (from jabber: report issue via https://github.com/mbj4668/pyang)
Rob Wilton (from Jabber):
   On the path computation presentation, and having looked at RFC 7950,
for issue #76 (1) and (2) I think that the pyang 2.1 behaviour is
correct.  I.e. don't include "input" and for (2), I think that this
isn't allowed. The key text being section 6.4.1 or RFC 7950

## 4    11:20    10    Title:    Yang model update
 > Draft:
 > https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-04
 >
https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-03
 > https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-09
 > Presenter:    Dhruv Dhody

Tarek Saad: Is the path computed by "template" in TE-Service mapping,
stateful in nature?
Dhruv Dhody: This is just the constraints and optimization criteria and
nothing to do with the statefulness of path.
Daniele Ceccarelli: This comes from the OSS layer, which doesn't care
about how it is provided via te tunnels, just that the service
characteristics are met

## 5    11:30    10    Title:    DT Intro, IETF Definition of Transport
Slice
 > Draft:
 > https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-03
 > Presenter:    Jari Arkko + Reza Rokui
Actual Start Time: 11:42

## 6    11:40    10    Title:    Framework for Transport Network Slices
 > Draft:
 > https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-04
     > Presenter:Eric Gray
 >
Actual Start Time: 11:53

Daniele Ceccarelli: in ACTN we have defined the interface between MDSC
and CNC as a boundary between a customer and the operator. We are now
lacking of a reference point between the MDSC and another entity within
the operator. We have identified a similar issue in the context of POI.
On the MDSC role, I agree with the interpretation.

Lou Berger: Any objections to adoption?
     <none></none>
     Please expect an adoption call on list.

## 7    11:50    10    Title:    Transport Network Slice YANG Data Model
 > Draft:
https://tools.ietf.org/html/draft-liu-teas-transport-network-slice-yang-01
 > Presenter:    Xufeng Liu
Actual Start time: 12:10

## 8    12:00    10    Title:     A Yang Data Model for Transport Slice NBI
 > Draft:
 > https://tools.ietf.org/html/draft-wd-teas-transport-slice-yang-02
 > Presenter:    Bo Wu
Actual Start Time: 12:18

(From Jabber) Vishnu Beeram: Note that the previous presentation ties
the modeling of a transport network slice to existing network topology
models while the current presentation focuses on the service view of a
slice. Please chime in with your views on these 2 approaches (either
here or on the list).. There seems to be a case being made (by both sets
of authors) to make room for both -- please discuss if you have any
objections...
Lou Berger: Please take comments/discussion to list

## 9    12:10    10    Title:    Network Slicing with Flexible Traffic
Engineering
 > Draft:
https://tools.ietf.org/html/draft-zzhang-teas-network-slicing-with-flex-te-00
 > Presenter:    Jeffrey Zhang
Actual Start Time: 12:26

Please take comments/discussion to list

## 10    12:20    10    Title:    Packet Network Slicing using Segment
Routing
 > Draft: https://tools.ietf.org/html/draft-peng-teas-network-slicing-03
 > Presenter:    Ran Chen
Actual Start Time: 12:31

Please take comments/discussion to list

## 11    12:30    10    Title:    A YANG Data Model for MPLS-TE Topology
 > Draft:
https://tools.ietf.org/html/draft-busizheng-teas-yang-te-mpls-topology-00
 > Presenter:    Italo Busi
 > Actual Start Time: 12:36

Please take comments/discussion to list

## Adjourn    12:40

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Sat, 26 Sep 2020 09:47:05 -0400

Hi Tom,

     sorry about the delayed response.  I think this a fair question for 
the WG as a whole (not me alone).

My view as a WG participant is in-line below.

> ie do you see the new technology sitting alongside te-topology or subordinate to it?

IMO it depends on the specifics of the augmentation.  If it is 
TE-specific and relying on general TE information, then subordinate 
makes sense to me.

> wson-yang is in IETF last call and has just been revised and the presence container wson-topology is subordinate to te-topology while the description says augment network types.  What matters I think is that the approach is consistent.

I previously looks at this draft and it's augmentations looked correct 
to me.  I focused more on the tree representation rather than the actual 
model so missed this in the description.  Even so, I'm not sure I would 
have noticed as  it reads:

      augment "/nw:networks/nw:network/nw:network-types"
            + "/tet:te-topology" {
        description
          "Augment network types to define WSON topology type.";

and it's the te-topology network type (container) that is being augmented.  It sounds like you'd like to see the description changed from "network types " to "te-topology network type".  I think this is a fine, and very minor, clarification.
Lou

>   I looked at RFC8795 but could not see any guidance there.
>
> Tom Petch
>

---

From: Italo Busi <[email-masked]>
Date: Mon, 28 Sep 2020 15:30:41 +0000

Tom, Lou,

The augmentation statements in WSON, as well in other technology-specific models in CCAMP, we are following the guidelines in section 6 and Appendix C of RFC8795 and augmenting the te-topology network-type.

The main reason is that these modules augments structures defined in te-topology.

If the issue is caused by the description, I am ok to update the description following Lou’s suggestion:

OLD
   "Introduce new network type for WSON topology.";
NEW
   "Introduce new te-topology network type for WSON topology.";

Italo

From: Lou Berger [mailto:[email-masked]]
Sent: sabato 26 settembre 2020 15:47
To: tom petch <[email-masked]>; TEAS WG <[email-masked]>
Cc: [email-masked]; TEAS WG Chairs <[email-masked]>
Subject: Re: [CCAMP] [Teas] Augmenting te-topo wasRe: rough notes from meeting

Hi Tom,

    sorry about the delayed response.  I think this a fair question for the WG as a whole (not me alone).

Lou

or an augment to

IMO it depends on the specifics of the augmentation.  If it is TE-specific and relying on general TE information, then subordinate makes sense to me.

I previously looks at this draft and it's augmentations looked correct to me.  I focused more on the tree representation rather than the actual model so missed this in the description.  Even so, I'm not sure I would have noticed as  it reads:

           + "/tet:te-topology" {

       description

Lou

Tom Petch

From: Teas <[email-masked]><mailto:[email-masked]> on behalf of Lou Berger <[email-masked]><mailto:[email-masked]>

Sent: 31 July 2020 14:04

To: TEAS WG

Cc: TEAS WG Chairs

All,

Thank you!

Lou (and Pavan and Matt)

## Session Information

                 TEAS Agenda For IETF 108

                 Version: Jul 26, 2020

| |  |

| -------- | -------- |

|  Location:    |

| WG  ICS:    |

| Session ICS:     |

document

stateful in nature?

characteristics are met

Slice

Actual Start Time: 11:42

Actual Start Time: 11:53

     <none></none>

Actual Start time: 12:10

Actual Start Time: 12:18

objections...

Engineering

Actual Start Time: 12:26

Routing

Actual Start Time: 12:31

## Adjourn    12:40

Teas mailing list

[email-masked]<mailto:[email-masked]>

Teas mailing list

[email-masked]<mailto:[email-masked]>

---

From: tom petch <[email-masked]>
Date: Tue, 29 Sep 2020 11:51:31 +0000

From: CCAMP <[email-masked]> on behalf of Italo Busi <[email-masked]>
Sent: 28 September 2020 16:30

Tom, Lou,

<tp>
No, I do not see it.  I agree that WSON augments te-topology but do not see RFC8345 (or RFC8795) as then suggesting that the augmentation of the network type should reflect the YANG augmentation of the data nodes.  As I said before, the only example I see in RFC8345 is of OSPF augmenting Layer 3, which figures.  The end of s.4.3 talks of a hierarchy of network types and suggests that a more specific network type could augment a more general network type (which fits with Layer 3 and OSPF). We could have had a layer one which got augmented but we have not.  I posted to the I2RS list in the hope that one of the authors of RFC8345 could expand on their thinking but no.

A minor consequence of augmenting the nework type te-topology is the longer path statements and I note that RFC8345 does raise the length of path statements as an issue but my greater concern is that hard coding this hierarchy into the YANG will stop us doing something we want to do at a later date but I have no concrete example in mind.

Tom Petch.

OLD

Italo

Hi Tom,

Lou

or an augment to

           + "/tet:te-topology" {

       description

Lou

Tom Petch

Sent: 31 July 2020 14:04

To: TEAS WG

Cc: TEAS WG Chairs

All,

Thank you!

Lou (and Pavan and Matt)

## Session Information

                 TEAS Agenda For IETF 108

                 Version: Jul 26, 2020

| |  |

| -------- | -------- |

|  Location:    |

| WG  ICS:    |

| Session ICS:     |

document

stateful in nature?

characteristics are met

Slice

Actual Start Time: 11:42

Actual Start Time: 11:53

     <none></none>

Actual Start time: 12:10

Actual Start Time: 12:18

objections...

Engineering

Actual Start Time: 12:26

Routing

Actual Start Time: 12:31

## Adjourn    12:40

Teas mailing list

Teas mailing list

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Sep 2020 09:27:37 -0400

> A minor consequence of augmenting the nework type te-topology is the longer path statements and I note that RFC8345 does raise the length of path statements as an issue but my greater concern is th…

Tom,

Given the explanations sent to you on i2rs/teas/ccamp - that what has 
been done is consistent with RFC8795 and has WG support, and that you 
don't have concrete issue in mind justifying a change, can we consider 
this issue closed once the description change is made?

Thanks,

Lou