********************************************************************** IETF 92 PALS - Tuesday, March 24, 2015 - 9-10:30 Far East (75/90 min allocated; ** Please note the slot placement may be adjusted.) ********************************************************************** Chairs: Stewart Bryant and Andy Malis Secretary: David Sinicrope (x = slide sets NOT received as of March 24, 2015 8:30 CDT) 1. 15 min - Agenda bash, WG Agenda and Status - Andy MALIS and Stewart BRYANT Andy opened the meeting at 9am and went through the Chair's slides. No slides for RFC4447bis. Will be presented slideless. The Chairs requested that draft authors look at the charter and milestones and ensure they are accurate and realistic for the update prior to the next IETF. Congratulations to Himanshu for the IPLS RFC after 11 years. draft-ietf-pwe3-iccp-stp-03 is in IESG review. Being reviewed for English language. See slides for WG drafts in or completed WG Last Call. vccv-for-gal - went to IESG review Andy reminded the working group that any work on Yang models in the Routing Area should be coordinated through the Routing Area Yang Coordinators. See the Routing Area Yang Coordinator's Wiki area. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord Dave commented that in addition to tracking Yang drafts, there is also an area of the wiki to announce intent to create a yang model and solicit in put and contributors from the community. The Chairs encouraged everyone to take a look at the wiki and make good use of it. x2. 10 min - Pseudowire Setup and Maintenance using the Label Distribution Protocol - Luca MARTINI http://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis Objective: Agree whether draft is ready for Working Group Last Call. Slideless presentation Luca presented RFC 4447bis. Luca took all erratas over last 15 years and included in document. It's stuff that has been around for a while and wanted to get it in the document and get a last look at it. References were left as is, NOT updated to references that came out after the document. The order of FEC 129 TLVs. One implementation that sends in order in the picture and another that sends in random order. The doc doesn't say they need to be in any order. No need to say you can send in any order, because implied. The "fixed" and "next release" errata were all considered in the update. Did all the "held for next revision". Did you go through all the updated bys on RFC 4447? No not yet. We can do a reference. Not keen to put in the text because text will change too much. Document is well established and ready for proposed STD. The documents are not at the same status. But we need to go through all the updated by, because this line will not be in the new RFC and the assumption is that the new document will include all of these RFCs. Stewart and Luca will look at the updates offline and figure out how to proceed. The path forward must address updates, but not cause document to linger. Eric Gray: Regarding the order of TLVs. Even if it doesn't say there is order and this implies it can go in any order, but if it is shown in a particular order then the implication is that it should be in that order. Luca: The figure has an order, (it must), but it is clear the order is not dictated. We could add clarifying text. Eric: this would be helpful. The implication is that if the TLVs MAY appear in any order, the receiver MUST accept in any order. 3. 10 min - MAC withdraw signaling for Static PW over MPLS-TP - Himanshu SHAH http://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd Objective: The objective of the presentation is to go over the brief history and latest updates that addresses the comments received so far, solicit more comments, and request for last call. Loa: - speakers must stay in the box on the floor. (for the video camera) Himanshu presented the uploaded slides. Sharam: eVPN also has MAC withdraw? Himanshu: no this is for static based on LDP within an inband OAM channel Sharam: how does the PE2 know there is a failure on the other link Himanshu: there is the status signaling, but PE2 doesn't need to know. PE2 just forwards it. Sharam: should call something other than OAM. HImanshu: PW Status is also called OAM Andy: if there is strong objection there should be comment on the list. Himanshu: many idea here is don't keep sending traffic to the old one. Take the old one down and let it broadcast and relearn Andy: Chairs agree this is ready for WG Last Call 4. 10 min - Seamless-BFD for VCCV - Stewart BRYANT for Carlos PIGNATARO http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-for-gal Objective: -00 version of SBFD for VCCV, get initial feedback from WG of future course Stewart presented for Carlos Need to discuss the capabilities - need to discuss the order of preference. The question from the authors, can they be independent, no order of preference. There is concern there, need to ensure two systems have expected behavior. Greg Mirsky: compare SBFD to ICMP and LSP Ping. More like ICMP Ping than LSP Ping. Stewart: Two PW PEs need common agreement to run 1. just BFD, 2. BFD and SBFD or 3. just SBFD Andy: personal druthers that we as a WG choose a default. No opinion as to which, but would like to see a default so if folks naively bring up systems it will just work Stewart: I agree Greg: In the case of ACH encap, there is no IP address to return to. How will a reflector know where to return to. There is no state. Stewart: there is PW state so you always know who your peer is. If you get something of the SBFD type, you take action and send it on the reverse PW (PW is always Bi Dir) Not sure what happens when you have a p2mp PW. no return channel there. Need to figure that one out. Andy: probably an IP return channel, but not sure, e.g., case of MPLS-TP Stewart: please put comments on the list and we can discuss. The authors will ask for WG adoption Robin: earlier said will not case LDP based l2vpn why not. Stewart: They are not considered for this revision, but will most likely be addressed in future revisions. Need to pick a default for negotiation. Sharam: clarification - this runs over L2TP control or data, this runs over data right? Stewart: signaling runs over control plane, and there is a bit in L2TP header saying this is OAM Yuanlong: is this purpose to replace BFD? Stewart: no, BFD exists anyway and don't see deprecating. This is to enhance BFD when you want to introduce scaling that can't be achieved with BFD. Yanlong: This could also be used for MPLS PW, now have two options. which should we use? Stewart: depends on what you want to achieve. The draft should discuss applicability of the options. (in particular when you want to run both) 5. 10 min - Yang Model for L2VPN - Zhenbin LI http://datatracker.ietf.org/doc/draft-zhuang-pals-l2vpn-yang Objective: -00 version, we have coordinated several L2VPN experts to try to set up the design team for the L2VPN Yang model. We will meet at Dallas to discuss the possible work plan. We hope to present it and get the guidance from the WG and co-chairs. Zhenbin (Robin) presented the slides There will be a work plan created after the architecture design. They will update the Yang Coordination Wiki as they progress the work. The wiki can be found https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoordSummary Nick: should produce Yang models for RFCs we write Greg: no problem having containers for implementation details Andy: History - back in 90s... FR and ATM MIBs. In each MIB there was a vendor neutral cross connect table. WITHDRAWN x6. 10 min - Definition of P2MP PW TLV for LSP-Ping Mechanisms - TBD http://datatracker.ietf.org/doc/draft-jain-pals-p2mp-pw-lsp-ping Objective: -00 version, get initial feedback from WG of future course 7. 10 min - Provisioning, Auto-Discovery, and Signaling in L2VPNs for IPv6 Remote PE - Mohamed BOUCADAIR http://datatracker.ietf.org/doc/draft-abhattacharya-bess-l2vpn-ipv6-remotepe Objective: Need to present the concept and receive feedback and direction from WG members and chairs Mohamed presented the slides uploaded. No comments. Andy closed the meeting at 10:19am local time ********************************************************************** Overflow (Will be presented if time permits.) ********************************************************************** xx. - None currently ********************************************************************** REMOTE INFORMATION FOR THE PALS SESSION(S) ********************************************************************** Remote Participation Info: http://www.ietf.org/meeting/92/remote-participation.html - No WebEx - Audio Stream for Far East: Channel 2 http://ietf92streaming.dnsalias.net/ietf/ietf922.m3u - Agenda with Audio and Jabber links: http://tools.ietf.org/agenda/92/