Minutes for TEAS at interim-2014-teas-1
minutes-interim-2014-teas-1-1

Agenda - TEAS Virtual Interim
Dec. 18, 2014 20:00 UTC (2 hour duration)

Held over Webex

Material is posted at:
    http://www.ietf.org/proceedings/interim/2014/12/18/teas/proceedings.html

Recording:
https://ietf.webex.com/ietf/ldr.php?RCID=fe6635b449db2141f7270c03617fe5ce

    Attendance copied from Webex during the meeting...
    Adrian Farrel
    Lou Berger
    Aihua Guo
    Alia Atlas
    Cyril Margaria
    Daniel King
    Deborah Brungard
    Don Fedyk
    Fred Gruman
    George Swallow
    Ignas Bogdanas
    Igor Bryskin
    Jonathan Sadler
    Kam Lam
    Young Lee
    Lyndon (Ong?)
    Matt Hartley
    Matthew Bocci
    M Waldman
    Oscar Gonzalez de Dios
    Pawel Brzozowski
    Rakesh Gandhi
    Scott Mansfield
    Susan Hares
    Tarek Saad
    Victor Lopez
    Vishnu Pavan Beeram
    Xufeng Liu
    Yuji Tochio
    Zafar Ali

> - 10 min - Agenda/Intro (Lou)
Welcome, ususal IETF note well
Meeting is being recorded
Scope: mostly about TE topology yang model
Everyone should please look at draft-ietf-netmod-routing-cfg, as Adrian keeps
pointing out Tarek has been coordinating TE yang model work in MPLS, which will
transition to TEAS In general, generic stuff will be in TEAS and
dataplane-specific things will be in CCAMP L2 network topologies are in I2RS,
not TE focused yet

> - 10 min - I2RS Related Activities (Sue)
Protocol-Independent Data Models and RIB are part of I2RS' charter
Lou: question going forward: how does TE fit in? And where do things like
TE-specific OSPF stuff go? Sue: IGP chairs are in agreement that TE stuff
specifically discussed in OSPF/ISIS docs are part of the OSPF/ISIS WGs. Same
goes for BGP. Lou: Yang aspects of BGP-LS are still in BGP? Sue: yes. Some
operators have suggested a yang model. Igor: you mentioned TE-OSPF and TE-ISIS,
but what does that mean? Once information is in the TED it doesn't matter how
it got there. Do you see any difference between OSPF and ISIS? Sue (very firmly
as an individual :) there's a difference in the handling of information in the
IGP, but not once it gets to TE Igor: OK, so there's no such thing as OSPF-TE
and ISIS-TE yang models? Sue: there is a difference; if you're tracking
information in OSPF or ISIS that relates to TE then that's part of OSPF/ISIS
Lou: something like an opaque LSA would end up in the TED, but other things
might not. Zafar: TE topology is independent of OSPF or ISIS topology Sue: yes.
Abstract topologies have a link back to the TE topology Zafar: so what's the
definition of an abstract topology here? Sue: The slide reflects the current
level of discussion, which proposes an abstract topology. Alex Clemm is pushing
for a topology where the highest level is abstact, and then things build on top
of that. This is being discussed in I2RS Kam: As to the Protocol Independent,
you are talking about that for topology Independent, but it is not Management
Protocol Independent. Sue: I2RS is focusing on topologies that aren't linked to
a protocol. If topology is attached to a protocol it needs to link to that
protocol's config Kam: but next slide talks about protocol-dependent IM, so
what's up with that? The term "protocol" is overloaded Sue: yes, I'm giving you
I2RS' current definition of it. Important as I2RS is focussing on RIB and
protocol-independent stuff first Igor: should we look at topologies from user
perspective, ie who's using them and why? e.g. Which protocol was used to build
the TED is unimportant (unles there's some conflict) Sue: agree, but there's
work to be done in I2RS on this too. There's a bit of a grey line here.

Sue: <more presentation>

Zafar: slide 7: we have a draft for the network topology, is that the same as
the abstract topology? Sue: no, they're different. Things are a bit mixed up at
the moment and I think you need to have a clean definition; Clemm tends not to.
This is still in discussion. Lou: I'd expect TE stuff to be addressed by the
DT, and then we'll have to integrate with other models above this. Zafar: I'd
like to know more about how the WG can participate. Lou: we'll get to this in a
bit. Sue: I2RS will carry on examining protocol-independent modules as we need
to know if netconf/restconf will need changes.

> - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek)
Tarek: <presentation>
Design team has been meeting weekly
Multiple drafts presented in Homolulu, need coordinating so DT was formed
(draft co-authors + other intersted people) Meetings have been announced on
MPLS WG mailer, will also be on TEAS going forward Zafar: where does generic
RSVP work go? Lou: I don't think there is one but we'll need to discuss the
division of work as this stuff goes to TEAS. We should have a placeholder yang
model for RSVP that the TE-specific stuff can hang off. We also need to worry
about how GMPLS fits in and how we coordinate the generic work in TEAS and the
dataplane-specific stuff in CCAMP. Tarek: so you think GMPLS should bind into
TE? Lou: as we move to TEAS we should have a TE model that covers both MPLS-TE
and GMPLS Igor: agree. igor: new question. So there will be groupings common to
RSVP and TE? e.g ERO, node, link... so how do we reconcile these common
definitions? Can we create as many reusable libraries as we need that can be
imported wherever needed? Tarek: we plan tohave a module with all this stuff
igor: I'd rather see it in smaller chunks Tarek: OK, DT will take feedback on
board

