Minutes IETF97: teas
minutes-97-teas-00

IETF 97 - TEAS WG - Meeting Minutes
Version: Dec 08, 2016

Monday November 14th 2016
09:30 - 12:00 - Monday Morning Session I
Room: Grand Ballroom 3

Slides:  https://datatracker.ietf.org/meeting/97/session/teas
YouTube:
https://www.youtube.com/watch?v=71PKKZUKX94&t=4s&index=89&list=PLC86T-6ZTP5gtLuoSjpTGO_mS5Ly2pfIS
Audio:  
https://www.ietf.org/audio/ietf97/ietf97-grandballroom3-20161114-0930.mp3
Jabber:  https://www.ietf.org/jabber/logs/teas/2016-11-14.html

> Num     Start Time      Duration        Information
> 0       9:30    10      Title:  Administrivia & WG Status
>                         Draft:
>                         Presenter:      Chairs
Two drafts in last call, publication request of second draft should be in the
next couple of weeks. Reminder that draft discussions should be on the list so
that others can see and comment if desired.

> 1       9:40    10      Title:  WG Draft updates
>                         Draft:  Many
>                         Presenter:      Chairs
Pavan Beeram:
   16 active WG drafts
   te-metric-recording: no status update received. is there still interest?
   Poll: How many think the WG still work on this? <A few people> Ingress
   protection: Chairs believe it needs an editorial scrub in next few weeks and
   then WG last call. No issue in progressing it since the experimental status.
   network-assigned-upstream-label: Poll: how many have read the latest
   version? <a couple> Please review it.

> 2       9:50    10      Title:  A YANG Data Model for Traffic Engineering
Tunnels and Interfaces >                         Draft: 
https:/tools.ietf.org/html/draft-ietf-teas-yang-te >                        
Presenter:      Rakesh Gandhi 3 open issues, that are still being discussed on
the list. Next steps to conclude on open issues, and also complete PCC-TE data
augmentation. Pavan Beeram: Does anyone want to comment on open issues? No
questions. Lou Berger: what is your plan for the different modules? Rakesh
Gandhi: wrt RSVP it is very stable. wrt TE model it is one model but further
discussion is needed. Lou Berger: It may be time to peal off the more mature
parts and start publishing them. Aslo should consider to allow implementors
only implement the parts that they care about, e.g., just a specific
technology. Daniele Ceccarelli: Relationship between otn model and L1 model -
you already answered. What is the relationship with italo's path computation
API? Rakesh Gandhi: We have had some discussion with PCE team on PCE yang
model. We need to do some more work Dhruv Dhody: Need to clarify role of
ietf-te-pcc model. PCC can mean device, NMS, etc. Perhaps clarify in joint
session, what is the role of this model? Lou Berger: In terms of splitting the
draft up, please think about what parts are stable enough to do that now so
they can be progressed.

> 3       10:00   10      Title:  Extensions to RSVP-TE for LSP Egress Local
Protection >                         Draft: 
https:/tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection
>                         Presenter:      Huaimo Chen

Huaimo Chen: Status update, First slide - More details have been provided in
the draft. Huaimo Chen: Need WG chairs help on one comment: Author of draft
[draft-shen-mpls-egress-protection-framework] asks for a reference in this
draft.  Stuck figuring out how to resolve this issue, draft is 6.5 years old. 
Concern about making a reference from this stable draft on an
unstable/individual draft. Lou Berger: An informative reference isn't blocking
and is your choice.  If useful, add it. Lou Berger: Asking MPLS chairs to
comment.  Question to MPLS chairs, will this individual draft be adopted? Loa
Anderson:  It is an individual I-D in MPLS and MPLS WG does not have an opinion
(yet). Loa thinks MPLS work might become a delta on TEAS work Lou Berger: Happy
to have a solution draft come before a framework draft.  For the concern about
a WG document referencing an individual draft, it is fine to reference as an
informative reference. Lou Berger: Huaimo has the choice whether to include the
reference Pavan Beeram: how many have read this version? A few. How many think
it's ready for last call? <Approximately the same>. Not a lot either way. Lou
Berger: Please read and review and send comments send to the list.
(particularly objections or ready to go comments).Seems we have adequate
support to wrap this document up.

> 4       10:10   10      Title:  Extensions to Resource Reservation Protocol
For Fast Reroute of Traffic Engineering GMPLS LSPs >                        
Draft:  https:/tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute
>                         Presenter:      Rakesh Gandhi Rakesh speaking:
    Current status - has completed WG last call.  Hence presenting updates from
    WG LC review Giving summary of signalling extensions (as per slides):
      Bypass tunnel is in the same direction as the protected tunnel.
      PLR can receive multiple bypass tunnel assignments: Document has an
      improvement, notify message sent by upstream PLR Discussing Bypass
      Assignment error notifications. Other updates: terminology changes, added
      details on revertive, unidirection link failures.
    No open issues at the moment, would like feedback from the WG on the
    changes, might issue another WG LC.
Lou Berger: Good changes worth re-reading. How are you dealing with off-path
control? Here it needs to be in-band unlikely GMPLS. Lou Berger: It would be
good to address this. Rakesh Gandhi: Current scope is just in-band signaling.
Lou Berger You can't claim you support GMPLS if you don't support off-path
control. Have a look at it and come back. Himanshu Shah: Agree it should be
addressed. Rakesh Gandhi: Will take a look at this. Pavan Beeram: Will move to
another last call after changes.

> 5       10:20   10      Title:  Requirements for Abstraction and Control of
TE Networks >                                 Framework for Abstraction and
Control of Traffic Engineered Networks >                         Draft: 
https:/tools.ietf.org/html/draft-ietf-teas-actn-requirements
>                                
https:/tools.ietf.org/html/draft-ietf-teas-actn-framework/
>                         Presenter:      Young Lee Young speaking:
    To give update on requirements and framework
    Requirements draft is stable and ready for WG last call.
    Framework draft has been updated, addressed WG request to clean up
    terminology Lots of clean up work to make it consistent. Definition of
    Virtual Network has been sent to the list. Discussing Virtual Network
    creation (can be preconfigured, or dynamically configured, with a givne SLA
    attribute) VN dynamic can be further modified. Virtual Network can be
    viewed as an end-to-end tunnel.  Asking the WG to look a this definition to
    see if it makes sense. ACTN framework, document is quite stable, but need
    more reviewers.
Young Lee: ACTN framework, document is quite stable, but need more reviewers.
Adrian Farell: Apologies for not doing a terminology review.  Will try and get
the review done. Lou Berger: There were changes in terminology, getting it
stable and consistent is important, they were old issues that were put on hold
until the terminology is updated.  Please can WG look at the terminology and
review both documents, and see if it makes sense.  Then check old comments, and
see if they still apply after the terminology update.  Now is the time to
review the documents, in particular the terminology.

> 6       10:30   10      Title:  Information Model for Abstraction and Control
of TE Networks (ACTN) >                         Draft: 
https:/tools.ietf.org/html/draft-leebelotti-teas-actn-info
>                         Presenter:      Sergio Belotti Sergio presenting:
    Talking through the slides:terminology alignment and refinement with
    RFC7926 and across various ACTN documents; VN objective function and
    computed list added; no primitive changes. Went on to describe primitives
    with objects. Asking for a WG adoption
        Work has also started on solution drafts.
Lou Berger: Questions/comments? [None] Same information appears to be repeated
in other documents. Sergio: Yes, there is some terminology that is repeated
from other drafts.  Could decide that the definitions should be in other
frameworks. Lou Berger: Once the other drafts have been completed, what will be
left in this draft?  Is there still enough left to be published? Young Lee This
is an info model that is useful before implementation. It is a standalone RBNF
info model, independent of other ACTN related documents. Daniele Ceccarelli:
May not be overlap, but should remove any content that overlaps in other
documents.  Information model applies at the CMI where we don't have any
solution yet.  In CMI many more things are missing.  Even if we remove
redundant information from the document, there is still enough to publish as a
useful independent document. Pavan Beeram: So you see this document being
eventually published? Sergio Belotti: Yes Lou Berger: How many people think
that this is useful work? [A reasonable number of hands]
       How many have read? [About the same]
       How many think that this should be adopted as a WG document? [about the
       same]. Chairs will discuss next steps (and go from there.)

