Welcome to Etherpad! This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents! Get involved with Etherpad at http://etherpad.org Tuesday, March 28, 2017 (CDT) - 9:00-11:30 - Morning session I Meeting minutes: ================================================================================ Deborah: special occasion that this is the 2oth IETF for George 1- George presented WG update 2- Kireeti presents draft-ietf-mpls-rmr George: when LSP does not start/end on same node, there are some cases that will cause false failure detections George: other folks will present the companion docs 3- Abhishek presents draft-deshmukh-mpls-rsvp-rmr-extension: Greg Mirsky: collecting SENDER_TEMPLATES in 1 path message there is issue with fragmantation If using multiple PATH messages, how do you identify individual PATH message? Kireet: rely on multiple path messages or on IPv4 fragmantation Tarek: it is not clear how is MBB-ID used? is it synonymous with RING-ID? Abhishek: MBB-ID is used to create new Tunnel for same ring George: concerns with MBB-ID in the SESSION obj, did you consider adding it in a new SENDER_TEMPLATE? 4- Abhishek presents draft-esale-ldp-rmr-extensions George: why do we need to extend protocols - why need to extend for both protocols Kireeti: for LDP, need extensions.. some ppl comfortable with RSVP and some for LDP George: there was an attempt to extend LDP for creating tunnels Eric Osborne: I see ppl may want this for RSVP and LDP - so extending is easier 5- Harish presents draft-sitaraman-mpls-rsvp-shared-labels Greg Mirsky: why introduce new construct and not re-use existing segments Harish: this is not stitching.. Pavan: stitching needs control-logic to exist at all stitching points, multiple touch-points are needed; with the proposal in the draft only the head-end comes into play. Kireeti: in control plane, this is 1 LSP and in dataplane, there are more Geoerge: well written 1st version and support the work 6- Kireeti presents draft-esale-mpls-ldp-node-frr 7- Stewart presents draft-xu-mpls-unified-source-routing-instruction Ron Bonica: elegant since we can replace 128-bits with the 32-bit MPLS labels George: .. Kireeti: this could be used as an interim solution (until SRv6 is delivered) one difference is SRv6 maintains the SRH stack to the end MPLS loses the MPLS stack Ahmed Bashandy: iPhone does not run MPLS.. Stewart: MPLS as a network programming language Adrian: your phone does not run SR too? they might run IPv6 Ron Bonica: no need to argue SRv6 vs. proposal... there is some acceptance Stewart: the draft will be updated to be more easily readable 8- Kamran presents draft-ietf-mpls-ldp-yang Qs: George: expert reviwer took a long time, but email was missed . Debora promised to review and document will move along. 9- Yimin presents: will take this to the list JOINT CCAMP/PCE/TEAS/MPLS session (MPLS sponsored): Friday, March 31, 2017 (CDT) - 9:00-11:30 - Morning session I - Minutes: ======================================================================== Alia presents "Recommendation for YANG models in the Routing Area" Tarek: Many of us have implemented the openconfig approach with separate config and state containers. Should we get rid of the config containers? Alia: It is essentially up to you. This is our guideline not a hard rule. Dhruv: If we are on the old train, must we republish in a year again? Alia: You could augment the normal tree. Not ideal. Netmod are talking about revving the routing config model but this gives us a path forward in parallel. Dhruv: So do we have to publish again once revised data store happens? Alia: Yes I believe that we will want to republish, which is unfortunate. It is more important to get models done. If too many models on old traoion then it is highly unfortunate operationally. George: We owe the community guidelines to the likely outcomes. If work may get cancelled then it demotivates them. Alia: This is a decision from netmod this week. Must give out correct guidance. Lou: objective is to minimize disruption on the models Alia: not a "must/should" but what makes sense Dhruv: what happens if the model is published? Lou: we're trying in netmod to come with guidance to minimize pain now/future (trying to find sweetspot). What happens in RA is ..? ALia: my focus is to keep the hard work been done from being "not conformant".. I can set guidance on what happens in Routing area.. George: timing is of concern. Amy Ye presents draft-mwdt-ccamp-mw-yang: No comments. Italo Busi presents draft-busibel-teas-yang-path-computation: Tarek: Some constraints are mandatory or optional. How do you do an unconstrained LSP? Constraints cannot be mandatory. Italo: By "mandatory" we mean constraints must be fulfilled by path computation reply - not that that constraint must be present in all queries. Daniele: By mandatory you mean "not relaxable" Dhruv: stateful vs. stateless, for PCEP YANG should we allow stateless queries too? We should align these two YANG models. Jon: from PCE-WG POV, we have had no discussion on stateless - raise this initially in TEAS. If TEAS wishes to adopt that model then yes, we should make the PCEP model consistent. George: In which WG should this discussion happen? Pavan: Start with TEAS. Xufeng presents draft-ietf-mpls-ldp-mldp-yang Xufeng presents next drafts No comments. Tarek presents draft-ietf-teas-yang-te Moving on to draft-ietf-teas-yang-rsvp / draft-ietf-teas-yang-rsvp-te Moving on to draft-ietf-mpls-base-yang Daniel K. presents draft-vergara-ccamp-flexigrid-yang Daniel K. presents draft-ietf-ccamp-wson-yang Gert: there is a transponder (not audible) - LOS, not necessary to have transponders in the model. No transponder defintion to use.. It might be easier to progress the document Dhruv: presents draft-ietf-pce-pcep-yang Dhruv: Need guidance on using traditional yang notifications vs subscribe/push notifications. Julien: Discuss it with YANG doctors Tarek: In RSVP/TE Yang Models, we chose to use subscribe/push notifications; would be good to get some guidance on this. Gert presents draft-dharini-ccamp-dwdm-if-param-yang No comments Danielle: presneted 2 options (need to capture..) Italo: is ok with either option Kun presents draft-zhang-ccamp-l1-topo-yang and draft-sharma-ccamp-otn-tunnel-model Daniel: had discussion with topology design team and may go with option 2 Daniele: What is the relation with transpport tunnel and ACTN interfaces tansport tunnel extends the TE tunnel work Lou Berger: analysis is assuming certain way of implementing ACTN - we are going ahead Italo: we can discuss in design team, analysis can use this document too.