Minutes for TEAS at IETF-94
minutes-94-teas-1

 IETF 94 - TEAS Agenda
>           TEAS Agenda For IETF 94
>           Version: Nov 03, 2015
>
>           Thursday, November 5th, 2015
>           0900 - 11:30 - Thursday Morning Session I
>           Room: 301
> Presentation     Start Time   Duration   Information
> 0       9:00   5   Title:   Administrivia & WG Status
>         Draft:
>         Presenter:   Chairs

Video: https://www.youtube.com/watch?v=naWGWqRgdfw

2 drafts in RFC Ed Q
2 drafts with IESG
Lou Berger: Question for ADs: we'll need to work out how to handle errata for
docs that were originally done through CCAMP? Does CCAMP handle it, or TEAS? 1
draft in WGLC, 3 in pre-LC state (IPR poll) 4 liaisons Lou Berger: BBF liaison
requires response by 8 Nov; detailed review required.  CCAMP is coordinating
the response so comments should go there. Lou Berger: The working group is
reminded to use the mailing list to discuss issues, not just to report back on
the resolution of issues.  We haven't been doing a good job of this. WG
consensus is determined on the mailing list. Issues that have been discussed
between document authors still need to be shared with the WG list. Lou Berger:
Wiki page is now available, for experts to share their view point.

> 1       9:05   5   Title:   WG Draft updates
>         Draft:   Many
>         Presenter:   Chairs

Cyril Margaria: draft-ietf-teas-rsvp-te-srlg-collect: authors will address
comments received and welcomes new comments. Lou Berger: Any documents where
authors are asking for last call - it is a good time to review this draft and
send comments to the list Jeffrey Zhang:
draft-ietf-teas-rsvp-egress-protection: had some comments last year that we
didn't get consensus on, and I lost track of the draft when it moved to TEAS. I
need to review latest revision to see if my comments have been addressed. Pavan
Beeram: please review and send your comments to the list.

> 2       9:10   10   Title:   Extensions to RSVP-TE for LSP Ingress Local
Protection >         Draft:  
https://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-04 >       
 Presenter:   Huaimo Chen

Huaimo Chen: 8 people support relay-message method.  4 people support
proxy-ingress method. Each group of supporters are saying that their preferred
method is simpler. Lou Berger: so the main change from the previous version is
that you've selected one optionbased on voting? Huaimo Chen: Yes Lou Berger:
Simple voting really isn't the same as consensus.  Please bring the technical
tradeoffs to the mailing list and let's try to discuss and reach consensus
there.  If you (authors) think it would be helpful we can have a conference
call (interim) to discuss the more details.

> 3       9:20   15   Title:   TE Topology Model
>         Draft:   http://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo
>         Presenter:   Xufeng Liu

Lou Berger: Please move (advanced) scheduling to its own document
Xufeng Liu: We have to decide which WG
Lou Berger: It's fine to start in TEAS, but please separate it out for next
time. This is the third time we've had this discussion. Xufeng Liu: A few weeks
ago we had a demo of this model to demonstrate topology-as-a-service, so now we
have working implementations. Lou Berger: Please send comments to the list, and
also update the list as issues are resolved by the authors. Lou Berger: YANG
model alignment to the I2RS draft will be done in their documents? Is it
finished in teas? Xufeng Liu: Mostly, yes, I2RS documents will be updated. But
their changes will affect us so we'll have to update accordingly. Pavan Beeram:
There are multiple I2RS topology documents; can you comment on the L2 and L2
topology models? Xufeng: We discussed this at the last IETF. Decision was to
let other topology models (L3, L2) have a reference to the TE topology model.
Alex Clemm: We resolved most of the issues; we just have to decide which model
this goes in. Xufeng Liu: we're trying to progress the L3 topology model
without waiting for this one (it's in LC), so we'll have a new model that
references this one so they can proceed independently. Alex Clemm: if we put
things from this model into the L3 topology we'll create circular dependencies.
We must be careful to avoid that. Lou Berger: It's good that you are working
together to resolve this; if there is a coordination issue between WGs then
please raise with chairs; please discuss technical issues on the mailing lists.

> 4       9:35   15   Title:   RSVP and TE Yang models
>         Draft:   http://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp
>           http://datatracker.ietf.org/doc/draft-ietf-teas-yang-te
>         Presenter:   Tarek Saad

Ina Minei: We (OpenConfig) had the same challenge deciding how to enable MPLS
on interfaces. Based on discussions among operators the decided that turning on
MPLS on explicitly onx interfaces is what we want to do since there's no good
way to do filtering. The only way you have to block MPLS traffic on an
interface is to not enable it. Tarek Saad: Thanks. That could sway us towards
doing it that way. Lou Berger: The model allows MPLS and RSVP to be enabled
independently. Question to Ina: is that what you wanted? Ina Minei: We wanted
to see if we could get rid of the need to enable them independently but we
could not find a way to do that. Pawel Brzozowski: We use unnumbered interfaces
a lot, this model has to cover them. Augmenting the routing interfaces list
won't work for them. Tarek Saad: OK. Ina Minei: re slide 8 (enabling RSVP
interfaces): option 4 is also the approach we took. Lou Berger: (To Tarek) It's
not always clear which RFCs you are mapping back to and which you are
supporting. It is important for implementers to know this. It will also expose
places where there's no RFC to map to, which is also important; it's OK for us
to support a feature that's not fully documented, but we have to have a
clean/uniform solution. Lou Berger: I think it's time to pull out the
PSC-specific pieces from this document. The split pieces can start as a -00
working group document as they are being split out from a WG document. Please
let the Chairs know when you're ready.

> 5       9:50   10   Title:   OpenConfig MPLS Model (TE Aspects)
>          
http://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model >     
   Presenter:   Ina Minei

Anees Sheikh: Find these models on github.com/openconfig/public.
Lou Berger: Thanks for working slow closely with the community to get the
models aligned.

> 6       10:00   10   Title:   Usage of IM for network topology to support TE
Topology YANG Module Development >         Draft:  
http://datatracker.ietf.org/doc/draft-lam-teas-usage-info-model-net-topology > 
       Presenter:   Scott Mansfield

Lou Berger:  Working to harmonize this is appreciated. Your intent is to build
an information model that provides guidance for and aligns with the data models
that we are working on, correct? Scott Mansfield: yes Lou Berger: In which
case, please could you bring any disconnects that you find to the mailing list?
Scott Mansfield: Yes, that's what we're looking for here. We have years of work
on this in the ITU, and we'd like to make sure that if you start with our
information model you get to the yang data model that the IETF is building.
Scott Mansfield: I've told folks at the ITU, ONF etc that the IETF considers
people as individuals, and getting on the WG mailing lists and commenting there
is much faster than working through liaisons. Lou Berger: information model
authors are likely to spot issues in data models, so we'd appreciate the
feedback Lou Berger: for Appendix A, confused about why a Data model is
presented. Scott Mansfield: it demonstrates how you can generate a data model
if you already have a info model, an example for guideline on how to write an
information model to make it easier to generate a data model Scott Mansfield:
Appendix A is supposed to be an example; it is intended to guide you to what
you are building. Lou Berger: a pointer to this information may be better; it
is confusing to find a data model in an information model document. It looks
like a competing data model. Lou Berger: It would also be good to provide the
same sort of feedback to CCAMP on their technology-specific models.

> 7       10:10   10   Title:   Requirements for Abstraction and Control of
Transport Networks >         Draft:  
http://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements >        
Presenter:   Young Lee

Pavan Beeram: is there any ACTN work that needs a change to the TEAS charter?
Young Lee: We don't think there's a need to change the charter. Daniele's
presentation will discuss this.

> 8       10:20   10   Title:   Framework for Abstraction and Control of
Transport Networks >         Draft:  
http://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework >        
Presenter:   Daniele Ceccarelli

Giovanni Martinelli: What is the relationship between this draft and the
TE-interconnection draft? Lou raised this last time but I'm not sure what the
answer was. Lou Berger: The evolution of this draft will be similar to the
evolution of the TE-interconnection draft, i.e. we'll go from a contentious
draft and a lot of debate to something that's not contentious at all. We might
repeat that process here. Adrian Farrel: As an editor of that other document...
it would be useful to bring some terminology and concepts from
te-interconnection into ACTN work as ACTN is also a layering/virtualization
problem. Lou Berger: alignment with existing terminology is good. We now have
an RFC that talks about SDN and puts names to some of the components in SDN so
you (the authors) might want to look at that. Daniele Ceccarelli: the
infrastructure is common between ACTN and TE-interconnection (LSPs) so we'll
use the same terminology for that. Louy Berger: it's not just the
TE-interconnected draft - it's all TE documents that the IETF has produced.
Young Lee: would like to collaborate on terminology level. I don't think we
invented any new terminology, so if there is a conflict in usage then we need
to elaborate on that. Lou Berger: See RFC 7426 for the SDN terminology - you
may wish to reuse that terminology, that is what the IETF is using. Lou Berger:
Is everything in the framework controller-based? Daniele Ceccarelli: Yes - ACTN
is between controllers, not between controllers and nodes Lou Berger: In TEAS
we want to make sure that the number of layers is arbitrary Daniele Ceccarelli:
This is OK, stacking of layers is allowed. Lou Berger: document is a little
confusing so please make it clear. Some of the questions you have seem to have
been answered already by precedent. Young Lee: OK.

> 9       10:30   10   Title:   Information Model for Abstraction and Control
of TE Networks (ACTN) >         Draft:  
http://datatracker.ietf.org/doc/draft-leebelotti-teas-actn-info >        
Presenter:   Sergio Belotti

Lou Berger: When you talked about connectivity topology there seems to be
overlap with Scott's presentation. It would be good if you could work together
on that.

> 10       10:40   10   Title:   Architecture for Scheduled Use of Resources
>         Draft:  
http://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources >        
Presenter:   Adrian Farrel

Ken Colberg: Are future bookings always first come first served or are there
other prioritizations? Adrian Farrel: This is a question of what policy do you
want to implement on your service which is beyond our scope. Daniele
Ceccarelli: will this be a WG document or not? Lou Berger: we can discuss after
the next presentation as there's a lot of overlap Robin Xu: We have proposed a
similar time-based approach for BGP flowspec. The service needs to map to the
TE path. I think there should be some framework for synchronizing the
time-based request with the actual service flow.

> 11       10:50  10   Title:   Framework for Temporal Tunnel Services
>         Draft:   http://datatracker.ietf.org/doc/draft-chen-teas-frmwk-tts
>         Presenter:   Huaimo Chen

Lou Berger: it seems that this documents and the preceding document both talk
about the same problem space.  Is the WG interested in working on this problem?
We'd like to hear from the WG. Daniele Ceccarelli: I am really interested in
this work, but what is the scope? Are we interested only in networks with
RSVP-TE? Lou Berger: No, we are interested in all TE networks.  We want to
discuss architecture for now, not solutions (yet). Gert Grammel:
Bandwidth-on-demand and bandwidth scheduling have come up before, and I have
never seen a large scale deployment of them. When it comes to TE, I'm wondering
what kind of TE would be needed for such a demand if it came up. So I'm OK with
these things existing as a use-case but I don't have much interest in seeing
drafts. Lou Berger: This discussion has come up often over many years since the
first days of TE LSPs, but we have not got to the point where enough people are
prepared to work on it. Are we there yet? Lou Berger: Who is interested in
working on this?  Raise your hands. (About 15 people.) Lou Berger: Now who does
not want to work on it?  Raise your hands.  (About 6-8 people.) Lou Berger: OK,
somewhat more people want to work on it than don't. So, I'd ask that people
read these drafts and comment, both on the specific proposals and the problems
space and let's see if there is value in continuing to do this. Himanshu Shah:
I would prefer to ask who wants to work on the distributed model? I'm OK with
scheduling for TE services but not the distributed model Lou Berger: OK. That's
useful, but the first thing is to find out if people want to work on this at
all. But I'm sure many people would prefer to work on one over another. Adrian:
I also don't want to work on a model that doesn't work. Daniele Ceccarelli:
prefer to follow a single model.

> 12       11:00   10   Title:   Architecture and Requirement for Distribution
of Link-State and TE Information via PCEP >         Draft:  
http://datatracker.ietf.org/doc/draft-leedhody-teas-pcep-ls >        
Presenter:   Dhruv Dhody

Lou Berger: Any architecture changes? They should be discussed here, protocol
changes to the appropriate WG. Dhruv Dhody: I think we've done that. Lou
Berger: Most of this is basic architecture, and most of it is existing
architecture. So having a discussion of the basic architecture in a
protocol-agnostic way is OK for clarification, but we should focus only on the
architectural aspects. Dhruv Dhody: We are not trying to introduce a new
architectural concept. We are trying to assess the impact and applicability of
using a new protocol. Making this document agnostic of the protocol destroys
the value of the document.  The whole purpose is to explore the applicability
of using PCEP for this. Lou Berger: OK, I'll send further comments offline
Sergio Belotti: To provide remote information you need to have IGP in the
network, so what is the advantage of using PCEP as well? Dhruv Dhody: we don't
aim to replace any existing protocol. Sergio Belotti: You provide both local
and remote information, so you need an IGP for remote information. What's the
advantage of this? Dhruv Dhody: You're not running the IGP for the controller
to talk to your network. We know that there's some considerations with respect
to multi-area.

> 13       11:10   10   Title:   PCE as a Central Controller (PCECC)
>         Draft:  
http://datatracker.ietf.org/doc/draft-zhao-pce-central-controller-user-cases > 
       Presenter:   Dhruv Dhody/Quintin Zhao

(no time for presentation of slides)
Lou Berger: How many have read this document?  (Quite a few)
Lou Berger: Do you intend this as an informational or standards track document?
Dhruv Dhody: Informational
Lou: the document says standards track
Dhruv Dhody: there are two drafts related, informational for use case one
(presented here), and experimental for the protocol extension (in PCE working
group). Lou Berger: Who thinks this is a useful function for the WG to work on?
 (Almost the same) Lou Berger: Who thinks we should not work on this (One or
two) Sergio Belotti: Not a bad idea, but PCE should be a part of the
controller, not the controller itself. Lou Berger: I'd like to discuss more on
the list.

> 14       11:20   10   Title:   ISIS Extensions in Support of Inter-AS MPLS
and GMPLS Traffic Engineering >         Draft:  
http://datatracker.ietf.org/doc/draft-chen-teas-rfc5316bis >         Presenter:
  Mach Chen

Les Ginsberg: Does this draft belong in ISIS WG or here? RFC 5316 was
originally done in CCAMP but I'm not sure why as all the similar documents were
done in ISIS Lou Berger: The original RFC was done at the same time as the OSPF
version - does the OSPF document suffer the same flaws as RFC 5316? Mach Chen:
No, the problems are only for IS-IS. Lou Berger: so the text was right in one
document and wrong in the other? Les???: OSPF has AFI-specific versions, but
ISIS is AFI-independent Chris Hopps: Happy for this document to move to ISIS WG
if everyone agrees. We have another draft with the same change there so we'll
merge them.

Lou Berger: That's all we have time for. See you in Buenos Aires.
> Adjourn       11:30
>
>

Note takers add your name here
Jon Hardwick
Haomian Zheng
Matt Hartley (reviewed audio at
http://www.ietf.org/audio/ietf94/ietf94-room301-20151104-0900.mp3