> 7       10:40   10      Title:  Abstraction and Control of TE Networks (ACTN)
Abstraction Methods >                         Draft: 
https:/tools.ietf.org/html/draft-lee-teas-actn-abstraction
>                         Presenter:      Daniele Ceccarelli Daniele presenting:
    Defining abstraction, what factors impact the abstraction.  This document
    is mostly focused on MPI layers. Factors: Nature of underlying domains:
    Opticial, TDN; Different capabilities; Or different abstraction algorithms,
    Last factor: if scalability and frequency of updates.  If old topology is
    flooded then we will kill it. Abstraction levels: 0% abstraction on left to
    100% on the right.
       White (no abstraction) - no filtering, MDSC has full knowledge.
       Black (total abstraction) - Make include border nodes, or exclude border
       nodes.  Border nodes might be useful for building services (e.g. PE
       nodes). Grey (partial abstraction) - 2 problems to be addressed: (1)
       Types: Providing a full mesh of connectivity, e.g. delay, bandwidth.
                                                                (2) How to
                                                                build it?
    Requirements: Suggest that WG reads these in the draft:
    Conclusions and Open Issues:
        Question: Is there anything missing from the document?
        Question: Is this a useful document:
        Comments:
Adrian Farrel: I find most of this useful.  Struggling with the abstract node
with border nodes. Daniele Ceccarelli: From requirement point of view, ask the
PNC to set up a tunnel or set up a service -- need to know the two PE nodes to
set up a tunnel.  Perhaps could have further refinement. Dhruv Dhody: Border
nodes are still nodes. Gert Grammel: A model without the border nodes isn't
useful. Daniele Ceccarelli: Starts with a black abstraction and then can added
extra detail. Dhruv Dhody: RFC6805 H-PCE uses the black topology. Both exist
and both are usable. Dieter Beller (Nokia): For the left abstraction need to
know the links between the border nodes, for the right total abstraction , need
connectivity information. Young Lee: This is a justification for path compute
request/reply. Gert Grammel: What is the problem that we are going to solve? 
Path computation or not? Daniele Ceccarelli: Draft is to find common agreement.
Gert Grammel: Agree, it would be nice to have something talking about
abstraction, but abstraction has to serve a purpose.  Work out the purpose and
then figure out the abstraction.  Need to link the two. Lou Berger: Cataloging
possibilities, and useful from that purpose.  The document is introducing new
terms (from black links to black networks), terminology should be defined in
the framework. Loa Andersson: Need some information on the connectivity.
Daniele Ceccarelli: Black topology gives you the information to ask for the
connectivity. Adrian Farrell: Already have switches with limited capabilities. 
Concerned about the terminology.  Abstract node has a very specific meaning,
perhaps use virtual node instead.  7926 RFC talking about problem with too much
abstraction nodes. Lou Berger: Need to align terms, being loose with terms
causes confusion. Italo Busi: Think that this work is very useful.  Useful to
think about abstractions in different context. GQ : What does the circle mean. 
Is an abstracted topology equal to information entity? Daniele Ceccarelli: The
circle is the domain.  The black abstraction doesn't tell you the internal
connectivity.

> 8       10:50   10      Title:  Applicability of Yang models for Abstraction
and Control of Traffic Engineered Networks >                         Draft: 
https:/tools.ietf.org/html/draft-zhang-teas-actn-yang >                        
Presenter:      Young Lee Young presenting:
    Another information draft.  Explain how the different YANG models are
    applicable to the ACTN framework.  Sister document to ACTN-PCE
    applicability draft Highlight possible missing YANG models. This is a
    service YANG model. Describing the different service layers on the slide.
    Device configuration at the problem.  How does this fit with ACTN
    architecture. Describing how the different service models map to the
    different layers or protocols (e.g. CMI/MPI/SBI) Describe how that map into
    the current models. Next steps: If this is useful effort then we can keep
    updating, and reference other YANG models.  Use this document as a
    guideline of how various YANG models fit together. Is this is a useful
    thing.
