Minutes IETF99: teas: Tue 09:30
minutes-99-teas-201707180930-00

> TEAS Agenda For IETF 99
>
> Tuesday July 18th 2017
> 0930-1200  Morning Session I
> Grand Hilton Ballroom
>
> Slides:    https://datatracker.ietf.org/meeting/99/session/teas
> Etherpad: 
http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-teas?useMonospaceFont=true
> Meetecho:  http://www.meetecho.com/ietf99/teas > Audio stream:
http://ietf99streaming.dnsalias.net/ietf/ietf996.m3u > Jabber:   
xmpp:teas@jabber.ietf.org?join > > Available post session: > Recording:
https://www.ietf.org/audio/ietf99/ > YouTube:  
https://www.youtube.com/user/ietf/playlists > > > Num Start #Min Information >
0   9:30   10  Title:  Administrivia & WG Status >                Draft: >     
          Presenter:  Chairs

Lou Berger: IETF Note Well has changed recently. In particular, we have new IPR
disclosure document (RFC8179)

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

(regarding draft-ietf-teas-scheduled-resource)
Julien Meuric (PCE Chair hat): PCE WG has already adopted the solution draft.
No identified showstopper during the adoption call so nothing to prevent TEAS
progressing the document. Lou Berger: The reason for us to wait was to ensure
that the general direction of this draft is correct; it sounds like the PCE WG
thinks that it is. Pavan Beeram: (poll) How many have read the latest version
of this: a few
              How many think document is ready: about the same
       (conclusion) we'll take it to the list [for confirmation]

> 2   9:50   10  Title:  Recommendations for RSVP-TE and Segment Routing LSP
co-existence >                Draft: 
https://datatracker.ietf.org/doc/draft-ietf-teas-sr-rsvp-coexistence-rec/ >    
           Presenter:  Harish Sitaraman

Lou Berger: (poll) How many have read draft? (a few)
                   How many think document is ready? (about the same)
                   Does anyone think there are outstanding issues? (none)
            (conclusion) we'll take it to the list [for confirmation]

> 3   10:00  15  Title:  YANG Data Models - TE Topologies
>                Drafts: 
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ >               
         https://datatracker.ietf.org/doc/draft-liu-teas-yang-l3-te-topo/ >    
                   
https://datatracker.ietf.org/doc/draft-liu-teas-yang-sr-te-topo/ >             
  Presenter:  Xufeng Liu

TE Topology:
Lou Berger: do you have any concerns with the alignment with I2RS?
Xufeng Liu: no pending issue with I2RS alignment. They have agreed on the
changes needed so we can augment their model. Lou Berger: any other outstanding
issue, that may impact the process of this work? Xufeng Liu: we don't see any.
Lou Berger: This model defines some types that are used by other TE models?
Xufeng Liu: we have moved all the types in the te-type module Lou Berger: So is
there anything that prevents this document moving forward? Xufeng Liu: we have
a few references to other models (TE tunnels, netmod scheduling) Lou Berger:
informational references are fine. Do you think it makes sense to hold this
document waiting for the TE Tunnel? Xufeng Liu: I do not think we need to wait
Lou Berger: how many have read this version? A few, more than I expected
     how many have read any version? A good number
     how many think the document is ready for WG LC? More than those who have
     read this version
Lou Berger: We'd like to progress this as rapidly as possible. Given the amount
of changes in the last version, we are thinking about having an extended WG LC

L3 TE Topology:
Lou Berger: (poll) How many have read any version of this draft: a few
                   How many think document is a reasonable foundation for the
                   WG: about the same
            (conclusion) we'll take it to the list [for confirmation]

SR and SR TE Topology
Lou Berger: (poll) does the WG think we should be working on this? A reasonable
number.
            How many have read draft: a few
            How many think document is a reasonable foundation for the WG:
            about the same
Daniele Ceccarelli: why should a NMS care whether a topology is using SR or not?
Xufeng Liu: we have generic topology model and technology-specific (as SR) for
different topology. Daniele Ceccarelli: So the TE topology is enough if I don't
care about the dataplane, and if I want to know that there's a SR dataplane I
can get that information? Xufeng Liu: Yes. Lou Berger: Back to the polling:
conclusion is that we'll take it to the list [for confirmation]

> 4   10:15  15  Title:  YANG Data Models - TE Tunnels and Interfaces, RSVP-TE
>                Drafts: 
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ >                    
    https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp-te/ >           
    Presenter:  Rakesh Gandhi

