Minutes IETF103: pals
minutes-103-pals-00

**********************************************************************
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