Jeff Tantsura:  Yes, this is useful work, how to mount the different YANG
models. Gert Grammel: A bit confused reading the draft. Is there an entire
hierarchy for each technology? e.g. one for packet, one for optical, one for
the services or everything is put together? Young Lee: A good question, how do
the different YANG models fit into this model.  Happy to develop details of
use-cases further if the WG thinks it is useful. Lou Berger: Note that on the
diagram (Slide 9) the left and right look the same but with different names
Young Lee: Because they are different areas of IETF. Lou Berger: The matching
is helpful. Rest of industry understand the left-hand-side terminology
(Orchestrators and Controllers), perhaps should adopt the same terminology as
everyone else rather than continue down a path that makes it harder for
everyone else to understand? Young Lee: Industries use different terminologies,
which is why it is being defined here. Lou Berger: Concept of service models is
well entrenched in IETF, e.g., L3SM and L2SM.  Do we want to align with
terminology with other areas to make it easy for others to understand. Jeff
Tantsura: Using existing terminology for existing functions would be great.
Daniele Ceccarelli: Mapping of terms isn't quite 1-to-1. PNC is one
functionalities of the controller, the MDSC is one of the functionalities of
Orchestration. It is not necessarily 1:1 mapping between service yang models
and ACTN arch/interfaces. Lou Berger: Adding this description to the
terminloogy description would be very helpful. Haomian Zheng: Propose
continuing to use ACTN terminology as we have been using them for a while. Only
change the terminology if the terms are exactly the same. Lou Berger: Lots of
people are likely to understand controllers/orchestrators, but not MDSC or PNC,
hence aligning with common terminology is useful independent of age of
terminology.

> 9       11:00   10      Title:  A Yang Data Model for ACTN VN Operation
>                         Draft: 
https:/tools.ietf.org/html/draft-lee-teas-actn-vn-yang
>                         Presenter:      Dhruv Dhody Dhruv presenting:
    Recapping of YANG model on CMI
    New updates: Presented in last joint YANG session.  Support for VN-compute
    before instantiation.  Added support in YANG model for multi-source and
    multi-destination, the user can choose.  Added references to abstract
    topology. Showing and describing YANG tree output of the updates. Next
    steps: All updated done and described.  Main question: Is this VN YANG
    model useful?  Any questions?
Lou Berger: How many have read this document? A reasonable number.  Have you
thought about relationship between L2SM and L3SM model? Dhruv Dhody: Yes.  Need
to translate Qos between the models.  May write a mapping model between L2/3
service models to ACTN VN model.  What to maintain a mapping between the models
(which is the job of the service orchestrator) Lou Berger: Want to see how
L3SM/L2SM use this model. Jeff Tantsura: Please make sure that the mapping
between the service model and the underlay infrastructure (being a tunnel or a
VN) is generalized enough to be able to  be used to L3SM, L2SM and whatever SM
will come. Xufeng Liu: What is the relationship between TE-abstract topology
model and this model? Dhruv Dhody: This uses a reference to the TE-Topology
model. Xufeng Liu: This looks like a simplified version of another model
(TE-abstract topology model).  Do we always need to build another model in such
cases? Dhruv Dhody: Our aim is to build a simple model for our customers doing
VN.  Still have to use abstract topology model if that is what you want. Xufeng
Liu: Topology model can already provide abstract nodes. Lou Berger: Interesting
discussion, but needs to be cut due to over time.  Perhaps we are looking at a
TE service model -- beginnings of one?

> 10      11:10   10      Title:  Inter-Op Test Cases in Multi-Vendor Scenario
based on ACTN Architecture >                         Draft: 
https:/tools.ietf.org/html/draft-zheng-teas-actn-multivendor-interop
>                         Presenter:      Haomian Zheng Haomian Zheng
presenting:
    Focus of MPI tests: Defined 4 testcases.
    Future work:  Continue interop-test.  Is anyone interested in helping with
    this work?
Dieter Beller:  Would like to get some clarification on intent -  is IETF going
to organize interop events between vendors.  Not all YANG models are stable? 
Not an official IETF interop test. Lou Berger: It is always good to hear
implementation reports and issues found for the model/protocol work in IETF.
Although there is no official inter-op in IETF, it is up to the volunteers to
work together which is encouraged.

> 11      11:20   10      Title:  The Use Cases for Using PCE as the Central
Controller (PCECC) of LSPs >                         Draft: 
https:/tools.ietf.org/html/draft-zhao-teas-pcecc-use-cases
>                         Presenter:      Boris Khasanov / Andrey Elperin /
Evgeniy Brodskiy (Potential -- Remote presentation) Boris Khasanov (Huawei): 
presenting remotely:
    Addressed comments raised in the previous session.
Andrey Elperin presenting:
    Share ideas of PCE use cases.
    L2VPNs heavily used in Ukraine (inter AS due to acquisition)
    Inter-AS Option B is difficult to meet requirements due to number of NNIs
No questions.
Lou Berger: How many people have read the document? <A reasonable number.> We
will talk a bit more about this after the next presentation.