Igor Bryskin: TE Topology and TE Tunnel model have a lot of commonalities and
are complementary and so people could assume they can only be used together,
but they could be used independently. It therefore doesn't make sense to hold
back the TE Topology model waiting for TE Tunnel, or vice versa. Lou Berger: do
you have any specific concern on structure of the models and dependencies
between them? Igor Bryskin: we designed the model carefully, and no issue found
at this moment. We have the same group of people working on both models. Lou
Berger: What needs to be done before documents are ready for LC? Rakesh Gandhi:
the RSVP model is stable; we just need to make updates for NMDA. Lou Berger: so
the plan is to update the structure for NMDA and then ask for last call? Rakesh
Gandhi: yes Lou Berger: Please let the WG know when these updates are complete
and ready for LC Lou Berger: (poll) How many people have read these docs?
(about the same as the previous drafts)
            Does anyone have any reservations on this set of documents? <none>
Dieter Beller (via jabber): support moving forward

> 5   10:30  10  Title:  Framework for Abstraction and Control of Traffic
Engineered Networks >                Draft: 
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ >             
  Presenter:  Young Lee

Pavan Beeram: let's discuss the WG LC after the requirements and abstraction
methods documents Lou Berger: how many have read this document? More than the
other documents; a good number

> 6   10:40  10  Title:  Requirements for Abstraction and Control of TE Networks
>                        Information Model for Abstraction and Control of TE
Networks >                Drafts:
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements/ >          
             https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/
>                Presenter:  Sergio Belotti

Pavan Beeram: do we need to progress the info model before the TE Tunnel yang
model? Sergio Belotti: I think the document is stable, we have just fixed some
mistakes we have discovered while working with TE Tunnel Lou Berger: I am
asking whether info model depends on TE Tunnel model Sergio Belotti: I do not
think so. The info model can precede the TE tunnel model. Young Lee: info model
is very high level so that TE tunnel model details are not affecting the info
model. Haomian Zheng: I also think the models are separate and don't need to
progress together. Lou Berger: how many have read the requirements? A good
number
     how mnay have read the info model? Still a good number, but less
     how many think the info model is ready for WG LC? Almost the same number
Lou Bergber: Pavan and I will talk offline and discuss whether we should link
the documents or not. Daniele Ceccarelli: in any case, I think the correct
order is requirements, then framework, then info model.

> 7   10:50  10  Title:  Applicability of YANG models for Abstraction and
Control of Traffic Engineered Networks >                        Abstraction and
Control of TE Networks (ACTN) Abstraction Methods >                Draft: 
https://datatracker.ietf.org/doc/draft-zhang-teas-actn-yang/ >                 
      https://datatracker.ietf.org/doc/draft-lee-teas-actn-abstraction/ >      
         Presenter:  Daniele Ceccarelli

Applicability of YANG models to ACTN:

Lou Berger: Previously, content like this has been part of the framework. Do we
need a separate document or could we move this material to the framework draft?
Daniele Ceccarelli: This is not just gap analysis; it's guidelines and
applicability. We've discussed whether this document needs to be informational
or standard-track. Lou Berger: so now that you've decided not to make it
standrad-track, why not bring it in to the framework? Similar to the TP control
plane document. Daniele Ceccarelli: that would make for a very large framework
document. Lou Berger: so it is better to have one large document, or two
separate ones? Haomian Zheng: current framework draft is self-contained and
complete, we don't need to include every possible solution/gap/applicability in
the framework. Moving the corresponding work into framework will be endless and
make the framework document too heavy. We suggest to move the framework first,
and then look at this applicability analysis to be aligned with both ACTN
framework and IETF YANG model. Young Lee: I agree with Haomian. Framework is
technology independent and in PCE WG we have applicability of ACTN to PCE, and
we don't want to tie the applicability data model in this WG to the framework.
Daniele Ceccarelli: even if this is applicability, in the end it's the solution
to the problem identified by the framework. Lou Berger: do you think we need to
wait for other documents before progressing it? Daniele Ceccarelli: Making a WG
document can be done without any dependency. Lou Berger: I'm jumping ahead
because if we're going to end up holding it up, that strengthens the argument
to keep it as a separate document. If not, it doesn't matter. Daniele
Ceccarelli: I would wait for the mandatory functionality to be approved before
progressing it. Jeff Tantsura: This document should stay informational. Also,
this doesn't describe how the models interact together, and there's additional
work required to do that for the people who will implement it. Lou Berger:
(poll) how many people think it makes sense to move this into the framework?
zero
            (conclusion) sounds like that's the way to go.
Lou Berger: (poll) how many people this information is needed? A reasonable
number
     how many have read the docuemnt? almost the same
     how many think it is a good foundation? almost the same
     conclusion: take to the list

