Subject: PWE3 WG Meeting IETF-57, Wed 16th July 2003 - minutes

From: Stewart Bryant <[email-masked]>
Date: Wed, 06 Aug 2003 11:38:43 +0100

PWE3 WG Meeting IETF-57, Wed 16th July 2003
===========================================

Chairs: Stewart Bryant and Danny McPherson
Minutes take by: Matthew Bocci

"Danny McPherson" <[email-masked]>
WG Document Status
------------------

There has been good progress on Requirements and Architecture drafts.
Intend to send both to IESG next week. After this, most services
stuff can proceed. The intention is to wrap up a lot of the stuff
in 3 or 4 months.

There are some issues with Frame Relay which will hold it up a bit.
Authors should clean up docs to deal with ID nits before progressing them.

"Thomas Narten" <[email-masked]>
PWE3 move to Internet Area
--------------------------

Thomas is Internet Area co-AD. There is a plan to transition PWE3 to the
Internet Area. PPVPN has been split into L2 and L3 VPN. We should bring PWE3
into the same area (L2TPv3 extensions is here too).
Reason: It is arguable which area, but this is all related to tunneling.
Transport originally took it because of congestion control issues.

Transition will occur when architecture and requirements are done.

"Thomas Nadeau" [email-masked]
http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-01.txt
-----------------------------------------------------------------

Rahul Aggarwal Juniper Juniper, presented VCCV update.

This stands for Virtual Circuit Connection Verification.

Capabilities: Inband MPLS VCCV, Router alert label.
Changes in v1:
Inband MPLS VCCV: Message indicated in data flow by using first nibble of
PW control header: 0001
LS 16 bits specify protocol no.
Router alert used to indicate an OAM flow
Changes for L2TPv3: VCCV verifies session forwarding state at egress PE.
Encodes LSP ping header.
Message types are listed.
2 Reply modes:
Contains L2 circuit ID
OAM capability must be signaled before a PE may send OAM messages.
The presenter lists the cases for MPLS, L2TPv3 as PSN. VCCV control channel
indicated by receiving PE.
Should L2 circuit ID be in LSP PING spec, OAM capability advertisement:
where should this be defined?

The presenter request that this be made a WG document

Sasha Vainshtein: What should happen with PWs that by default do not use
CW?
Rahul Aggarwal: still possible to use router alert label. If you want

Luca Martini: supports this, but more belongs here. Might belong somewhere
else.
Rahul Aggarwal: why? Several issues related to PWs. Capability advertisement,
open to what WG wants.
Luca: Could limit it in this draft
George Swallow: If you think your objects belong in MPLS, send them over MPLS
Mustapha Aissaoui (Alcatel): What about MPLS payload ID?
George Swallow: We define IP control channel associated with PWE3 circuit.
and put IP in code point.
Mustapha Aissaoui: OK, but we are using MPLS PID in Arch document, not CW.
Must get terminology right. It is PW PID, not control word.
Rahul Aggarwal: OK, get the same picture.

Rough consensus was tested and there was majority support to accept
the document as a WG draft. This support to be further tested by
asking the list.

  "Mustapha Aissaoui" <[email-masked]>
  http://www.ietf.org/internet-drafts/draft-aissaoui-extended-pid-00.txt
-----------------------------------------------------------------------

Presenter describes MPLS PID in architecture doc.
Allows multiple user plane protocols in same PW.
PW PID can be used for control plane to
ID control channel.
Allows different control planes, (LSP PING, Y.1711, etc).
Also resolves OAM packets sharing path of user packets in case of ECMP.
Allows interworking of different link layers over MPLS network.
This is not an alternative to current paradigm. Does not require PID.
Shows example application.  GigE link through MPLS to FR VC
Could extend FR to remote PE across MPLS.

Issues: remote PE would have to understand FR over MPLS
Could terminate FR VC on PE, and create multiple PWs, one for each payload
type.
3rd option, to do PID translation between FR, PW, and Ethernet. This is
addressed here.

Most straightforward option is to use PW PID.
But, Used value of 0001 for first nibble, and removed alert bit.

Relationship between CW and PID: precedes PW CW in architecture

Proposal is to reverse this to use the control word to consistently solve
IP aliasing issue.
No major other issues.
Would like to keep current order of PID and CW as in architecture draft.
Would like to progress this in PWE3.

Yakov Stein: Understand, and it is a good idea, but looks like service
interworking. Trying to not use this word.

Mustapha Aissaoui: Had thought about this issue. Key point is that we have
an issue to solve. I believe this is part of PWE3 because it allows
migration of existing installed base.

Luca Martini: why do you need PW ID, when you could use a simple label?
Mustapha Aissaoui: that is the second option above. You must assign a label
for each protocol type. Issue is that for each FR VC, you must have
multiple PWs

Luca Martini: must still do the lookup for forwarding. This makes hardware
complex.
Mustapha Aissaoui: translating PID is straightforward. You do this if you
support FR over ATM.

George Swallow: It's not the right hand side that does translation. Don't
want to force other side to know what protocol is. Luca's point is that you
can do this from label context.
Mustapha Aisasoui: not sufficient

Danny McPherson: take to mailing list as this is a new charter item.
Ali Sajassi: not as simple as a PW ID. There is a dependency of L3 over L2
medium. Need to be careful. My draft suggests IP PW and then all non IP to
used bridged encap. Need to look at bigger picture.
Sasha Vainshtein: draft-sharc-arp-mediation describes a solution

"Dave Allan" <[email-masked]>
http://www.ietf.org/internet-drafts/draft-allan-mpls-a-bit-00.txt
-----------------------------------------------------------------

This was presented in MPLS yesterday. It has implications for PWE3 and
MPLS. MPLS aspects will be discussed on list. Recast today to illustrate
thought process that lead to solution, and make clear why we got here.

Motivation: MPLS reserve label functions don't fate share with associated
LSPs/PWs in presence of ECMP. Directions in proactive network supervision
complicate fault detection. Faults can be simultaneously detected by
multiple uncoordinated means. Fault correlation is an issue. Need to
increase locality of detection. One way is for probes to examine OAM flows.
MPLS router alert has limitations. Use of label stacking for demarcation
has limitations: useful for security reasons, push testing as close to
CE as possible, ability to do OAM on a portion of an LSP.
In Dave's opinion, there is a progressive divergence of PWs and LSPs.
Driving commonality has utility. Multi-hop or spliced LSPs may require more
commonality. PID perceived as a point of commonality between PWs and MPLS.
Allows control and OAM flows to be muxed with PWs/LSPs.

A bit proposal is about migrating reserved label functions to PID. Diagram
shows the position of the A-bit.
This is a Data Plane change: issues with b/w compatibility. E.g. what if
payload aliases with an RA.
In summary: ECMP breaks reserve labels. Reserved labels do not exists for
PWs. PID+A

George Swallow: no problem with ECMP. Should not use ECMP if you need
ordering. That's what you get.

Dave Allan: What about problem statements

George Swallow: Happy to use TTL

Rahul Aggarwal: Not clear what problem we are trying to solve. ECMP works
just fine. Reserved labels in MPLS are used for specific purposes. Leave
this alone.
Dave Allan: ECMP implementations are sensitive to where reserved label is
in stack.

Rahul Aggarwal: use inband VCCV
Dave Allan: in absence of control word, depends on implementation

Rahul Aggarwal: borderline case
George Swallow: do you want to put 4 bytes into header?

Danny McPherson: Take to list

Overview of Y.17iw
Dave Allan
http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt
---------------------------------------------------------------------

Put in as information on ITU work on OAM interworking. May be of utility.
Scope of Y.17iw. Interworking of I.610 and Y.1711 in network interworking
and service interworking scenarios. Approach is not to try and interwork
OAM protocols , but instead to use 'trigger state'. Summarizes actions
if PW breaks in ATM over MPLS.

Applicability: directly applicable to encapsulations for ATM over M PLS
here, where Y.1711 and ATM OAM is properly supported. Also shows
applicability to service interworking i.e. ATM and MPLS peers.
Similar or OAM interworking in FRF.8
Work in progress. Proposed for consent at July SG13 meeting.

"Sasha Vainshtein" <[email-masked]>
http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt
-------------------------------------------------------------------

Presents some of the discussion. First presented at IETF-52. Evolved in mean
time to cover additional functionality and remove restrictions. Aligned
with WG charter, requirements, architecture, TDM PW requirements, RFC 2736,
and SONET emulation draft.

