* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Teas Status Pages

Traffic Engineering Architecture and Signaling (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2014-Dec-05 —  
Chairs
 
 


IETF-102 teas minutes

Session 2018-07-18 0930-1200: Centre Ville - Audio stream - teas chatroom

Minutes

minutes-102-teas-00 minutes



          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
          
          



Generated from PyHt script /wg/teas/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -