Minutes IETF102: teas
minutes-102-teas-00

TEAS Agenda For IETF 102

Version: Jul 17, 2018

Wednesday, July 18th 2018
09:30 - 12:00 - Wednesday  Morning Session I
Location:  Centre Ville

Slides:  https://datatracker.ietf.org/meeting/102/session/teas
Etherpad: 
http://etherpad.tools.ietf.org:9000/p/notes-ietf-102-teas?useMonospaceFont=true
Meetecho:  http://www.meetecho.com/ietf102/teas Audio stream: 
http://ietf102streaming.dnsalias.net/ietf/ietf1021.m3u Jabber: 
xmpp:teas@jabber.ietf.org?join

Available post session:
Recording:  https://www.ietf.org/audio/ietf102/
YouTube:  https://www.youtube.com/watch?v=340B3qS1pDc

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

Deborah Brungard: re ACTN: the framework has surpassed the requirements and
provides much more detail, so we need to figure out whether or not we need to
publish the requirements separately. The AD watch list is a way to let the
requirements doc die if need be. Lou Berger: if you think there's important
text there please lift it and put it in other documents.

0:07:20
1     9:40  10  Title:  WG Draft updates
Draft:  Many
Presenter:  Chairs

Pavan Beeram: We (Chairs) are considering the need for a document giving an
overview of the IP MPLS-TE networking landscape. Currently we refer people to
RFCs 3272 and 7926. If anyone's interested in contributing, please get in
touch. Dhruv Dhody: I'll be taking on the editor role for PCECC use cases to
progress the draft Adrian Farrel: the use cases was to support RFC8283 and the
IESG doesn't really like use-case documents. I'd prefer to let it die and
remain as an archival record Lou Berger: there are various ways of creating an
archival record. Why stop the work? Why not take it to WG LC and see what
happens there? Adrian Farrel: OK. I was just trying to save Dhruv some work Lou
Berger: use-cases are a good way for people to contribute to the WG, and we're
always trying to get people to contribute. I don't think we should devalue that
work. Deborah Brungard: ensure the doc is strong and has support from the WG
and Chairs, and I'll do my best to take it through the IESG. But the IESG will
push back. Make sure it isn't something that will be irrelevant in five years.
Dhruv Dhody: my immediate goal is to just correct and update the doc, and then
we can discuss what to do with it. Igor Bryskin: I agree with Adrian. A
use-case doc helps to understand the requirements, which help the framework...
but by the time you have a solution the use-cases aren't much help except as an
aid to understanding the work. Deborah Brungard: one aspect from the IESG's
point of view is that they see use-case docs as delaying solution work. Make it
clear that the solution work is in progress when the use-case doc is submitted
to them.

0:17:40
2     9:50  15  Title:  Yang Data Model - Traffic  Engineering Tunnels and
Interfaces Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-te-16
Presenter:  Tarek Saad

Lou Berger: RFC process question: if we extract the types module, can we just
change the name of a document that's in refwait state? Deborah Brungard: talk
to the RFC editor about that. Loa Andersson: is it the yang naming or the
datatracking naming that's a problem? Lou Berger: datatracking Loa Andersson:
you can sort that out with a "replaced by" Lou Berger: the problem is that the
new doc has the same name. Other problem is that there's a doc in refwait in
the RFC editor queue that will need a change to reference the new types doc
we're going to create. I'm not sure if we can do that. Loa Andersson: I think
we've done that before Lou Berger: that's good to know Dhruv Dhody: You only
discuss the association types defined in RSVP. What's the plan for the
association types defined in PCEP? I'd prefer they all be in one place Tarek
Saad: there are additional association objects in drafts at the moment and we
haven't defined those yet. For the PCE ones in RFCs we will look into it. Or
another module could extend this one and add those. Julien Meuric (Meetecho):
The association mechanism in PCEP passed PCE WG LC. It will soon move. Dhruv
Dhody: why define two lists for basic and extended Associations? With YANG you
could have only one list making the Extended Association ID optional. Tarek
Saad: we have the problem of having unique keys so we decided to split into two
lists. We are open to consider better alternatives. Lou Berger: the yang
doctors will help with encoding things in the right way.

0:31:00
3     10:05  10  Title:  TE Topology and Tunnel Modeling for Transport Networks
Draft: 
https://tools.ietf.org/html/draft-ietf-teas-te-topo-and-tunnel-modeling-02
Presenter:  Igor Bryskin

