TUESDAY, March 20th, 2007 - 15:20 - 17:20 ----------------------------------- CHAIRS: Danny McPherson (danny at tcb.net) & Stewart Bryant (stbryant at cisco.com) Minutes: Matthew Bocci (matthew.bocci at alcatel-lucent.co.uk) SLIDES (to be posted): http://www3.ietf.org/proceedings/07mar/index.html WG Status and Update - Chairs ----------------------------- AII aggregation in RFC editor queue. IPR statement delayed sent in august. OAM msg map in LC. MIBs - 4 are in LC, ends at end of this week. Fibre Channel - held up by transport area review. VCCV is past LC and is at the IESG for review. Ronen Solomon - can we schedule a time line for when we are expecting a response? Stewart - We tried to assign date of before this IETF. Will chase them. T-MPLS draft: Yakov Rekhter - We should accept as a WG draft Danny - I agree this is time. We will put forward on the list. RFC4446 has an AGI type that is a route distinguisher. MS-PW requirements is in last call. PW protection - added to the charter. TDM signalling - this has expired. Yaakov Stein - needs a couple of small changes then ready for last call PW security - Yaakov Stein (yaakov_s@rad.com) --------------------------------------------- After the last meeting there were some comments on requirements. A new rev of draft was done. PW sec mechanisms draft is still at - 00. Question - do we need a PW specific or a general MPLS solution? What is the issue: confidentiality, integrity, or authentication? What are the scenarios requiring PW specific security? Are there enough providers who want this? What are the solutions? - Requiring MPLSoIPoMPLS and using IPSec: which providers use this? - Defining a security PW type in which arbitrary MPLS can be tunnelled? But is this ruled out by MPLS as currently defined? - Generic security option for PWs e.g. PWsec. Danny McPherson: will take PW security work to the list and see if support from operators and vendors. If sufficient support, then get officially chartered. Luca Martini: Service providers he polled, only one said they needed it using L2TP cookie. No others had any interest. Segmented Pseudowire - Luca Martini (lmartini@cisco.com) -------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw- 04.txt Reviews changes to the draft, in particular procedures for mapping PW status at S-PEs. Presents changes since v3. - MS VCCV - MS-PW status section. - Move active/passive role section to this document - Switching point TLV is a useful feature and should be MUST to process and OPTIONAL to send - Added PW status introduction text To do: - Finish MS-VCCV - Expand the applicability section Explains the way PW status works with a failure of the transmit direction in an intermediate segment of an MS-PW, and how multiple failures clear. Dave McDyson: Status information might be challenging. What if an attachment circuit goes down? There is information in this control plane to do a better job. With this model, you have to mine everything from the network. Mustapha Aissaoui: It's not that you keep track of many failures. If you get an AC fault and a PW fault, AC failure after PW failure, you should suppress AC failure. ?: Should keep option to pass AC down. Need this for dynamic MS PW case and other applications. Danny McPherson: Take it to the list. George Swallow: I don't see any value in suppressing the generation. We suppress the alarm already. Whether you have the extra bit set then you will not suppress this in the control plane. Ronen Solomon - both status can go through the network and can suppress at the end. Luca Martini: Trade off with the number of PWs. Pseudowire (PW) Redundancy - Praveen Muley (praveen.muley@alcatel- lucent.com) ------------------------------------------------------------------ ----------- http://www.ietf.org/internet-drafts/draft-muley-pwe3-redundancy- 01.txt Changes are to merge with draft-dutta on VPLS standby from L2VPN. Move forwarding bit definition to a separate draft. Danny McPherson: Would like to request as a working group draft. Luca Martini: Want to understand what the problem is. This is a property of the attachment circuit. We don't need any protocol changes. Praveen Muley: Need to not propagate the fault to the attachment circuit on the other side. Mustapha Aissaoui: When you do APS to two different nodes, the two nodes in Multi-chassis APS do communicate among themselves, but they need to synchronise to the other side of the network. Luca Martini: All you need is a bit to say PW is not down Mustapha Aissaoui: PW is not down - you can use VCCV on it etc Luca Martini: Nothing says you have to stop OAM. Danny McPherson: There is a requirement to switch between T-PEs and S-PEs in MS-PWs requirements. Praveen Muley: This is intended to be informational. Pseudowire Preferential Forwarding Status bit definition - Mustapha Aissaoui (mustapha.aissaoui@alcatel-lucent.com) ------------------------------------------------------------------ -------------- http://www.ietf.org/internet-drafts/draft-muley-dutta-pwe3- redundancy-bit-00.txt This describes the Active/standby bit. Two other drafts describe the applications. Outcome of IETF 67 was to write a separate draft explaining the new bit, how it is used, and how it interoperates with existing implementations. Defined active state: PW labels are exchanged between two terminating points. Standby state is when PW labels are exchanged, but data path traffic is blocked at either or both ends. Two modes of operation - Independent mode does not mandate synchronization of the PW forwarding paths. If a PW shows local and remote active, then this must be selected as active. Shows a diagram illustrating the independent use case Master/slave mode - one side drives the other side, and has to drive the other side to tell it what forwarding to use. The slave node should block forwarding when over the PW when the RX status bit transitions from active to standby. Shows an example of the master/slave use case for H-VPLS Interop with existing implementations - T-PE/S-PE that does not implement this keeps PW active as long as it is operationally up. Requests status bit Luca Martini: H-VPLS example. There are several solutions for this already e.g. using CFM, Spanning tree. In L2VPN you can use MAC flush. Mustapha Aissaoui: yes, and those are fine as far as they go. Luca Martini: Need to be clear that no matter what the bits are OAM will flow. Mustapha Aissaoui: Yes, this does not change that. Continued discussion on whether PW not forwarding should raise an alarm at the other side. Dynamic MS-PW Routing using OSPF - Andrew Dolganow (andrew.dolganow@alcatel-lucent.com) ------------------------------------------------------------------ ----------- http://www.ietf.org/internet-drafts/draft-dolganow-pwe3-ospf-ms-pw- ext-00.txt Motivation - - Need to dynamically route MS-PWs in a single IGP network where routers have limited routing Shows example architecture where MS-PW overlays on a single IGP network Solution adds a couple of TLVs for OSPF representing S-PEs-S-PE adjacencies and T-PE to S-PE adjacencies Wang: Need IGP to converge faster What is impact on convergence time? Andrew Dolganow: No intent to add to convergence time. Some of the OSPF routers are not PE routers. The draft addresses this point. Wong: What's wrong with BGP - worries about multiprotocol aspects. Andy Malis: This is not needed. TE using TE tunnels. Luca Martini: Issues with oscillations. Use OSPF to propagate external routes - not figure out the best path. Andrew: Don't try to limit # tunnels. But do get scaling advantages. Not interAS. May be a simpler approach Matthew Bocci: Enable you to build link state for the PWs. There is a use case for MS-PWs in access and metro networks, which can be flat. May not be at edge. We need solution that does not need EGP. Because LS - can TE the MS-PWs through the existing tunnels. There is also a requirement to specify a strict route for a MS-PW. This gives enough topology to do that. Dimmitri Papadimitriou: Draft makes clear draft it is protection of PWs with no impact on the protection of area. IGP makes sense for intraAS case. Lou Berger: Highlights the point that we are creating new TE switching layer - should do this based on TE semantics. Look at 2370bis from OSPF WG. Don't redo this work. To be discussed in OSPF list Requirements for P2MP Pseudowires - Frederic Jounay (frederic.jounay@orange-ft.com) ------------------------------------------------------------------ ---------- http://www.ietf.org/internet-drafts/draft-jounay-pwe3-p2mp-pw- requirements-00.txt Presents some motivation for the P2MP PW. Needs to collect the requirements for P2MP PW and identify the use cases. TDM based use case: - adaptive clock distribution and recovery e.g mobile backhauling. Pros are provisioning, bandwidth savings ATM- based use case - Broadcast TV over ATM. e.g. wholesale services over IP/MPLS network Ethernet based use case Framework includes: P2MP SS-PW, which is a PW over a P2MP LSP. P2MP MS-PW over P2P LSP (downstream label assignment), and PW segment over P2MP LSP (upstream label assignment) Further steps: Is there interest in this work? Comments on draft-00 Other use cases, additional requirements for transfer plane, signalling, security, etc There are a couple of related solutions drafts. Charter review? Danny McPherson: Yes, we need a charter review. There seems to be general interest in this. Yakov Rekhter: There is work to use P2MP LSPs. This has to be limited to that. Gile Heron: In the SS case, we are not using P2MP LSPs. There is a solution that you can use this with VPLS. Kireeti Kompella: Is there a requirement that this is bidirectional? Fred: P2MP PW is unidirectional Kireeti Kompella: Can we use BGP to signal P2MP PW? Yaakov Stein: how important is this that it requires a recharter? Is this the best way of doing sync, given TICTOC? Fred: This is one way to transfer the adaptive clock. Luca Martini: Good to start the discussion. Can use P2P PWs connected to VSIs in real networks to build P2MP Danny McPherson: Is there interest in adding this to the charter? A few hands go up. Any opposed? one or two IEEE 1588v2 and PWE3 - Ron Cohen (ronc@resolutenetworks.com) ------------------------------------------------------------ Presents and overview of the status of 1588. v2 is nearly ready. Timing protocol aligns slaves to master time. Time stamp at master and slave. There is also a peer delay measurement which is optional Introduces end to end transparent clocks. Can use peer-to-peer transparent clocks Topology changes to not affect slave clocks Shows an application of 1588 for CES. Summarises differences between PWE3 and TICTOC service There are some commonalities and some differences Yaakov Stein - 1588 for CES: there is no connection between PWE3 and 1588 here. Do you have an example of running timing over PWE3? Ron - don't disagree Kireeti Kompella - I am clueless about this, but is it possible to use P2MP in this? Is the messaging from server to clients the same? MEETING CLOSES