Tarek: <presentation>
Lou: what does generic mean? RSVP-TE vs SR?
Tarek: agnostic of RSVP-TE or SR.
Lou: I understand it to also mean generic across dataplanes, not just control
planes. We'll need to be careful about terminology here.

Tarek: <presentation>
Igor: what's a path-template?
Tarek: LSP template applies to all LSPs, path-template applies to all paths
that are defined, e.g. to set all hops strict or loose or something Rakesh: so
if you want to have many LSPs take the same path you can do this. Igor: so
where does the definition go and how does it get shared? Tarek: in te-base, at
the moment. Igor: so we should define atomic libraries for little things so
that the entire model doesn't have to be imported Lou: so maybe we should have
a te-types for this

Tarek: <presentation>
Igor: so where would SRLGs go? In types?
Tarek: yes

Tarek: <presentation><end>

Zafar: dataplane should be separate.
Tarek: yes.
Lou: having discussions both on-list and in DT calls makes sense. What's the
schedule for the next few calls? Tarek: one today, then resume in January Lou:
instead of ietf-mpls-te, call it... <missed> so that te can augment the rsvp
model

> -  5 min - TE Topology YANG Model Design Team Introduction (Chairs)
Deborah <presentation>
Zafar: work requires a lot of interaction and collaboration. not good if WG
members who want to contribute aren't there. Weekly calls are good. Can we do
this for the TED design team? Deborah: this is up to the DT in the short
term... but in the longer term this will be a normal WG document, or the DT's
work could be rejected if the WG doesn't like it. Lou: bear in mind this is
also only until Dallas, and we'll poll the WG on what's been produced. There
will be plenty of time for everyone to contribute both before and after we have
a WG doc. Zafar: why can't you do wwhat the TE DT is doing? Igor: premature to
open discussion to too many people; will make no progress at all. DT was
selected to have repesentation from a variety of vendors and operators Lou: DT
members really just came from different drafts. You can work with colleagues at
your company or collaborators on draft you already have. Deborah: bear in mind
also that TEAS has only just started so we have no baseline. many folks are
interested in this and we needed to get a core group together. This is a
temproary arrangement, not a new way of doing things.

Kam: topology should be independent of management protocol in use (netconf,
etc). There will be a draft on this. Lou: it'd be good to see the doc, and then
worry about which WG to put it in.

