Minutes IETF106: teas

Meeting Minutes Traffic Engineering Architecture and Signaling (teas) WG
Title Minutes IETF106: teas
State Active
Other versions plain text
Last updated 2020-01-09

Meeting Minutes

>                                         TEAS Agenda For IETF 106
>                                         Version: Nov 17, 2019
>                                         Tuesday, November 19, 2019 (+08)
>                                         Session 1: Tuesday, November 19th
2019 >                                         13:30 - 15:00 Tuesday
Afternoon Session I >                                         Session 2:
Tuesday, November 19th 2019 >                                         17:10
- 18:40 Tuesday Afternoon Session III >                                
Location:        Collyer > >                                 Slides:     
  https://datatracker.ietf.org/meeting/106/session/teas >                   
             Etherpad:        https://etherpad.ietf.org/p/notes-ietf-106-teas
>                                 Meetecho:       
http://www.meetecho.com/ietf106/teas/ >                                
Audio stream:        http://mp3.conf.meetecho.com/ietf/ietf1062.m3u >       
                         Jabber:        xmpp:teas@jabber.ietf.org?join >
>                                         Available post session: >      
                          Recording: >                                
YouTube: https://www.youtube.com/watch?v=Fn60DSxJLks > > Presentation    
           Start Time        Duration        Information > 1               
13:30        5        Title:        Administrivia & WG Status >         
                       Draft: >                                 Presenter:  

> 2                13:35        10        Title:        WG Draft updates
>                                 Draft:        Many
>                                 Presenter:        Chairs

> 3                13:45        10        Title:        YANG Models Updates
>                    (13:40)        Draft:       
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-07 >               
https://tools.ietf.org/html/draft-ietf-teas-yang-te-mpls-02 >               
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-07 >               
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-11 >                  
              Presenter:        Tarek Saad

Lou Berger: Should the set of base/extended RSVP modules be progressed
separately or should they be clubbed with the TE modules set? Tarek Saad: The
authors recommendation would be to have them progressed separately. Lou Berger:
Any reservations to move these to LC? Lou Berger: Expect to see some of these
progress to LC soon.

> 4                13:55        10        Title:        YANG Models for L3
and SR TE Topologies >                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-05 >            
https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-06 >            
                    Presenter:        Xufeng Liu

Tarek: Clarification question -- What is the ietf-eth-te-topology used for? Is
this for setting up Ethernet LSPs? Haomian: Ethernet can be configured as a
client signal in GMPLS-based networks, so with that configuration there can be
an Ethernet topology; there doesn't need to be an Ethernet LSP setup. Lou:
GMPLS allows Ethernet LSPs to be set up. Xufeng: This is no different than any
other technology specific TE topology model.

(Regarding Options 1&2)
Haomian: Agree that both options work; But we need to evaluate if there any
common sections that can be put in a generic types module. Xufeng: We did the
evaluation -- can discuss further offline if needed Fatai: Besides Ethernet and
MPLS-TP do we have any other modules augmenting the te-packet module? Xufeng:
No so far. Tarek Saad: can IP Native use this? Xufeng: That is already covered
in the L3 topology module Lou: There is some proposed work (RAW) that might
come into play in this discussion Lou: Regarding SR-TE-Topo model, what is
SR-TE? How many would be willing to work on a good definition of SR-TE? Enough
people to work on it. Will work with Spring Chairs and work this out.

> 5                14:05        10        Title:        Yang model for
requesting Path Computation >                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-06 >      
                          Presenter:        Sergio Belotti

Tarek Saad: Question on the 32 bit Association ID used in Slide 6. The notion
of ASSSOCIATION is well defined in RSVP — it is typically specified with a
type. How is the association specified here different from the RSVP
Association? Italo Busi: This is different; Here the intent is to associate
multiple paths in one tunnel Tarek: Using Association for what you are doing is
confusing, maybe rename it. Dhruv: Agree with Tarek; Association has been
specified in both pcep and teas. That aside, why is there a choice here between
tunnel-ref and tunnel-association-id? Why can't the regular RSVP/PCEP
Association be used? Sergio: We will explore this more. Tarek: at the very
least, we may need to reconsider the term 'association' used here. Lou: It
would be useful to clarify if this association is the same as existing
"association". Italo: We have different variants of association -- all of them
applicable. We'll explore this more.

> 6                14:15        10        Title:        ACTN Yang Models
>                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-04 >               
https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-02 >    
                            Presenter:        Dhruv Dhody

Lou: Regarding ACTN-VN yang, were all the comments from the previous meeting
addressed, especially the ones raised by Qin Wu? Dhruv: Yes, we believe they
have been addressed. Qin: I'm happy with the changes that have been made.

