Minutes IETF101: teas
minutes-101-teas-00

INSTRUCTIONS:
Please find the related presentation slot below and add/correct notes there.
Please DO NOT add notes at the end or beginning.

NOTE TAKERS ADD YOUR NAMES HERE (not required):

> TEAS Agenda For IETF 101
> Version: Mar 15, 2018
>
> Monday, March 19, 2018 (GMT)
> 09:30 - 12:00 - Wdnesday Morning Session I
> Location:        Park Suite
>
> Slides:        https://datatracker.ietf.org/meeting/101/session/teas
> Etherpad:       
http://etherpad.tools.ietf.org:9000/p/notes-ietf-101-teas?useMonospaceFont=true
> Meetecho:        http://www.meetecho.com/ietf101/teas > Audio stream:       
http://ietf101streaming.dnsalias.net/ietf/ietf1015.m3u > Jabber:       
xmpp:teas@jabber.ietf.org?join > > Available post session: > Recording:       
https://www.ietf.org/audio/ietf101/ > YouTube:       
https://www.youtube.com/watch?v=1HfL8jBtnv8 > > #        Start Time       
Information

> 0        9:30        10        Title:                Administrivia & WG Status
>                         Draft:
>                         Presenter:        Chairs

Loa Andersson: the MPLS WG has not really done an extensive review and
discussion on draft-deshmukh-teas-rsvp-rmr-extension-00, the only discussion
was about the WG the work belongs to. Same for the LDP one. Lou Berger: So
should we have more discussion here before adoption? Loa Andersson: I should at
least allow for it. I've reviewed the document halfway before sending it to
TEAS but that's the only review the document has had so far. It hasn't been
through our usual review team. Lou Berger: The chairs will discuss and get back
to the WG (list) on next steps

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

Robin Li: regarding draft-ietf-teas-pcecc-use-cases, will progress after a
discussion among authors.

> 2        9:50        30        Title:                Yang Data Models -
TE/RSVP >                         Draft:               
https://tools.ietf.org/html/draft-ietf-teas-yang-te-14 >                       
 Draft:                https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-08
>                         Draft:               
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-03 >                  
      Presenter:        Tarek Saad

Lou Berger: make sure all models should properly indicate references to the RFC
defining the function being controlled, particularly when the function is not
defined in the base RFC.  In the case where there is no good reference, please
ensure there is a description adequate for someone less familiar with the
function to understand what is being controlled. Tarek Saad: Good points. We'll
take that as an action item.

Lou Berger: We'd like to wrap this work up soon. There has been a move to go
through models and make sure that the generic pieces are clearly split from
non-generic ones. Please review the documents . As soon as the split is done,
the documents will go to early YANG doctor review and then proceed through the
process, so now would be a really good time for the WG to review them. We don't
anticipate that the technical content will change much at this point.

> 3        10:20        10        Title:                TE Topology and Tunnel
Modeling for Transport Networks >                         Draft:               
https://tools.ietf.org/html/draft-ietf-teas-te-topo-and-tunnel-modeling-01 >   
                     Presenter:        Igor Bryskin

Igor Bryskin: I would encourage people to raise more questions for
definitions/clarifications. We are also looking for additional use cases that 
could be added to the document. Lou Berger: This sort of document is very
important for people coming to the topic fresh as there is a lot of complexity
in the models as we support a lot of different functions. Please read this
document and raise any questions/clafication between the TE-topo model and
TE-tunnel model. This document should help with questions relating to the other
models and if you have questions, it's likely that others will too. This
document is the right place to capture the answers. Igor Bryskin:  We are
introducing new concepts in addition to strict inclusion like desirable
inclusion and optimization, especially on client-specific optimization criteria
which allow the path-computation algorithm to achieve the best possible
trade-off between constraints. These things are not conventional and are not
part of current PCE. We allow for customized objective functions which are not
well defined. Fatai Zhang: I think this draft is very useful for vendors and
operators. In CCAMP we have another similar draft on Transport
NBI(draft-ietf-ccamp-transport-nbi-app-statement) which has similar motivations
behind it. The authors of these two drafts need more discussion and
coordination. Igor Bryskin: I am participating and providing input to the CCAMP
Transport NBI design team and CCAMP members are also active and raising
questions on the TEAS TE work so we are coordinating. Lou Berger: between CCAMP
Transport-NBI document and TEAS document (this document), we're relying on
authors of the two document coordinate each other so that proper material is in
each  document. If they decide it's best to combine the documents, we'll work
with CCAMP chairs to ensure that our process can support such.