Daniele Ceccarelli: do we need multi-domain TE tunnels? Isn't it a P2P virtual
network? Igor Bryskin: no, a single tunnel could go through several domains, so
if you have a super-controller overseeing the entire network it treats it as a
tunnel, but the domain controllers need to be told what to do. Daniele
Ceccarelli: how is it different from stitched tunnels? Igor Bryskin: the tunnel
looks very different in different domains, e.g. in a transit domain it just has
labels at each end. Daniele Ceccarelli: but this is just implementation Igor
Bryskin: that depends on how you look at it from the client's point of view. It
looks different to the super-controller vs the individual domain controllers.
Italo Busi: I think you're missing the difference between CMI and MPI. VN (type
1) is the request at the CMI from the customer. Multi-domain TE tunnel is the
way MDSC should implement the request at the MPIs toward different PNCs.
Daniele Ceccarelli: why do you need this concept at the mpi level? why can't
you just ask for an intra-domain tunnel from teh domain controller? Igor
Bryskin: we're talking about inter-domain tunnels Lou Berger: we're providing a
toolbox here with the tools that operators can use to do what they want.
Daniele Ceccarelli: I think you do not need the multi-domain TE Tunnel since
there is another solution Igor Bryskin: the confusion is the level at which you
control tunnels. We use the same model for all levels. Lou Berger: vendors
implement things differently and carriers use things differently, so we should
support both ways of doing things Lou Berger: something we did in TE topology
because of its complexity is that we added a section on how it should be
augmented in future (e.g. for technology-specific extensions), which is already
being used in other WGs. Should we do that here too? And in Tarek's documents,
or this one? Igor Bryskin: any model could be augmented, so if we need this
section then all models should have it. I think this document is the right
place for it if we do Tarek Saad: we're defining a technology-agnostic model,
so we need to say how to augment it for different technologies Lou Berger:
we're defining very complex modules in this group. The fact that we need this
guidance and other modules don't is OK (and that's speaking with any hat on,
including Netmod Chair). Which document we do it in is up to the authors. Igor
Bryskin: We have sections on how we do abstraction of the topology model. How
you do augmentation comes under the same category. Lou Berger: I think Tarek
said this should go with the document that defines the module, and that sounds
reasonable.

0:46:30
4     10:15  10  Title:  Yang model for requesting Path Computation
Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-02
Presenter:  Sergio Belotti

Igor Bryskin: I do not advocate this approach (dropping configuration
parameters from path computation request). The logic is when you ask for a path
with contraints the tunnel will take the path returned by the computation. But
there are use cases where local policy is then applied. If we drop this from
the path computation request there's a chance the tunnel could use a different
path to that returned. So we don't lose anything by keeping things like tunnel
name in the request, but we allow the server to do the same thing for the
tunnel as the client would. Dieter Beller: I don't understand why we need
specific parameters to support policy- or constraint-based path computation
without modeling it explicitly. I'd prefer clearly defined policy rules and a
path computation request can include an identifier for the policy to apply.
Using input parameters that aren't obviously related to policy isn't a good
approach Italo Busi: the user may not use the policy and even if you add these
attributes you get the same problem. If the server has the atribute and the
user doesn't provide it you get false results. We need a very clean design and
specify that these attributes are required. The risk is that the user will use
the model in the wrong way if it isn't clear. Igor Bryskin: this is the point.
The client isn't supposed to know the local policies in the operator networks.
The idea is to get the same path for the same tunnel/path computation request
each time Lou Berger: are you asking for these parameters to be required or
optional? Igor Bryskin: all parameters are optional, but I want an option to be
able to specify everything Dhruv Dhody: in PCEP you can include the LSP
identifier if you want, and when you do that you identify the path calculation
as being for a specific LSP or tunnel. We can do similar here. Sergio Belotti:
but it's explicit there, not hidden Lou Berger: should we do a straw poll of
the room on this?
  who would like to go with the authors' recommendation? A few
  who would like to go with Igor's approach and include these as optional
  params? More
Lou Berger: so more for the optional params, but it's not overwhelming. We
should take it to the list. Sergio Belotti: we should discuss on the list, and
also talk about use cases for each option. Lou Berger: reminder - the editor of
a WG document is responsible for reflecting the WG consensus, even if it isn't
their own opinion. You're welcome to argue your case as a contributor Italo
Busi: we need to provide good guidelines on how to use the model so people
don't do it wrong.