Summary of updates: Requested to adopt as a WG draft as the basis for
further WG work posted in June 03.
4 successful interop tests.
Few technical issues remain.
No conceptual objections to unstructured services:
draft-stein-pwe3-stpp-00.
Specific technical issues: non ECMP compliant control word, because it is
aligned with SONET.

Technically possible to use control word : sufficient flags (4 flags
needed), sufficient sequence number space, use fragmentation bits for
splitting basic structures of trunk specific Nx64

Second issue: Usage of RTP header.

Minor issues: default packet latency of unstructured E1, Frame alignment
for unstructured services, ?.

Danny McPherson: presentation in a few minutes will affect this, so hold
off for progression discussion.

"Yaakov Stein" <[email-masked]>
http://www.ietf.org/internet-drafts/draft-stein-pwe3-stpp-00.txt
----------------------------------------------------------------

Simple TDM Pseudo-Wire Protocol
Draft-anavi first presented at 50th IETF.
Several compromises reached and rejected.
Multiple main modes for special cases. These are there for good reason.
Also, various special mechanisms for clock recovery etc.
Simple interworking with existing AAL1/2 networks.
Claimed draft-Vainshtein has evolved into a long and complex draft. Single
main mode with plethora of sub-modes.

STPP was supposed to be a 'dumb' draft. Draft is only 11 pages, readable by
non-TDMers. Designed to cover common TDM cases. Simply encapsulate
arbitrary length TDM packets. No special payload treatment, and highest
possible b/w efficiency.

Proposal: accept STPP for most common (simplest) TDM cases: broad support,
easy to implement.

Accept TDMoIP and CESoPSN for special cases.

Sasha Vainshtein: You listed four issues. Packet loss concealment is the
only one that has been addressed I a draft.

Yaakov Stein:  No. Loss avoidance has been covered as well.

"Danny McPherson" <[email-masked]>
"Stewart Bryant" <[email-masked]>
Discussion: Getting Traction on TDM
------------------------------------

Put together as a result of lots of consideration by chairs.
TDM is the long pole test. Every encap except TDM has pretty firm.
TDM Unstructured TDM consensus is plausible. However, structured
consensus is difficult and as far away as ever.

2 problems: commercial interests, and not enough TDM experts in IETF

Chairs cannot allow TDM work to continue to defocus group

4 options:

draft-Vainshtein goes to WG, and draft-anavi becomes informational.
Or draft-anavi goes to WG, and draft-vainshtein becomes informational.
But, not clear consensus which way to go.

Could remove structured work, in which case this would cease and we would
pick one of the unstructured approaches from the draft. Structured
approached become informational.

Alternatively, drop TDM altogether.

Draft-stein-pwe3-stpp-00.txt is the only current draft. Short.
May need RTP support. Could take draft Vainshtein unstructured as
alternate starting point.

Decision: Chairs pick a neutral editor to pick best of both. Split
structured and unstructured work. Editor to take it forward.

Yakov Stein: other possibility is to make one common draft that we can
agree on. No issues with STPP, issue is wording, so perhaps we could
consider a short time frame of one month to do this.

Tim Fross: unstructured draft is fine whichever. Structured drafts will
have to be rewritten, so as a refinement to chairs approach, rewrite
draft-stein and draft-anavi with just unstructured and then have WG run
off.

Tim Fross: unstructured draft is fine whichever. Structured drafts will
have to be rewritten.  I support the  chairs suggestion of progressing
the structured versions of draft-vainshtein and draft-anavi as
informational.

Yakov Stein: lack of support for either draft is not the problem.
Agrees we should remove unstructured portions out, clean up.

Stewart: About time we stopped the beauty contest. Time to stop it.
Concerned about RTP should it be dropped off?

Yakov Stein: no problem with RTP as an option for whoever wants it.

Danny McPherson: Sasha & Yakov to get back to chairs on this and come up
with unstructured draft. Need to see something by Sept 1st.

Sasha Vainshtein: Agree with proposal for split to structured and
unstructured and will produce something in around one month.

Stewart Bryant: The chairs will look for some one to edit unstructured
draft after September, if we need to.

Sasha Vainshtein: tight timetable is reasonable.