Lou: Question for Dan King.. Does the ECA work in netmod have any applicability
here? Dan: As co-author of ECA framework, there is definitely some
applicability here. Lou: this work is more advanced, may make sense to have
this influence the ECA work

Adrian: L3NM is a recently adopted model by ops-area. Regarding the usage of
this by L3NM, suggest a meeting between service-mapping authors (l3sm) and L3NM
authors Lou (side comment): There are issues with the way L3NM currently
describes protocols. It is unclear what the scope is. This should reference
other work especially in RTGWG. The sit-down would those folks would be really
useful. Dhruv: We have been engaging with them, we will continue to do so.

Greg: There was some effort to define availability in CCAMP for specific
technology. But it would be good to define what availability means in general
in IETF.

> 7                14:25        10        Title:        Interworking of
GMPLS Control and Centralized Controller System >                    32     
https://tools.ietf.org/html/draft-ietf-teas-gmpls-controller-inter-work-02 >
                                Presenter:        Yi Lin Jayant: Is it possible
to do OAM on the segment as well as on e2e for the interdomain LSP Yi: yes, .

> 8                14:35        10        Title:        Applicability of
ACTN to Packet Optical Integration (POI) >                     14:43        
https://tools.ietf.org/html/draft-peru-teas-actn-poi-applicability-02 >     
                           Presenter:        Daniel King Dan: Who has read the
document? Decent number, 2 operators Dhruv: How is different from
draft-lee-teas-actn-poi-applicability? Dan: They are complementary rather than
competitive, we will make that clear in the document.

> 9                14:45        5        Title:        3272bis Design Team
update >                                 Draft:             
https://tools.ietf.org/html/draft-dt-teas-rfc3272bis >                      
          Presenter:        Adrian Farrel

> 10                14:50        10        Title:        ETSI Communication
>                                 Draft:        None
>                                 Presenter:        Daniele Ceccarelli
(remote) Lou: How should the communication between IETF and ETSI happen? There
is no currently no formal relationship. Julien: Mutual participation Adrian:
Good news is that ACTN is being looked at beyond this WG. As Lou said, there is
currently no formal relationship between IETF and ETSI and it would take a
while to establish one. what you want really is an individual to be sending a
mail to the WG list saying we're doing this stuff does and asking does this
look right and getting other individuals to comment back; that's the most
effective way to make progress Reza: How does this relate to the slicing work?
Jeff T: ETSI leadership doesn't recognize IETF. It would be wrong to say there
is an existing relationship. Daniele: This work has nothing to do with slicing

> Adjourn                15:00
>                                         Session 2: Tuesday, November 19th
2019 >                                         17:10 - 18:40 Tuesday
Afternoon Session IIIx >                                 Location:       
Collyer > > >                                         Available post
session: >                                 Recording: >                  
              YouTube:  https://www.youtube.com/watch?v=JMDuPgOjN3g > >
Presentation                Start Time        Duration        Information >
1                17:10        5        Title:        Administrivia >        
                        Draft: >                                 Presenter: 
      Chairs > 11                17:15        10        Title:        A
Framework for Enhanced Virtual Private Networks (VPN+) Service

>                                 Draft:       
https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-01 >               
                 Presenter:        Jie Dong

David Sinicrope: The introduction to the draft talks about enhanced VPN and
about deterministic transport in the existing VPN mechanisms, but in your
presentation you are pitching the draft as an architecture for network slicing.
Which is it? Is it a method of providing deterministic transport VPNs or is
this the new architecture for network slicing. Jie: This is a framework for
VPN+ and one of the use-case of this is network slicing. Lou: The presentation
went a little afield from the actual WG adopted document and that is confusing
things. In future, just focus on the WG draft and let the work of design team
be covered by the design team's presentation Adrian Farrel: I think the draft
is very clear on the slicing aspects, enhanced VPN could be used in Transport
Network Slicing Pavan: The new version has new slicing specific definitions. My
expectation was that the Slicing DT would come up with those and other relevant
drafts would reference those. Jie: We will coordinate with the DT. Lou: Again,
the recommendation is to limit the scope of the discussion of this document to
enhanced VPN (and not the DT work). David Sinicrope: The document is currently
too focused on Network Slicing, but network slicing is not the only use case of
enhance VPN. This needs to be made clear. Lou: I also see some discussions
about using enhanced VPNs in detnet. This is another use-case.

