Here are the raw notes from today's session. Please review and correct (at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-teas). Just a reminder the notes should only cover what was actually said at mics in the session, and these are input to the final minutes. Recordings of the session are also available.
Thanks to Matt and all others who contributed to the notes and the successful meeting! Lou (+ cast of many co-chairs) > > > TEAS/MPLS/PCE Yang Agenda For IETF 95 > Version: Mar 31, 2016 > > Tuesday, April 5th, 2016 > 17:30 - 19:10 - 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... <note-taker missed a bit> 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? <they seem to agree> 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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
