[19:38:22] rjc joins the room [19:38:51] rjc is now known as rogerc [19:44:54] rogerc leaves the room [19:56:08] OH-86A9B220249B joins the room [20:01:07] YJS joins the room [20:04:21] test [20:04:51] starting ... [20:05:16] Stewart is agenda bashing [20:05:55] Matthew is going over the WG status [20:06:03] lllmartini joins the room [20:06:07] Danny is continuing to shepherd the MIB docs [20:06:25] shirleyhm joins the room [20:06:31] congestion frmwk still on hold (Stewart takes responsibility for not putting together a DT) [20:06:53] fiber channel doc was restructured and split into encap and flow-control drafts (need WGLC) [20:07:13] MPLS transport draft will be discussed today [20:07:23] MS-PW-arch recently completed LC [20:07:44] both chairs are on that draft, so David will arbitrate [20:08:10] going quickly through the other open docs (most on agenda) [20:09:07] cpignata joins the room [20:09:24] p2mp PWs - 2 solutions were proposed last time - asked for the authors to work together [20:09:36] source initiated draft is on the agenda [20:09:45] OAM MSG MAP (Peter B) [20:10:09] that was simply B and a ), but my jabber client changed it ! [20:10:28] started 6 years ago ! [20:11:30] last major gap was TDM section (thanks to YJS!) [20:12:21] need review of CEP section (Andy was volunteered for this) [20:13:47] minor changes - option to use PW status, terminology change (forward defect became transmit defect), some inaccuracies regarding segment ATM [20:13:55] author believe ready for WGLC [20:14:16] Matthew - we will issue a LC on the list\ [20:14:23] next - segmented PW [20:15:13] Luca - No significant change since -09 [20:15:29] in LC right now [20:16:00] lots of editorial changes, "defect" was changed to "fault" but can be changed back [20:16:18] clarified VCCV path trace procedures [20:16:32] Stewart sent an extensive review [20:16:47] section 9.4 was rewritten [20:18:06] proposals - terminology sync with ms-pw-arch doc, remove intro (since we have the arch doc!), remove L2TPv3 part [20:19:10] Matthew - don't need to remove intro, just reduce it [20:19:16] Luca and Stewart - OK [20:21:17] chairs : who is interested in L2TPv3 MS-PWs ? No-one [20:21:37] anyone interested in interworking L2TPv3 PWs and MPLS ones ? once again no hands up [20:22:11] Luca - don't want to block it. Stewart - most people would not be interested [20:22:43] I'm here :-) [20:22:44] Mark T - already written ! Carlos could review. Probably more work to remove than to keep [20:23:21] Tom N - might cause IESG problem to remove [20:23:28] Mark T - nonproblem - leave it. DECIDED [20:24:06] Next steps - finish processing LC comments, progress this together with MS-PW-arch doc [20:24:19] chairs agree to link the processing of the two [20:25:37] question from audience about 3 control channel types - how does the OAM work when each type has some limitation (require CWs, etc) [20:25:54] Luca - type 1 uses CW which is must be used for this type [20:26:11] type 3 uses TTL to get to a particular PE [20:26:52] type 2 (router alert label) is not supported since this was temporary solution and difficult to use for MS case [20:27:21] there was discussion about type 1 with TTL [20:28:26] next - Tom on Ethernet PWs over MPLS transport networks [20:28:40] this doc has been sitting around since MPLS-TP work started [20:29:23] document demonstrates that there is an existing IETF mechanism with known implementations that satisfies MPLS-TP requirements [20:30:00] without prejudicing MPLS-TP, WGLC ending - please review ! [20:30:14] Matthew - LC ends in 2 weeks [20:30:36] satoru.matsushima joins the room [20:30:40] chairs - it will be informational RFC [20:31:25] Andy Malis - Packet Pseudowire Encapsulation over an MPLS PSN [20:31:57] goal is to carry a packet service - intended for MPLS-TP which is mostly for router interconnection [20:32:17] there are many protocols going between two routers ! [20:32:43] this protocol allows isolation between the two networks [20:32:54] can be in regular MPLS, not just MPLS-TP [20:33:16] simplification - client LSR and server PE are co-located in one box [20:34:07] problem with slide [20:34:55] on a MAC the ppt comes up OK [20:36:01] showing where the problem arises - not when there is a physical wire carrying Ethernet [20:37:42] there are lots of protocols between routers - IS-IS packets, OAM, discovery, etc. [20:38:15] with PPP OR Ethernet connections this works, but can't do PPP to ethernet [20:39:01] we COULD use Ethernet encap, but that would add a lot of overhead, so instead we do a kind of PPP encap [20:39:17] not to mention the need to support ARP ! [20:40:51] showing packet format - after CW has 16bit PPP ID [20:41:24] since the virtual interface and the clients can go up and down, need to relay status across PW [20:41:57] Florin - don't you need a non-zero first nibble ? [20:42:06] Andy - no , this is the data part of the CW [20:42:41] someone - this has an encap and an architectural function - isn't it possible to decouple ? [20:43:01] Andy - would be more complex [20:43:57] Stewart - adjacency formation is more complex than you would think [20:44:23] Ronen S - what is the advantage as compare to Eth PW or PPP PW on virtual interface [20:44:36] Andy and Stewart - less overhead and less control plane [20:46:48] Andy - at 40G and 100G it is not practical to run an ATM stack [20:47:08] Kireeti - is this only for adjacency formation ? [20:47:14] Andy - and for transport [20:48:55] Kireeti - why waste 2 bytes - if less than 256 protocols than one byte enough [20:49:04] Andy - don't want a new registry [20:50:30] Greg M - UNI is router, after decap have MPLS w/o IP [20:50:45] Andy - anything that can go between routers [20:51:02] Greg - worth clairfying that it depends on what you are using [20:51:26] Andy - would like to test consensus [20:51:47] Matthew - who has read ? about 30 [20:52:06] of those who have read who agrees ? most of the 30 [20:52:52] next - Stewart fat PW [20:53:33] draft has been discussed several times. has been merged with the Vach draft. rewritten to include more technical detail [20:53:45] added applicability and intro material [20:53:48] OH-86A9B220249B leaves the room [20:54:04] applies equally to ECMP and LAG [20:54:24] showing stack, flow label > 15 (can't misinterpret as reserved label) [20:54:42] signaling - presence is signaled, but not value [20:55:05] also specify that no FL TLV means feature not supported [20:55:31] next version want to have symmetric situation only (not FL in one direction) [20:56:15] Kireeti - much harder to introduce label than to process at the other end (read S bit) [20:56:27] Stewart - the signaling is harder [20:58:16] consensus - symmetric (just put a useless label in the other direction) [20:58:50] Nick Slabakov joins the room [20:59:02] single VCCV session is sufficient OAM, VCCV at FL scales poorly [21:02:05] YJS - bad not to have VCCV on each path, since you will see loss instead of CC problem [21:02:31] Kireeti - it's OK since the core problems will be fixed, and the access problems will be caught [21:02:49] single large flow case is a problem [21:04:40] YJS and Luca discussed the large flow case at mike [21:05:08] need to check the TTL test (HW guys need to look at this) [21:06:39] YJS and Luca at mike about transitioning to making CW "less optional" [21:07:19] signficant interest in this draft, needn't wait for generalized (Kireeti) case [21:07:38] orthog to YJS PW bonding draft [21:07:48] Matthew - who has read ? 13 [21:08:15] who is in favor ? 9 [21:08:51] next - Yuji Kamite [21:08:58] standing in for Fred [21:09:11] LDP extensions for source initiated P2MP PW setup [21:10:18] reqs work - signaling req being done here, and service reqs in L2VPN [21:10:51] this draft uses LDP signaling and is source initiated [21:11:39] going over reqs addressed [21:14:13] showing relationship between AC and P2MP PW - one AC may serve one P2MP PW or multiple PWs [21:15:16] addressing with FEC 129 [21:16:24] in particular, same AGI and SAII as in generalized PWid, but now need 4B P2MP ID [21:17:10] new TAII leaf sub-TLV which carries the P2MP PW destination address [21:17:53] labels distributed upstream unsolicited, liberal retention mode [21:18:13] targetted hellos used for discovery [21:19:30] ingress PE initiates mapping, PHP must be disabled on PSN tunnel, 2 types of PSN tunnels P2MP-TE and MLDP [21:20:55] explaining signaling messages (in detail ...) [21:22:08] still explaining ... [21:23:00] open issues - MLDP FEC element is not yet defined [21:23:32] also, how is leaf directly attached to ingress PE handled ? [21:24:10] summary - source initiated method is preferable, new FEC129-based element introduced [21:24:30] asks for WG to back this approach [21:25:48] Greg M - mapping between AC and P2MP entities is different than in arch doc. [21:26:14] should always be 1 AC to 1 P2MP PW (there can be redundancy for backup) [21:27:27] Yuji - ingress AC uniquely maps to PW, but reliability requires multiple PWs [21:27:42] Greg - but then one active PW and one standby [21:27:54] Matthew - hwo many read the draft ? 8 [21:28:05] take to the list [21:29:21] Luca - ICCP for L2VPN PE redundancy [21:29:49] the idea is to define a generic interchassis communications channel [21:30:13] provides discovery, keepalive, failover, etc. - both boxes look like one! [21:30:36] this is done by a channel between the two PEs [21:31:06] lllmartini leaves the room: Replaced by new connection [21:31:06] lllmartini joins the room [21:31:38] updates - RG ID became a TLV (to be consistent with LDP design) [21:31:58] added support for specific ACs [21:32:10] added more detail to make implementable [21:32:30] there have been comments, and many people expressed interest in working on this [21:32:48] Stewart - how many read ? Lots , about 20 [21:33:01] how many want to adopt as WG draft ? 15 [21:33:12] confirm on list, but sounds like consensus [21:33:43] Vikas Puri - infiniband over MPLS [21:34:10] infiniband is a technology for connecting CPUs and I/O [21:34:28] designed around a p2p switched I/O fabric [21:35:27] it has high reliability, high performance, low latency, centralized management [21:35:43] it is an open industry standard, and SW stacks are available [21:36:11] infiniband does not provide WAN connectivity - which is what this draft tries to address [21:36:57] we want to connect islands of infiniband fabrics over PWs [21:37:10] need to encap infiniband PDUs inside PW [21:37:35] the draft is a port mode service [21:38:06] CW is required, and length field must be used when less than 64 B [21:39:02] also address DiffServ QoS, fault management, and congestion control (FECN bits) [21:40:07] Asks for comments and for acceptance as WG draft [21:40:50] Stewart - can packet loss of a standard MPLS network be withstood ? [21:41:51] Vikas - PW need only closely approximate IB service (which itself is lossless) [21:42:43] Luca - so still useful if PW has some loss ? [21:42:46] Vikas - yes [21:43:01] cpignata leaves the room [21:43:01] cpignata joins the room [21:43:29] Stewart - what about congestion caused by IB on PSN ? [21:43:47] Stewart - This was addressed in the FC draft [21:44:41] Vikas - IB has preset BW rates which can be signaled. We don't have all the answers yet. [21:45:12] Stewart - assume only run on a managed BW RSVP-TE service [21:46:00] pseudoport facing PW will determine the rate for the IB side [21:46:41] David B - the FC PW taught us what to do with fixed BW traffic [21:47:00] cpignata leaves the room: Logging off [21:47:56] Luca - if there is backpressure, then should use it [21:48:41] David B - need to do TE and dynamic reaction [21:49:07] Stewart - last question - is this a proposal of the IB forum ? [21:49:15] VIkas - no it is ours [21:49:41] Stewart - who read ? no-one [21:50:38] shirleyhm leaves the room [21:50:40] YJS going to present, so dropping off jabber [22:01:16] lllmartini leaves the room [22:04:08] satoru.matsushima leaves the room [22:11:38] YJS leaves the room [23:15:44] YJS joins the room [23:16:19] YJS leaves the room [23:23:08] fmcway joins the room [23:23:29] nick, do u have the pwe3 audio record, thanks [23:37:44] Nick Slabakov leaves the room