> 12                17:25        10        Title:        Control plane
considerations of enhanced VPN >                                 Draft:     
>                                 Presenter:        Jie Dong Lou: Your title
is VPN+, but the context seems to be about the network slice; Is it about the
control plane for VPN+ or for Network Slicing? Jie: It is about the VPN+ Lou:
How is this different from the control plane discussion in the previous draft?
why is the context of this draft all about Network Slicing? Jie: Not different.
This draft just provides more detailed considerations Daniele
Ceccarelli(Remote): Agree with Lou, should avoid overlap with other drafts.
There seems to be come confusion on the scope of the base enhanced vpn draft.
Jeff: Agree with Lou. Is this management plane or control plane? It looks more
like management plane with the name of control plane. See if you can extend
this to cover both management plane and control plane considerations. Jayant:
My understanding was the enhanced VPN architecture was not meant for a large
scale deployment. Yet here you are talking about a large scale. Jie: Enhanced
VPN is scalable. This draft provides more details on the considerations.
Adrain: Agree with Jeff, management plane needs to be covered; Agree with Lou,
it should to be consistent with framework; we have about half page in framework
document discussing both management plane and control plane; we have 10 pages
in this current document. Should we add more material to the framework
document? Pavan: The details from the framework document were culled for a good
reason and moved into this document. Given the current the text, I wouldn't be
comfortable at all moving it back. Lou: We need to understand the
considerations for VPN+ control plane (not network slicing) first. Adrian: So
control & management plane should be in one or separate document? Lou: We
care more about the text, let's clarify that first. Uma: It would be useful if
underlay and overlay discussion is kept separate. Lou(Daniele's comment?): In
this draft, it is confusing whether it is about deterministic VPN or enhanced
VPN, needs more clarity on scope. Jie: We will fix the problem with terminology
in the next version.

> 13                17:35        15        Title:        Network Slicing
Design Team update >                          45       Draft:        n/a
>                                 Presenter:        Jari Arkko Himanshu
Shah: Clarification question -- Is this covering Soft slices or Hard slices or
something else? Jari: It is based on requirement Jeff: Idea is to build an API
that caters to all types of requirements. Robin: As a member of IAB; What is
the plan about handling the liaison from 3GPP? Jeff: We don't need to liaise
with 3GPP for this work. Jari: The idea is to define functions that could be
used Yi Lin: As part of this effort, suggest to explain the meaning of 'network
slice' and its relationship with other terms, such as VPN.. Reza Rokui: Terms
like VPN+ are a kind of 'implementation of transport slice'. In the current
stage, we are keeping the discussion independent of implementation.

> 14                17:50        10        Title:        Transport Network
Slice YANG Data Model >                      605       Draft:       
https://tools.ietf.org/html/draft-liu-teas-transport-network-slice-yang-00 >
                                Presenter:        Xufeng Liu Reza: Keep the
terminology consistent with the design team definition

> 15                18:00        10        Title:        Instant Congestion
Assessment Network (iCAN) for Data Plane Traffic Engineering >              
         13         Draft:        https://tools.ietf.org/html/draft-liu-ican-01
>                                 Presenter:        Joanna Dang Lou: this WG
or RTGWG, load based routing, e.g., ECMP, has typically been done in RTGWG?
Jeff T: Can be discussed in RTGWG, but this seems like deja vu.

> 16                18:10        10        Title:        RSVP-TE Extensions
in Support of Proactive Protection >                                 Draft: 
>                                 Presenter:        Yi Lin Jeff T: Why RSVP?
Doesn't seem to be the right protocol. Prediction may not come true, so it is
possible for the the configuration to never be used. Lou: Doesn't need to
propagate state; Just an error code in signaling message may suffice. Italo:
local protection may not be optimal especially for optical. Lou: how many
people think this topic is interesting to work on? A few.
   how many totally uninterested? A couple.

> 17                18:20        10        Title:        A YANG Model for
Network and VPN Service Performance Monitoring >                            
https://tools.ietf.org/html/draft-www-bess-yang-vpn-service-pm-04 >         
                       Presenter:        Michael Wang

Lou: We need to talk to the bess chairs and ADs

> 18                18:30        10        Title:        A YANG Data Model
for Client Signal Performance Monitoring >                                
Draft:        https://tools.ietf.org/html/draft-zheng-ccamp-client-pm-yang-00
>                                 Presenter:        Haomian Zheng Dieter
Beller: This document is not specifying any new performance monitoring
capabilities, it is just referring to existing mechanisms -- it would be good
to have references to relevant specifications that define those mechanisms
Haomian: No, there is no new concept, will try our best to add all references.
Lou: It is not technology specific? Haomian: We monitor the performance for
tech-specific service, so the model should be tech-specific. Lou: But the
parameters listed in the table seem generic. Haomian: Perhaps what you would
like to see is have a generic model, and at least there is one
pm-telemetry-autonomics. Lou: You are not augmenting, at least you should try.
Italo: We could define possibly generic types. Lou: We should at least try and
see if generalization is possible. Little more work needs to be done before a
call can be made. Haomian: We'll try and report our findings.

> Adjourn                18:40