Minutes IETF97: teas
minutes-97-teas-01

Meeting Minutes Traffic Engineering Architecture and Signaling (teas) WG
Title Minutes IETF97: teas
State Active
Other versions plain text
Last updated 2016-12-08

Meeting Minutes
minutes-97-teas

   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:
   te-metric-recording: no status update received. is there still interest?
   Poll: How many think the WG still work on this?  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?  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 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? . 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 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 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 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 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 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 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 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) Lou Berger: How many people have read the
document?  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 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  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 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 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