Last Modified: 2004-09-07
| Done | PWE3 WG started, organize editing teams. | |
| Done | Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables | |
| Done | Accept drafts of service-specific documents as WG items | |
| Done | Requirements Document Last Call | |
| Done | TDM Circuit Documents Last Call | |
| Done | ATM Documents Last Call | |
| Done | Ethernet Documents Last Call | |
| Jan 04 | Fragmentation LC | |
| Jan 04 | TDM Requirements LC | |
| Feb 04 | SONET Documents Last Call | |
| Mar 04 | TDM Documents Last Call | |
| Mar 04 | PWE3 WG Charter Review, Additional Work or Ends | |
| Apr 04 | Frame Relay Documents Last Call | |
| Apr 04 | PWE3 MIBs Last Call | |
| Apr 04 | SONET Documents Last Call | |
| Apr 04 | FCS retention Last Call | |
| May 04 | VCCV Last Call |
| RFC | Status | Title |
|---|---|---|
| RFC3916 | I | Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) |
|
PWE3
1530-1730 Afternoon Session II; Lincoln East Administrivia ------------- Chairs: Danny McPherson & Stewart Bryant Minutes: Matthew Bocci Slides are available on pwe3.tcb.net Charter & Draft Status - Stewart Bryant & Danny McPherson --------------------------------------------------------- Working on updating charter with ADs. Danny to send email to list with prposed updated and goals and milestones. Draft status: Stewart Dependencies: Lots of dependencies between drafts. Cannot become RFCs until dependencies become RFCs. Very important to get this right. Draft text may change if dependency text changes. Stewart carried out a dependency analysis: this is shown and looks very complex. This will drive order in which we send documents to RFC editor. Concerns: Not all normative references are really normative. Authors need to double check this. Also need to make sure all things that should be normative are called out as such. Need to check for informative refs and docs with no normative references. Base requirements now an RFC. Architecture: list of dependencies, but one may not be correct. Edits sent to the list. Now in editors queue. Waiting for fragmentation and L2TP. This will be RFC. Fragmentation: needs an updated. Encap refs can be moved to control word references. Andy Malis: Refs to arch can also be changed to refs to CW. Stewart: not sure this is allowed as arch is informational. Arch needs frag, needs control, and control doesn't have dependencies. Luca Martini: Architecture doc should be an informative reference becasue you define CW in architecture. Stewart: Fragmentation called up 2 bits in CW. Yaakov Stein: CW has to be standards track because of 1st 4 bits Luca Martini: Every documents defines the CW bits that it uses. CW document is the generic template. Mark Townsley: would be preferable if description was all in one place. Yaakov Stein: important to keep things the way they are now for expediency Eric Rosen: will confuse the IESG Control Word Draft: Most refs to arch refer to sec 5 and could be deleted. These could be changed to arch. Will respin and send up. IANA: This is in last call and will be sent out as soon as this is completed. Needed to set up the registries. Also lots of requests to stabalise code points. Control : This is one of the most strategic docs. Past last call, but keeps getting minor change requests. This is an urgent gating draft. Need to take a hard line on this. Luca Martini: Also some editorial nits that need to be fixed. Stewart: as long as protocol works, need to draw a line in the sand. ATM and Ethernet: Had 1st go of AD review. A few edits to fix. Thomas: very close to last call. TDM Reqs in Thomas' queue SONET needs TDM requirements to get AD review before progressing. SATOP sent to Thomas, but want to resolve UDP issues first. CESoPSN is informational, but want to resolve UDP situation too. HDLC encap: Needs a respin to fix refs. Completed last call. Frame Relay: Needs some TLC. A get well package has been agreed, and should see a new rev shortly. Style out of step with rest of document set. terms need fixing. Yaakov Stein: Titles of encap drafts could be standardised or made more consistent. Luca Martini: Titles are not consistent. Most say MPLS/IP, some say just MPLS.... Want comments on changing all of the titles and making them consistent. VCCV: Pressure to move this on. It went to last call. Dave Allen's comments have not yet been resolved: should be in rev 04, but this has not been published yet. Needs a serious edit pass, and should be last called. Depends on BFD and LSP-ping. MIBs: these have a hge cross dependency list. Need to make sure procedures are published before. FCS retention: Has standard encap dependencies. Not in last call yet. Andy Malis: it is ready for last call. Cell transparent mode ready too. TDMoIP: Need to resolve UDP issue. Appendix depends on VCCV. Waiting for comments on 2 OAM issues. OAM messag mapping: Big dependencies, so wait for others to get out of the way. Plan: 1. Get -iana-allocation- to IESG 2. Finish -pwe3-cw- and send to IESG 3. Edit -control-protocol- to sort out refs and send to IESG 4. Edit fragmentation and then send to IESG At this point we have the platform needed to progress the encap drafts 5) -ethernet-encap- 6) -atm-encap- Get TDM requirements to IESG, then the TDM encaps 7) -tdm-requirements- 8) -satop- 9) -cesopsn Then finish the following encaps as they become available <draft-ietf-pwe3-frame-relay-03.txt> <draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt> <draft-ietf-pwe3-sonet-09.txt> When we have made progress on the above we will promote the other work to the priority list Architecture draft is in editors queue. Waiting on frag and L2TP. CW dtaft will be standard. Arch will be informational. Yaakov Stein: Why is CW standards track, if it is not refered to as normative in other docs? Danny: Take to list and see what WG consensus is on new title. Mustapha: is CW is informational, why not just merge back to the architecture draft. Danny agrees that this is an issue that needs to be addressed. Will take offline. PW CW - Stewart & Danny ----------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cw-00.txt There was lots of work after last IETF. Introduced associated channel concept. Only use of 001 encapsualtion is for associated channel for OAM traffic. This needs a formal definition for associated channel. Suggestions to the list on this. Other format ID values are available for additional purposes. Yaakov Stein: word channel clashes with the use in the architecture draft Stewart: propose some text to the mailing list. Channel type will have its own registry. Plan is to grandfather VCCV value (21). Some errors in the text around IANA assignment. UDP Statement to ITU - Stewart ------------------------------ This is one of the most discussed issues. TDM encaps are being pursued in SG13 as well. UDP encaps are only used by low speed TDM. IETF documents are vague on use of UDP. Need to resolve this before we can go forward. The ITU started to talk about introducing an expected mechanism for handling the ports. 5 techniques proposed in liaison. Extensive comment on this to the list. Unable to reach consensus. Statement proposed to the list. Essentially says PWE3 deals with L2TP, and MPLS tunnelled over IP. Unable to reach consensus on whether we need a 3rd method, so unable to give advice to ITU on where to go next. However, are willing to listen to proposals on how to carry PW over UDP, but anyway will need to consider issues such as congestion, security, and specific application. UDP Encapsulation - Yaakov Stein -------------------------------- Service provider model is presented. Emulation is PE to PE. IWF is located in the PE. AC is native service. Encap sits at the PE. Becomes MPLS at the PE. However, another model is that the iwf is at the CE. The AC does not run the native circuit. 3 possibilities: - MPLS AC - UDP/IP AC - other AC possibilities (L2TP, MPLS over IP, native service over IP using GRE, etc) Lively thread on the list. Over 50 emails from 16 participants. Advantages: UDP/IP familiar to customer base, PW label as UDP port no. reduces overhead, already extensively deployed for TDM PWs, reuse of AVT protocols, simplify NAT traversal. Disadvantages: had to provide QoS without c/o pt-pt trail. Cannot be layer network above UDP. UDP doesn't scale, not enough port numbers and increases NAT/firewall state. Need protocol for UDP port signalling. UDP checksum needs to be calculated. Why a new PW type at a late stage? Security and congestion control Other comments: need to reply to ITU liaison, PWE charter aimed at operators, not enterprise customers, wrong, but how to stop enterprise using it, no consensus, should divert to AVT, but CE-CE PWs not in AVT charter, UDP OK for VoIP since adapts an application, some comments seem to rule out MPLS Presents an rebuttal: - QoS similar to LDP based MPLS or L2TP - Enterprises don't need large number of UDP ports - Scales better than VoIP today - can use manual port provisioning - UDP checksum can simply be set to 0 - PW type has been in the charter from day 1 - Security: LDP and L2TP protocols are similarly unsafe - Congestion similar to L2TP Proposal: Explicitly limit UDP/IP to enterprises (CE-CE case) - only allow manual provisioning - enterprise responsible to security, congestion avoidance - MPLS should be used if large numberof PWs needed. Stewart: would like comments to help draft ITU response Sasha: Agrees that there is no sense in developing a control protocol for UDP PWs. Don't understand what enterprise PWs means. If it connects to a class 5 switch, what is it? Also not sure that admission control should be up to the customer. Yaakov Stein: On congestion avoidance, the link that is UDP will suffer. SP can discard excess traffic. The access PW is the point from the CE to the core network. Sasha: Confused. Are UDP PWs only a part of Multi hop PWs? Yaakov: yes Sasha: don't know what to do with MH PWs Eric Rosen: is is too late to remove this TDM from charter entirely? Stewart: many people want to work on this Eric: if you want to get this though, stop drawing attention to the problems e.g. NAT, signalling, how you do multiplexing, seems to need to be manually configured to interoperate. Solution is to take UDP out and leave up to SG13, or only have manual configuration. IESG may still notice this. Better to leave this in the hands of the ITU. Luca Martini: Be careful and write a good security section. You are mixing control protocol with data planes. We are very exposed here. Danny: We are trying to define protocols, not how and where they are deployed. A lot of concern on how to scope enterprise vs. service provider here. We need to assume the protocols defined here will be deployed in the Internet. Stewart: can either: - not respond - say unable to reach consesus - say we recognise that there are limited cases where UDP would be appropriate, supported by manual configuration Scott Bradner: You have about a week to honor tradition and not respond, but it would be better to send them a response Thomas Narten: Be pragmatic and reasonable. If we don't respond, what will happen? Stewart: we have an opinion as to how UDP is correctly operated. We have a duty of care. Yaakov Stein: reason this was sent was that this was going to be progressed in SG13. If we cannot reach consensus, SG13 wil l do what it wants. Scott Bradner: ITU is trying to work with us. We should cooperate going forward, even if it is to say that we don't have an opinion. We must not ignore them. Thomas Narten: Agrees. We can give our thoughts. We may not like what they want to do, but should explain why. Mark Townsley: could say PWE3 doesn't care. Is there some work to do at an IAB level on what you do with UDP? Craig White: We do need to send a fairly strong statement similar to what eric expressed, but need to be cognisant of the fact that they have implementations. Need to say that on the Internet, this is not an appropriate use, but may be appropriate in a private network. be aware of issues if it gets connected to Internet at any time. Scott Bradner: What is magic about UDP in this context? Stewart: this was not an issue until it was noticed that we needed a port assignment protocol Scott Bradner: This working group was formed with the assumption of UDP and MPLS Craig: congestion avoidance problem with UDP Scott: no real difference Yaakov Stein: ITU would be happy to hear that we only want manual configuration. Luca Martini: We also have an implementation of this. Bottom line is that a better design is L2TPv3 and this should be used instead. IETF thinks this is a better idea. Eric Rosen: 2 issues: signalling. Suggestion that you could use LDP, with port numbers instead of labels. Do you use source or destination port? What about NATs? not sure we can come to consensus, except you need to manually configure it. Stewart: We do not recommend UDP, but L2TP. If you use UDP, you so manual config. Yaakov Stein: why? Stewart: We recommend that you only do manual configuration of the ports. Mark Townsley: ...and if you want to do automatic configuration, use L2TPv3 Issue with UDP is that it can cause problems for NATs. Some of the arguments made on the list are significant. Yaakov Stein: why does RTP group get away with this? Shasha: Neither MPLS nor L2TP are suitable for NAT traversal. Could say: No signalling protocol, should not be used in NAT environment. Agree that there is substantially more VoIP and so we could say that UDP already used for VoIP sessions with operational success. Mark Townsley: L2TPv3 designed to run over UDP. Every NAT knows how to do L2TPv3 as in RFC2661 Thomas Narten: Liaison doesn't ask if it is a good or a bad thing. It asks how to do port number stuff. We should answer the question. Stewart: Our advice is that this is only done in a manually configured mode, and anything more advanced should be made as a proposal to the PWE3 group. Yaakov Stein: pick one and send it back already! Pick manually configured, but use L2TPv3 for signaled Consensus around this. Propose to the mailing list by Friday afternoon. PW Multi-Hop Requirements - Luca Martini ---------------------------------------- Presents the outcome of the requirements team. Last IETF was a discussion about PW stitching. Since then, we had a long drawn out email thread. Concluded we needed a requirement document. Document not achieved by this IETF deadline. Met face to face. We are regrouping, and trying to produce a draft by the end of november concentrating on requirements for this technology. This will guide if we need to do any more protocol work. Open Microphone --------------- Luca Martini: What is the state of the rechartering? Danny: Will provide an update on the charter, goals and milestones on the mailing list. Meeting Adjourned |