TUESDAY, March 21, 2006 - 1300-1500 =================================== CHAIRS: Danny McPherson (danny@tcb.net) & Stewart Bryant (stbryant@cisco.com) SCRIBE: Matthew Bocci (matthew.bocci@alcatel.co.uk) JABBER: Yaakov Stein (yaakov_s@rad.com) Presentations available at: http://pwe3.tcb.net/meetings/ietf65/index.html Jabber log: http://www.ietf.org/meetings/ietf- logs/pwe3@rooms.jabber.ietf.org/2006-03-21.html WG Status and Update - Chairs ----------------------------- Agenda bashing (Danny) WG charter update - some new items. Worked on already, or seemed intuitive. WG document status. Also have generic PW discussion. Danny sent question to the list about this. Discussion yesterday with ADs and MPLS WG chairs. Discussion on list on this will drive a problem statement. Lists charter items. Fibre channel and PW protection moving forward. Wildcard, MIBS etc are moving along. Things are looking pretty good. Generic PW stuff is not here yet. We had a discussion with the ADs. Need a draft describing requirements for this. Shows a summary of the status from the IETF web page (http:// tools.ietf.org/wg/pwe3). 4 RFCs published, 5 in RFC editor queue, 4 in IESG processing There are a few nits that need to be fixed. Asks for comments on any of these, please do so at the end of the session. Stewart: We have about another 4 to go after this. Stewart: historical ones such as draft-martini will get released when we have RFC numbers for the WG drafts. Target Choice of Pseudowire Type - George Swallow (swallow@cisco.com) --------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-wildcard-pw-type-01.txt Updated to make a WG draft. Would like to send to last call. Danny: please comment before we send to last call. MS-PW Requirements - Nabil Bitar (nabil.n.bita@verizon.com) ----------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-01.txt Brief update on MS PW requirements draft. Document updated before Vancouver, but not presented. Main contents remain the same, but restructured. There are now 5 sections: arch, use cases, req for placement mechanisms, - MS PW arch - Use cases and configurations - static/signalled with static routing / signalled with dynamic routing - Requirements on MS-PW placement mechanisms - OAM - Security considerations Comments from list: editorial (Ben from BT), VCCV end-end and segmented (Dimitri from Alcatel) These will be taken account of in the new version. Next steps: will reissue and solicit comments. Then ask for last call Danny: please comment on the list because last call is coming. Stewart: We can't publish solutions without requirements MS-PW Architecture - Matthew Bocci (matthew.bocci@alcatel.co.uk) ----------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-arch-00.txt Brief update: Became a WG draft after Vancouver. Main changes: strengthened text on NSP in S-PE, added congestion considerations, updated security considerations, removed ss-pw scaling issues Outstanding issues: NSP - do we need a list of compatible PW types (e.g. MPLS to L2TP)? Security issues - is PW label spoofing a problem? (probably not as need type and Sequence Number. Next step - another revision and then WG last call Sasha Vainshtein: Need to address QoS since PSN header isn't intact end-to-end Sasha Vainshtein: PW label spoofing is a big problem Sasha Vainshtein: do you mean there is never an NSP in S-PE? Matthew: You shouldn't need to process the encapsulation based on native service knowledge (PW type) at the S-PE Danny: After requirements document, we want to WG last call on this one too please provide comments, LC in a few weeks PW Timing Requirements - Stewart Bryant (stbryant@cisco.com) ------------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-frost-pwe3-timing-pw-reqs-01.txt This is a revision of a draft Tim Frost did a while ago. It doesn't mean a timing PW. These are to specify what we need to have provided by someone. 3 aspects: frequency e.g. for PSN networks and emulation Phase lock Time alignment (wall clock): two objects needing a common view of time 1st two are definitely result of this WGs work. The 3rd is from other applications. Done some work on TDM sync. We have also done ATM, but AAL1/2 need a clock. Cellular base stations over packet backhaul, sync of IP PBX or voice gateways... Performance requirements are application specific GSM base station needs a 50 parts per billion clock CDMA cell systems CDMA cell sync needs phase alignment to within 10uS Wireline telecoms need 18ss Some audio applications e.g IP speakers need 5us G.8261 defines requirements for delivery of sync over Ethernet for TDM emulation. Additional requirements: Robustness, discovery for best master clock, redundancy and fault tolerance, hardware help Candidate solutions: adaptive clock, as in TDM PWs, NTP, IEEE 1588 NTPv4: Designed to time syc in computers with goal of 50ms. COuld be improved to give sufficient level of timing, but with hardware assistance IEEE1588v2 designed for industrial applications over LAN. Being extended to support wide area services. But requires modification of routers to achieve performance Next steps: to understand how the existing solutions match our requirements Decide if they can be fixed Decide which WG or body should carry out this work Sasha Vainshtein: Requirements also needs to account for load on the network. E.g. should not need to send lots of timing packets. Stewart: NTP takes this to an extreme, and sends very few packets. IEEE sends up to about 100pps to achieve a very accurate clock. Sasha Vainshtein: don't need to go to an extreme position like NTP, and should not go to the other extreme. We need a requirement on this. Sasha Vainshtein: when you describe candidate solutions, you noted that two need hardware support Stewart: need to compensate for dwell time in routers... 1588 does this. So you may need this. Sasha Vainshtein: NTPv4 achieves about 50ms accuracy. But protocol can be much better - it is not limited to this. Stewart: would need to increase packet rate and provide hardware support Yaakov Stein: also submitted to NTP Stewart: Tim Frost is the lead author, so please send comments and requirements. Yaakov Stein: There is a quandary of the protocols. Didn't mention where to work. NTP has a good protocol structure under it. The problem is in the algorithm. Few people working on this, and NTP is only chartered to do documentation work. IEEE is missing the protocol portion, but IETF will not take this and do protocol work. Whichever way we look at it, we are missing a portion. Mark Townsley: How many people in the room would like to see NTP used? A few, Who care? About the same number Who want 1588: less NTP working group is tasked with getting NTPv4 out the door. They need reviewers of their specs. Need to walk across the hall and participate in NTP. Blocking issue is getting v4 out of the door. They have a scope and requirements document Sasha Vainshtein: is the algorithmic part considered part of this standards effort, or just protocol stuff? The two are not really related. You may use same info and process it in a different way. Yaakov Stain: We need to specify a protocol that can support the accuracy we need. We should not go further than we need in the algorithmic work. VCCV Control Channel - Thomas Nadeau (tnadeau@cisco.com) -------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-perf-timing-measure- 00.txt A month ago started having offline discussions with customers about performance measurements over PWs. The main problem is described in the draft. There seems to be a requirement to do performance measurements over PWs VCCV provides only connectivity verification. Do we need to do performance measurements over this with a new control channel type.. Yaakov Stein: if we look at ITU-T Y,1731, they had a good idea. Rather than redo other work, specify a toolkit. Leave up to someone else how interpret it. Peter Busschbach: I worked on 1731. Was not just a toolkit. The ITU split into this and the equipment spec. Some things like delay are straightforward. Packet loss is a problem: do you count every packet, or do you use probes? 1731 decided to count every packet. Tom: depends on the typw of PW. Peter Busschbach: question is not how much you care, but whether you want to count it. Sasha Vainshtein: wants to second Peter's concerns. Need to look at PWE3 congestion. Important weaknesses should be taken into account as to what we measure and interpret results. RTT is relatively easier, but one-way delay needs wall-clock synchronization between the PEs. Craig White: concerned about amount to traffic needed in addition to synchronizing the clocks. Already borrowed from RTP. We should look at this so that we don't loose it. Yaakov Stein takes over the presentation. We can also send timing through the VCCV associated channel. If we do our own work, we have some questions. e.g. time format, how many time stamps, how do we handle loop back requests? Current proposals to move forward: need to extend VCCV for PM and / or timing. Two drafts: one for timing, one for clock sync. We can reused PM protocols e.g. 1731 in VCCV Asks how to progress. Stewart: don't mix requirements with a solution. Any solution with VCCV needs to go into the pool of solutions drafts. Separate measurement from the timing. Wants separate requirements documents. Pseudo wire Attachment Identifiers for Aggregation and VPN Auto discovery - Chris Metz (chmetz@cisco.com) -------------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-aii-aggregate-00.txt Changed name from AII aggregate. The idea is to specify naming hierarchy e.g. for inter-domain. Lists changes: pointer to AII type 1 in L2VPN draft. Glocal ID in AII type 2 is 4 octets to hold 2 or 4 octet AS#, AII type 3 removed. Shows a snapshot of AII type 2. Danny asked who has read draft. Please send comments to Chris. Ping Pan: what about MFA AII types? Chris Metz: no plans to reconcile that Luca Martini: this draft does not preclude other AII types. Welcome to write a draft. PW Protection - Ping Pan (ppan@hammerheadsystems.com) ----------------------------------------------------- http://pwe3.tcb.net/meetings/ietf65/draft-pan-pwe3-protection-02.txt Explains why need PW protection. For a long time assumed the FRR on the tunnel would solve problem. However, PWs used for a mix of traffic: PWs are not all created equal. Also assumes primary and backups have same BW. Need to treat each PW differently. We need per-PW protection. Some PWs may preempt others. Design considerations: need it to work in both SS and MS environment. Need to uniquely identify working and protection PWs, but making use of AII/AGI may not be a good idea. Needs a TLV to say this is working or protection PW. Backup path computation. Have ERO in RSVP, but it is not a desirable behaviour in MS-PW because it's up to the domain edge. QoS e.g CAC on each hop. 1:1 or 1:n protection : need to validate the need for 1:N. Fate sharing: useful in multi-hop applications. Hot-standby vs cold standby Proposes a protection TLV with setup and holding preference levels. PW status with bad message, no bandwidth etc, everything else keep as is. AII/AGI must be the same on all working and protecting PWs Shows how it works. Edge nodes set up a working MH-PW as is. Edge node triggers setup of PWs. On failure detection e.g. BFD, switch to the backup PW. Claims procedures are not very different from the current multi-segment. Next steps: would like to go for a WG draft. Kireeti Kompella: What does it take for people to see this for what protocol this is? Peter Busschbach: One reason is because you cannot rely on transport LSPs to have enough BW. Not sure why you can't. Peter Busschbach: you are saying transport carries both important an non- important Adrian Farrel: is this only 1:1 Ping Pan: 1:1 definitely works. 1:N needs looking at. How do you attach multiple ACs to one PW? Danny: this is a charter point. Do you want a requirements draft? Sasha Vainshtein: What happens when original failure repairs? Ping: should revert back Yaakov Stein: only at PW layer do we need to know how to prioritise. Why not just one PSN Tunnel for high, and one for low priority. Why can't this be handled by mechanisms we already have. Ping: what happens if you have a GRE tunnel Danny: should work on a requirements document Nabil Bitar: already requirements for resiliency oin MS-PW document, so if you want to apply to single segment as well Stewart: please give feedback on this section. Solutions for PW Security - Yaakov Stein (yaakov_s@rad.com) ----------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-stein-pwe3-sec-req-00.txt Reviews issues discussed at IETF64. This is in draft-stein-PWE3... Here are a few solution ideas: - Control protocol does not specify authentication. - Use MD5 signature option - Authentication TLV for initialization. This uses a shared key, which might be easier to distribute. Could use the two together. At the packet layer: - PW label is the only identifier - CW sequence number can be used for DoS attack Solution: add optional authentication field between control word and payload. Lightweight option: 32 bit CW extension Heavyweight option: 64 or 128 bit CW extension But this enables a DoS attack if you do it in software Encryption: - ECB mode on sequence number + payload, or - Generate per-packet key based on secret key and sequence number Dave McDyson: read through this. I wouldn't support another requirements document. One addition is to refer to L3VPN (RFC41111 for security , and RFC4381). State of the art is separation. Similar issues in other protocols. Would like to see more alignment. Need to reference layer 3 VPN work to see what requirements and solutions are. Yaakov: definitely can take a look at it. Dave: you are assuming the providers PE has been compromised. Let's not have PW unique. Danny: should also consider abstracting MS-PW issues to single segments. Yakov Rekhter: Why is MD5 not sufficient? Yaakov Stein: people are worried that MD5 is not unique. Other issue is that it may be considered too heavy. Could add something just covering initializing. Yakov Rekhter: MD5 implemented for many years. Yet to hear any vendor complain that its hard to implement. Yaakov Stein: Does anyone have MD5 on PW signaling? 2 vendors Yakov Rekhter: why not IPSec? Yaakov Stein: these aren't IP packets. So would need a version for something similar. Yakov Rekhter: can you use IKE? Yaakov Stein: yes. But up to working group. Don O'Connor: why not use Ethernet encryption? e.g. MAC Sec over PW for Ethernet attachment circuits. Yaakov: is it sufficient to use native service security? there a re two types of DoS attacks that can cause this. Danny: need to take form L2VPN/L3VPN. If you are interested, contact the chairs or Yaakov. MS-PW OAM - Yang Yang (healthinghearts@huawei.com) -------------------------------------------------- http://www.ietf.org/internet-drafts/draft-dong-pwe3-mspw-oam-02.txt Shows update from version 1. - Reserve only 1 bit in CV type for MS-OAM PW OAM should be detached from control plane: add fault notification (FDI/RDI) to message format. Suggests using fault notification functions in BFD. Misconnection detection at S-PE. Define a new OAM PDU for misconnection monitoring. Next step: add performance monitoring ??: Why did you add FDI and RDI? Yang: RDI is used for reverse fault notification. Don O'Connor: what if you wan to monitor a few segments of a 3 segment PW?. Ethernet OAM can do this. Yang: not sure if you PWs can handle many levels. Don O'Connor: should be more general and do ME levels. ??: what do you mean by PM? Yang: are planning to monitor latency etc with OAM packets. Peter Busschbach: you said that BFD does not work for misconnection. BFD and LSP-Ping provide this. BFD has a discriminator identification, but this is locally significant. Peter Busschbach: when you set up BFD session, you establish connectivity IDs. This is not local. You don;t need another solution. Yang: you need a management plan for this. Yaakov Stein: do you mean CW only in OAM packets, or regular packets? Yang: on data packets Yaakov Stein: not enough bits. This is the 3rd mention of PW performance. Rahul Aggarwal: there is a draft in the BFD group which describes how BFD should be used for MPLS LSPs. Is that not sufficient to cover the cases? Yang: yes. BFD has no function for FDI. Rahul Aggarwal: take this up in BFD working group. Stewart: that has to be done there. Dinesh Mohan: Intention is to do it in VCCV, which uses CW as channel. Is there an intention to use other types e.g. router alert? George Swallow: BFD does have ability to do FDI now. This is a bit obscure: Concatenated Channel Down. We should add an RDI. Rahul Aggarwal: if you want some small changes, the BFD working group is the place for that. Stewart: need to resolve what's happening with the group. Danny: get with Dave , Nabil etc and see if requirements are already covered. ??: Do we need a requirement? Danny: we need to say here is the requirement and why it is an issue George Swallow: want to extend it everywhere we can... router aler will work in MS, but there are some issues in getting TTL to work. Peter Busschbach: we already have two solutions for RDI: BFD and PW status. SO should not invent new solutions. Danny: please take to the list. GID Protection - Yang Yang (healthinghearts@huawei.com) ------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-zhang-pwe3-gid-app-00.txt Addresses issue when multiple PWs fail on a link. It is more efficient to protect whole group. Cannot use tunnel protection for MS-PW. Per-PW PW protection consumes BW because it uses continuity checks on each PW For a group, could have just one OAM channel per group Shows tunnel switching mode: tunnel switched at S-PE. Danny: how does this relate to Ping's draft? Ping Pan: Seems to use AGI. We can talk offline, because it looks like 1:n Yang: AGI could be used, but this is generic. Don't define specific procedures. Danny: saw quite a few people had read it.Please provide comments to the list. Routing Area Requirements ------------------------- Danny: RFC1264 routing area requirements may apply to PWE3. If you are concerned with this, might want to comment.