PWE3 WG Meeting IETF-57, Wed 16th July 2003
===========================================
Chairs: Stewart Bryant and Danny McPherson
Minutes take by: Matthew Bocci
"Danny McPherson" <danny@tcb.net>
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" <narten@us.ibm.com>
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" tnadeau@cisco.com
http://www.ietf.org/internet-drafts/draf
t-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"
<mustapha.aissaoui@alcatel.com>
http://www.ietf.org/internet-drafts/draf
t-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" <dallan@nortelnetworks.com>
http://www.ietf.org/internet-drafts/draf
t-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/draf
t-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" <Sasha@AXERRA.com>
http://www.ietf.org/internet-drafts/draf
t-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" <yaakov_s@rad.com>
http://www.ietf.org/internet-drafts/draf
t-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" <danny@tcb.net>
"Stewart Bryant" <stbryant@cisco.com>
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 <luca@level3.net>
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" <hshah@ciena.com>
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" <ghassem@nortelnetworks.com>
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
|