1:04:15
5     10:25  10  Title:  Yang Data Models - L3 TE Topology / SR TE Topology
Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-02
Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-02
Presenter:  Xufeng Liu

Lou Berger: as you update the SR documents, please send updates to SPRING to
tell them the work is progressing Xia Chen: will the SR draft include
multi-domain scenarios? How do we include cross-domain information? Xufeng Liu:
TE handles multi-domain, so it will be similar in SR. Igor Bryskin: do we need
a section on how to augment this? Lou Berger: I'd expect this to follow the TE
topology augmentation guidelines. If you think this will be augmented a lot,
then yes, add guidelines. Igor: how would we know? Lou Berger: use your best
judgement as technology experts Xia Chen: I think the SR is different from
RSVP-TE multi-domain, so you need to handle that. Xufeng Liu: we should discuss
why the base topology model can't handle that

1:13:50
6     10:35  10  Title:  SF Aware TE Topology Model - Use-Cases / Yang Model
Draft: 
https://tools.ietf.org/html/draft-ietf-teas-use-cases-sf-aware-topo-model-00
Draft:  https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-01
Presenter:  Young Lee

Lou Berger: if the documents are ready at the same time putting the use cases
as an appendix in the solution may be a good idea. But don't hold anything up.
Igor Bryskin: question for Chairs/AD: we have a challenge here. We don't want
to overstep the tools that describe Service Function types, etc so we're hoping
we can identify the SFs by global IDs that define what a SF is doing and how
close in functionality it is to others. Do we wait until the necessary work is
done elsewhere or repeat what they're doing and throw the work away when it's
not needed any more? Adrian Farrel: this isn't the first time this question has
been asked at the IETF. Other WGs are also working on SF chaining. What we did
in BESS was to have a single integer identifier of the type of the SF and apply
no interpretation of that in anything we touch, so then you can use other
mechanisms to describe the SF and index that to your identifier. Young Lee:
that's already iin the model Igor Bryskin: the problem is if we want to replace
one SF with another, what's the extent to which it could be done? Lou Berger:
from a Chair perspective, what you're doing goes beyond this WG's scope. I'm
not sure if it goes beyond the IETF's scope or not - could talk to ADs about
that. Maybe this is where you put augmentation guidelines in. Pavan Beeram:
keep the SFC WG in the loop on this.

1:26:00
7     10:45  15  Title:  RSVP Extensions for RMR
Draft:  https://tools.ietf.org/html/draft-ietf-teas-rsvp-rmr-extension-01
Presenter:  Abhishek Deshmukh

Lou Berger: rings seem to be hot at the moment - we had presentations on them
in DETNET and MPLS too. We should see if there's overlap and make sure we
aren't stepping on each others' toes.

1:36:45
8     11:00  10  Title:  PCE in Native IP Network
Draft:  https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-01
Draft:  https://tools.ietf.org/html/draft-ietf-teas-native-ip-scenarios-01
Presenter:  Aijun Wang

Lou Berger: have you considered the work in DETNET on IP TE flows?
Aijun Wang: DETNET work needs a forwarding plane change, and we want to use our
existing devices in our network. We'd prefer to just have a control plane
change as it's easier to deploy. Lou Berger: from the WG standpoint you should
consider it as it'll be coming in. And current forwarding planes support
policy-based routing mechanisms.

1:45:50
9     11:10  10  Title:  ACTN VN YANG
Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-01
Presenter: Dhruv Dhody

(no questions)

1:48:10
10     11:20  10  Title:  ACTN TE Service Mapping
Draft:  https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-09
Presenter:  Daniele Ceccarelli

Igor Bryskin: Same point as I raised in CCAMP: we need a generic framework for
this binding relationship between services and tunnels. There should be a
framework that describes how we bind services to tunnels, either specifically
or based on policy or preferences. Daniele Ceccarelli: I think this is already
partially described. We had a previous discussion on whether to do this per
service model or something more generic. Igor Bryskin: You're describing
bindings at the interface between client and network. I'm looking at something
more generic that coudl happen at any node in the operator network. Lou Berger:
we're rehashing a debate we had at the last meeting. There was supposed to be
offline discussion about this. Young Lee: this is different - we're talking
about CMI Lou Berger: It sounds like that discussion didn't happen, so please
spend time with the people who made comments last time and this time and sort
it out. If you decide you're talking about different things, that's OK. We
should not have the same comments over and over again. Adrian Farrel: Lou has
asked me to look at this as Techincal Advisor. I think we've dropped the ball
on this discussion so we (authors and other participants) need to sort that
out. I think something that's missing from this document is to understand the
flow of information between different components. We need a description of
where this new model fits. Daniele Ceccarelli: this fits at the CMI. Adrian
Farrel: that will help decide whether this is an augmentation of the service
models or not. Lou Berger: please continue the discussion offline