42:00
> 4        10:30        10        Title:                Yang model for
requesting Path Computation >                         Draft:               
https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-01 >         
               Presenter:        Sergio Belotti

Lou Berger: this is another document that it would be good for people to look
at and provide comments to the list. If you see areas that you don't think are
adequately covered, that's particularly important to mention.

50:30
> 5        10:40        10        Title:                ACTN YANG applicability
>                         Draft:               
https://tools.ietf.org/html/draft-ietf-teas-actn-yang-01 >                     
   Presenter:        Daniele Ceccarelli

Lou Berger: there is some disagreement on how to support the  CMI, to use the
VN yang and service mapping models or existing models (TE topo/tunnel, etc. )
CMI. It would be helpful if we can have others comment on this. Daniele
Ceccarelli: we have made steps forward in the ACTN VN YANG. Dhruv will explain
next.

56:50
> 6        10:50        10        Title:                ACTN VN YANG
>                         Draft:               
https://tools.ietf.org/html/draft-lee-teas-actn-vn-yang-12 >                   
     Presenter:        Dhruv Dhody

Dieter Beller: we found out that there is another draft in the operations area
WG that also addresses virtual netowrks. Are yo uaware of that? There seems to
be some commonality. The other draft's title is YANG data model for network
virtualization overlay resource management. Dhruv Dhody: I feel the documents
cover differnent things. If I remember correctly that document talked more
about network slicing and doesn't cover VNs as we do. But yes, we need to
coordinate. Dieter Beller: that documetn also defines a traffic matrix,
connectivity, etc Dhruv Dhody: I think that sounds more like something a TE
topology should handle, so we should check ??Daniele Ceccarelli??: I guess the
OPS area draft doesn't deal with traffic engineering, and if it does it's in
the wrong WG. Lou Berger: sounds like a good discussion to have with those
chairs and the ADs. I was not aware of it so thanks for pointing it out. Pavan
Beeram: what's the significance of the bandwidth field> Are those the only
constraints? Dhruv Dhody: those are the customer-facing access links, so
sometimes they're not part of the TE topology if the TE topology is the
provider view of the network. We wanted to make sure that they were present
somewhere, but if you think there's a better place for the information we're OK
with that. As I understood it it wasn't possible to put this in the TE topology
model. Young Lee: this one is possibly not defined by the TE topology because
the access link is only one entity. Here we're talking about an AP so customers
need to maintain a bandwidth partition Pavan Beeram: we'll take it offline - I
still have concerns about using it here. Lou Berger: this is a major update.
Reusing mechanisms rather than defining mechanisms is a great step.
  How many have looked at this version? A reasonable number
  Clearly this is the type of work we should be doing here. How many think this
  work is a suitable foundation for the WG? About the same as those who have
  read it
Keep in mind that this an individual document so it's OK for there to be issues
when we start working on it.
  Does anyone have reservations about adopting this as a WG document? no hands
Thanks for the big step forward. Before we take any action moving the document
forward here we will have to talk to the ops area folks to ensure there's no
conflict

1:18:30
> 7        11:00        10        Title:                ACTN TE Service Mapping
>                         Draft:               
https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-06 >        
                Presenter:        Young Lee/Guiseppe Fioccola

