********************************************************************** IETF 103 PALS - Monday, 5 November 2018 - 11:20-12:20 Room: Boromphimarn 1/2 35/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 1 November 2018 3:00 Bangkok time) 1. 15 min - Agenda bash, WG Agenda and Status - Andy MALIS and Stewart BRYANT Andy presented the status update and chair's slides. It was noted that draft-ietf-pals-ethernet-cw is in the RFC Editor's queue. This draft makes the CW for Ethernet PWs strongly recommended. All other work is completed. 2. 20 min - Pseudowire (PW) Control Word (CW) Stitching - Italo BUSI https://datatracker.ietf.org/doc/draft-busi-pals-pw-cw-stitching/ Objective: Gather interest from the WG to work on this solution. Note: Dave chaired the session on the draft given that the draft authors include all the PALS chairs. Italo presented the draft. The draft proposes a new type of S-PE that can take PW segments without a CW and switch them to a PW segment with a CW. This handles cases where upgrading the existing T-PE is not possible or desired. It was stressed that T-PE1 need not be upgraded or touched to use this method. Matthew: are you doing a label swap and adding a CW added? Italo: Yes Matthew: The architecture doesn't allow it. You are really stitching the two PWs together, after having gone to the Ethernet frame and then pushing the label stack with the CW. This is in the architecture. Change the draft to point to that. Stewart: OK Himanshu: So this isn't a switching PE, its a tear down and rebuild of the stack? Stewart: Yes, with end to end OAM. Himanshu: But everything terminates. It's not native, and not end to end if it terminates. Matthew: Could do the OAM at the Ethernet level, but not VCCV Stewart: OK there is some work to be done. We should continue and see if this is a useful function. If so then we can rework within architecture. Dave: Continue with presentation but focus on the problem and if it is a useful function. We will consider the solution if folks agree it is a useful function. - Focus is on existing deployments and protecting them from the ECMP issue. - It was noted in several slides that a requirement is to keep PW changes transparent to T-PEs so no change to T-PEs. - See the current assumptions on the Next Steps slide to validate them Slides ask for WG adoption, but the draft is clearly not ready for WG adoption. Matthew: It says in the draft that this works with dynamic MSPWs. Those are auto-discovered through BGP so this would need to be added to the BGP for the discovery or it won't work with dynamic MSPWs. Stewart: Do we need to do this? Is this a useful problem to solve? Matthew: Don' t know how many TPEs don't have the hardware support for the CW. Coupled with being able to just hash on the label stack, not sure this solution is needed. Himanshu: Could also use FAT PW for ECMP. Andy: some networks are running without the CW and there is bad ECMP hashing. Problem exists and implementations running without control word. Matthew: In those cases where bad hasing is, is it only because TPEs don't support CW or does the whole network not support the CW? Andy: mostly whole network doesn't. Eric: Do they have the capability but don't turn it on? Stewart: In previous draft it was noted that there is equipment that doesn't have support. Himanshu: For the proposed solution, it needs a chip that can do line rate PW label swapping. Does this exist? Stewart: we have a chip that can do it. Himanshu: yes, but is there merchant silicon? (doubtful) Matthew: This solution requires a significant redsign of the network to make this solution work. All tunnels would need to begin/end at an "SPE" (node stitching the PWs). Only hub and spoke topologies have a lot of PW switching. Andy: TPE1 is a cheap PE that didn't support the CW. Dave: more analysis needs to be done on: 1. the use cases where this function would be used e.g., mobile transport? Ethernet enterprise services? data center interconnect? etc. 2. In these cases identified, how likely would it be where the TPE would not be upgraded? Himanshu: in the devices we use for backhaul, they are using MPLS-TP with VCCV type 4. No ECMP in those networks and it always has the control word. i.e., this solution is not needed. Stewart: Is the situation likely to resolve itself due to an LTE or 5G upgrade? or will the equipment persist and we need to solve the issue? Matthew: how much ECMP do you get in the cell site mobile networks? and if you do the hashing is the situation such that the problem is controlled? Dave: In the architectures seen (e.g., BBF), the cell site routers are not mulithomed, because other cell sites pick up traffic. For larger cell sites that are multihomed, they are not ECMP, and it would be a case where it would be cheaper to upgrade the TPE than put in two stitching capable SPEs. Dave: The authors need to do analysis on requirements and whether other solutions exist within the architecture and function we have or if this new function is needed. Stewart: The authors are encouraged to summarize the discussion here, the use cases they see this solution be used in and propose the alternative ways to resolve the issues raised. ----------- Andy: Having a separate PALS session vs put into MPLS was useful for discussion on the draft. Depending on list discussion we will decide on whether to continue to schedule PALS sessions or request time on the MPLS WG agenda. The meeting was adjourned 12:03pm local time. ********************************************************************** Overflow (Will be presented if time permits.) ********************************************************************** xx. - None currently ********************************************************************** REMOTE INFORMATION FOR THE PALS SESSION(S) ********************************************************************** - IETF 101 Agenda with Audio and Jabber links: https://datatracker.ietf.org/meeting/103/agenda.html