Outcome:

1) Yaakov Stein and Sasha Vainshtein agreed to produce a joint
unstructured draft by 1st September

2) WG Chairs will hold off seeking neutral editor unless this effort
fails

3) Yaakov Stein and Sasha Vainstein invited to re-present their
structured work as individual drafts.

Luca Martini <[email-masked]>
draft-ietf-pwe3-control-protocol-03.txt
----------------------------------------

Rewritten ATM Oam procedures. Added status TLV section. Updated diagrams.
More work? Add clarification to generalized FEC? Could do in PPVPN.
Would like to go for last call after next revisions.

draft-ietf-pwe3-ethernet-encap-03.txt
     Stable for a long time and would like to go for last call.

draft-ietf-pwe3-iana-allocation-01.txt
     Cleaned up some allocation conflicts, and added PW status TLV bit
     allocations.
     Should I rewrite the status TLV?

Sahsa V: assuming unstructured TDM will be done soon, can we have PW types
for this included?

Stewart: assume this is a convenient method for talking to IANA?

Luca Martini: Yes.  Will put allocations in.

Danny: good, we have progress for some things to last call.

draft-ietf-pwe3-atm-encap-02.txt
     This is a major revision. Consolidated applicability statements
     and control word. Updated OAM. Aligned control word with architecture
     draft. Other list of updates. Should be ready to go for last call.

Stewart: does this align with ITU Recommendation?
Luca: yes. No major technical change.

"Himanshu Shah" <[email-masked]>
draft-shah-pwe3-control-protocol-extension-01.txt
-------------------------------------------------

Extension to control protocol for dynamic parameter signaling.
Draft proposes mechanism for 2 PEs to exchange attributes without tearing
down the PW. E.g. IP address for ARP mediation, and IP+MAC for IPLS.

Claims simple and easy and easy to implement.

PEs learn each others capability for exchanging dynamically.
Dynamic signaling: two methods to signal updates to PW attributes without
withdrawing the FEC. Both methods work, but draft recommends LDP
notification message.
Would like feedback from WG. Shows example of PW status signaling., but
other attributes can be exchanged e.g. IP address TLV, IP+MAC address TLV,
etc.
Conclusion: need generic mechanism to extend signaling in backward
compatible fashion to include capability signaling.
Requests draft adopted as WG item.

Sasha Vainshtein: this mechanism would be very helpful in solving
congestion detection problem. Would like to support this draft. Also
resolves issue of ARP mediation, where you cannot
Luca Martini: Status indication is already in control draft. Other TLVs are
all useful and should be defined. Question is where? Doesn't necessarily
fit in control draft You are proposing list of parameters for PW. Most
useful for VPLS.

H.Shah: not limited to VPLS
Luca Martini: we can do the agreeable parts if there is another interest on
the mailing list.

Hamid Ould-Brahim: additions are just a particular provisioning model.
Signaling capability is an important aspect.
Luca Martini: that's why we have L2VPN WG.

Danny: take to the list.
Ali Sajassi: good to have this mechanism, but TLVs are not right for PWE3.

Stewart: continue on list, and decide which parts to take in PWE3

"Ghassem Koleyni" <[email-masked]>
Update on activities in ITU-T SG13 regarding interworking topics
----------------------------------------------------------------

Update on what is happening on Q5 of SG13. Shows the general network
interworking model.  Two Recommendations will be published: cell mode and
frame mode. Cell mode has two modes: N-to-one and one-to-one. Aligned with
IETF and ATM forum. Thanks all authors.

Frame mode document (AAL5 PDU mode and SDU mode) expected to go for consent
at July SG13 meeting.

Other topics: FR-MPLS network interworking, TDM-MPLS network interworking,
voice services over MPLS, and general service interworking where networks
either side of MPLS core are dissimilar. Have started to work on
requirements for ATM-MPLS-FR.
OAM aspects are jointly handled by Q5 and Q3.

Andy Malis: suggest SG13 should follow SG17 work on X.84 on FR
interworking.

Andy Malis: Work here in FR interworking has been kept aligned with SG17
work.

Ghassem Koleyni: need as much synergy as possible if multiple parties work
on the same draft.

Stewart: would like to receive contribution drafts on how to tackle
congestion.

MEETING CLOSES