Parviz Yegani: Is there an overlap between these IETF models and the MEF LSO
interfaces? Young Lee: MEF LSO has LEGATO but not yet data models. MEF is
currently working on information model. We can provide the YANG model for MEF
if they want to have a liaison with the IETF. Jeff Tantsura: MEF models are not
open to those who are not participating to MEF. I think they'll eventually use
IETF models because someone has to write the model. Pavan Beeram: I think this
WG should be working on a generalized service mapping function, but I don't see
why it needs to be under the ACTN umbrella, but let's see how the previous
document progresses. Young Lee: this is not under the ACTN umbrella Pavan
Beeram: I think it is at the moment, but let's see how the other document goes
and we can revisit this. Lou Berger: it would be helpful to make it clear that
this applies to all TE. Pavan Beeram: I don't understand the slide with ACTN-VN
in a box. I understand how you map onto an ACTN VN but I'd like to see a
generic discussion. Young Lee: OK. Dhruv Dhody: One source of confusion here is
that when we were writing this document we were focusing on CMI where we're
seeing the L2SM model and service model being mapped to a single thing. On the
device side you may want to bind a VRF to a tunnel and that would be a  bit
different becasue that mapping is on the device. I think it's good to
differentiate between looking at the service model and when we're looking at
the network and the device model. Lou Berger: I think this goes to the
disconnect earlier where some see the TE topology as equally applicable as a
service model as it is on a device. I think we have a difference of
perspectives here that we have to work through. We can have more discussions
here but some getting together offline might also be necessary. Dhruv Dhody: in
this model, if we don't want to go via ACTN VN and want to look at the TE
topology abstract node nothing will stop you. The difference is that when
you're mapping the L3SM that has to be at the higher level. If you have VPN and
VRFs we need to work out how to map those to the TE topology Igor Bryskin: I
agree that the service mapping problem has to be solved in a general way. As an
example, we have a lot of discussions in the ethernet layer on how to map EPL
services and EVPL services onto tunnels as well, and they have the same issues
as we have here. I think that TE tunnels and topology should be decoupled from
the services. So you have one service model in which a network-wide model like
a L3 VPN network is described, and then you have a device-specific model that
describes how to map, for example, service on a particular PE to a tunnel. Then
you have the tunnel model which is completely separate. Policies are just one
part of service mapping, and there are other policies that are not our job to
discuss, e.g. connectivity constraints, or how to translate LAN IDs from the
customer to LAN IDs in the network. These are very generic issues that need to
be discussed separately; it would be good to have some kind of
service-independent agnostic model that provides various divisions, e.g. key
policies like connectivity. I would strongly suggest we decouple the TE tunnels
from the services. We need an infrastructure that can service requests like a
L2VPN with a delay constraint so that appropriate TE tunnels can be established
to meet this need. Young Lee: I agree. This is more or less what the L3VPN guys
are saying, e.g. they want a service with a specific latency and it has to be
deterministic, without any variation of queue delay. Then we can create a TE
tunnel and the customer can monitor it in a closed loop through telemetry. Igor
Bryskin: There's duplication of what you specify as a TE policy vs what you
specify as key constraints. The customer may specify reliability of a service
or diversity of two services and this could be translated into, say, an SRLG to
join, but the customer doesn't know what that means or which SRLG to join - he
only cares about availablity. We have to have a service mapping to translate
this into how tunnels can be set up on the network. Adrian Farrel: I think Igor
nailed it there and the generalization of that statement is that the service
model is not aware of the content of the network, and somewhere you need a
model that is aware of the content of the network. There may also be a loop
where as you stack networks (which is what ACTN is about) the TE tunnel request
at one level may become a p2p connection request back down to another network,
and then the whole thing reverses. Young Lee: I think that's exactly why TE
service mapping is needed, because the service model doesn't address how TE
should be constructed. That's why we need this glue between the two worlds so
the customer can have visibility into the underlay and monitoring capabilities
in a closed loop. Jeff Tantsura: So it maps service-level objectives into a
physical path through the network Lou Berger: it sounds like there's an
opportunity for some really good input into this document, so please work with
the people who made the comments to capture that.