1:58:00
11     11:30  10  Title:  YANG models for ACTN TE Performance Monitoring
Telemetry and Network Autonomics Draft: 
https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics-07
Presenter:  Young Lee

Greg Mirsky, via jabber: what's the difference between TE KPI telemetry and PM
OAM? Young Lee: we're not talking about OAM here. We're talking about
unidirectinal delay here, from the customer perspective. Lou Berger: so it's
the difference between collecting the information (OAM) and reporting it? Young
Lee: yes Greg Mirsky: have you looked at the STAMP data model? Young Lee: we're
not reinventing the wheel here - we're just referencing performance attributes
from TE types (link, tunnel, LSP). MSDC has to concatenate all this data from
the lower level. If Greg can point out the exact reference I can take a look
and give him a reply Greg Mirsky: I think the STAMP module contains all PM
metrics and more. [https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang]
Young Lee: OK, but this is a customer subscribing to it Lou Berger: did you
look at it? Young Lee: yes, in the past. If they have a yang model we can
import then we can do that. Lou Berger: how many people think we should be
doing this and are interested in this work? Reasonable number
  how many have read this doc? About the same
  how many think this is a reasonable starting point for the WG? More than have
  read it :)
Igor Bryskin: we should look at what Greg pointed to as TE types don't exist in
a bubble. Lou Berger: yes, please look at the document Greg referenced and
report back to the list and will decide how to proceed from there.

2:06:40
12     11:40  10  Title:  Applicability of ACTN to Network Slicing
Draft: 
https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-03
Presenter:  Young Lee

Igor: I think it's good work. You mentioned that client-driven automation is
missing. I'd encourage you to look at the work in NETMOD for the generic
network automation as it's indended for this. Young Lee: Thanks - please send a
reference to it.

2:15:00
13     11:50  10  Title:  Enhanced Virtual Private Networks (VPN+)
Draft:  https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-00
Presenter:  Stewart Bryant

Lou Berger: do you cover the case where the current toolset does allow mapping
VPNs to RSVP-TE? This is deployed. Stewart Bryant: RSVP is clearly a candidate
technology to use, but we don't cover that explicitly Lou Berger: it's deployed
in the real world. Not widely because of scale issues, but it exists. Greg
Mirsky: Would physical isolation e.g. TDM be a strong isolation example?
Stewart Bryant: TDM is a good example of strong isolation, yes Greg Mirsky: Do
you think that DETNET can be scaled to Internel level? Stewart Bryant: I don't
think you can do anything at the Internet level like this. We're only looking
at provider networks Andy Malis: there's a draft in DETNET for large-scale
networks (as defined by Stewart, not the Internet) Stewart Bryant: we're
talking about mobile phone ares, not something where anyone can connect
anywhere. Lou Berger: as you move forward, try to clean up the separation
between control plane and data plane. RSVP-TE is control plane, not network
layer. Dongjie (jimmy): we do want to mention TE LSPs here? Stewart Bryant: we
do need to talk about whether resources are bound to the path or the packet.
I've been thinking with my lower-layer hat on. Daniele Ceccarelli: a service
operator will have VPNS and VPN+. What's the scalabilty? Stewart Bryant: I
don't think we'll have one application per service, but considering the
resource binding you'll have to do it will look like a lot more compared to a
classic VPN where you only have 8 classes of service. Daniele Ceccarelli: so
there's still a scalability issue Stewart Bryant: yes. With mobile operators
you're sharing the same infrastructure. I think we're talkign more than ten,
but not millions. Adrian Farrel: the document is in the right place in my
opinion, and is going the right way. I think we need more of a framework to
point at things and identify gaps Dean Bogdanovic: I have a concern about the
underlying hardware capabilities, but I'll take that to the list Lou Berger:
how many people are interested in this work and want to hear more about it? Lots

Lou Berger: That's all. See you all in Bangkok

Adjourn     12:00