Re: [Teas] Raw notes from TEAS session

All,

I've gone over the audio and made some markups to the etherpad based on that. We have one person who commented on the last presentation (Mach's rfc5316bis draft) who remains anonymous at this point.

Cheers

Matt

> All,
> 
> Thanks to we have Jon Hardwick, Haomian Zheng and other anonymous note
> takers to thank for the enclosed  raw notes from today.  These notes are
> also available, and editable, via the URL:
>         http://etherpad.tools.ietf.org:9000/p/notes-ietf-94-teas
> 
> Please review and feel free to add your corrections via the link above.
> Changes/notes will be reviewed and approved by the chairs (and WG) before
> being finalized.  Please limit changes to what actually transpired in the
> meeting.  Session audio is available at
> http://www.ietf.org/audio/ietf94/ietf94-room301-20151104-0900.mp3
> 
> If you have a question or want to discuss any topics raised in the
> session, please feel free to do so on the list, but please do so with an
> appropriate Subject line.
> 
> Thank you!
> Lou and Pavan
> 
> 
>  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
> 
> > 1       9:05   5   Title:   WG Draft updates
> >         Draft:   Many
> >         Presenter:   Chairs
> 
> 2 drafts in RFC Ed Q
> 2 drafts with IESG
> 1 draft in WGLC
> 4 liaisons
> BBF liaison requires response by 8 Nov; detailed review required.  CCAMP
> is coordinating the response.
> 
> The working groups is reminded to use the mailing list to discuss issues,
> not just to report back on the resolution of issues.  WG consensus is
> determined on the mailing list.
> Wiki page is now available, for experts to share their view point.
> 
> Cyril: SRLG collection draft: authors will address comments received and
> welcomes new comments.
> Lou: RSVP egress protection draft authors are asking for last call - it is
> a good time to review this draft.
> 
> > 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
> 
> 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: the selction between the two options was  obtained by voting?
> (Yes) 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 seperate it Lou Berger: YANG model align to the I2RS draft will
> be done in their WG?
> Is it finished in teas?
> Xufeng Liu: Almost, I2RS draft will be updated.
> Xufeng: L3 topology model will have a reference to the TE topology model.
> Alex: We must be careful to avoid circular dependencies between these two
> models.
> Lou: 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: Operators want to turn MPLS on explicitly on interfaces.
> Lou: The model allows MPLS and RSVP to be enabled independently.
> Question to Ina: is that what you wanted?
> Ina: 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: We use unnumbered interfaces a lot, this model has to cover them.
> Lou: (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.
> Lou: 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 doument.
> 
> > 5       9:50   10   Title:   OpenConfig MPLS Model (TE Aspects)
> >           http://datatracker.ietf.org/doc/draft-openconfig-mpls-
> consolidated-model
> >         Presenter:   Ina Minei
> 
> Anees: Find these models on github.com/openconfig/public.
> 
> > 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 with information models is appreciated. Your intent
> is to build an information model that informs the data models that we are
> working on, correct? (Scott, yes) In which case, please could you bring
> any gaps that you find to the mailing list?
> Scott: Yes, will bring that back to the authors.
> Lou Berger: for Appendix A, confused about why a Data model is presented.
> Scott: it demonstrates how you can generate a data model if you already
> have a info model, an example for guideline.
> Scott: Appendix A is supposed to be an example; it is intended to guide
> you to what you are building.
> Lou: a pointer to this information may be better; it is confusing to find
> a data model in an information model document.
> Lou: 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: is there any ACTN work that need to change TEAS charter?
> Young: We don't think it's going to change the charter.
> 
> > 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: What is the relationship between this draft and the te-
> interconnection draft?
> Lou Berger: that is already clarified, as
> Adrian: bring some terminology from te-interconnection into ACTN work to
> avoid inconsistency.
> Young Lee: would like to collaborate on terminology level.
> Young: we did not invent any new terminology, so if there is a conflict in
> usage then we need to elaborate on that.
> Lou: See RFC 7426 - you may wish to reuse that terminology, that is what
> the IETF is using.
> Lou: is everything in the framework controller-based?
> Daniele: Yes - ACTN is between controllers, not between controllers and NE
> Lou: In TEAS we want to make sure that the number of layers is arbitrary
> Daniele: This is OK, stacking of layers is allowed.
> 
> > 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: 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: Are future bookings always first come first serveed or are there
> other prioritizations?
> Adrian: This is a question of what policy do you want to implement on your
> servce which is beyond our scope.
> Robin: We have proposed a similar time-based approach for BGP flowspec.
> ??? 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: 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?
> Daniele: I am really interested in this work, but what is the scope? Are
> we interested only in networks with RSVP-TE?
> Lou: No, we are interested in all TE networks.  We want to discuss
> architecture for now, nor solutions.
> 
> Gert: I have never seen a large scale TE signaling deployment. So I do not
> have much interest in seeing these drafts.
> Lou: This discussion has come up often over many years, but we have not
> got to the point where enough people are prepared to work on it.
> 
> Lou: Who is interested in working on this?  Raise your hands. (About 15
> people.)
> Lou: Now who does not want to work on it?  Raise your hands.  (About 6-8
> people.)  OK, somewhat more people want to work on it than don't.
> 
> Lou: WG please go and read this draft and comment, let's see if there is
> value on continue doing this.
> Himanshu: I would prefer to ask who wants to work on the distributed
> model?
> Adrian:
> Daniele: 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?
> Lou: 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: We are not trying to introduce a new architectural concept. We are
> trying to assess the impact and applicability to use a new protocol.
> Dhruv: 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.
> 
> Sergio: To provide remote information you need to have IGP in the network,
> so what is the advtangtage of using PCEP as well?
> Dhruv:
> 
> > 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
> 
> Lou: How many have read this document?  (Quite a few)
> Lou: informational or standard track?
> Dhruv: there are two drafts related, informational for use case one
> (presented here), and experimental for the protocol extension (in PCE
> working group).
> Lou: Who thinks this is a good idea?  (Almost the same)
> Lou: Who thinks we should not work on this (One or two)
> Sergio: Not a bad idea, but PCE should be a part of the controller, not
> the controller itself.
> 
> > 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?
> Lou: 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: No, the problems are only for IS-IS.
> Chris Hopps: Happy for this document to move to ISIS WG.
> 
> > Adjourn       11:30
> >
> >
> 
> Note takers add your name here
> Jon Hardwick
> Haomian Zheng
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas