Last Modified: 2005-01-17
| 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 IETF62 WEDNESDAY, March 9, 2005, 1530-1730
CHAIRs: Danny McPherson (danny@tcb.net) Stewart Bryant (stbryant@cisco.com) Minutes: Matthew Bocci (matthew.bocci@alcatel.co.uk) --------------------------------------------------------------------- ADMINISTRIVIA ------------- Chairs: Stewart Bryant chaired the meeting. Apologies from Danny who was called away at the last minute. Agenda Bashing: After the front end items, Luca will deal with all of control and encapsulation drafts. Then we will do Multi-Hop requirements, OAM and then signalling. Minutes: Matthew Bocci takes the minutes. WG DOCUMENT STATUS ------------------ Stewart Bryant 2 RFCs now: PWE3 architecture came out today officially. In IESG review: TDM Requirements. Received some comments last week. Edits are in hand and a new version should be cut this week. In AD Review: Control word, PW setup/maintenance, Ethernet. These will act as template for all the other encapsulation drafts. Completed last call: HDLC was refreshed. IANA allocation, fragmentation, and ATM need an update to tie in with new style. Thomas Narten: IANA allocation needs to go with previous set. SONET/SDH, SATOP and structure aware TDM have completed last call These will need another spin to cover bits moved from the control draft to the encapsulation documents. ATM cell transport is ready to go. Work in progress: VCCV is now ready for WG last call. Frame Relay needs to resolve the port mode issue. Then it will be ready for last call. PW over MPLS MIBs: (Tom Nadeau) All 7 drafts need a refresh after editing yesterday. PSEUDOWIRE SETUP AND MAINTENANCE USING LDP AND ETHERNET OVER MPLS ----------------------------------------------------------------- Luca Martini draft-ietf-pwe3-control-protocol-15.txt draft-ietf-pwe3-ethernet-encap-09.txt Restructure of the drafts following AD review. PPP HDLC draft was sent out, got an acknowledgement, but was not posted for some reason. Thomas Narten: please follow up and CC Mark Townsend and chairs. 8 different drafts updated for this IETF. General reorganisation of the drafts. AD review points: - Too many normative refs, - MPLS WG needs to review LDP usage, Stewart: We should give them the final document. - Duplication of text in IANA and control, - Remove dependencies between control and encapsulation documents. This is so that in the future we can just create a new document and not update the control draft. Because we have L2TPv3 defined elsewhere, we removed notes to L2TPv3 and IP, so the documents are about MPLS only now. There are also some grammar and syntax corrections. General reorganisations: Documents only contain new allocations from existing IANA registries. All new IANA registries and initial allocations are in IANA document. Service specific text moved from control draft to the encapsulation drafts. Interface parameters specific to a given technologies. All text referring to IP/L2TPv3 remove needs to be removed. Control document: Removed IANA duplications, move technology specific text to service docs, updated PW status section according to email thread on list: MUST for PW status TLV, and MAY for label withdraw. IP PW type is left in the control document because this is described in RFC 3032. Security section needs some rewording to pass IESG review. Comments is that we must implement all applicable MPLS/LDP security measures, as defined in those documents. Ethernet encapsulation document: Changed tagged vs raw mode to be clearer. Remove SHOULD implement MIB as this was redundant. Security section -> use security offered by PSN. ATM encapsulation document: Did not make draft update deadline. Requires service specific text from the control draft. CW presence: MANDARTORY changed to REQUIRED. Grammar fixes. Reference structure changed with a normative reference to the control protocol document. Fame Relay Document: There was 80% rewrite of version 3. Document is now inline with PWE3 architecture and terminology. Requirement for padding removed. Changes still to come: sequencing text is ancient and broken. FR port mode text needs to be removed or edited, as this looks the same as HDLC mode. Plan to remove and put a note in the HDLC document that for historical reasons there is a FR port mode and this is the same. PPP/HDLC document: updated boilerplates, moved specific text to it. Next revision changes: - add note about HDLC = FR port mode. Chair asks for comments to resolve this: No one opposed PW types still have to match, but the bits on the wire are the same. Stewart Bryant: Take this as OK. Luca to send email out on the list with what he is doing. IANA document: Minor addition of new registries for TAII, SAII, and AGI type Andy Malis: I would be in favour of increasing the size of the 1st come 1st served at expense of vendor specific range. Luca Martini: several options: - IETF consensus - Expert allocation - 1st come 1st served - Vendor specific (private) - Experimental George Swallow: Why do you need 2 different registries for TAII and SAII? Luca Martini: Do we ever need different types? they should be the same. George Swallow: Its not the field's that need to be the same, but we only need one registry. Luca Martini: OK, one for SAII/TAII type, and one for AGI type. On the IANA allocation: Eric Rosen: I suggest that the vendor-specific space have no more than 32 or 64 values, and the rest be added to the FCFS space. Stewart Bryant: OK we can play with the sizes, but what about the policy? Andy Malis: would be interested to know why need strict control on allocations Luca Martini: we have much more space for control protocols. Would like to avoid people using the wrong types. I can change the ranges, but right now there is no expert allocations in the ranges. Do we want this? Andy Malis: No Luca Martini: is anyone in favour of expert allocation for control protocols Thomas Narten: There is no reason for expert review for 1st come 1st served. What is the minimal level of review required? Is there a potential of abuse? Luca Martini: personally, we should make it as easy as possible to allocate as people will do it anyway. People gave feedback that expert review did not work in the past. Thomas Narten: I'm not sure this is a good reason for no review. Need to say what is the minimal level of review, and then make sure it is timely. For expert review, there could be guidelines on what the WG intended. Could have expert review, and say that as long as WG is comfortable with it, then that is good enough. Yakov Rekter: do you mean IESG should outlaw 1st come 1st served? Thomas: No. But in 1st come 1st served, you run the risk of the outcome being undesired later. The right thing is to look at name space and see if there is no hard. Am opposed to blanket 1st come 1st served. Andy Malis: need to look far enough in future when there is no longer a working group. Stewart Bryant: isn't this a AD job if there is no WG left? Luca Martini: could put a time out in the draft for the expert to reply Thomas Narten: In that case, should replace the expert reviewer or use other mechanisms. Vach Kompella: what if you don't need an expert review, but just need to submit a draft. Luca Martini: OK put a requirement in that you need a draft. Vach Kompella: so rather than 1st come 1st served, that has its own DoS characteristics, write a draft. Andy Malis: not sure there has ever been abuse Mark Townsley: never been any abuse of 1st come 1st served. What concerns me is that if somebody does something stupid after a WG shuts, there would be no review. If the registry space was huge, would be less of a concern. So, would be good to have some form of review. Right way is to fix the expert review process. Eric Grey: I think that having an ID being submitted for 1st come 1st served, it must be an ID targeted as being an RFC. Otherwise no one will review it. Luca Martini: you need this for IETF consensus. Eric Grey: IETF consensus agreed for standards track, but this is not true for an informational. Eric Rosen: there have been cases where I have regretted a code point but that has almost always been when they have been allocated through IETF consensus. A DoS attack is not likely because there is no money to be made in claiming code points and then selling them back. Thomas Narten: a designated expert is a loaded term. The IANA considerations RFC has this because IANA does not want to make the judgement call. It is useful to have someone who understands what the registry is for. The designated expert simply says yes or no as an interface to IANA. They do not have all power: WG if still around has input. Luca Martini: process can take 6 months to a year Yakov Rekter: problem is that expert becomes judge. Expert should advise the people who want the allocation. Eric Rosen: The value of FCFS space is that it prevents innovation from being stifled by political machinations over the granting of a codepoint. This in turn helps to keep corporate competition in the marketplace rather than in the IETF. Luca Martini: Agrees that we would not want to kill innovation with the allocation process. Kireeti Kompella: Would like to revise 2334. Stewart Bryant: Would like to ask Mark (AD) on how to proceed. Sense of the room: consensus is 1st come 1st served. Mark Townsley: OK but would like to take this to the list. Stewart Bryant asks if 1st come 1st served with a draft or without a draft: Stewart Bryant: Saw a minor preference towards with a draft: anyone object? Eric Grey: would prefer an informational RFC. People who have been putting proprietary protocols in informational RFCs. Outcome: Debate taken to the list. PW CONTROL WORD --------------- Stewart Bryant draft-ietf-pwe3-cw-01.txt Both chairs are the authors, so am concerned that this has full buy in from WG. This went to AD review. Most of the comments were editorial. There was also some discussion at last IETF on IANA policy. Two issues discussed on the list: - Wording on generic verses preferred CW Sense of the room: seems to indicate this is OK - Text for length field. Actually, all encapsulation drafts use a simpler version of the text. New text was sent to the list. New text addresses trimming of any added padding. Would like to get these words sorted out. Need to change text "Layer 2" to PW. Also, "must be trimmed if required". Sense of room: Consensus on this. MULTI-HOP PSEUDO WIRE REQUIREMENTS ---------------------------------- Nabil Bitar draft-martini-pwe3-mh-pw-requirements-01.txt Note: Agenda showed version 0. Actual draft discussed was version 1. The scope is to describe requirements to allow a Service Provider to extend PWs across multiple domains and tunnels. Could be ASs, areas, etc. Shows current single segment architecture. In contrast, multi-segment PWs are composed of multiple segments, over any PSN tunnel. Explains concept and terminology. Endpoints are ultimate PEs, while switching points are S-PEs. Draft defines a list of terminology, applications: scalability, extending PWs to metro and access networks, extending PWs across provider boundaries to deal with confidentiality and security requirements, avoid continuous PSN tunnels across providers, and interworking between different PSN tunnelling technologies. Lists some of the architecture requirements: Transparency to P-routers maintained. Both directions must traverse same S-PEs. Setup mechanism requirements: - static endpoints with static or dynamic switching points List of detailed requirements on setup, resiliency, We talk about a PW backup as well as a path backup. TE and QoS requirements: - need to do admission control and carry PW parameters in the signalling. Routing requirements: - Must support static as well as optional dynamic OAM requirements Next steps: - Security requirements text ready to add to next version. All existing security requirements apply, but also new ones for inter-provider case - Policy requirements - Consideration for any further refinement - WG option on multi-segment vs. multi-hop terminology - Request to accept this document as a WG draft Dimitri Papadimitriou: why does section 6.4 refer to a list of mechanisms of single segment signalling mechanisms. Why are you referring to single segment? Luca Martini: The idea was to use this document for all types of PWs, not just MPLS Dimitri Papadimitriou: The intention is to discuss multi-segment. But refers to single segment protocols. Why should I support this? Luca Martini: requirements is to support multi-hop for all types of PWs Rahul Aggarwal: This document talks about MS PW requirements. Why should it presuppose a particular SS signalling technology? Nabil Bitar: there was a discussion on the list about backwards compatibility. Luca Martini: Now this document has a collection of requirements from different people. If you think this requirement is a problem, send an email to the list. Himanshu Shah: it is ok to have requirements for a single hop to show we are consistent with single hop. There have been discussions on mailing list about explicit route. We are talking inter-domain: is it known at U-PEs that you can provide list of hops? Nabil Bitar: these are not always ASs. Could have a list of one AS that leads you to the next AS. Himanshu Shah: so there are cases when it is not possible. Stewart: please focus on issues blocking this moving to a WG document. Vach Kompella: are you talking about tunnel resiliency? Nabil Bitar: when you configure static endpoints, you need to protect the path of the PW, not the tunnel. You want to be able to choose different S-PEs if S-PEs fail. Yakov Rekter: in its present shape this document should not be WG document. Bruce Davie: a fine start and pruning can happen later, after WG status. Also, on L2TPv3, would be a nice requirement for this. Sense of the room to make a WG document. Stewart Bryant: should take discussion to the list. PWE3 APPLICATIONS & OAM SCENARIOS --------------------------------- Simon Delord draft-delord-pwe3-oam-applications-00.txt Thanks co-authors and many vendors that have provided feedback. Explains the service provider context: deliver end-to-end services over many technologies. Draft considers specific problems that will be met by SPs for deployment and monitoring of end-to-end services. Issues include: - Access/metro technologies may use different technologies, CEs may or may not be managed by SP, networks can belong to same or different SPs. What does it bring? - Background on how SPs handle/divide network sand for which type of services - E2E service architecture from CE to CE - Specific focus on service supervision: fault detection and fault localisation. - Based on well-known definitions. - Defines 3 generic models for E2E service supervision and applies MEP and MIP points to these services 3 options: use specific e-e OAM, interworking between OAM segments, using a client server model. Models are technology agnostic. Where does this draft fit?: There are 4 minor documents today in PWE3 and L2VPN: - OAM message mapping - OAM for VPWS interworking - L2VPN OAM framework - VCCV This draft can be the glue for all these documents. It provides clarification and applicability guidelines. Also brings requirements for pt2pt supervision. Conclusion and next steps: - A common view among service providers with generic models. Next steps: - L2VPN has already acknowledged this draft. - Specific requirements on PWE3 OAM will be identified - Include MH PWs Stewart Bryant: should this be done here or in PWE3? Simon Delord: it covers parts from PWE3 Vach Kompella: Transit PSN could be a MH PW if you generalised picture. I am not convinced what the IETF needs to do except acknowledge that this exists. This is technology agnostic, but IETF is only interested in IETF protocols and how they are affected. Should this be defined here, or in a body that covers all of these other technologies. If they decide it is in scope, should do whole thing in L2VPN. Simon Delord: We are not talking about any specific OAM. This is a generic model. Vach Kompella: we have already defined OAM message mappings. Do we need a framework to show how these work end to end, or only how they impact IETF protocols? Mustapha Aissaoui: There is a place holder for VPWS OAM requirements. In the message mapping doc etc we made assumptions, which may not be understood by others. It does not do harm to include this in L2VPN framework. However, can understand Vach's position. Dave McDyson: This contains stuff relevant to L2VPN, so should be split. Tom Nadeau: The point is not to redefine what we have already done. Should take VPWS stuff and do it here. Monique Morrow: this is a good document and would like to see relevant parts split between the working groups. Ali Sajassi: Should include service specific stuff in L2VPN OAM requirements/framework. Outcome: Continue discussion on the list. PSEUDO WIRE (PW) OAM MESSAGE MAPPING ------------------------------------ draft-ietf-pwe3-oam-msg-map-02.txt Mustapha Aissaoui Provides a quick update. Changes similar to those for draft-aissaoui. Separated forward and reverse PW state. Major entry / exit criteria rewrites. Next steps: Document is in a stable state and wants to ask to go for last call, but should see what happens to Simon's document. SETUP AND MAINTENANCE OF PSEUDOWIRES USING RSVP-TE -------------------------------------------------- Rahul Aggarwal draft-raggarwa-rsvpte-pw-01.txt Why RSVP-TE: - Inter-domain TE pseudo-wires - Intra domain tunnels are RSVP-TE LSPs - Look at entire picture with all pieces - Multi-segment PWs and PW TE and PW resiliency Uses the same tools as inter-domain RSVP-TE and hierarchy. The PW is instantiated as a bi-directional RSVP-TE LSP. The PW LSP is nested in PSN RSVP-TE LSPs between PW segment end points. Explains how inter-domain TE PW setup works. Need to be able to do a partial path computation to next ASBR. Mechanisms already exist for this. Originally presented at IETF 60. Primary motivation has been clarified since then. Then presents a requirements analysis versus the requirements draft: - RSVP TE already supports inter-domain signalling. This implies hierarchy, implicit route expansion. - Avoid a full mesh of signalling adjacencies between U-PEs. - Fast reroute for protection of tunnels and S-PEs. - Mechanisms to perform fast switchover - QoS: need to support crank-back in any inter-domain protocol Compares LDP and RSVP: TE is missing piece from LDP signalling. Addresses some of the misconceptions, e.g: LSP hierarchy supports targeted signalling Claims that RSVP state the same as LDP Asks for the draft to become a working group document. Andy Malis: Vendors are free to implement anything, and SPs are free to deploy anything. That doesn't mean we have to standardise it. Mustapha Aissaoui: believe this draft uses forwarding adjacency LSPs Rahul Aggarwal: it doesn't. We can take off line Mustapha Aissaoui: T-spec for QoS: its a bidirectional PW, but not symmetrical. Rahul Aggarwal: CCAMP solves this Luca Martini: We should make a decision this time. We need features that are not in the current protocol, do we want to start over? If you want this, use SIP Rahul Aggarwal: RSVP does scale. Dimitri Papadimitriou: there are mechanisms to cover Mustapha's comments Nurit Sprecher: RSVP provides many features that LDP cannot. Cannot see how LDP can do it. reading the requirements draft on the MH (MS) PW, there are new requirements for TE (Traffic Engineering) services (PWs). These include requirements for explicit routes, traffic parameters, traffic priority, traffic class, resiliency, etc. In order to allow the S-PEs to select the appropriate tunnel for the MS PWs (Which apply to the TE requirements), the entire information should be signaled when establishing the PWs. RSVP-TE naturally provides the means to include this information, except for two things, which is very easy to add: the PW ID/PW type and the control word. LDP should be enhanced to include the new requirements for TE PWs. And my assumption is that we are behind the argument of using RSVP-TE or CR-LDP. RSVP-TE was already chosen as the protocol for TE. Florin Balus: When the ABRs are not S-PEs, adjacent S-PEs being for example in different OSPF areas. A direct forwarding adjacency cannot be used in between those 2 S-PEs. How do you do path computation? Rahul Aggarwal: The case is the same Kireeti Kompella: The question is really take the mechanisms that you need. For LDP, TLV by TLV you will create CR-LDP. Yakov Rekter: If one follows Luca's arguments that that RSVP-TE should not be used for PWs because RSVP-TE was not designed for PWs, then following the same line of reasoning one should not use LDP for PWs (as the original LDP was not designed for PWs), and one should not use BGP for the current Internet (as BGP was not designed to carry well over 140,000 routes). Discussion taken to the list. MULTI-HOP PSEUDOWIRE SETUP AND MAINTENANCE USING LDP ---------------------------------------------------- David McDysan & Florin Balus draft-balus-mh-pw-control-protocol-00.txt Dave explains the MH PW challenges and solutions, and described in the MS PW requirements draft. Basic approach is to add a switching PE. There are a number of solutions e.g. add BGP or RADIUS, RSVP-TE, This approach to use a simple protocol in areas where you don't want BGP or RSVP. Dynamic creation using IP addressing Use IP routing to determine intermediate S-PEs. Lists some of the requirements not yet addressed: QoS and admission control, MH PW resiliency, do we need to traverse same S-PEs in the forward and the reverse directions. Asks for input from the list on the last point. Florin gives an overview of the solution. Introduces a MH PW TLV. Explains the fields. Runs through the signalling procedures. We are not trying to do CR-LDP. Use IP routing to find the next hop. Next steps: - Should signalling procedures be in L2VPN or here? Mustapha Aissaoui: need to constrain the S-PEs to be the same in each direction so that you know where you get the state from. Also, are you using LDP-DU, and if so how the explicit route list helps? Florin Balus: the example was LDP DU, could use the same TLV for DoD. Kireeti Kompella: Why do you have a new TLV, when we already have one? Why not just use ERO object? PSEUDOWIRE QOS SIGNALING ------------------------ Himanshu Shah draft-shah-pwe3-pw-qos-signaling-02.txt This was presented 2 IETF meetings ago. We reviewed why we need to signal QoS. New draft has added dynamically signalled ATM circuits, multi-segment PWs. Updates in the current rev: added clarifications on why PW QoS TLV needed, support for multiple QoS TLVs. Shows example of how this works in MS PW and congestion notification case. Asks for this to be a WG item. Kireeti Kompella: do you want LDP with explicit routing and QoS? That is described in RFC 3212. Nurit Sprecher: QoS is a very important part of the TE requirements but not the only one. We have requirements for traffic priority, requirements for specific traffic class, requirements for protection (e.g. no more than 50 ms of traffic disruption when a failure occurs), requirements for traffic priority, etc. None of these, except for the QoS traffic parameters is included in the proposed draft. In addition I said that for TE we are using TE tunnels (which are signaled using the RSVP-TE protocol). Why should we use another new protocol for establishing the services? MULTIHOP PSEUDOWIRE SIGNALING ------------------------------ Himanshu Shah draft-shah-bocci-pwe3-ms-pw-signaling-00.txt This is another PW signalling mechanisms want to reuse the same PW signalling as much as possible, Eliminate requirement to configure SPEs, and want to use a mechanism that gives resiliency for primary with a backup PW. Gives overview of the solution with animations for some scenarios. Kireeti Kompella: all these things about backwards compatibility. I have nothing against LDP, but just call a spade a spade. Dave McDysan: this is more general work than PWE3 Luca Martini: would like to know where routing of PWs belongs Stewart Bryant: routing is a layer 2 VPN problem Hamid Ould-Brahim: I don't see routing is relevant. Why not use PCE? Mark Townsley: What Stewart says makes sense: one PW does not do much. The service is L2VPN. Stewart: take to the list. |