> 12      11:30   10      Title:  PCE in Native IP Network
>                         Draft: 
https:/tools.ietf.org/html/draft-wang-teas-pce-native-ip
>                         Presenter:      Aijun Wang Aijun Wang presenting:
    MPLS TE is well covered but there is a gap in IPv4 case. This draft is
    focused on addressing this gap. Key idea of PCE in IP is dual/multi BGP
    sessions control and PCE based central control Solution proposes a PCEP
    extension, 3 new PCEP objects:
        •       Peer Address List - PAL;
        •       Peer Prefix Association - PPA;
        •       Explicit Peer Route - EPR;
    Describing a solution comparison (BGP FlowSpec, OpenFlow, Dual/Multi BGP
    (deployed via NETCONF), Dual/Multi BGP (deployed via PCEP); Dual/Multi BGP
    (deployed via PCEP) is not as flexible as NETCONF-based solution D, but
    faster. Asking whether draft can be adopted as a WG draft?
Lou Berger: How many have read the draft? A few people.  The draft describes a
new use case, and also a solution for that.  Would be useful to move the use
case description into <draft-zhao-teas-pcecc-use-cases> document.  The solution
can continue to be discussed in this draft. Would like to get feedback from
authors and the room? Aijun Wang: Ok. What about the solution itself? Lou
Berger: This draft would continue as a solutions draft. Dhruv Dhody: As a
co-author/contributor of previous document (draft-zhao-teas-pcecc-use-cases),
concerned that adding this usecase might slow the other draft; not sure that
this is a good use case. Danielle Ceccarelli: We already have a solution for
Traffic-Engineering in IP networks -- it is called MPLS. Jeff Tantsura: Would
like to see better comparison with FlowSpec and BGP based solutions before we
proceed. Lou Berger: I would take the reaction of the room as rejection to the
Chairs' proposal to bring the native-IP use-case into the use-cases document.
How many would like to see a PCECC use-case to be adopted as WG draft?
[reasonable number, about the same who read the draft]. How many think that
draft-zhao-teas-pcecc-use-cases is a good foundation for this work? [About the
same number, no reservations]. Chairs will talk and decide the next step.

> 13      11:40   10      Title:  Recommendations for RSVP-TE and
Segment-Routing LSP co-existence >                         Draft: 
https:/tools.ietf.org/html/draft-sitaraman-sr-rsvp-coexistence-rec
>                         Presenter:      Vishnu Pavan Beeram Pavan Beeram
presenting:
    SR LSP and RSVP-TE LSPs must coexist without causing disruption to each
    other; must ensure no inaccuracies in TED get introduced; 5 possible
    solutions:
        1) Static partitioning of bandwidth
        2) Centralized management of available capacity
        3) Flooding SR Utilization in IGP
        4) Run SR over RSVP-TE
        5) TED consistency by reflecting SR traffic (adjusting max-reservable
        bandwidth)
Dhruv Dhody:
    Looking at Central controller - Why cant we do only SR by the controller?
    Also wouldnt there be backwards compatibility issues when we don’t know if
    the node is updating SR resv bandwidth or not.
Lou Berger: Question has to go the list.
Pavan Beeram: Will respond on the list.
Lou Berger: Next question has to go to the list as well.
Rakesh Gandhi: Quick point -- For the option with adjusting max-res-bw, can
document cover the Diff-serve TE BC models RDM, MAM, etc. and explain what
happens to Pool0, pool1, etc.

> 14      11:50   10      Title:  Generalized Routing Interface Switching
Capability Descriptor Switching Capability Specific Information
>                         Draft: 
https:/tools.ietf.org/html/draft-ceccarelli-teas-gneralized-scsi
>                         Presenter:      Daniele Ceccarelli Daniele Ceccarelli
presenting (rushing through):
    Possible solutions (without this draft):
        Use the sub-TLV for each new switch capability?  Problem - no backwards
        compatible solution.
    Proposed solution (this draft):
        Generalize SCSI format made up of multiple sub-TLVs.  It is backwards
        compatible.
    One open issue: Whether to split the range of values.
    Next steps: Want to move quickly, showstopper for CCAMP draft.
Amy Yemin: I support this solution.  8 bits will be enough.
Pavan Beeram: How many think that this is a problem that needs to be solved?  A
good number.  How many have read this draft? A good number.  How many think
that this draft is ready to be adopted???  Slightly less than the number of
people who read it, but still a good number.

> 15      12:00   Adjourn
>
Note takers:Huaimo, Rob Wilton, PK