Subject: [Teas] Raw notes from TEAS session

From: Lou Berger <[email-masked]>
Date: Thu, 5 Nov 2015 14:14:19 +0900

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

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 17 Nov 2015 18:44:02 +0000

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:
> 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
> 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.
> Lou: RSVP egress protection draft authors are asking for last call - it is
> a good time to review this draft.
> 
> 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.
> 
> 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?
> 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.
> 
> 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?
> Lou: a pointer to this information may be better; it is confusing to find
> a data model in an information model document.
> Giovanni: What is the relationship between this draft and the te-
> interconnection draft?
> Young: we did not invent any new terminology, so if there is a conflict in
> usage then we need to elaborate on that.
> 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.
> 
> Adrian: This is a question of what policy do you want to implement on your
> servce which is beyond our scope.
> ??? I think there should be some framework for synchronizing the time-
> based request with the actual service flow.
> 
> Gert: I have never seen a large scale TE signaling deployment. So I do not
> have much interest in seeing these drafts.
> 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:
> 
> 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?
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Nov 2015 13:57:16 -0500

Thank you! So you think this is ready for review and distribution, right?

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 17 Nov 2015 19:08:33 +0000

> Thank you! So you think this is ready for review and distribution, right?

As far as I'm concerned, yes. Although given that I made quite a few changes, would it be worth giving the WG a day or two to comment if they want to?

Cheers

Matt

> > 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:
> >> 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
> >>>
> >> BBF liaison requires response by 8 Nov; detailed review required.
> >> CCAMP is coordinating the response.
> >>
> >> 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.
> >>
> >> 8 people support relay-message method.  4 people support
> >> proxy-ingress method.
> 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
> >> 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?
> >> 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.
> >>
> >> 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.
> >> document. The split pieces can start as a -00 working group document
> >> as they are being split out from a WG doument.
> >>
> >> 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: 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: It would also be good to provide the same sort of feedback to
> >> CCAMP on their technology-specific models.
> >>
> >> Adrian: bring some terminology from te-interconnection into ACTN work
> >> to avoid inconsistency.
> >> 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.
> >>>         Draft:   http://datatracker.ietf.org/doc/draft-leebelotti-
> teas-
> >> actn-info
> >> time- based request with the actual service flow.
> >>
> >>>         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?
> >> 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: WG please go and read this draft and comment, let's see if there
> >> is value on continue doing this.
> >> protocol-agnostic way is OK for clarification, but we should focus
> >> only on the architectural aspects.
> >> 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.
> >>
> >> http://datatracker.ietf.org/doc/draft-zhao-pce-central-controller-use
> >> r-
> >> cases
> >> Sergio: Not a bad idea, but PCE should be a part of the controller,
> >> not the controller itself.
> >>

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Nov 2015 14:31:53 -0500

The next step is for me and Pavan to review/okay then poll the WG for
input..

On 11/17/2015 2:08 PM, Matt Hartley (mhartley) wrote:
>>>> rfc5316bis