ACTN Abstraction Methods

Pavan Beeram: to confirm, last time it was mentioned to integrate into the
framework, now are you still prefer to have this separate draft? Daniele
Ceccarelli: Yes. Lou Berger: it would be good to discuss why there's value in
keeping it separate. It's almost as if the framework and requirements can't
stand alone without this document. Daniele Ceccarelli: to read the framework
you need to understand the concepts of black, white and grey topologies which
is now in the framework but not all the other details in this document. Lou
Berger: it seems unnecessary. Last time the WG agreed that this was good
material. It seems that it would be natural to incorporate it into the
requirements and framework docs. Daniele Ceccarelli: I don't have strong
objections. I don't want to overload the framework document. Young Lee: I think
that the remaining content of this document is quite advanced material that a
reader of a framework should not necessarily need to read Lou Berger: I am
thinking at least about the abstraction factors to be moved in the framework
draft Haomian Zheng: there is enough information in the framework draft about
abstraction and the basic terminology. This draft discusses how different
methods may be used to do the abstraction and I think that's different. I
suggest moving the framework draft first and new abstraction techniques can use
that as a reference. Michael Scharf (speaking for Dieter Beller): there is a
risk of inconsistencies with many documents, so it would be good to reduce the
number if possible Lou Berger: how may people would object to moving this
material into existing ACTN WG documents? (no hands) Young Lee: whether this
goes to the framework doc or not, I don't want the process to be delayed again.
If we merge this, can we still proceed to WG LC for the framework? What's the
Chairs' position on this? We don't want to wait until the next IETF. Lou
Berger: my position is that it would be best to produce the best document that
the WG can. If that's by a simple cut/paste that's great, but I would think
that a real integration would produce a better document. We'll LC the document
when it's ready; we won't LC it until then. I can't make any promises. I think
we should do the right thing rather than drop text in to move the document past
a milestone. Italo Busi: I share the concerns about moving this information to
the framework since it is too much advanced for a framework but I do not see
any other WG document where it can be moved, so I'd prefer to keep it separate
for now. We might merge into this document any future advanced ACTN topic. Loa
Andersson: I didn't raise my hand to object, but I was very close to it. I
dont' really see the implications of merging the documents. We should do what's
reasonable, but the question is probably too involved for an open meeting. Jeff
Tantsura: I'm in favor of merging, given that the content definitely aligns;
I'm against a simple copy-and-paste. I think the detail could go in an appendix
while the use cases should be a sub-section in the framework. Daniele
Ceccarelli: the whole text could go to an appendix Lou Berger: since you're
interested in trying to make it work, have a go at it. It the authors like it,
they can publish as a new revision; if not, put it somewhere for people to look
at and see what the WG thinks. It's tough to talk about hypotheticals.

> 8   11:00  10  Title:  A Yang Data Model for ACTN VN Operation
>                Draft: 
https://datatracker.ietf.org/doc/draft-lee-teas-actn-vn-yang/ >               
Presenter:  Dhruv Dhody (remote) (presented by Young Lee due to remote
communication issues)

Michael Scharf: from my understanding, type 1 and type 2 is quite different,
and why we must have the same model to describe them? From a customer
perspective the use of VNs 1 and 2 seems different. Young Lee: all containers
are optional in the YANG model so you can pick and choose. Dhruv Dhody: the
first reason is, if you look at the VN model, the only difference between type
1 and type 2 is a reference to the abstrct TE topology, so the yang model
constructs are the same irrespective of how they're used. You just have an
extra mechanism for type 2. I agree that they look different at a higher level,
but they look very similar in the yang model. Michael Scharf: for me, VN1 is
just a list of tunnels and there's no added value in that. Do we really need a
yang model for it? There are also other ways to do things, e.g. adding policy
to a list of tunnels - you don't need a yang model for that. Same with path
calculations for multiple tunnels - you can do this in software. Dhruv Dhody:
main question is: as a customer, what's the best way to communicate my
requirements to a service provider? In the framework, everything's referenced
in terms of the VN, so shouldn't we use the same construct in the yang model?
Michael Scharf: Just adding one identifier to a list of tunnels doesn't give a
lot of benefit. Do we really need a YANG model for this sort of list? Igor
Bryskin: tend to agree with Michael, the concern is valid, because client
usualy need to specify how they want to use the Tunnel/resource. The topology
is sufficient for this Young Lee: That's exactly why type 1 and 2 are
differentiated; you're referring to type 2. Some clients don't need the
complexity so they would choose to implement only the type 1 where clients
don't need any of network details just expressing their service policy and
QoS/SLA for their e2e connectivity. Igor Bryskin: If I have a set of OTN
tunnels, how can I use them? Can I send ethernet traffic, or SDN traffic? How
does the client know that? Lou Berger: Sorry to cut off an interesting
discussion, but we're running late. Please continue discussing on the list.
Let's not wait until the next meeting.

> 9   11:10  10  Title:  Traffic Engineering and Service Mapping Yang Model
>                Draft: 
https://datatracker.ietf.org/doc/draft-lee-teas-te-service-mapping-yang/ >     
          Presenter:  Dhruv Dhody (remote)

Lou Berger: this module has a dependency on the VN model?
Dhurv Dhody: yes
Michael Scharf: The L3SM model (RFC 1849) is more complex (e.g., a site can be
multi-homed, cloud access) and I do not see how this model would work in more
complex cases Dhruv Dhody: I agree and I would provide more text to clarify
this point Lou Berger: If we just want to add TE to the L3 service model, why
does it have to be specific to how L3 is supported? Do you really need to know
the internal details? Jeff Tantsura: we need the reverse feedback. It's missing
at the moment. Dhruv Dhody: you can use telemetry to get the feedbacks (next
presentation) Young Lee: To address Lou's question, this model does not
necessarily depend on VN YANG model since we can use the TE Tunnel model
instead as an option (in case statement) to provide the mapping Lou Berger: we
should discuss further on the list.

> 10  11:20   5  Title:  YANG models for ACTN TE Performance Monitoring
Telemetry and Network Autonomics >                Draft: 
https://datatracker.ietf.org/doc/draft-lee-teas-actn-pm-telemetry-autonomics/ >
               Presenter:  Young Lee

Lou Berger: Does this depend on VN YANG model?
Young Lee: We have two modules, one that augments TE tunnel model and the other
that augments VN YANG model. Lou Berger: Further discussion to the list, but
could consider moving some of this into the base TE tunnel module.

> 11  11:25  10  Title:  TE Topology and Tunnel Modeling for Transport Networks
>                Draft: 
https://datatracker.ietf.org/doc/draft-bryskin-teas-te-topo-and-tunnel-modeling/
>                Presenter:  Igor Bryskin

Lou Berger: it looks a good and useful informative text
Lou Berger: how many thinks it is a useful document: a good number
     how many have read the document: almost the same number
     how many think the WG should take it: a little bit less
     conclusion: take to the list

> 12  11:35  10  Title:  Use Cases for SF Aware Topology Models
>                Draft: 
https://datatracker.ietf.org/doc/draft-bryskin-use-cases-sf-aware-topo-model/ >
               Presenter:  Igor Bryskin

(no time for discussion)

> 13  11:45  10  Title:  CCDR (Centrally Control Dynamic Routing) Scenario,
Simulation and Suggestion >                Draft: 
https://datatracker.ietf.org/doc/draft-wang-teas-ccdr/ >               
Presenter:  Aijun Wang (Remote)/Sun Qiong/Li Chen (presented by Lu Huang due to
remote access issues)

Lou Berger: do we want to discuss TE for native IP in this WG? Our charter is
TE, and we have things like MPLS and SR in scope. Julien Meuric: I still
struggle to map this to my actual operational needs, so at this stage my answer
is no Lou Berger: are you saying no to the specific proposal or to the topic?
Julien Meuric: the way it is presented today is no, if the problem is better
explained, I can change my position Michael Scharf: This a good starting point,
but other IP solutions exist and it is not clear what the value of this
solution is compared with those Zhong Chen? (China Telecom): we have a big IP
network and need a solution for this problem Lou Berger: I think for the group,
talking more about what is the problem you are trying to solve would be useful
before jumping to a solution Deborah Brungard (AD hat): it is a very early work
so it is difficult to judge if it fits or not. We need to more more specific
about the problem and use case Lu Huang: We have both pure IP and MPLS
networks. An MPLS-TE solution would not fit for our existing IP networks Lou
Berger: I think there's a problem to be solved here, but we need a bit more
education. Please discuss further on the list. At the moment people are
disagreeing with the solutions, so maybe discussing the problem will get more
people on board.

Lou Berger: we're over time. See you on Thursday

> 14  11:55   5  Title:  BGP Community based PCE in native IP network
>                Draft: 
https://datatracker.ietf.org/doc/draft-huang-teas-bgp-community-pce >          
     Presenter:  Lu Huang (not presented) > Adjourn 12:00

Minutes by: Haomian Zheng, Italo Busi, Matt Hartley