PWE3: TUESDAY, July 11, 2006 - 1740-1840 & 1850-1950 ---------------------------------------------------- CHAIRS: Danny McPherson & Stewart Bryant Minutes: Y(J)S Presentations available at http://pwe3.tcb.net Agenda bashing - Danny ---------------------- WG Status and Update - Chairs ------------------------------------- 8 RFCs: 3916 (PWE reqs), 3985 (arch), 4197 (TDM reqs), 4385 (cw), 4446 (IANA), 4447 (control), 4448 (Ethernet), 4553 (SAToP) 5 in RFC editor's queue : ATM (waiting for announce), FCS (blocked by l2tpext-ethernet), frag, frame relay, hdlc TDMoIP, CESoPSN, SONET and cell transport sent to IESG just before meeting This completes the phase I set of documents. MIBs - need serious review! are we ready for LC ? ATM and SAToP MIBs expired (need?), we need a volunteer to write a frame relay PW MIB MS-PW reqs - ready for LC are any of the others ready for LC? wildcard and VCCV need updates. for reference: L2TPv3 has 2 RFCs (4349 - hdlc, 4454 - atm) 1 in RFC editor queue (fr), 1 at IESG (Ethernet) We crucially need to address congestion (will discuss later). VCCV Extension for Ethernet OAM - Dinesh Mohan (mohand@nortel.com) http://www.ietf.org/internet-drafts/draft-mohan-pwe3-vccv-eth-00.txt -------------------------------------------------------------------- Proposes a new VCCV payload type based on Ethernet OAM joint work with large group of vendors and carriers background: Ethernet can be the PSN for PW to run over (see e.g. TRILL, GELS) also PWs over Ethernet basically the same as over MPLS MS-PWs can extend across MPLS PSN and Ethernet PSN segments Need different types of OAM for full solution - end-to-end OAM, AC OAM, VCCV OAM. VCCV provides platform for PW layer OAM presently 3 ways to distinguish VCCV packet from user packet (CW, router alert, TTL=1) and 3 OAM PDU types (ICMP, LSP-ping, BFD). We can define a new PDU type based on Ethernet OAM (Y.1731, 802.1ag) Rationale: strong functionality and extensively specified (would need to augment BFD) Already implemented if Ethernet PSN 8 hierarchical levels defined - needed for MS-PW Need to define a new CV type in VCCV draft and reference existing work in ITU/IEEE May need an appendix to answer questions brought up on list Can address implications for MS-PWs in MS-PW drafts Yaakov - need code point for PWACH (right now only IPv4 and IPv6) Sasha - slide 5 shows BFD packet control packet and not BFD echo packet note: 2 redundant MAC addresses also sent several questions to list, would like answers Luca - 4447 has status messaging - why do we need anything more? Dinesh - MPLS is not necessarily the tunnel here, Ethernet PSN Stewart - in that case out of scope Dinesh - Y.1731 has higher functionality than BFD Luca - don't need OAM here at all - PWE control status is sufficient Don O - a major advantage is that it reduces number of redundant OAM flows, better for SPs, also this is not restricted to Eth PSNs Stewart - proponents need to clarify advantages on list before continuing do we need anything in VCCV draft other than IANA codepoints? Dinesh - no, everything else OK Stewart - so needn't hold up VCCV draft, follow up to list VCCV Extensions for Segmented Pseudo-Wire - Mustapha Aissaoui (mustapha.aissaoui@alcatel.com) http://www.ietf.org/internet-drafts/draft-hart-pwe3-segmented-pw-vccv-00.txt ---------------------------------------------------------------------------- draft describes a method for extension of VCCV to MS-PW with both ping and trace of PW FEC. Such method should be backward compatible with VCCV in SS-PW (CW, etc) Just add new VCCV subTLV and new VCCV CW with TTL field Operational principles: T-PE and S-PE negotiate use of CW for VCCV end-to-end S-PE does not pass other CC types, so need CW! Data plane: PW FEC ping T-PE sends VCCV packet with high TTL S-PE does outer label pop, TTL-- new outer label push no requirement for S-PE to look at CW egress T-PE inspects and responds to the VCCV packet PW FEC trace T-PE sends VCCV packet with determined TTL S-PE does outer label pop TTL-- if TTL=0 S-PE checks if VCCV and inspects / responds Design considerations Each S-PE needs to TTL-- Problem: if LSR between S-PE and T-PE manipulates TTL VCCV then may go to wrong S-PE Authors request feedback. Sasha - why can't router alert work? Mustapha - no real problem (although TTL obviously can't work), but we decided to limit combinations Don O - Y.1731 can already handle MS-PWs, and needn't define new mechanism Mustapha - here we don't assume the service is Ethernet Dinesh - concerns with use of TTL, e.g. what about point-to-multipoint? Mustapha - PWE hasn't dealt with point-to-multipoint PWs! Danny - point-to-multipoint implicitly out of charter Dinesh - should consider and be pragmatic when going forward Mustapha - valid concern but shouldn't stop all work because of possible future directions in any case the important point is compatibility with SS-PW VCCV Dinesh - haven't seen framework for management expectations - what about >2 OAM layers ? Y.1731 method is less restrictive Mustapha - yes, this method is restricted to cases presently considered by PWE Danny - at some point you will want this to become a WG item? Mustapha - want to work with coauthors, will take to list VCCV-BFD Issues - Tom Nadeau (tnadeau@cisco.com) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-10.txt ----------------------------------------------------------------- (Tom Nadeau's flight was cancelled and couldn't make it back to Montreal) Control protocol has status messages and VCCV has a conflicting mechanism What if they don't agree (e.g. inband message comes faster)? Text on VCCV capability advertisement is contradictory, suggest to change to read: if (LDP DOWN and BFD is UP) or (LDP UP and BFD DOWN) then DOWN only BOTH UP is UP Mustapha - addressed in OAM message mapping draft there are several faults, could be AC up, etc. Peter B - wording in message mapping draft eliminates this problem Luca - this was just an example - there is a general logic problem that needs to be solved. Propose new text for VCCV draft saying logically OR the BFD and LDP status messages. Monique - need to make consistent with message mapping draft Stewart - OAM message mapping won't block (incidentally - needs to divide references into normative and informative) Another issue is the BFD mode presently using UDP/IP encapsulation This requires redundant lookups, is confusing and could be used for attacks Propose removing UDP/IP from BFD mode Yaakov - additional mode or instead of present mode? Luca - instead of present mode Sasha - this refers to generic BFD draft - what about echo packet (not defined there) ? Need additional channel types since UDP ports are needed ! George - this was meant to run in demand mode, and not echo mode Rahul - there is a draft for BFD in MPLS, this includes PWs as well need to make all these drafts consistent also, OAM protocols should take into account that data plane may be corrupted and misrouting Luca - there is a discriminator, and chance of match minimal Rahul - LSP ping uses UDP/IP also - why is BFD different? Mustapha - no consensus here - need existing behavior, so let's have 2 modes Peter B - echo mode is explicitly excluded here also inner IP addresses are not used for IP addressing in BFD proponents should be sure they understand how the OAM works PW Redundancy - Praveen Muley (Praveen.Muley@alcatel.com) Please see the draft posted to the list: draft-muley-pwe3-redundancy-00.txt Available at: http://pwe3.tcb.net/drafts/draft-muley-pwe3-redundancy-00.txt --------------------------------------------------------------------------- How many have seen the draft? (Sorry was sent in late) - not many have read! Set of redundant PWs configured between PE nodes for SS-PWs or between T-PE nodes for MS-PWs. Status bit needed in PWE control protocol to indicate active or standby for each PW in redundancy set. The draft describes scenarios where PW redundancy is needed Tunnel protection mechanisms are not sufficient when multi-homing a CE to multiple PEs or there is failure of S-PE in segmented pseudo-wire. Deal with end-to-end protection of pseudo-wire switchover to backup PW is at T- PE/PE only (no fast restoration at S-PE) T-PE/PE signals multiple pseudo-wires and indicates the choice of PW. Since PW is bi-directional, need synchronization of status at both end-points. PE/T-PE needs to indicate preferred PW path Solution - activity status bit defined to indicate active/standby (set means standby) Synchronization of status on ends helps in selecting active PW. Shows diagrams of scenarios (multi-homing CE with SS-PWs and MS-PWs) Requests feedback from WG, and would like to become WG item. Peter B - what AC dual-homing protocol do you intend to use? Praveen - not important Peter B - ITU defining APS for Ethernet at service layer, isn't this enough? Praveen - carriers have asked for separation of switch directions Ben NJ - do we need mesh of PWs across core for this to work? Praveen - not really needed, but carriers sometimes want Ben NJ - but this necessitates twice as much state without more protection Vach K - we had requests from SPs NOT to move from PE to PE unless needed (less network disturbance) so shouldn't have "cross" PWs Ali S - dual homing protocol may not work between CE and PE need decision to be made by PE too, so APS model doesn't work avoid problem completely by anchoring at egress PE Praveen - still would want differentiation between active and standby state Ali S - why? two PWs, either can be used Mustapha - Praveen is assuming APS on one side Danny - take to list Ronen S - do you want BW conservation (not waste resources for both PWs) OSPF external protection solves this problem PW Protection - Ping Pan (ppan@hammerheadsystems.com) Please see the draft available at: http://pwe3.tcb.net/drafts/draft-pan-pwe3-protection-03.txt ----------------------------------------------------------- Third revision of draft - we initially thought it was a simple problem Since last IETF learned that protection may mean different things - end-to-end, congestion relief, multi-homing, or SS-PW/MS-PW protection Someone should write a use-case document first Key changes in version 3 - preference TLV and protection TLV removed 1:N protection option (useless) more text on processing PW path protection need a reference ID otherwise S-PE doesn't know how to forward identify working and protection PWs (CAC-desired and fate-sharing) Congestion control Set preference level and control pre-emption Other issues multi-homed PW protection (just heard discussion in previous talk) PW segment protection Next steps - PW pre-emption and path protection need to iron out other issues work out use-cases Can make this a WG document? Danny - this is now in the new charter can we unite these two drafts? Generic PWs - Danny McPherson - (danny@tcb.net) ----------------------------------------------- We didn't add this to the new charter, due to not being ready but we want now to add a new charter item. What do we want to do? Want to carry MPLS, IPv4, IPv6, compressed header, IS-IS, another PW, etc IN A SINGLE PW Concern from MPLS WG on the MPLS over MPLS issue. Topology example - connect two PEs interchanging IP, IS-IS, MPLS and OAM over PW Goals - Decouple control protocol from SP signaling (don't want to interop LDP!) Distinguish MPLS in PW from "classical MPLS" (not allowed to have two S=1 packets) Are there implications of CW and ECMP ? MPLS relies on IP signaling - can't ignore bootstraping functions We tried not to define a solution yet, but ... CW required? SS-PW and MS-PW? L2VPN requirements (IPLS) Extraneous considerations Who else is working on this ITU, MPLS forum UNI, L2TPv3 (already have IP PW!), L2VPN ? Payload considerations Self-describing payload Registry for ID (PPP, Ethertype, new) Can we accept as WG item? Need applicability/requirements ID, then arch/framework Shahram D - do we need a PID? Danny - yes Luca - let's charter MPLS v2 ! this is not a PW, it is a new MPLS Danny - we have engaged George in order to avoid problems here Stewart - some of this work has been requested, e.g. IP PW for IPLS Sasha - IP PW type described in 4447 Luca - yes, we already have an IP PW Don O - this is not MPLS v2. If not done here it will be done at ITU, as SPs need. Yakov R - If somewhere else - is this T-MPLS ? We need a clearly written requirements statement. George - enough to say what SPs can not do today with the present infrastructure Yakov - just because someone wants this, doesn't mean IETF needs to do it Don O - not only T-MPLS, but Y.1415 is relevant Kireeti K - "GMPLS only" - GMPLS includes packet LSPs Need to consider "MPLS service", i.e. give LSP to end customer Stewart - need a group to work on requirements document - volunteers contact Danny Congestion Issues - Stewart Bryant (stbryant@cisco.com) http://www.ietf.org/internet-drafts/draft-rosen-pwe3-congestion-03.txt ---------------------------------------------------------------------- When PWE was formed it was put in the transport area because of congestion worries. Can't claim that PWs would always run over TE networks and there are counter examples today (e.g. TDM PWs over Internet) "anything that we define - someone will run over the public Internet" Charter states - end-user deployed PW needs congestion avoidance mechanisms Requirements RFC completely ignores congestion TDM requirements RFC does discuss congestion, says need to detect and shutdown PW, and mentions instability of bringing up and down RFC 3985 (architecture) has text (shown in slide!) but doesn't give mechanism other than mentioning TCP-friendly rate control. Most encap drafts only point to 3985! TDM drafts introduce special considerations, since can't do very much ATM draft had a discuss focused on absence of congestion mechanism resolved by chairs promising to work on this. Only real attempt at addressing PW congestion has been draft-rosen-pwe3- congestion. Draft died but recently resurrected Basic idea - when traffic starts getting lost then drop rate and when gets through rate should climb It has been said that we do not need this mechanism One argument is - no since other than TDM the content is actually IP payload Another argument - congestion impossible on our links (implausible) Existing endsystem solutions (e.g. TCP) ruled out Need router implementation - no acks, no complex state machine, limit HW/SW interactions How to detect congestion? Sequence numbers - but many implementations don't use CWs (due to high rates) Periodic VCCV packets Control plane Tunnel level method how do we respond to loss - AIMD (like TCP) or softer rate control ? TCP friendly slow response but maybe better TDM PWs - can we adjust rates? (e.g. select channels) Proposal Adopt draft-rosen as WG draft Need framework as to the meaning of congestion in PW context Form a design team with PWE and transport experts David B with T11 liaison hat on - fiber channel PW people brought proposal to T11 and T11 returned to IETF some work with TFRC has been done Bob B - first need to distinguish flows in PW, some using TCP some not 2nd, TSV WG working on edge-to-edge congestion control with infrequent messages Danny - need happy medium between large effort and something that will be implemented Yakov R - change order - the first thing we need to do is to investigate the feasibility of having congestion control mechanisms at two layers - first at the layer of pseudo-wires, and second at the level of TCP, and document the interaction of these two congestion control mechanisms. Ping P - congestion has 2 parts - detection and retransmisson if need TCP then why not TCP/IP PSN ? Stewart - not fast enough Vach - can we keep up the charade until we have an RFC number for ATM draft? George - PW mechanisms can not push back on source - and buffering dangerous need system view Kireeti K - need to protect Internet from PWs, but also the other way around ITU T-MPLS Liaison Update - Stewart ----------------------------------- ITU SG15/12 sent a liaison to PWE3, MPLS and MFA regarding G.8110.1 (T-MPLS) IETF representatives attended the SG15/12 meeting in Ottawa (Stewart, Loa, Ross). ITU accepted essentially all the corrections PWE asked for response to MPLS WG will be discussed at MPLS WG session. ITU sent IETF an updated copy of G.8110.1 and requested that we respond with technical comments before August 1st (!) Please respond if important to you Loa - let's coordinate a unified IETF response Fibre Channel over MPLS - Ronen Solomon (ronens@corrigent.com) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-01.txt ------------------------------------------------------------------- Work done with KDDI - implemented and tested. Version 1 of the draft discusses congestion management This presentation will also cover Interworking between TFRC and LAPB Rate shaping Selective retransmission FC credit management Native service processing termination for Fibre Channel is handled by T11 PW termination is handled by PWE3 in IETF. FCoMPLS may be used in controlled and non-controlled environment (i.e. CIR and EIR specified) Rate adaptation uses TFRC rate equation Selective retransmission (SR-LAPB) mechanism (already used for FC over ATM) This indicates congestion conditions to the TFRC mechanism for throughput calculation. TFRC/LAPB interworking Rate shaping via TFRC to avoid traffic bursts Adapt to available BW Selective retransmission via LAPB FC credit manager (NSP function) encap L2 hdr PW hdr (outer + inner label + PW) FC frame (LAPB hdr + FC frame + CRC) Rate shaping RFC 3448 + adaptive rate shaper Assures minimum bandwidth guarantee (CIR) Interworks with LAPB Works in conjunction with SR Monitors SR frame loss Frame loss monitoring Selective retransmission Reuse mechanism described in T.11 FCoATM Reliable (sequencing + acks) Retransmissions 4 byte overhead Fixed window size Need new PW type for fiber channel port mode Wrap up - Danny --------------- Finished on time ! Good idea to have Yaakov take minutes. When he doesn't get to mike everything goes faster