Note: preliminary minutes, let us know if you have comments/corrections. Final minutes will be extracted from audio recording and uploaded soon. MPLS WG - Session I: Chair: Loa + Andy Mallis (help) Chair update: Loa NOTE WLLL and update. Agenda Bashing + Blue sheets WG Status NOTE-WELL Daniel King: He gave a short update on his draft: ??? Icmp-bier draftr: should we move it to BIER ? IPR’s in future polls: How to discuss IPR discussions on list ? IPR disclosure to IESG with simple state chandra: RSVP refresh-interval In MPLS RT review ryoo: MPLS TP … RFC 7271 4-5 ppl read the draft; Loa asked to ask/seek comment on mailing list. santosh: app-aware-tldp Loa: Make it active on alias Andy: Overlap with PALS – send an email to PALS WG , intro to the draft and seek comments. Several ppl have read the draft, and support WG LC. Loa: Too many authors on the 1st page … Max 6 ppl please. santosh: Node Prot for LDP LSPs Loa comments: Requirements are very generic. Will like to look and might ask for rewrite the req section of the doc. Jeff Tantsura: Ericsson: Like to see real reason for doing something else than LFA (proven). Possibly Some data on LFA SPF vs LDP. Present in rtgwg Autumn (??? L2VPN YANG llady) Ericsson: Why node protection with two protocols involved ? (IGP is always there)? Chris Bowers (JNPR): RSVP/TE Tunnel scalability when used e2e (100 of 100s of transit LSPs)… Using RSVP/TE *only* for protection is not an issue. Robin (Huawei): LFA does not provide all the coverage Loa: slide mentioned: mLDP protection for free ? Does current draft has this info. Clarify in the document. Jeff: Read mLDP Node Protection. Also get feedback from SPs Good # of ppl read the draft; Lesser # of ppl for WG adoption. tarek: LSP instant install Shahram Davari: It is not a good idea. With number of hops increase, the stack depth increases and . Chandra (JNPR): Is the primary motive is due to scale of LSPs on transit LSRs ? Tarek: Not really. It is due to race b/w fwding programming and signaling upstream. Eliminating current “wait” time will eliminate this issue. >>> Loa: Move this discussion on mailign list. Kireeti (JNPR): Overall idea is good but need to see how many distraction occur on traffic and how to deal with it? Chris Bowers (JNPR): It will be helpful to post the slides on the material section of the MPLS WG for overall discussion. Ina (GOOG): Couple of concerns with deployability of this solution (on ingress – num of labels) + how to account for LSP ? Tarek: Is it more ingress or transit side concern ? Loa: Take it to the mailing list. deborah: Loa: Requirements when we we update/change the status of an RFC ? RFC 6410: Proposed and Internet Standard levels What is an “IS” and How much can revise from the original RFC. RFC 5036 can be moved from PS to IS. PALS need it for RFC 4447. Carlos P. / Cisco: One goal is to cleanup the doc + other is to move it in standardization. Adrian: Why do we need to spend cycles on this ? Chris Bowers (JNPR): Selectively moving some items from PS to IS might confused ppl for the documents which remain as PS. Loa/Deborah: This is not WG choice but pushed by. carlos: rfc 4379bis carlos: Two Qs for WG/chairs: Is it useful work ? What needs to be brought in ? loa: in view of deborah’s preso on PS->IS, … Carlos: this is a WG RFC and we need to take it to WG ASAP. Loa: Will initiate. Kireeti: RMR Eric Gray (Ericsson): re: U-shaped rings: we need to know more about the use, cost etc – before we go and update the draft. Luyan: MS: It is a good concept. Need to look for beyond shortest path. Kireeti: LARP No slides Andy Mallis: HUWEI: Q1: There must be some high use case for overloading ARP. Kireeti: ARP is not an ehternet protocol.. Can be used for other hardware/atm etc. There is H/W field that is going to be updated for LARP. Q2: Security section is weak. Kireetai: ARP security is already low… there are security issues that we are inheriting… Luyan: forwarding-no-swap: Eric Gray : Ericsson: Not all the Q on the mailing list have been answered. Kireeti: It is not a matter of English but technical. Adding another operation is not a good idea. There are other things in the MPLS header besides label .. TTL etc… These bits need processing. Fabio Chiussi: Stabdard need to change to support most efficient impl (no-swap). Xia Chen : Huawei: It is important to clarify label operations in view of SR standardization. Robin Huawei: We propose domain wide labels; Shahram: Broadcomm: Support this draft from chip implementation. Luyan: SDN Loa: Is it a good doc or interest for industry. Make it Informational ? Should this be not an MPLS WG doc ? Robin : Huawei: Robin: Global label use case Loa: Out of time – take on the list. MPLS WG - Session II: Introduction/Purpose Combined MPLS / TEAS session – YANG models NOTE WELL Kamran Raza: mpls-static-yang Tarek: do we split into separate drafts? Loa: can you consider splitting into two different drafts Robin: in RTGWG network instance yang model, how do you sync up with them? Robin: MPLS-TP? Kamran: We think it deserves its own model and we’re planning to tackle it next Lou: where does mpls-te sits? I expect MPLS-TP to be instant of MPLS-TE? Tarek: we defined ietf-rsvp-te model Lou: If TE protocol have dependencies on mpls-base, MPLS chairs should consider having mpls-base in its own doc and be progressed faster. Kamran Raza: mpls-ldp-mldp-yang Himanshu: question on MPLS-Static? TP is subset of TE.. Lou: will be addressed in the next presentation Kamran: The draft Author request adoption. Loa: Being a co-author, will need to defer this for other chairs to consider. Tarek Saad: rsvp yang, te yang Re-preso of RSVP/TE YANG (from earlier TEAS session) Acee: There is another option for RSVP/TE intf: augment intf (RFC 7277); Xufeng: Option 1 is not available any more. Lou: With reference to control plane channel, How a dataplane enabled intf that is controlled by RSVP would work ? Ina: Operational feedback is to explicitly enable MPLS and not implicitly enabled when control plane is enabled. Lou: Relationship of different switching type is not shown on this slide 9. There are TE LSP which are not RSVP signaled. Some discussion on whether MPLS TP be augment under TE, or be a sibling of mpls-static (slide 9). Robin: Agree with Lou ’s comments. Himanshu: static lsp should be under te? Lou: Static LSP has mostly, if not only, LDP LSPs so why make static under TE ? Loa: Take it to the list. Xufeng Liu: te topo yang Re-preso (from earlier TEAS session) No Qs.