Minutes IETF106: teas
minutes-106-teas-01

>
>                                         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:        Chairs

> 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? <No comments/reservations raised in the
room> 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-actn-pm-telemetry-autonomics-01 >  
                                     
https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang-02 >       
                         Presenter:        Dhruv Dhody
<draft-ietf-teas-actn-vn-yang> 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.

<draft-ietf-teas-actn-pm-telemetry-autonomics>
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

<draft-ietf-teas-te-service-mapping-yang>
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.

<regarding reference for the term "availability">
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            
Draft:       
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,
<Jayant will email/followup on the list>.

> 8                14:35        10        Title:        Applicability of ACTN
to Packet Optical Integration (POI) >                     14:43           
Draft:       
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:       
https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-control-plane-00 >    
                            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:       
https://tools.ietf.org/html/draft-lin-ccamp-gmpls-proactive-protection-00 >    
                            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 >                               
 Draft:       
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