* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Pals Status Pages

Pseudowire And LDP-enabled Services (Active WG)
Rtg Area: Alia Atlas, Alvaro Retana, Deborah Brungard | 2014-Oct-31 —  

IETF-100 pals minutes

Session 2017-11-13 1740-1840: Orchard - Audio stream - pals chatroom


minutes-100-pals-00 minutes

          IETF 100 PALS - Monday, 13 November 2017 - 17:40-18:40 Room: Orchard
          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 12 November 2017 17:00 Singapore time)
          1. 15 min - Agenda bash, WG Agenda and Status - Andy MALIS and Stewart
          Andy went through the posted slides.
          It was noted in slide 5 the MD5 no longer meets security
          requirements. There
          will be work in the MPLS WG on a new security mechanism.
          It was noted this is not just an LDP problem but a problem for all TCP
          protocols. 1. there is no default mechanism and 2. no negotiation
          The Rtg Area should work with Transport and Security Areas to resolve.
          2. 20 min - Use of Ethernet Control Word RECOMMENDED - Stewart BRYANT
          Objective: Calling out potential misordering issue with sending Ethernet
          packets in PWs with out the control word.
          Stewart went through the posted slides.
          Himanshu: - what are they doing wrong?
          Stewart: some vendors have a switch that causes the router to look down
          packet and if it sees a 00 the implementation skips x bytes down the
          header then
          does a 5-tuple has for load balancing.  (it assumes that the pseudowire
          type is
          Some operators have turned on these on either by not understanding or by
          evolution of the network that then causes problems.  They have asked
          that we
          publish recommendations on how to address the problem.
          Ignas: had 44 different discussions with operators and only 2 operators
          aware of the problem.  Need to raise awareness of the issue.
          The group will do live editing of the two recommendations in the draft.
          Section 4 and Section 7.
          (Note: the text resulting from the meeting will be posted in a
          revision of the draft.)
          Loa: the recommendations talk about quite a bit of work to be done in
          the MPLS
          WG.  Can you give the MPLS WG a heads up?
          Stewart: yes, how much is needed
          Loa: need to make sure that people understand what problem we are solving
          Stewart: OK will talk offline about the details
          Himanshu: Regarding section 7: This doesn't look right. LSRs are doing
          ECMP but LSRs can't recognize the FAT PW.
          Stewart: The operator would need to understand and discuss how to resolve
          Himanshu: but the proposed paragraph does not look correct.   How does
          the P
          router decide whether to enable or disable and whether to enable ECMP.
          Greg Mirsky: THe paragraph is basically saying dont do it by default
          and if you
          do, then think about it before you do it.
          Stewart: If you need to do ECMP, then try to use other techniques. If
          you can't
          do the other techniques, then analyse the situation.
          Adrian: Is the intention only to talk about ECMP only at egress PEs?
          Stewart: no, the problem is broader.  Some carriers wanted control word
          number checking.
          Adrian: is this intended to work on P routers doing ECMP?
          Stewart: yes
          Adrian: Prouters do ECMP in a wide variety of ways and is it better to
          the desired behavior rather than make recommendations
          Stewart: trying to give guidance
          John Drake: The text does not mention P routers and is not enforceable.
          *** Andy displayed text for the group to edit the proposed text.
          Andy recorded
          the changes.  The result will be posted in the next revision of the draft.
          result will be further vetted on the PALS list. ***
          Section 4 and Section 7 on use of the CW was accepted as proposed by
          the room.
          Section 4 and Section 7 text on use of ECMP was discussed.
          Adrian: concerned the solution is too prescriptive.  A solution should
          what should happen in the network and let implementors implement
          Himanshu: To identify a micro flow in a PW one can use the FAT or ELI,
          make the context clear.
          Stewart: context is clear, Ethernet PW.
          Himanshu: but needs to be clearer and let the implementor decide.
          Matthew:  It could be clearer that the ELI and FAT are to identify
          Italo: do these recommendations work for MS PW?
          Stewart: yes could use FAT for the PW
          Greg: If ELI is above the PW, it could be used for the next segment.
          It is up
          to the implementation.
          Matthew: an SPE would not pass an ELI/EL across.
          Stewart: can't assume the EL stays.  FAT is the safer way since it is
          below the
          PW label.
          Loa: if you are looking though label stack for the ELI do you know if
          you are
          above or below the FAT label?  You don't know.
          Stewart: the FAT label is the Bottom of Stack and immediately follows
          the PW
          Italo: don't recommend one or the other, just note that one should be
          Matthew: not making assumptions about hash on EL.  Just need to say that
          ELI is used then ELI should be used on every segment.
          Onto section 7
          Matthew: not sure this should be in the draft, this is talking about P
          so should be in the draft in the MPLS WG.
          Andrw Dolcanow: agree with Matthew
          Stewart: Where the DPI problem came up is in the context of PWs.
          Andrew: why are we only talking about DPI, there could be other hashing
          loadbalancing that this impacts.
          Stewart: someone on the list noted that we need to do more than what
          the draft
          says, e.g., should use sequence numbers
          Matthew: if there is load balancing going on in the network how do we
          design PW
          so that they can handle it?  Can't say how to design LSRs
          Stewart: but the problem is with PWs, should we not warn operators?
          Matthew: no, but should be more general.
          Andy: But the feature assumes an Eth PW
          Matthew: But the issue occurs on P routers and is outside of PWs.
          Stewart: we should at least say this is an interesting feature but should
          accessed before use.
          Himanshu: take to MPLS group since largely in scope of LSRs not PW.
          MPLS WG
          should say what the right behavior is at the LSR.
          Loa: so operational considerations section, no problem with PALS
          describing a
          behavior related to PWs. However, the solution should possibly be in
          one of the
          MPLS drafts.  Need more description brought to MPLS WG.
          Andrew:  saying that the CW and getting into the DPI, is naive.
          Should simply
          say that using DPI should be considered carefully before deployed.
          Stewart: what to do from here.
          Andy: the proposed text for section 7 should be replaced by text that
          the problem.
          In section 4, should it be capital MUST/SHOULD or must/should
          Dave: given it is deployment guidance and not implementation requirement
          should be lower case.
          John: If the PEs are seeing misordered packets, then only choice is to
          seq numbers
          Stewart: Not get SP to turn off DPI based loadbalancing?
          Himanshu: but not likely to get them to do it, so sequence numbers are
          Stewart: will update the text and post to the list for comments.
          3. (added during agenda bash)
          Liaison telling liaison partners about the changes in the control word
          - Broadband Forum (for action)
          - ITU-T SG15 WP3 (for action)
          - IEEE 802.1, RAC (for information and review)
          - MEF (for action)
          o briefly state the issue
          o point to the recommendation and clarification  (i.e., the draft)
          o ask that the new draft/RFC be considered and taken into account in
          and future works.
          Andy closed the meeting at 19:01pm
          Overflow (Will be presented if time permits.)
          xx. - None currently
          Remote Participation Info:
          - No WebEx
          - IETF 100 Agenda with Audio and Jabber links:

Generated from PyHt script /wg/pals/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -