[Teas] raw notes from this morning's session

[Lou Berger <[e-mail]>]

Kudos to Matt for the note taking and all who contributed to the session
and the notes!

[Notes from 2016-01-28 interim:
http://etherpad.tools.ietf.org:9000/p/notes-interim-2016-teas-1]

> Agenda
> TEAS Agenda For IETF 95
>                     TEAS Agenda For IETF 95
>                     Version: Mar 31, 2016
>                    
>                     Monday, April 4th, 2016
>                     10:00 - 12:30 - Monday Morning Session I
>                     Room: Atlantico B
> Presentation         Start Time     Duration     Information    
> 0           10:00     10     Title:     Administrivia & WG Status
>                 Draft:    
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-0.pptx
>                 Presenter:     Chairs

(no questions/comments)

> 1           10:10     10     Title:     WG Draft updates
>                 Draft:     Many
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-1.pptx
>                 Presenter:     Chairs

(no questions/comments)

> 2           10:20     10     Title:     Discussion on  RSVP-TE for LSP
Ingress Local Protection
>                 Draft:    
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-2.pptx
>                 Presenter:     Adrian Farrel

Lou Berger: I find it useful that you labelled LSP-ingress in the final
case (slide 5). Where does the LSP start in the other 2?
Adrian Farrel: double-line on the slides is the LSP. The problem is that
the head-end fails; the solution is how we get traffic to the destination.
Eric Osborne: I'm not sure what's in and out of scope（on page 5）, but
if I'm interested in anything it's the third case
Adrian Farrel: Thanks, that's helpful
Eric Osborne: Are we just talking about RSVP LSPs?
Adrian Farrel: Just RSVP for this WG
Eric Osborne: Not everyone runs PE-PE RSVP...
Greg Mirsky: I agree that OAM has to be considered. We also need to
specify what type of protection or restoration we can deliver as that
will define the mechanisms we can use for monitoring
Adrian Farrel: so you're saying, whether it's 1+1 or 1:1 or 1:n
protection, and for restoration whether it's repair after failure
Lou Berger: FRR is missed;
Adrian Farrel: FRR as currently defined cannot settle the ingress
problem; FRR is a big problem...
Lou Berger: do we want a solution that's tailored to work with FRR? Do
we not care?
Greg Mirsky: I think we can not use FRR but say segment protection
Adrian Farrel: maybe say 'bypass tunnel'? Would that be less contentious?
Eric Osborne: if I have to do something other than the FRR I already
have I'm not that interested right now
Gabriele Galimberti: would you also consider CE-PE link failures? This
doesn't change the way you handle it but it changes detection
Adrian Farrel: if you run LSPs from the CE you're interested in CE
failure; if you run from the PE then it's PE failure. The main scope
here is head-end LSP failure, wherever the LSP happens to run from.
Gabriele Galimberti: CE failure requires the same actions
Greg Mirsky: one more thing we need to define: what LSP head-end failure is.
Adrian Farrel: yes
Jeff Tantsura: More things we need to define: Do you want to merge back
up and primary at merge-point? What do you want to do with LSPs?
Adrian Farrel: challenge is to separate that out into the behaviour you
want to define, rather than the techniques you want to use. Danger is
that people say "I want to use FRR".
Lou Berger: first focus on the problem before talking about solutions;
(Questions) how many of you think it's a valuable problem? （reasonable
number）; only first and third use case receive interests. How many of
you understand the discussed options sufficently to have an opinion on
the three use cases (a few).
Lou Berger: I feel we don't understand the problem well enough yet to
discuss options here
Jeff Tantsura: we can learn a lot from pseudowire protection discussions.
Lou Berger: That's great, if you have any pointers, please send them to
the list. I don't think we have a good enough understanding of the
problems yet.  Think that we need to further discuss what problem we'd
like to solve with ingress protection on the list.
Lou Berger: It's useful to hear from the room that there is interest in
the WG continuing to work on the problem (Ingress protection).

> 3           10:30     20     Title:     Extensions to RSVP-TE for LSP
Ingress Local Protection
>                                         Extensions to RSVP-TE for LSP
Egress Local Protection
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-3.pptx
>                 Presenter:     Huaimo Chen
(for Ingress local protection draft)
Pavan Beeram: for the scope are you referring to the FRR?
Huaimo Chen: yes
(for Egress local protection draft)
Eric Osborne: I realize the ingress and egress are different but it'd be
nice if the solutions were as close as possible. It doesn't make sense
to have locally-scoped ingress protection and end-to-end egress
Huaimo Chen: egress is also local
Jeffery Zhang: we have a doc in MPLS for both RSVP and mLDP egress
protection.
Huaimo Chen: OK. I read Yimin's draft. Looks like there's overlap.
Lou Berger: it'd be good to look at existing solutions, if they exist,
expecially for egress protection. And also discuss on the list
Lou Berger: you said this covers FRR. Do you think the scope of egress
protection is limited to FRR?
Huaimo Chen: only FRR at this stage
Lou Berger: is the WG OK with egress protection excluding segment
protection and using only FRR.
Eric Osborne: as long as it's at least FRR, it doesn't bother me if you
do other stuff too
Lou Berger: in general we want to look at the broadest scope possible.
Can narrow scope if there's a reason to do so but if not, we should
cover both FRR and segment protection in this WG, even if it's just
informative (beacuse nothing new is needed)

> 4           10:50     30     Title:     YANG Data Model for TE Topologies
>                               
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-4.pptx
>                 Presenter:     Xufeng Liu

Lou Berger: for this presentation we're covering changes to the model
that haven't really been discussed on-list
Pavan Beeram: we've had quite a bit of dicussion off-list, so please use
the WG list for further discussion
Gert Grammel: (page 12), what do you mean by switching layer? where does
this layer exist? Are you talking about ITU layers, which can all be
switched? Or are you talking about things like MPLS and IP? It needs to
be clarified.
Fatai Zhang: are you going to define both transitional link and
inter-layer lock?
Xufeng Liu: yes
Fatai Zhang: better to define one of them as we can then do more
analysis on pros and cons, and then pick one
Igor Bryskin: we don't talk about inter-layer leaks. I think inter-layer
computations are an important problem to solve. It would be useful to be
able to have separate topologies at different layers but allow
computations across layers. Inter-layer lock Using SRLGs can achieve
this, which has advantage compared with transitional link.
Dieter Beller: during the weekly calls we discusssed the two approaches,
and the inter-layer lock id also has some drawbacks (you need an admin
entity to assign the lock IDs). The concept of transitional links has
the advantage that it's based on links and only requires some extensions.
Lou Berger: I think this has been informative for folks that aren't
involved. Informal discussions are open to all, but please send updates
to WG list to coordinate calls and send updates so everyone's on the
same page.
Igor Bryskin: I disagree with Dieter....
Lou Berger: I look forward to seeing that discussion on the list. And
also the announcement for the next informal meeting.

> 5           11:20     10     Title:     RSVP Extensions For
Re-optimization of Loosely Routed Point-to-Multipoint Traffic
Engineering Label Switched Paths (LSPs)
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-5.pptx
>                 Presenter:     Rakesh Gandhi

Lou Berger: I'm having trouble understanding the need for another
fragmentation mechanism - s2l was introduced for this in the first
place. I'd like to understand the need for this one. I think this needs
to be clarified before LC.
Rakesh Gandhi: Problem is when we send one s2l at a time, head-end
doesn't know when to start things like reoptimization. RFC 4875 has a
combined message defined but there's an issue when things are fragmented.
Lou Berger: I think this is a discussion to have offline, and I'd like
to have it. I know this (fragmentation) wasn't in the original proposal
and came in as a result of comments in MPLS WG. I think we need to make
sure we're not overloading too many mechanisms, and that it's clear why
the existing mechnisms are insufficient.

> 6           11:30     10     Title:     RSVP-TE Extensions for
Collecting SRLG Information
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-6.pptx
>                 Presenter:     Matt Hartley (remote)

<No questions>
Lou Berger: A successful remote presentation! Thank you Matt (and Meetecho)

> 7           11:40     15     Title:     Framework for Abstraction and
Control of Transport Networks
>                 Draft:    
http://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-7.pptx
>                 Presenter:     Daniele Ceccarelli

Igor Bryskin: for a multi-domain network there will be inter-domain leaks.
Daniele Ceccarelli: same concepts apply to inter-domain links as to
access links
Igor Bryskin:
Daniele Ceccarelli: So maybe we should call them access links rather
than inter-domain links
Igor Bryskin: Everything you discussed could be done with two models
Lou Berger: doesn't change whether we move fwd w/ this doc. Just they
point better at each other
Gert Grammel: I was confused between a customer service provider model
(often cited) which is more a policy issue, vs a network model
(client-server relationship) where considerations about visibility
simply don't apply. So it's tricky to figure out what you're describing
in the draft. The assumption is that a layer is controlled by an entity
and it has a client that's controlled by another entity, but that's not
always the case.
Daniele Ceccarelli: multi-layer applies. if client and server are
managed by the same entity then that's one issue...
Gert Grammel: question is how to define a 'domain'?
Daniele Ceccarelli: domain is everything managed by an MDSC. Could be
tens of differnet networks but as long as they're managed by the same
MDSC they're one domain
Gert Grammel: so if you have three domains run by a single provider, is
that one domain?
Daniele Ceccarelli: customer sees it as a single domain, provider runs
it as he prefers.
Gert Grammel: so need to distinguish between customer domain vs
technical domain.
Lou Berger: it seems that there's room for better-aligned terminology. I
know you did this with SDN terminology, but also should align with the
yang terminology
Daniele Ceccarelli: what's not aligned?
Lou Berger: what Igor talked about - access points. Also whether the
boxes in the figure can be referred as a PCE or not?
Daniele Ceccarelli: the PNC can be a PCE or something else.
Lou Berger: are you gonig to take another pass?
Daniele Ceccarelli: well, the WG needs to approve before the draft gets
adopted.
Lou Berger: (poll) How many think this is ready for adoption?
(reasonable number)
Lou Berger: how many want another revision
(two)
Lou Berger: okay will poll for adoption.  Question 1: is this work we
should be doing in the WG
(reasonable number)
Lou Berger: Question 2:how many have read this draft?
(slightly more)
Lou Berger: Question 3: how many think this draft is a good foundation
for the work?
(more than the first one)
Lou Berger: looks like we have good support in the room so we can take
it to the list.

> 8           11:55     10     Title:     Information Model for
Abstraction and Control of TE Networks (ACTN)
>                 Draft:    
http://datatracker.ietf.org/doc/draft-leebelotti-teas-actn-info
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-8.pptx
>                 Presenter:     Sergio Belotti / Young Lee

Lou Berger: Last time Scott Mansfield gave another presentation on info
model, and it was mentioned to work together, how's that going?
Sergio Belotti: That info model presentation (by Scott) focused on how
to make use of the YANG model, which is different from the one presented
here.
Lou Berger: concern is that we'd end up with two information models
modelling the samething differently
Gert Grammel: is this a client-server relationship or a
customer-provider relationship? Need to spell that out.
Young Lee: This is based on ACTN requirements and framework - nothing to
do with other SDO model (by Scott). We're just trying to capture
information elements before designing a protocol.
Lou Berger: we should make sure such models are orthogonal and there is
no overlap, otherwise there will be conflict.
Young Lee: but this is based on ACTN rather than anything else.
Lou Berger: We should have more discussion on the list. We don't have to
wait for a meeting to declare consensus but we do need to discuss.
Lou Berger: we're running short of time, so cutting the discussion short
here.

> 9           12:05     10     Title:     RSVP-TE Extensions For
Associated Co-routed Bidirectional Label Switched Paths (LSPs)
>                 Draft:    
https://datatracker.ietf.org/doc/draft-gandhishah-teas-assoc-corouted-bidir/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-9.pptx
>                 Presenter:     Rakesh Gandhi

Pavan Beeram: So you're just adding the co-routed flag and the extension
object?
Rakesh Gandhi: yes - source, lsp-id and co-routed flag
Pavan Beeram: and you're just proposing a flag to make it co-routed
Rakesh Gandhi: Yes, and also the midpoint needs to assign a corouted bypass
Lou Berger: But the egress node already has that information
Rakesh Gandhi: Yes, but it doesn't say the LSP is co-routed
Lou Berger: So you're saying there's ambiguity in the current spec?
Rakesh Gandhi: Yes. If there's a loose hop, how does the egress know it
should follow the same path?
Lou Berger: So you're requiring co-routing?
Rakesh Gandhi: yes
Lou Berger: And then you're adding a hint for the transit LSR. But isn't
this already in the path message?
Rakesh Gandhi: But nodes can have multiple LSPs (e.g. during reoptimization)
Lou Berger: OK. I think we need a better definition of what's missing
from the current definitions (RFCs) and what the gap is in order to have
agreement that we need to solve the problem.  Feel free to send new
draft text to list to get this discussion going.

> 10           12:15     15     Title:     The Use Cases for Using PCE
as the Central Controller(PCECC) of LSPs
>                 Draft:    
https://datatracker.ietf.org/doc/draft-zhao-teas-pcecc-use-cases/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-10.pptx
>                 Presenter:     Quintin Zhao

Dieter Beller: I found some negative statements in the draft about the
RSVP solutions already deployed, and I have some concerns about that.
Quintin Zhao: Customers decide this, if they prefer not implementing
RSVP, we provide this solution.
Lou Berger: people sometimes feel they have to destroy old solutions to
define new ones; this isn't really necessary. Just focus on the new stuff.
Jeff Tantsura:Need to think about SR and separation of the link state.
This reminds me of openflow with its centralized controller.
Adrian Farrel: I'm intrigued to see the last two speakers say that SDN
is a bad idea
Lou Berger: TEAS is a big tent, we can accomodate both approaches :)
Lou Berger: thanks for coming, see you all tomorrow for the joint Yang
session


> Adjourn           12:30