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

Meeting Minutes Traffic Engineering Architecture and Signaling (teas) WG
Title Minutes for TEAS at IETF-95
State Active
Other versions plain text
Last updated 2016-04-28

Meeting Minutes
minutes-95-teas

   [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)

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

>
>
>                     TEAS/MPLS/PCE Yang Agenda For IETF 95
>                     Version: Mar 31, 2016
>
>                     Tuesday, April 5th, 2016
>                     17:30 - 19:00 - Tuesday Afternoon Session III
>                     Room: Atlantico B
> Presentation         Start Time     Duration     Information
> 0           17:30     10     Title:     Administrivia
>                 Draft:
>                 Presenter:     Chairs
> 11           17:40     10     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-11.pptx
>                 Presenter:     Xufeng Liu

Pavan Beeram: guidance at last IETF was to separate out packet-specific stuff
and publish as a separate TEAS document and share details on the MPLS WG list.
Loa Andersson: Model will support multi-layer (work in progress). Two
approaches are considered "transition link" and "inter layer lock".

> 12           17:50     15     Title:     A YANG Data Model for Resource
Reservation Protocol (RSVP) >                                          A
YANG Data Model for Traffic Engineering Tunnels and Interfaces
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp/
>                 Draft:    
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ >                
Slides:     https://www.ietf.org/proceedings/95/slides/slides-95-teas-12.pptx
>                 Presenter:     Tarek Saad

Dhruv Dhody: in PCE WG our aim was to have a generic PCEP Yang. What's the
ietf-te-PCC you have? Tarek Saad: Dhruv Dhody: We can discuss offline, but
should that belong in IETF-PCEP? Tarek Saad: OK, let's talk about that Cyril
Margaria: Where's the source in the tunnels? Tarek Saad: data needs to be
globally scoped to model the network, and it's keyed by name. We thought that
the name can be made global by prepending the source router name or id. All
implementations seem to support name-based tunnels. Cyril: is this in the
draft? Tarek Saad: the key in teh draft is a string. we can make this clearer
if need be. Dhruv: I'd like to thank the authors for taking comments form PCEP
and making a generic ietf-te . ? Tarek Saad: we thought about embedding a
distinuisher in the tunnel name but we decided it was unnecessary Pawel
Brzozowski: Name can be globally unique - are you saying the source isn't
valuable? Tarek Saad: no, but the name is sufficient for a unique key. Pawel
Brzozowski: So the source ID doesn't have to be part of the key Tarek Saad: we
have the source in the model Lou Berger: Naming: you didn't want to use PSC, so
you used MPLS. That will lead to confusion as we have some base models that are
MPLS that will be used for non-packet stuff. I appreciate that PSC is
GMPLS-centric term - maybe just use "packet"? Tarek Saad: other models will use
this too Lou Berger: I think MPLS as packet will lead to confusion, but I'm
interesting in what other folks have to say. I think having MPLS implicitly be
PSC will cause confusion Adrian Farrel: suppose there was another box for
RSVP/GMPLS...

Lou Berger: GMPLS-packet is an augmentation
Tarek Saad: Yes, for bidirectional
Lou Berger: I'd hope bidir would be part of the core as it applies to
everything except traditional RSVP-TE Lou Berger: I'll back up: until you have
GMPLS in this picture I don't understand it. I still think you need a term for
packet other than MPLS. Loa Andersson: question to Lou: what's the cause of the
confusion by using MPLS and why is packet better? Lou Berger: I think we'll end
up with a bunch of technology-specific models, which will look like GMPLS.
until we see how it all fits together i dont' really understand it. So I'd like
to see the authors proposal for this. Jon Hardwick: we should take this offline
as we need to keep to schedule Lou Berger: OK. As TEAS chair I'd like to see a
GMPLS module. Lou Berger: another thing: you have a use-case for the schema
mount idea that we (routing design team) think is likely to happen. Please take
this to netmod and say that their restrictions are too extreme for your
use-case - that would be useful information Igor Bryskin: I agree with Lou that
'MPLS' is confusing. I like to call PSC PSC - we should use the right names for
each technology. Things like MPLS are ambiguous. Tarek Saad: we went away from
PSC becasue ti was confusing. Qeustion now is between packet and MPLS.

> 13           18:05     10     Title:     A YANG Data Model for MPLS Base
and Static LSPs >                 Draft:    
https://datatracker.ietf.org/doc/draft-saad-mpls-static-yang/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-13.pptx
>                 Presenter:     Tarek Saad