1:38:50
> 8        11:10        10        Title:                Use Cases for SF Aware
Topology Models >                         Draft:               
https://tools.ietf.org/html/draft-bryskin-teas-use-cases-sf-aware-topo-model-02
>                         Presenter:        Igor Bryskin

Tarek Saad: The way you've modelled the service function is as a property of a
node. Can it not be a stand-alone elsement rather than being hosted on a node?
Igor Bryskin: Node here could mean an abstract node that could be e.g., a data
center abstracted as node attachement. Node is not necessarily a switch or
router. Fatai Zhang: The examples in this draft all apply to packet networks.
Is it applicable to transport networks, such as WSON and OTN? Igor Bryskin:
Yes, we've tried to add use cases to the draft to illustrate this. We have 3R
generators as an example for layer 1 or layer 0. There are other examples like
OAM capabilities that require hardware support from the OTN network which is
not readily available on all devices. These can also be modeled as network
functions so that TE tunnels can be routed in the best way. Fatai Zhang: could
you please add into draft Igor Bryskin: Yes. I think we have six or seven
already. Himanshu Shah: You have SFC with TE constraints. What about the
service constraints themselves, e.g. replications and availability of the
services? Does that affect the topology? Igor Bryskin: No. The point is that
we're trying to build this model as an augmentation to the TE topology model.
This model will provide the identity of the functions in the network as well as
constraints on how they could be connected. Himanshu Shah: but say, for
instance, you have a firewall which is utilized 90% and so you only have 10%
availability. There could be other places where it's available, so does your
topology change based on the service availability or utilization? Igor Bryskin:
This is a good point. We haven't considered service attributes as we hoped that
this could come from models like Tosca. It might be an idea to separate
connectivity from the actual resources available to a function. We'll consider
that. Parviz Yegani: We're looking into separating the service layer in our
information model. The information model includes the service function and the
topology graph, and that graph drives the service layer connectivity. There's a
separation of the information model from the data model that describes the
actual network. have you considered the info model, as SF is different from
network model, an info model may be useful than a data model. Igor Bryskin: we
want to decouple service models from topology models but we also want to allow
them to be combined to produce this dual optimization. I dont' like very
complex yang models; I prefer to have simple ones that can be interrelated.
Some clients may be only interested in limited things and may not want to have
to handle large and complex models. Lou Berger: Keep in mind that this is a
use-case document, not a solution document, so we have to focus on the use
cases first Jeff Tantsura: there's a difference between network-driven
application and application-driven network, and we should look at it from the
perspective of a network-driven application. Lou Berger: we should determine
whether the WG wants to work on this type of solution.
    how many support to work on this type of solution? <a reasonable number>
    how many think this document is the good place to start? <a reasonable
    number> how many has read this document ? <slightly more>

> 9        11:20        10        Title:                SF Aware TE Topology
YANG Model >                         Draft:               
https://tools.ietf.org/html/draft-bryskin-teas-sf-aware-topo-model-01 >        
                Presenter:        Igor Bryskin No presentation/combined with
previous topic.

2:06:00
> 10        11:30        20        Title:                Framework for Traffic
Engineering with BIER-TE forwarding >                         Draft:           
    https://tools.ietf.org/html/draft-eckert-teas-bier-te-framework-00 >       
                 Presenter:        Toerless Eckert

Lou Berger: This is early work but well aligned with other work in the working
group and there are a lot of common ideas.
  How many have looked at this? (reasonable number)
  How many who haven't looked at it are interested in learning more? (some)
Seems like there's good alignment and good interest.

2:21:50
> 11        11:50        10        Title:                Hierarchy of IP
Controllers (HIC) >                         Draft:               
https://tools.ietf.org/html/draft-li-teas-hierarchy-ip-controllers-00 >        
                Presenter:        Dhruv Dhody

(no comments)
Lou Berger: no joint session this time. Thanks for coming!

> Adjourn        12:00