> - Design Team Led Discussion
https://github.com/ietf-mpls-yang/te and
https://github.com/ietf-mpls-yang/te/blob/master/draft-liu-ted.yang Pavan:
<presentation> Zafar: there's also a TED model Igor: it's just a library, not a
full model Pavan: <presentation> Pavan: any questions on logistics? <silence>
Pavan: what about dependencies on network topology, etc? Igor: need to decide
whether to reuse concepts like nodes, links, etc or whether to define our own.
I think we should define our own so that we can do what we like with them. ISTR
Lou questioned this in Honolulu Lou: no. Higher-level model doens't need to
define where lower-level model comes in, but lower model needs to define where
it fits in. Igor: the problem is that a lot of the basic stuff isn't working
for the TE model. Looking at it another way: from a Chair's POV, would it be OK
to have no base model? So we don't assume where the topology comes from or how
it's used? Lou: from Chair perspective, we need to look at where we can re-use
stuff or minimize duplication... but the DT doesn't necessarily need to worry
too much about it. We can tidy this stuff up later once the various models are
more mature. However, it needs doing before we end the WG process. igor: good.
That's what we're doing. Lou: it'd be good if the doc captures open issues and
flags this as a to-do Pavan: not slowing us down yet, so if it's OK to just
flag it that's OK. Xufeng: if we want to base this onthe generic topology, we'd
need many changes from the base topology, and the base isnt' moving forward
very fast Matt: should this go to the Area yang list? Lou: syncing up models
needs doing; the question is when. igor: but we don't want to get into a
situation where models are so diverse that we cant' reconcile them. We'll need
to keep in touch with Alex, etc but we'll push on Adrian: if one lot of peope
have a dependency on another and progress isn't fast enough, contribute there
too and help them out to remove the roadblock. Xufeng: so can we take the base
topology to other WGs? Lou: no, make comments on the base docs in other WGs
Igor: if we know how to improve things, we can contribute. But if we don't know
how to change things...? Lou: so send a message to the list and talk to authors
to see what can be done. Igor: we did, and we weren't happy with the answers.
We thought we could inherit the idea of overlay/underlay, but we realized we
can't, so we defined a te-path element which is not generic Lou: sounds like
these are good things to flag in the doc. These are areas where we'll have to
work across WGs. Sue: I'd like to continue this discussion... I2RS will have
interim meetings and we'd like to keep communication going. Young: if the yang
model doesn't provide what we need in TE, could we augment/inherit to add what
we need? Can we add new semantics? Xufeng: we've been talking about augmenting
the netowrk topology model to create the TE model Young: so since yang allows
augmentation we can just go ahead? igor: want to define model so things we can
re-use are in separate libraries. I think it's a good idea to define stuff we
need and then make stuff common when we see a need to do so. Young: sounds good
Zafar: where do we send comments on specific bits of the model? Pavan: TEAS
list Lou: list is good. You're welcome to send stuff privately if you like Kam:
idea of common information model that people can pick from is a good one. we
can ensure consistency between models and divergence/inconcistency in future.
We presented a draft in Honolulu.
draft-betts-netmod-framework-data-schema-uml-00. From webex chat: "describes a
framework for how interface protocol specific data schema can be systematically
derived from an underlying common information model, focusing upon the
networking and forwarding domain.  The benefit of using such an approach in
interface specification development is to promote convergence,
interoperability, and efficiency."

Lou: almost officially out of time; I think we've achieved our main objectives.
Before we carry on, are there any high-level issues to discuss before people
start to leave? <silence>

Pavan: next thing: dependencies on MPLS-TE-specific models. We'll be
collaborating with Tarek and that DT, especially on common stuff, but there may
be other stuff that's TED-specific. Any other comments? Igor: it'd be good to
be able to carry on with the various models in parallel and independently. So
it'd be a good plan to have the common stuff defined ASAP. Tarek: agreed. Igor:
also need to have the granularity correct. And need to think about which bits
can be reused elsewhere when defining models

Pavan: Technology-specific TE-topology models. We wanted to get the
abstract/agnostic stuff done first, but how do we coordinate? Zafar: yes.
What's the timeline? Submit before next IETF? Pavan; yes Lou: how much is it
reasonable to do in that timeframe? Details are out of scope for DT. Zafar:
that's fine. We can work offline on specific questions. Lou: to be clear, DT
should not be producing technology-specific models as part of its effort (but
individuals can do what they like)

Pavan: are there any other topology models that will have a dependency on ours?
At the moment, we're OK as a lot of stuff will be in common libraries so other
models can use that. Any comments? <silence>

> - Open Discussion

Lou: anything else?
igor: meeting has been a good experience and I'd like to thank the organizers.
We can do other things in parallel :) Lou: etherpad has notes. Kudos to our new
WG secretary, Matt. Raw notes will go to list. <adjourn>