Adrian Farrel: Static LSP... I'm trying to work out whether what you describe
is an end-to-end LSP or an LSP as seen at one node Tarek Saad: End-to-end. We
have the notion of in- and out-segment so we're defining exposed swap and
pop... but for the LSP we have an operation that applies on head/transit/egress
Adrian Farrel: So it's a bit like an explicit route with labels Tarek Saad: Yes
Adrian Farrel: So when I use the model, what's different between a static LSP
and a RSVP-TE signaled one? Tarek Saad: Static is config-driven Adrian Farrel:
But from the point of view of a user who doesn't understand the difference, how
does the model look different? Tarek Saad: What we're trying to model is what
operations need to be invoked on invoming/outgoing labels. RSVP has a lot of
state and timers, etc. In the data-plane they'll look alike but we aren't
modeling that yet Adrian Farrel: I understand the data-plane and what coders
have to do, but when you request an LSP from the management plane, isn't the
information all the same? Tarek Saad: The interface we're exposing is a data
model. But this is mostly config-driven. Jon: please take to the list Dhruv
Dhody: IETF-TE works at the controller. Is MPLS static LSP only for the device
or can it be used at the controller too? Tarek Saad: controller can provision
an LSP using this? ? (inaudible) George Swallow: you mentioned multiple labels.
Have you considered how a SR LSP would look? And are you engaging with SPRING
WG? Tarek Saad: It's still a static LSP. George Swallow: Or it could be a stack
of labels. Tarek Saad: We think the operations we've defined (impose/swap/pop)
also cover SR Lou Berger: From a chair's perspective you have at least a couple
of models here and you should consider separating them Tarek Saad: OK, thanks.
Jon Hardwick: The right list is MPLS. OK? Lou Berger: I think it should be the
list for the WG that owns the draft. And if the intent is that it should cover
TE and non-TE then MPLS is the right list.

> (~18:25)
> 17           18:50     10     Title:     Yang Data Model for LSP-PING
>                 Draft:    
https://datatracker.ietf.org/doc/draft-zheng-mpls-lsp-ping-yang-cfg/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-17.pptx
>                 Presenter:     Guangying Zheng

(no questions)

> (~18:34)
> 15           18:30     10     Title:     A YANG Data Model for Path
Computation Element Communications Protocol (PCEP) >                
Draft:     https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-15.pptx
>                 Presenter:     Dhruv Dhody

Tarek Saad: I see that the ietf-device model we've introduced is a fit to be
augmented by this. Dhruv Dhody: Yes for the first part, but when you come to
PCE it's PCE stuff. We can figure this out but the feeling is this belongs in
IETF-TE rather than in PCEP. Lou Berger: As NETMOD chair, I'll say that this
whole topic is an open one and the WG is trying to come up with a solution. I
have no idea if we'll succeed, but we hope to have a better idea by Berlin. The
objective right now is that model writers won't have to do anything to support
opstate - there will be tooling to provide the elements we need. That's the
hope. Dhruv Dhody: So keep drafts as they are for now? Lou Berger: Don't go
decorating your models with intended/applied if you haven't already done so. If
you have, don't change it back. Jon Hardwick: we should talk about this in PCE
WG tomorrow.

(~18:41)
> 16           18:40     10     Title:     YANG Models for the Northbound
Interface of a Transport Network Controller: Requirements, Functions, and a
List of YANG Models >                 Draft:    
https://datatracker.ietf.org/doc/draft-zhang-ccamp-transport-ctrlnorth-yang/
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-16.pptx
>                 Presenter:     Xian Zhang

Cyril Margaria: the service model looks a lot like tunnel information. Why not
use that? Xian Zhang: the reason we do it separately is that for the tunnel
model there's a lot of stuff the client doesn't need. Cyril Margaria: but those
aren't mandatory Tarek Saad: I would expect that some of these would be
augmentations to TE-tunnel. Xian Zhang: So do you think these things are
generic? Lou Berger: What we're seeing here is specific to a specific
technology - it's in CCAMP. What here is technology-specific? Xian Zhang: Not a
lot. But the use-case we focus on is technology-specific which is why the draft
is in CCAMP Lou Berger: OK. I think the details belong in TEAS. Do the CCAMP
chairs want to say anything?

Adrian Farrel: I'm interested by the scheduling piece of this. We have work
going on in TEAS around scheduling LSPs from a control-pane point of view. What
I see here is a very generic scheduling policy - you could schedule anything in
the IETF with this. Someone probably needs to talk to the right person about
whether this should be a separate model. Xian Zhang: I'm not writing my own
schedule paths - I'm using pre-existing ones Rajiv Asati: if it's related to
northbound, so we really need to have the specifics in the model that describes
every node where the service needs to be instantiated? Can we abstract the
details out Xian Zhang: you're right to some extent. Some use-cases (e.g. #2)
need to expose technology-specific info. We'd need a use-case for the
abstracted version.

(~18:52)
> 14           18:15     15     Title:     YANG Data Model for MPLS LDP and
mLDP >                 Draft:    
https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang
>                 Slides:    
https://www.ietf.org/proceedings/95/slides/slides-95-teas-14.pptx
>                 Presenter:     Rajiv Asati

Loa Andersson: I'm a bit split as I'm an author of LDP and also a member of the
design team. I don't think we're doing anything more strict than in RFC 5036.
What's stricter is that we're getting away from the rather loose concept that
we've had since then. Lou Berger: Did you hear Andy's talk in NETMOD yesterday?
Rajiv Asati: Yes Lou Berger: There's a guideline update happening, so please
send that to Andy Rajiv Asati: I sent a mail this morning Jeff T: Could we have
a goal for the yang design team to come up with this by Berlin? This quesiton
comes up over and over again Lou Berger: it's an AI for netmod at this point.
One of the changes from yesterday to now is that this is now a specific
deliverable. Rajiv Asati: even if there's no recommendation, pros and cons
would be nice. Lou Berger: I'd like specific guidelines. NETMOD is the right
place for that conversation.

============

Jon: I think that was a really useful session. Special mention to Matt for the
agenda. That's the end of the agenda. Please come to PCE tomorrow :)

> Adjourn           19:10
>
>
>
Notes from Haomian and Matt