Subject: [Teas] rough notes from today's session

From: Lou Berger <[email-masked]>
Date: Mon, 27 Mar 2017 14:19:35 -0400

> TEAS Agenda For IETF 98
> Version: Mar 23, 2017
> 
> Session 1
> Monday March 27th 2017
> 09:00 - 11:30 - Monday Morning Session I
> Room: Vevey 1/2
> 
> Session 2: Joint with MPLS, PCE, CCAMP
> FRIDAY, March 31, 2017
> 0900-1130  Morning Session I
> Zurich D
> https://datatracker.ietf.org/meeting/98/agenda/mpls/
> 
> Etherpad:       http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-teas?useMonospaceFont=true
> Meetecho:       http://www.meetecho.com/ietf98/teas
> Audio stream:   http://ietf98streaming.dnsalias.net/ietf/ietf982.m3u
> Jabber: xmpp:[email-masked]?join
>         
>         Available post session:
> Recording:      https://www.ietf.org/audio/ietf98/
> YouTube:        https://www.youtube.com/user/ietf/playlists
> 
>             Session 1
> Num  Start Duration    Information    
> 0    9:00  10    Title:    Administrivia & WG Status
>                  Draft:    n/a
>                  Presenter:    Chairs

Lou Berger: presentation 8 will go before 6

> 1    9:10  15    Title:    WG Draft updates
>                  Draft:    Many
>                  Presenter:    Chairs

> 2    9:25  20    Title:    Yang Data Model for TE Topologies
>                  Draft:    https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo
>                  Presenter:    Xufeng Liu
Michael Shaarf: Model is complex to implement, particularly from the
single layer perspective.  Would be worth defining what is needed for
single-layer, i.e. can you provide direction for the simple case. 
???:
Fatai: this is foundational, please publish as soon as possible
Igor Bryskin: We have a tutorial that includes tunnel model as well --
we publish seperately 

> 3    9:45  20    Title:    A YANG Data Model for Traffic Engineering Tunnels and Interfaces
>                            A YANG Data Model for Resource Reservation Protocol
>                            A YANG Data Model for RSVP-TE
>                  Draft:    https:/tools.ietf.org/html/draft-ietf-teas-yang-te
>                            https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp
>                            https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te
>                  Presenter:    Tarek Saad
Lou Berger: WRT items that are not explicitly covered in specs, but
allowed for -- should these be features or not
Tarek: we've struggled with this, and are generally using features when
something isn't supported by all 
Lou Berger: Also please revisit the modules to ensure that technology
specific parts aren't in the generic and the reverse

Dhruv: Can you clarify the semantics of bandwidth-type?
Tarek: static type is used if the bandwidth is explicitly set; dynamic
type is used to indicate auto-bandwidth functionality.

> 4    10:05  10   Title:    ACTN Framework and Requirements
>                  Draft:    https://tools.ietf.org/html/draft-ietf-teas-actn-framework
>                            https://tools.ietf.org/html/draft-ietf-teas-actn-requirements
>                  Presenter:    Young Lee/Daniele Ceccarelli
Michael Shaarf: the document seems a bit dated, it sems it needs an
update to reflect recent developments and state of industry in 2017,
e.g., requirments have not kept pace with framework.  Also not clear
what all interfaces are all about, e.g., CMI
Young: MMI is a special case of MPI so no need for specific
requirements. We can add specifics for MPI and MMI in the requirements
Lou: it is not clear where the requirements apply
Lou: I am proposing to take the text from the mapping draft into the
framework draft to help people understanding the ACTN terminology

> 5    10:15  10   Title:    Applicability of YANG models for ACTN 
>                            ACTN Abstraction Methods
>                  Draft:    https://tools.ietf.org/html/draft-zhang-teas-actn-yang
>                            https://tools.ietf.org/html/draft-lee-teas-actn-abstraction
>                  Presenter:    Daniele / Haomian

ACTN Abstraction Methods (Daniele)
Igor: how does white topology helps with proprietary extensions?
Dainele: do not make it white. Unless you have an MDSC that understands
the proprietary extensions, you should suggest not to use white topology
and go for grey topology

Applicability of YANG models for ACTN (Haomian)
Michael: for CMI technology-specific attributes, is there no overlap
with other WGs?

> 8    10:25  10   Title:    Traffic Engineering and Service Mapping Yang Model
>                  Draft:   
https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang
>                  Presenter:    Dhruv Dhody

Igor: It is too simple, there is no 1:! mapping between L3SM and TE
Tunnel. The only way to do is via versatile policy models
Dhruv: we have a map-type which is not yet an exaustive list but new
modes can be added to address this use case
Michael: not clear the use case. The mapping for L3SM can be more
complex, expecially with multi-AS case. Why this mapping cannot be
internal and needs a YANG model?
Dhruv: need to visualize which TE Tunnel is used for an L3SM, e.g., to
monitor it
Michael: With multiple-AS we need to envision if we have one or multiple
MDCS which impacts the whole ACTN architecture

> 6    10:35  10   Title:    A Yang Data Model for ACTN VN Operation
>                  Draft:    https://tools.ietf.org/html/draft-lee-teas-actn-vn-yang
>                  Presenter:    Dhruv Dhody
Igor: what is the difference between VN model and TE abstract topology
model. Abstract topology can address all these things
Lou: please have a discussion on the list about this comment before the
next meeting

> 7    10:45  10   Title:    YANG models for ACTN TE Performance Monitoring
Telemetry and Network Autonomics
>  (real :49)      Draft:   
https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics
>                  Presenter:    Young Lee

Michael: I have not found requirements for telemetry in the requirements
document. The telemetry information is packet technology specific
Igor: we are defining telemetric information for TE Tunnel/Topology with
technology-specific augmentation
Lou: the authors of the two drafts to work together to reconcile the two
documents

> 9    10:55  10   Title:    PCE in Native IP Network
>      (10:58)     Draft:   
https://tools.ietf.org/html/draft-wang-teas-pce-native-ip
>                  Presenter:    Aijun Wang
Lou Berger: How many have read draft -- a few
            How many think that the WG should be working on this type of
TE? -- very few
(conclusion) It doesn't seem like there is currently support for this in
the WG, perhaps send mail on the how you are addressing questions
previously raised to generate interest and discussion on the list

> 10    11:05  10  Title:    Recommendations for RSVP-TE and Segment Routing LSP co-existence
>      (11:08)            Draft:   
https://tools.ietf.org/html/draft-sitaraman-sr-rsvp-coexistence-rec
>                  Presenter:    Harish Sitaraman / Vishnu Pavan Beeram
Lou Berger: How many think the WG should be looking at signalled and SR
based TE - A reasonable number
            How many have read the document - about the same
            How many think this draft is a good foundation for the WG
activity in this area - about the same
(conclusion) Looks like there is support for adoption, will take it to
the list.

> 11    11:15  10  Title:    Fast Reroute Procedures For Associated Bidirectional Label
Switched Paths (LSPs)
>                  Draft:   
https://tools.ietf.org/html/draft-gandhishah-teas-assoc-corouted-bidir
>                  Presenter:    Rakesh Gandhi
Stewart Bryant: How do you handle one way failures and maintain co-route
requirment
George Swallow: control plane will detect failure and take link down
Tarek: downstream node can detect failure and signal failure
Lou Berger: How many think this function is important for the WG to work
on - A reasonable number
            How many have read the document - a few less, but still a
reasonable number
            How many think this draft is a good foundation for the WG
activity in this area - about the same
            Does anyone have reservations on adoption? -- no
(conclusion) Looks like there is support for adoption, will take it to
the list.

> 12    11:25  5   Title:    ONF/T-API Services vs. IETF/YANG Models and Interfaces
>                  Draft:   
https://tools.ietf.org/html/draft-bryskin-teas-yang-ietf-vs-onf-00
>                  Presenter:    Igor Bryskin

Lou: we usually do not see drafts with comparisons with other groups,
what is the objective?
Igor: trying to compare two models to see what is missing
Lou: have you found something missing in the TEAS model?
Igor: no
Scott: as LS person, the perception from ONF people of this draft is
negative. If you wish to involve ONF people, it needs to be softened to
be more collaborative
Igor: we have at least got attention from T-API
Lou: getting attention from other SDOs is not our mission, we care about
what is missing in our work and not in what it is missing on the other
groups
Michael: concerns with the wording, the "versus" word is not inviting
collaboration
Daniele: having this work was one of the intention of the Transport NBI
DT in CCAMP, it would be good to synch-up with the DT
Gert: 
Fatai: we are doing standard for the industry, if there is confusion in
the industry, we need to help resolve it. I think this draft is useful

> Adjourn    11:30        

Note takers (feel free to add your name here):
Haomian Zheng
Italo Busi

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 27 Mar 2017 19:20:51 +0000

> Michael Shaarf: Model is complex to implement, particularly from the single
> layer perspective.  Would be worth defining what is needed for single-layer,
> i.e. can you provide direction for the simple case.

Since I was asked to follow-up on the list:

For instance, one example would be to have a feature for the parts of the model that are only needed in a multi-layer case. I haven't tried it out myself, but hopefully this would not change the YANG tree structure. This could it make easier for implementers to determine which parts of the YANG model are essential, in particular for vanilla single-layer TE (for which use cases exist).

There might be some other parts of the model that may also not be required in all use cases. One such example are the statistics. To me, this could be a candidate for a feature, too. I observe that the statistics are optional , but I still believe it would help implementers to identify the key parts of the model that are important for interoperability between different implementations.

Thanks

Michael