Minutes IETF99: pals
minutes-99-pals-01

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