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

[tom petch <[e-mail]>]

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

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.

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

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:[e-mail]]
Sent: sabato 26 settembre 2020 15:47
To: tom petch <[e-mail]>; TEAS WG <[e-mail]>
Cc: [e-mail]; TEAS WG Chairs <[e-mail]>
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).

My view as a WG participant is in-line below.
On 9/22/2020 7:17 AM, tom petch wrote:

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?

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: Teas <[e-mail]><mailto:[e-mail]> on behalf of Lou Berger <[e-mail]><mailto:[e-mail]>

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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/teas



_______________________________________________

Teas mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/teas