* 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-103 teas minutes

Session 2018-11-05 1120-1220: Meeting 2 - Audio stream - teas chatroom
Session 2018-11-06 1610-1810: Chitlada 3 - Audio stream - teas chatroom

Minutes

minutes-103-teas-00 minutes



          >                         Monday, November5th 2018
          >                         11:20 - 12:20 - Monday MorningSession II
          >                     Location:    Meeting 2
          >
          >                     Slides:
          https://datatracker.ietf.org/meeting/103/session/teas
          >                     Etherpad:
          https://etherpad.tools.ietf.org/p/notes-ietf-103-teas?useMonospaceFont=true
          >                     Meetecho:    http://www.meetecho.com/ietf103/teas
          >                     Audio stream:
          http://ietf103streaming.dnsalias.net/ietf/ietf1038.m3u
          >                     Jabber:    xmpp:teas@jabber.ietf.org?join
          >
          >                         Available post session:
          >                     Recording:    https://www.ietf.org/audio/ietf103/
          >                     YouTube:
          https://www.youtube.com/user/ietf/playlists
          >
          Youtube session 1: https://www.youtube.com/watch?v=7as2GwZGpIw
          
          > Slot Start     Duration    Information
          > 1    11:20    10   Title:    Administrivia & WG Status
          >                    Draft:
          >                    Presenter:    Chairs
          
          00:09:55
          > 2    11:30    10   Title:    WG Draft updates
          >                    Draft:    Many
          >                    Presenter:    Chairs
          
          Zafar Ali: WRT TE Metric recording - will have issue addressed before
          IETF 104
          Pavan Beeram: could you use some help with this?
          Zafar Ali: yes, that would be appreciated
          Lou Berger: How many people are interested in this document? (a few)
             Any volunteers to help edit? (none)
          Lou Berger: we're at the point where the authors need to either get this
          moving again by the next IETF, or we'll declare it dead and move on.
          Igor Bryskin: WRT tutorial draft, looking for input on packet network
          example; need volunteers to work on this
          Tarek Saad: RSVP-TE yang split - should be done shortly, then ready for
          YANG DR review and LC
          
          00:18:30
          > 3    11:40    15   Title:    A YANG Data Model for Traffic Engineering
          Tunnels and Interfaces
          >                    Draft:
          https://tools.ietf.org/html/draft-ietf-teas-yang-te-17
          >                    Presenter:    Tarek Saad
          
          Igor Bryskin: The comment from the YANG DR is very valid.  We don't
          cover defaults, but do want to cover active choice. We should take the
          comment seriously.
          Lou Berger: Authors are following approach of only defining defaults
          based on specifications, I think this is a good choice
          Igor Bryskin: my point was that it is better to choose some reasomable
          option
          Tarek Saad: the risk is that people may differ on what's a reasonable
          choice so we need to be careful here. Could maybe have a separate document
          with defaults?
          Lou Berger: I thought I heard that the authors' approach was only to
          have a default when it's specified somewhere in the protocol. Speaking
          as a contributor, I think that's a wise choice
          Igor Bryskin: if you do not go to default you need to have multiple
          choice and create confusion
          Aihua Guo: In my experience some defaults are necessary, but not all. If
          a default has interoperability implications should specify something
          Tarek Saad: yes, I think if there's a default that you feel is important
          to set then we should discuss on the list
          Igor Bryskin: A default doesn't preclude a user setting something else
          if they want
          Pavan Beeram: Please send a message to the list outlining the changes
          needed to te-types document to resolve the exising document MISSRef
          RFC editor state. (Including changes to align te-topology with final
          definition of te-types.)
          Lou Berger: where it's necessary to align the topology document with this
          one, I think it's sufficient to put out a proposal for that and give it
          to the RFC Editor. I know there were some substantive issues that were
          discussed off-list and those should be brought to the list and closed
          
          00:35:15
          > 4    11:55    10   Title:    SF Aware TE Topology YANG Model
          >                    Draft:
          https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-02
          >                    Presenter:    Young Lee
          
          Lou Berger: There was an issue from the last meeting on identifiers, that
          is addressed with new -id. Did we talk to SFC about how they handle this?
          Young: I did, yes. They refer to work in TEAS and NFV.
          
          00:40:15
          > 5    12:05    15   Title:    Yang model for requesting Path Computation
          >                    Draft:
          https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-03
          >                    Presenter:    Sergio Belotti
          
          Lou Berger: do you want to discuss the open issues now, or on the list?
          Sergio Belotti: on the list might be better
          Lou Berger: it would be good to say how you think you should do it
          now. We have time
          Igor Bryskin: To ensure the returned path is same as used for the tunnel
          when it's provisioned, we need to provide all tunnel configuration
          parameters. The discussion on the list, not much harm to provide
          everything.
          Tarek Saad: I agree with Igor. I don't think the fact tht policy isn't
          there should block progress. The attributes can be passed and the
          computation server can ignore them if it likes. Provides foundation for
          future policy module.
          Sergio Belotti: The problem is that if we need complete alignment on
          attributes, we'll need some modifications
          Tarek Saad: I'm proposing that you use the full set and the server can
          treat them as optional.
          Pavan Beeram: aren't we just using a grouping for the full set of
          constraints?
          Sergio Belotti: we don't have justification for a list of attributes
          when we don't know what they are
          Lou Berger: the justification is that a full set of attributes gives
          maximum flexibility
          Igor Bryskin: we want to avoid the situation where you ask for a path
          calculation and get a path, but then provision the tunnel with the same
          parameters and it takes a different path
          Italo Busi: that situation is difficult to avoid. If the client provides
          all attributes you can still get the same problem if the client doesn't
          provide an attribute that the server is nevertheless using. We're adding
          a path-verification phase in the next version of the document to try
          and address these issues. And if you have a policy, you have to explain
          exactly how it works for it to be useful. It can't be hidden.
          Sergio Belotti: No, we don't want hidden policies our position is that
          if the policy is there it has to be explicit.
          Igor Bryskin: I disagree with Italo. All we're requiring is that if
          you specify the same parameters for two tunnels, you get identical
          paths. Secondly, policies don't need to be known externally; they could
          be proprietary to the server.
          Lou Berger: there's clearly a difference of opinion here, but I saw
          there was some new text about path verification in the latest version
          and I don't think it has really been discussed on the list. It would be
          good to have the conversation
          
          WRT slide 5:
          Tarek Saad: To clarify the TE tunnel approach: setting multiple
          constraints is optional. When there are multiple constraints, it's
          not clear which the server should drop if need be. What does a server
          prioritize? We went with optimizing the inclusions/exclusions and make
          it clear that this is best-effort.
          Igor Bryskin: We need to define what it means to relax a constraint. If
          you can't satisfy a contstraint you could drop it entirely, or you could
          treat it more gently.
          Dhruv Dhody: WRT alignment with PCE, what is the cost of alignment,
          if cost too high, not worthwhile.  We need a smarter way of modeling it.
          Igor Bryskin: please look at the model, it already has a mechanism that
          may be sufficient
          Dhruv Dhody: I like the way PCEP has specified this. I'm confused by
          what Tarek said about hops - it's like loose vs strict hops. We need to
          discuss further.
          Jon Hardwick: Not sure how important this is. The user wants to set
          their constraints, just need to express same level of richness. To take
          the example here we're looking at two more-or-less equivalent ways of
          doing the same thing; PCE can do the same thing - the PCE can return a
          set of candidate paths to the PCC and allow the PCC to choose the one
          it likes best.
          Sergio Belotti: The example is chosen on purpose: not trivial to deduce
          for implementation in yang the same functionality while for PCEP it is
          just a Boolean variable to use per constraint
          Lou Berger: we're over time but I'd like to continue the discussion
          tomorrow when we resume.
          
          > Adjourn    12:20
          >
          >
          
          >                         Tuesday, November 6th 2018
          >                         16:10 - 18:10 - Tuesday Afternoon Session II
          >                     Location:    Chitlada 3
          >
          >                     Slides:
          https://datatracker.ietf.org/meeting/103/session/teas
          >                     Etherpad:
          http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-teas?useMonospaceFont=true
          >                     Meetecho:    http://www.meetecho.com/ietf103/teas
          >                     Audio stream:
          http://ietf103streaming.dnsalias.net/ietf/ietf1036.m3u
          >                     Jabber:    xmpp:teas@jabber.ietf.org?join
          >
          >                         Available post session:
          >                     Recording:    https://www.ietf.org/audio/ietf103/
          >                     YouTube:
          https://www.youtube.com/user/ietf/playlists
          >
          Session 2: https://www.youtube.com/watch?v=A7MJ8NY7kTk
          
          > Slot Start     Duration    Information
          > 1    16:10    10   Title:    Administrivia
          >                    Draft:
          >                    Presenter:    Chairs
          
          00:03:00
          > 6    16:20    10   Title:    ACTN applicability to YANG models
          >                    Draft:
          https://tools.ietf.org/html/draft-ietf-teas-actn-yang-02
          >                    Presenter:    Haomian Zheng
          
          Pavan Beeram: this references a bunch of YANG models which are under
          development so I do not see any need to rush to WG LC, we need the basic
          models cited in this draft to be mature.
          Haomian Zheng: Agree on not rushing, but we expect some clarification
          what is the basic models and how mature we need to wait.
          Daniele Ceccarelli: here we are defining a huge number of documents,
          maybe we should define which one can be the showstoppers for the draft
          without waiting for the all the other drafts. I'd propose TE topology,
          TE tunnel and Ppath Computation as the three we need.
          Lou Berger: when this document is published as RFC, which documents we
          would like to be referenced as RFCs and which one as drafts? Since this
          is informational it will be published quickly, and all the references
          that are still drafts will be referenced as drafts.
          Daniele Ceccarelli: I would like to see those three referenced as RFCs
          and the rest can be draft.
          
          00:10:20
          > 7    16:30    10   Title:    ACTN VN YANG
          >                    Draft:
          https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-02
          >                    Presenter:    Dhruv Dhody
          
          Adrian Farrel: there was original argument from the chairs on 'whether
          we need a separate model than TE', want to confirm whether this issue is
          addressed or not. I think the presentation explained this quite well -
          are the Chairs happy?
          Lou Berger: I think the question is whether the WG is happy.
               Poll: how many has read this draft (a reasonable number)?
               How many think the proposed approach is the right way? (same
               as above)
               How many thinks this is the wrong way ?(none)
          Lou Berger: the WG gives the answer.
          Adrian Farrel: the Chairs expressed that they had a lack of clarity. Have
          we cleared that up or is more work needed?
          Lou Berger: we look this work as ACTN specific, can this model apply to
          any other VN node/link control?
          Dhruv Dhody: we can of course use this as basic model, and augment to
          achieve other features (such as network slicing).
          Daniele Ceccarelli: ACTN is a structure that you don't necessarily
          implement everything, you can only implement a piece (like VN), or you
          can also implement all the pieces and put together, which is ACTN.
          Lou Berger: we'd like this work to be useful whenever we're modeling
          VN information
          Igor Bryskin: I agree with Lou, when we're talking about ACTN we're
          talking about all the building blocks. So you can use just the topology
          model from ACTN if you want.
          
          00:26:00
          > 8    16:40    10   Title:    Traffic Engineering and Service Mapping
          Yang Model
          >                    Draft:
          https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-12
          >                    Presenter:    Young Lee
          
          Lou Berger: it would be great to have a non-ACTN example in the document.
              How many think it is a topic we should work on? a reasonable number
              How many have read the document? more than those who think it is a
              topic we should work on
              How many think it is a reasonable starting point? a very reasonable
              number
          Let's take this to the list. It would be nice if the solution we adopt
          could be used for more than ACTN.
          
          00:32:15
          > 9    16:50    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-08
          >                    Presenter:    Young Lee
          
          Dieter Beller: we noticed in the model, there are parameters such
          as delay, delay-variation, packet-loss, etc: are they tech-specific
          or general?
          Young Lee: delay is not technology-specific
          Dieter Beller: delay-variation is packet-only. Should it be defined in
          a technology-specific augmentation?
          Young Lee: I agree with packet loss but not with delay
          Dieter Beller: I was talking about dealy variation
          Young Lee: what do we have other than packet routers and otn switches,
          what do we have?
          Lou Berger: our approach thus far has been to have a base model and then
          augmentations. That means people implementing only one technology don't
          have to flag deviations from the base model because they didn't implement
          all of it. It doesn't make any difference to how the topology works.
          Gert Grammel: in the last ITU-T meeting there was a presentation about
          delay variation in OTN caused by asynchronous mapping
          Young Lee: will this give us trouble with TE types? We just imported
          that model - do we need to make that more generic?
          Daniele Ceccarelli: if the issue is to separate packet-specific
          attributes, we can develop a new module but it is not worth having a
          separated draft. Let's avoid having a document for only one value
          Tarek Saad: as the author of ietf-te-types, we need to make sure that our
          model covers generic performance parameters, and leave the tech-specific
          parameters augmented to generic TE models.
          Lou Berger: the comment is about the packet loss attribute being
          technology-specific, and that's in TE-types We have a YANG Doctor comment
          about it that needs to be addressed and I think this is worth looking at.
          Pavan Beeram: I'd to see like some discussion on scaling intent and how
          that's addressed.
          Young Lee: you can define this as what happens when you're above or
          below a certain utilization
          Pavan Beeram: we should discuss on the list.
              How many have read the document? A reasonable number
              How many think it is ready for WG adoption (assuming the comments
              discussed here are addressed)? A bit less
          Lou Berger: do the update to the comment (on generic/tech-specific),
          and then we take it to the list.
          Young Lee: So what do we do about TE types?
          Lou Berger: we'll sort that out so it becomes generic.
          Tarek Saad: the grouping we defined in TE types is generic but maybe
          doesn't apply to optical. So we could take these out if they're
          packet-specific
          Lou Berger: the packet loss is a useful attribute. It does not need to be
          removed from the te-types document but just been removed from the grouping
          Pavan Beeram: the TE-types issue isn't the only caveat - also need to
          make it ACTN-agnostic
          
          Lou Berger: We'll swap the next two presentations, first the enhanced
          VPN framework, then will do ACTN for network slicing.
          00:46:40
          > 11    17:10    10  Title:    A Framework for Enhanced Virtual Private
          Networks (VPN+)
          >                    Draft:
          https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-02
          >                    Presenter:    Jie Dong
          
          Ketan Talulikar: Seems this draft defines an architecture. The changes
          needed are defined in other drafts in SRING, LSR and other areas. What
          to standardize here?
          Lou Berger: From process standpoint, this is the right working group
          for the architecture draft.
          Stewart Bryant: It is an informational draft, shows how to bring things
          together to solve a problem.
          Lou Berger: could you clarify the question?
          Ketan Talulikar: I'm not asking if this is the WG. My question is:
          what are we standardizing here?
          Lou Berger: it's an informational document, so by definition, nothing.
          Ketan Talulikar: This document generates requirements for standardization
          in other WGs.
          Lou Berger: This document informs how different standard mechanisms can
          be used in a particular way to solve a particular problem. We have many
          documents that do that.
          Stewart Bryant: This is absolutely normal. There are many similar
          documents, e.g. for MPLS-TP and Pseudowires.
          Lou Berger: It depends on WG's opinion whether there is value to move
          forward.
          Zafar Ali: There is a draft in SPRING which has addresses the same space
          as this draft. Maybe we should bring that draft here as well?
          Stewart Bryant: My recollection is that this draft is a superset of the
          draft you mentioned, it is not restricted to SPRING based solution.
          Zafar Ali: My question is - do you need a superset? This draft looks
          like marketing, and I think it would be fair to have both drafts
          discussed. This draft proposes specific ways of doing things that are
          not needed. We also need SPRING to look at this.
          Adrian Farrel: I would agree with Zafar if this document were proposing
          any changes to a technology, but I don't think it does. This document
          does not define specific extensions to segment routing. It is just one
          candidate technology, SR and MPLS-TE may both be used.
          Zafar Ali: I have no objection to the TE side, but for SR, specific SIT
          types are defined here.
          Jie Dong: The SR specific extensions are defined in another draft,
          which will be discussed in SPRING tomorrow morning.
          Lou Berger: We are happy to have architecture discussion happen in TEAS.
          Wim Hendricks: One question is about the scale, SPRING was a stateless
          architecture, we are going to introduce more state. The scale is an
          important factor and we should clarify this in the document and say
          which technologies are/are not in scope for a given scale
          Lou Berger: I've talked to one of the SRPING chairs about this, and we do
          have some marketing going on. The term SRTE is very confusing, can mean
          different things to different people. Some people think with TE you do
          introduce state into devices for resource allocation. Some others think
          SRTE is purely path steering or "PE" (path-engineering). We really need
          good definition of SRTE or PE.
          Zafar Ali: SPRING has an architecture document for SR policies or SRTE.
          Lou Berger: That's SR policy. There is no definition of SRTE anywhere. We
          hope we will get one.
          Zafar Ali: Agree with what Wim said on the scaling analysis, e.g. on
          the implications of using and adjacency-SID.
          Lou Berger: We need a definition of SR-TE first. Otherwise it could have
          different state implications.
          Daniele Ceccarelli: How about TEAS gives the definition of TE, then if
          SPRING agrees with it, we can call it SRTE, or they can call it SRPE.
          Lou Berger: Would be reasonable to have one informational document on
          what TE is. Can be based on the TE presentation on Sunday given by Adrian
          and Haomian. Maybe they could turn that into a draft.
          Robin Li: The framework document is not SR specific thus belong to
          TEAS. The discussion about SR or SRTE for VPN+ or network slicing could
          happen in SPRING.
          
          01:08:45
          > 10    17:00    10  Title:    Applicability of Abstraction and Control
          of Traffic Engineered Networks (ACTN) to Network Slicing
          >                    Draft:
          https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-04
          >                    Presenter:    Dan King
          
          Dan King: Our thought is to move portion of this document into the
          previous document as a subsection. Then will have a document which we
          could do liaison to other standards organizations looking at network
          slicing. Do we need to wait for the composite document be adopted before
          having formal liaison to other SDOs?
          Lou Berger: We don't usually do liaison on individual documents (look
          to Deborah). I don't know if there's a hard and fast rule on this.
          Deborah Brungard: We could do some liaisons as 3GPP already did liaisons
          to us showing interest in an area of work. And ITU-T SG-15 have started
          5G work, so we could liaison with them to show our work on 5G or network
          slicing, and ask about the work they are doing now.
          Lou Berger: If there is value it is certainly something we could do,
          whether we do it or until we have something adopted?
          Deborah Brungard: I would do it now. SG-15 is moving fast. The only
          concern is the data plane technology was FlexE, and that's not the only
          data plane technology. It would better to make things more general as
          individual technologies belong to the OIF or ITU.
          Lou Berger: Maybe we should set up a liaison. Propose some text and
          we'll work on it.
          Adrian Farrel: I'm working with the co-authors to do the merge of the
          three drafts. ACTN will be one of the candidate technologies. There will
          also clarifications about the terms - we have four terms that are almost
          the same (VPN, VPN+, Virtual Network and Network Slice), and they seem
          to be names for the same things depending on where you view it from. The
          data plane technologies will also be extended from packet focused to
          other TE technologies.
          Lou Berger: I want to confirm whether the authors want to do the merge
          (of this and the previous documents).
          Jie Dong: As coauthor of VPN+ framework, in support of the merge.
          Daniele Ceccarelli: VPN+ is something we should work on, but need to be
          careful about saying VPN+ is network slicing. If we merge everything we
          lose the distinction. Network slicing is a much bigger problem.
          Lou Berger: What I heard is VPN+ solves part of the problem of network
          slicing.
          Stewart Bryant: It was originally intended to solve the data plane
          and lower layers. Network Slicing is a much bigger problem. We didn't
          use the term network slicing in beginning because we want this to be
          universally useful, and applicable to some aspects of network slicing -
          and also because Netowrk Slicing was a very controversial term when we
          started the work.
          Young Lee: As coauthor of the 2 ACTN drafts, support the merge as long
          as we clarify what VPN+/network slicing mean. Could clarify our scope
          is transport or TE network slicing.
          Lou Berger: We are running over time so we need to wrap the
          discussion. The plan is to merge the documents. And that's gonna be
          pretty quick.
              Who is interested in working on this topic in this working group? Very
              healthy number.
          Lou Berger: We'll need to see the merged document, but given the level
          of interest and discussion we'd like to not wait for the next meeting
          to do a poll.
          Zafar Ali: There is another draft, WG also need to see it.
          Lou Berger: After adoption there is opportunity to bring your content
          into this document, and the ownership moves from the authors to the WG.
          Zafar Ali: Would like to work with the authors of the draft, even before
          the WG adoption poll.
          Dan King: we'd be happy to work with you.
          
          01:24:20
          > 12    17:20    10  Title:    Interworking of GMPLS Control and
          Centralized Controller System
          >                    Draft:
          https://tools.ietf.org/html/draft-zheng-teas-gmpls-controller-inter-work-01
          >                    Presenter:    Sergio Belotti
          
          Sergio Belotti: The draft was presented in CCAMP last time but was
          considered technology-agnostic so it is now presented in TEAS.
          Lou Berger: is it proposed as an Informational document or as a Standard
          Track document?
          Sergio Belotti: it is Informational
          Lou Berger: How many have read the document: an ok number
              How many think we should work on this: the same
              How many think it is ready for adoption: a bit less
              How many think we need to wait for the changes? none
          There is support but not overwhelming. We will discuss offline the
          next steps
          
          01:32:40
          > 13    17:30    10  Title:    Hierarchy of IP Controllers (HIC)
          >                    Draft:
          https://tools.ietf.org/html/draft-li-teas-hierarchy-ip-controllers-01
          >                    Presenter:    Dhruv Dhody
          
          Pavan Beeram: Is the scope of this limited to ACTN, or are we going
          beyond packet networks?
          Dhruv Dhody: this work include the BGP which is not a part of ACTN;
          Adrian Farrel: Is it possible to generalize this as a controller-driven
          document? i.e. something that covers the material in the previous draft?
          Dhruv Dhody: open to discussion.
          Lou Berger: How many are interested to this topic (even if they have
          not read the document)? A reasonable number
          Lou Berger: it would be good to follow up on Adrian's suggestion
          
          01:38:40
          > 14    17:40    10  Title:    Basic YANG Model for Steering Client
          Services To Server Tunnels
          >                    Draft:
          https://tools.ietf.org/html/draft-bryskin-teas-service-tunnel-steering-model-00
          >                    Presenter:    Igor Bryskin
          
          Daniele Ceccarelli: I like the idea of pools but I would like to see
          pools made by a single tunnel, i.e. specify that a particular tunnel is
          to be used
          Igor Bryskin: you have the option to reference a tunnel or a pool
          Italo Busi: I agree with Igor. It's better to reference the tunnel or
          the pool, rather than have to create a pool with one tunnel
          Daniele Ceccarelli: that's ok, I just need to have the possibility to
          specify a specific tunnel
          Lou Berger: we have to cut the discussion here. I think the conversation
          demonstrates that there's interest in this.
          
          01:45:20
          > 15    17:50    10  Title:    Applicability of ACTN to VPN with POI
          >                    Draft:
          https://tools.ietf.org/html/draft-lee-teas-actn-vpn-poi-00
          >                    Presenter:    Daniele Ceccarelli
          
          Lou Berger: How many thnk this is useful work? (a few)
            How many think we shouldn't be talking about this in the WG? (none)
            Please discuss more on the list
          
          1:53:20
          > 16    18:00    10  Title:    GMPLS Signaling Extensions for Shared
          Mesh Protection
          >                    Draft:
          https://tools.ietf.org/html/draft-he-teas-gmpls-signaling-smp-00
          >                    Presenter:    Italo Busi
          
          Pavan Beeram: There are three protection C-types. Need to clarify which
          we're changing.
          Italo Busi: second one
          Pavan Beeram: We currently don't have any IANA registry for the flags. We
          may want to consider one.
          Dieter Beller: the draft mentions shared-mesh protection, which is
          similar to shared-msh restoration. But protection is done by the data
          plane, whereas restoration is done in the control plane. How do the two
          coexist? Both use shared resources in the network.
          Italo Busi: I would not expect that SMP and SMR would be in the same
          network, but if they were I would expect them to share resources.
          Igor Bryskin: What's the environment for this? Do you envision a
          multi-vendor GMPLS network?
          Italo Busi: the requirement is to set up a working LSP and a protecting
          LSP. The transit nodes need to know that the protecting LSP belongs to
          an SMP schema rather than SMR or linear protection.
          Igor Bryskin: But is it a single- or multi-vendor environment?
          Italo Busi: at the moment I don't expect multi-vendor as there is no
          common APS signaling.
          Igor Bryskin: So why are we discussing this?
          Lou Berger: How many are interested in this? A small number
             How many have read the document? More
             Chairs will discuss.
          
          See you all at the next meeting.
          
          > Adjourn    18:10
          >
          
          Notes by:
          Italo Busi
          Haomian Zheng
          Matt Hartley
          
          



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