********************************************************************** IETF 99 PALS - Monday, 17 July 2017 - 17:40-18:40 Room: Congress Hall I 45/60 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 16 July 2017 22:00 Prague time) 1. 15 min - Agenda bash, WG Agenda and Status - Andy MALIS and Stewart BRYANT Andy opened the meeting at 17:45. See the Chair's Report slides. No changes to the agenda were proposed. No comments or questions. 2. 20 min - Use of Ethernet Control Word RECOMMENDED - Stewart BRYANT https://datatracker.ietf.org/doc/draft-bryant-pals-ethernet-cw Objective: Calling out potential misordering issue with sending Ethernet packets in PWs with out the control word. Stewart presented the slides uploaded to the materials pages. See the slides posted. In 2010, there have been MAC addrs with 0x4 and 0x6 assigned. It is also "legal" to use any address in local address space so could have had local addresses for quite a while. Assumption has been invalide for some time but has caused issues more recently. Some loadbalancing is looking below MPLS label stack and seeing 0x4 and 0x6 and mistakenly interpreting as IP packets and then using IP 5 tuple loadbalancing. Slide before Side Effects Dave Sinicrope: what about the existing platforms that don't support CW. Should there be stronger language to warn against the platforms that don't support CW. Ingas: 5-6 years - platform lifetime most that didn't support are long gone Stewart: do we add a statement that recommends replacement or update of legacy equipment Ignas: I recommend MUST Pat: prefer MUST - draft makes it clear that consequences of not using the CW can be severe. MAC address randomization for local address space, which is increasingly being recommended for wifi, uses whole local space. The local address space should be noted in the draft Himanshu: Likes RECOMMENDED vs MUST. We've discussed this before. A lot of legacy deployments that don't use CW. Stewart: text says that if ingress AND egress support, you must support it. Previous discussion was only on OAM Himanshu: Not really. It was discussed because MAC using 0x4 and 0x6 were messing up ECMP. OK with conditional language (if both support MUST use) Stewart: right if both support must do.. Don't invalidate existing install base although existing install base getting smaller Himanshu: less traction with L2VPN, but would still leave it as recommended. Operators are aware of this. Glenn: mandating makes a difference. IETF should be clear that protocol should be used to not invalidate a significant address space. Should also add that equipment that does not support this is not recommended. If not you should at least highlight the problems it causes. Stewart: recommend phasing out of equipment Ignas: operators are surprisingly unaware of this problem. New shiny router dropping packets. Perhaps from IETF this is understood, but tiny fraction of those experiencing it. Documenting and having a reference for a BCP would be the right way to go. Andy: this has been discussed on the NANOG email list Himanshu: This is an old problem. Can't put phase out language Dave: can soften language to recommend configuration, upgrade or enhancement Greg: Other PWs have mandatory CW if both ends support. Stewart: there may be concensus on this Andy: yes Deborah: we want our documents to be clear about problems that may be faced. Its our responsibility to inform users of problems in the specifications. Himanshu: noting the recommendation as being mandatory, is OK, but recommending phase out is not needed Glenn: On old vs. new equipement, there is no way to prohibit traffic with addresses starting with 0x4 and 0x6 from being sent to old equipment. An operator complained to the IEEE RAC that their addresses had a problem because 0x4 or 0x6 packets were dropped Himanshu: these ethernet servies have been humming for a while. Not sure routers will run into this problem given there is much more processing than just doing ECMP. Not in favor of language recommending phase out. Andy: Noted Stewart: Noted that Matthew Bocci will shepherd document. Recommended that we start the document adoption process and should be adopted by WG. Sends important message to IEEE that we are taking this seriously. Time scale is RFC Editor by Singapore. "Rush" is because the problem has become more visible. Will hand to Matthew to start the process. Dave: we should send liaisons to other organizations that use RFC4448 to notify them of the issue and ask that this be taken into consideration in their specifications Stewart: yes we will send a liaison to other SDOs 3. 10 min - YANG Data Model for PW Protocol - Fangwei HU https://tools.ietf.org/html/draft-chen-pals-pw-yang-02 Objective: Soliciting review and feedback from WG Fangwei presented slides Himanshu: almost all of this in L2VPN YANG data model. Multisegment part is not there. PW a separate container. Extend that vs. creating an new tree. Andy: there is an existing WG draft in BESS. May be better to merge your work into the work going on in BESS. Fangwei: one option. how about moving LDP PW work here Andy: but most of the work is done Himanshu: doesn't make sense Fangwei: will move MS PW modeling to that model Himanshu: I'm one of the authors of the L2VPN model, just forked out PW and most of the info is there. Most of the FR, ATM, PW can be put there, and so can the MSPW. Stewart: send text to be incorporated to the other model authors Himanshu: yes we should coordinate that. Andy adjourned the meeting at 18:27 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/99/remote-participation.html - No WebEx - IETF 99 Agenda with Audio and Jabber links: https://tools.ietf.org/agenda/99/