Subject: [Teas] Raw notes from this morning

From: Lou Berger <[email-masked]>
Date: Mon, 14 Nov 2016 12:02:58 +0900

Kudos to our awesome crowd sources notes!!!

> TEAS Agenda For IETF 97
> Version: Oct 31, 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
> 
> 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

16 active WG drafts
TE-METRIC-RECORDING: is there still interest? Poll: How many think the
WG still work on this? Few people.
NETWORK-ASSIGNED-UPSTREAM-LABL: Poll: how many have read the latest
version? a couple. Please review it.

Ingress protection...
Chairs believe need editorial scrub in next few weeks and then WG last
call. No issue in progressing it since the experimental status.

> 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: Does anyone want to comment on open issues? No questions.
Lou B: what is your plan for the different modules?
Rakesh: wrt RSVP it is very stable. wrt TE model it is one model but
further discussion is needed. 
Lou B: Suggesting that the draft be split up so that stable parts can be
published at different times, and to allow implementors only implement
the parts that they care about.

Daniele: Reln between otn model and L1 model - you already answered
What about italo's path computation API?
Rakesh: some discussion with PCE team on PCE yang model. We need to do
some more work

Dhruv: Need to clarify role of ietf-te-pcc model. PCC can mean device,
NMS, etc. Perhpas clarify in joint session, what is the role of this model?

Lou B: In terms of spliting the draft up, please think about what parts
are stable enough to do that nowso 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: Status update, First slide - More details have been provided in
the draft.
Huaimo: Need WG chairs help on one comment: Authoer 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/individualdraft.
Lou B: Asking MPLS chairs to comment.  Questionto MPLS chairs, with this
individual draft be adopted?
Loa lumbers toward microphone...
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 B: Happy to have a solution draft come before a framework draft. 
For the concern about a WG document referencingan individual draft, it
is fine to reference as an informative reference. 
Lou B: Huaimo has the choice whether to include the refernce
POLL: 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. Please red
and if you have comments send to the list. (particularly objections or
ready to go comments).
Lou: Please read and review. 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 Assignmetnt error notifications.
      Other updates: terminology changes, added details on revertive,
unidirection link failures.
    No open issues at the moment, would ike feedback from the WG on the
changes, might issue another WG LC.
Lou B: Comments/questions?  There are some good changes, please
re-read.  How are you dealing with off-path control?
Lou: good changes worth reading. How are you dealing with off-path
control? Here it needs to be in-band unlikely GMPLS. 
Lou B: It would be good to address this.
Rakesh: Actual scope covers in band signaling.
Lou: You can't claim you support GMPLS if you don't support off-path
control. Have a look at it and come back.
Himanshu: agree it should be addressed. 
Rakesh has agreed that he will take a look at this.
Pavan: 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.
Adrian Farell: Apologises for not doing a terminology review.  Will try
and get the review done.
Lou B: There were changes in terminology, getting it stable 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, and see if it makes sense.  Then check comments on the old
comments, and see if they still apply after the terminology update.  Now
is the time to decide to review the documents, and 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 B: 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 B: 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 implemention.It is
a standalone RBNF info model, independent of other ACTN related documents. 

Daniele:May not be overlap, but should report 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.
Sergio: Couldn't hear?
Lou B: 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 to the list.) 

> 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 differnet abstraction algorithms, Last factor: if
scalability and frequency of updates.  If old toplogy 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 buid 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
blackabstractnodewith border nodes.
Daniele: Add teh 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 furhter
refinement.
Dhruv: Border nodes are still nodes.
gert grammel: A model without the border nodes isn't useful.
Daniele: Starts with a black abstraction and then can added extra detail.
Dhruv:RFC6805 H-PCE uses the black topology.Thinks both existings and
both are usable.
Dieter BellerNokia: For the left abstraction need to know the links
between the border nodes, for the right total abstraction ...?
Young Lee: This is a justification for path compute request/reply. 
Gert: What is the problem that we are going to solve?  Path computation
or not?
Daniele: Draft is to find common agreement.
Gert: Agree, it would be nice ot 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 B: 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: Black topology gives you the information to ask for the
connectivity.
Adrian Farrell: Already have switches with limited capabilties. 
Concerned about the terminology.  Abstract node has a very specific
meaning, perhaps use virtual node instead.  7926RFC talking about
problem with too much abstraction nodes.
Lou B: Need to align terms, being loose with terms causes confusion.
Italo Busi: He thinks that this work is very useful.  Useful to think
about abstractions in different context.
GQ (huawei): What does the circle mean.  Is an abstractedtopology equal
to information entity?
Daniele: 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 differnet 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 guideine of how
various YANG models fit into the ???  Whats to ask if this is a questful
thing.
Jeff Tantsura:  Yes, this is useful work, how to mount the differnet
YANG models.
Gert: A but 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 togethere?
Young: A good question, how to the different YANG models fit into this
model.  Happy to develop details of use-cases further if the WG thinks
it is useful.
Lou B: Notes that on the diagram that left and right look the same but
with different names
Young: Because they are different areas of IETF.
Lou B: Rest of industry understand the lef-hand-side terminology,
perhaps should adopt the same terminology as everyone elese?
Young: Industries use differnet terminologies, which is why it is being
defined here.
Lou B: Concept of service models is well entrenched in IETF.  Do we want
to align with terminoligy with other areas.
Jeff: What the functionality to be well specified?
Daniellie: PNC is one functionalities of the controller, the MDSC is one
of the functionalities of ???. It is not necessarily 1:1 mapping between
service yang models and ACTN arch/interfaces. 
Haomian(Haewei): Only change the terminology is the terms are exactly
the same.
Lou B: Lots of people are likely to understand
controllers/orchestrators, but not MDSC or PNC, hence aligning with
common terminology is useful.

> 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 instiantion.  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 B: How many have read this document? Areasonable number.  Have you
thought about relationship between L2SM and L3SM model?
Dhruv: Yes.  Need to translate Qos between the models.  May write a
mapping modelbetween L2/3 service models to ACTV VN model.  What to
maintaim a mapping between the models (which is the job of the service
orchestrator)
Lou: want to see how L3SM/L2SM use this model.
JeffTantsura: 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 ableto be used to L3SM, L2SM and whatever SM
will come. 
Xufeng: What is the relationship between TE-abstract topology model and
this model? 
Dhruv: 
Xufeng: This looks like a simplified version of another
model(TE-abstract topology model).  Do we always need to build another
model every time.
Dhruv: Our aim is to build a simple model for ourcustomers doing VN. 
Still have to use abstract topology model if that is what you want.
Xufeng: Topology module can already provide abstract nodes.
Lou B: Interesting discussion, but needs to be cut due to over time. 
Perhpas we are looking at a TE service model?  When should this be done?

> 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 presenting:
    Focus of MPI tests: Defined 4 testcases.
    Future work:  Continue interop-test.  Is anyone interested in
helping with this work?
Dieter?:  Clarification, is IETF going to organize interop events
between vendors.  Not all YANG models are stable?  Not an official IETF
interop test.
Lou: It is always good to hear implementation reports and issue 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 B: How many people have read the document? A reasonable number.

> 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 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 ba adopted as a WG draft?
Lou B: 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 into XXX document.  Would like to get feedback from authors
and the room?
Aijun: Answer unclear
Lou B: This draft would continue as a solutions draft.
Dhruv: As an co-author/contributorof/toprevious
document(https:/tools.ietf.org/html/draft-zhao-teas-pcecc-use-cases),
concerned that adding this usecase might slow the other draft, and not
sure that this is a good use case.
Daniellie: Traffic solution in IP networks is MPLS.
JeffTanstsura: Better comparison between FlowSpec and PCEP needed.There
might be some performance concern associated with the PCEP solution. 
Lou: I am talking about use-case - bring use-case in this document to
the other 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]. 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? Presenting:
    SR LSP and RSVP-TE LSPs must coexist at the same place, this can
cause bandwidth management issues.
    5 possible solutions:
        1) Statically partition the bandwidth between SR and RSVP-TE
        2) Central management of capability.
        3) Flooding SR Utilization in IGP (Drawback ICP implemenations
need to be updated)
        4) Run SR over RSVP-TE
        5) Similar to option 3, but don't need to update, ... what is
this option???
Dhruv:
    Looking at Central controller - Why cant we do only SRby the
controller?Also wouldnt there be backward campatibilitry issues when we
dont node if the node is updating SR resv bandwidth or not. 
Lou B: Question has to go the list.

> 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 presenting (quickly):
    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.
    Comments?
Amy? (Huaweu): I support this solution.  8 bits will be enough.
WG Chair: How many thinks 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 ???  A good number, but
not as many.

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