[03:00:07] Matt Gillies joins the room [03:02:30] Matt Gillies leaves the room [05:21:15] sriganeshkini joins the room [05:21:21] sriganeshkini leaves the room [06:13:30] Matt Bocci joins the room [06:15:49] Matt Bocci leaves the room [06:16:24] Matt Bocci joins the room [06:17:51] Matt Bocci leaves the room [06:20:26] Matt Bocci joins the room [06:57:27] Carlos joins the room [06:58:51] David Sinicrope joins the room [07:00:00] cpignata joins the room [07:00:13] ndelregno joins the room [07:03:06] YJS joins the room [07:03:15] sorry for being late ... [07:03:33] Andy went through the agenda - one comment from David S [07:03:46] Matthew doing the status review [07:06:22] adrianfarrel joins the room [07:07:49] YJS made some some remarks on draft status [07:08:20] Luca talked at mike about comments he had received off-list on ICCP [07:09:40] correction - Luca was talking about eth-oam-iwk [07:10:06] Stewart talked at mike about fc-encap [07:11:23] next - Mick on survey results [07:12:35] implementation survey was done about encaps, CWs, and VCCV types [07:13:58] giheron@cisco.com joins the room [07:15:47] going over the survey questions [07:17:13] rarcea joins the room [07:18:38] going over results - respondents (diverse), locations [07:21:28] which encaps ? (YJS asked if 1:1 mode is correct) [07:21:41] number of PWs of each encap [07:23:23] which VCCV channel used - CW is high [07:24:45] rarcea leaves the room [07:24:53] use of CW - most support although not all in use [07:25:28] remarks question (in draft was cleansed) [07:25:41] findings - PWs are widely deployed [07:25:48] Eth is most used [07:26:07] some inconsistencies in responses [07:26:44] only 17 responses, but >243K PWs [07:27:11] about 50% using CW in Ethernet [07:28:35] Nick continuing with VCCV channel usage [07:28:59] recommended CC order type 1 3 2 [07:29:27] proposes moving to WG draft [07:32:27] giheron@cisco.com leaves the room [07:33:42] Andy - should move some of our RFCs to draft standard [07:34:01] Luca - if we change RFCs it can not remove modes, just editing [07:34:09] Himanshu at mike [07:34:45] Nick continuing on mandatory CW [07:35:03] draft proposes making CW mandatory for all encaps [07:35:44] problem is with ATM N:1 [07:36:00] will update based on survey results [07:37:46] YJS - what does this mean ? all new deployments must use CW ? [07:38:01] Nick - all new deployments must support, not necessarily use [07:38:35] George - instead - non-use of CW is deprecated [07:39:33] Luca - WG can agree that new encaps MUST use CW [07:39:49] but updating old RFCs not consistent with survey [07:40:39] can't mandate to SPs to deploy something ! [07:40:50] Himanshu - agree with Luca [07:43:19] Rob- in draft says SHOULD not MUST be mandatory Nick - I'll check [07:44:22] Luca (for Tom N) on unified control channel [07:44:33] remove limitation on GAL for ACh [07:45:10] draft describes new VCCV channel with new codepoint (basically new VCCV version) [07:45:30] supercedes 5085 [07:46:22] operational issue - too many CC + CV types (to test, for vendor to answer queries from SP) [07:47:44] actually was thought about 10 years ago, but MPLS chairs said it would be difficult to get a reserved label [07:48:29] VCCV type 4 - since higher mode number it will be used [07:48:41] will work with or without CW [07:49:39] if you want OAM to fate share then use CW, if not use GAL [07:49:55] easier to see label=13 [07:50:41] want to make this mandatory [07:51:23] capability advertisement in control protocol must match the C-bit [07:52:31] Shane Amante joins the room [07:52:50] logistics issues (will obsolete 5085 ?) [07:53:36] Rob - how is this unifying ? opposite of going towards CW mandatory [07:54:27] actually easier to trap a label than match CW [07:55:50] Sasha - already asked on list, how is this consistent with 6073 making tpe 3 mandatory for MS-PWs ? [07:56:18] please list how many RFCs need to be updated [07:56:32] Luca - don't need to update RFCs, this is an addition [07:56:50] the other modes will automatically fall out of favor [07:57:31] Curtis - made comments on list - GAL should be under PW label [07:58:46] Sri - same point about order to GAL and PW label [07:59:22] 2nd question - intermediate node for multipath [07:59:38] Luca - with multipath need CW [08:01:21] Giles joins the room [08:04:24] Curtis - could use TTL and GAL at the same time [08:04:31] (for tracert) [08:05:21] Sami (for Lishong) on CW negotiation [08:05:31] status - will be adopted as WG draft [08:06:07] updates 4447 to allow re-enable CW use after disabled [08:06:24] showing diagram of how it works [08:07:15] if already negotiated NOT using CW, when becomes prefered it does label withdrawal which triggers reset CW negotiation [08:09:54] Luca - MPLS WG must review this as it involves LDP changes [08:10:21] Andy - it is on the agenda for MPLS [08:10:32] Shane Amante leaves the room [08:10:59] next - Sri on efficient packet PW for IP/MPLS [08:11:35] was presented last time - received comments and updated [08:12:16] service model basedon VPWS [08:12:45] there is another packet PW draft, this is an optimization [08:13:25] note - here a single L2 is mapped to an AC, so not good for QinQ [08:14:07] if CW is used, CW is used to signal if the packet is IP, MPLS or "other" [08:14:21] if IP, MPLS then remove L2 header [08:15:15] if no CW, then need to encapsulate the packet in IP/MPLS, if not IP then use GRE with nonroutable IP address [08:15:54] this will ensure no re-order if intermedite nodes hash on IP headers [08:17:30] conclusion - save BW, less fragmentation, enables flow-based implementations to ECMP well [08:19:53] Sasha - question to group - what is wrong with GRE PW that can carry anything ? [08:20:06] Stewart Bryant joins the room [08:22:26] Mahesh Jethanandani joins the room [08:23:22] Luca asks Stewart to tell about the status of packet PW [08:23:49] it turns out to be harder to make packet PW than expected [08:24:15] this draft is also unclear - especially it there are IP and non-IP packets [08:24:36] Sri - this is not an alternative, just an enhancement to the existing draft [08:24:59] Luca - how do you support IS-IS ? Sri - single label [08:26:01] Stewart - update on packet PW draft, text needs update [08:26:40] asks what HW people think about this [08:27:12] is the complexity worth the efficiency increase ? [08:27:45] Sri - HW people say it is not too hard [08:28:40] ? from Broadcom - what are we solving here ? [08:29:47] the efficiency increase is not worth the complexity increase [08:30:09] Himanshu - how to you put the L2 headers back ? [08:30:22] Sri - the addresses need to be learned [08:30:31] all in draft [08:31:03] George - Ethernet is future-proofed [08:32:06] Matthew - quick feel of room - most people do NOT want to proceed with this draft (will take to list) [08:32:24] Sri continuing with VCCV [08:33:30] Multi-path is essential for load-balancing and redundancy but requires flow-label which may not be available [08:33:57] need a CC which is inband for any flow [08:34:18] solution - extend type 3 (TTL expiry) [08:34:41] Shane Amante joins the room [08:34:48] Shane Amante leaves the room [08:34:55] if VCCV is always at a fixed offset (known to both sides) [08:35:43] define a pseudoflow header of fixed size (64B) [08:35:51] describing format [08:36:50] Sven Huster joins the room [08:38:42] next - me [08:39:19] (PW usage nits) [08:39:54] RFC 4447 came before RFC 5885 [08:40:47] RFC5885 was afraid to change the status TLV wording in 4447 (about doing label withdraw if you can't support it). So the wording gets very complex re PW control protocol vs BFD [08:41:02] OAM has to fate share with user data [08:41:53] the issue is that PW control protocol is out of band. So while there may be magic cases where it's more reliable than BFD it's better to use BFD. [08:42:08] so why not say that if you run BFD then have BFD notify us of problems with PW status [08:42:09] ndelregno leaves the room [08:43:37] problem is that in 4447 you have to either use PW status or label withdraw. Proposal is to update 4447 to say that if you support VCCV-BFD then you can lie about status TLV support, and use BFD codes instead [08:44:11] Sasha (general question). how does all this supposed to interact with the static PW status messages? [08:44:41] Yakov - this is specifically for when you use LDP. The whole point is that if you're static then you can use BFD already. [08:45:45] Yakov - if you want to use static signalling that's fine [08:45:51] Sasha - can't we converge to a single method [08:46:11] Sasha - we have enough mess already with all the VCCV types. [08:46:24] Yakov - I'm not adding modes. I'm trying to resolve existing ones. [08:47:50] Luca - the problem here is when you have a control protocol. The reason 5885 didn't update 4447 is because in practical deployments IP works fine. MPLS sometimes goes down. So you'll have situations where an RSVP-TE LSP dies but there's still IP connectivity so LDP still works (i.e. the CP is more reliable than the DP). [08:48:05] Yaakov. If the return path dies you lose your BFD heartbeats so you'll drop the PW [08:48:36] Luca - we're only talking about the path down messages. We have to choose one of the protocols. we chose the CP not the DP as it was more reliable (TCP over IP, not BFD over MPLS) [08:49:29] Yaakov - I'm just giving people an option to use the static message/BFD. not saying we should obsolete the existing mechanism. the issue is the text of 4447 says that if you negotiate non-use of status TLV then you MUST use label withdraw. [08:49:58] Luca/Yaakov agree that as long as there's only one status method per PWE we're good. [08:50:17] Rob Rennison - don't want to lose use of the redundancy bits. [08:50:24] Yaakov - if you want that use status messages [08:51:09] Yaakov - thread on list about the CC types. We have 3 today. more being proposed (e.g. GAL, ESP - as in Extra Sensory Perception....) [08:52:09] Yaakov - 5085 says you can only use one CC type per CW and not recommended to change as that could cause interop problems. but what do you do if you get a message you don't expect?4385 mechanism MUST be supported (ACH *is* identified by CW nibble). [08:52:35] (that's one argument). But RA is an essential part of MPLS (supposedly). [08:52:59] and TTL expiry is kind of essential as any expired packet MUST go for special processing [08:53:11] so whatever you negotiated you need to support all 3 - so why signal CC? [08:54:20] so what do we do on statically configured PWEs? or what if we negotiated one type and receive another? and do both directions have to use the same type????? [08:55:25] giles.heron@gmail.com joins the room [08:55:39] Giles leaves the room [08:55:44] Carlos - agree you should accept anything (liberal in what you receive) [08:55:52] Yaakov - so is there any reason to signal it at all? [08:56:50] Luca - looking at all IETF RFCs there's always logical nits. but the common understanding tends to be in one direction. We can't specify every possibility to death. e.g. the router alert stuff doesn't apply to PWEs. [08:57:20] Luca - router alert has to be there for IP [08:57:43] Yaakov - even the MPLS over IP RFC says you have to support all MPLS procedures (incl therefore router alert) [08:58:13] Yaakov. Minor nit re CW usage with LDP [08:58:56] RFC goes to great trouble to ensure that CW usage is symmetric. but the L2VPN BGP case allows asymmetry. [08:59:11] is it a general principle that all PWs must be symmetric re CW usage? [09:00:06] actually seen it happen that an implementation changed CW usage during the life of a PWE [09:00:59] I'm back [09:01:02] Daniel Cohn. Extension to LDP VPLS for E-Tree (two PW soln) [09:01:17] issue is need to distinguish root and leaf PWE [09:02:28] so the solution is to handle the pair as a single interface in the VSI [09:03:32] root frames go to root PWE, leaf to leaf PWE. But frames from leaf PWE or leaf AC don't get sent to other leaf ACs [09:04:50] next steps - AGI for FEC 129, considering root PWE == Ethernet PWE etc. [09:05:23] luca - suggesting an interface parameter instead of PW type. [09:05:45] Daniel - we'll consider that [09:06:03] Luca - also you can use BGP AD to figure this out (but that belongs in L2VPN) [09:06:20] Next up is Sami. [09:06:31] (typed wildcard FEC) [09:07:02] Sven Huster leaves the room [09:07:21] extension is to used typed wildcard messages. various applications: [09:08:01] 1) consistency checks between two LSRs. So request bindings from other LSR and check them. [09:08:24] 2) graceful PW shutdown. So send wildcard withdraw for one application instead of one by one withdraw [09:08:39] Luca - so why not use the group ID? [09:09:06] Sami - issue is that group ID doesn't cover all bindings. [09:10:04] next draft for Sami. MAC address withdraw over static PW. [09:10:12] so extend OAM to do MAC withdraw [09:10:54] won't refresh messages forever, and mandating an ACK [09:11:39] adrianfarrel leaves the room [09:13:42] rolf.winter joins the room [09:13:46] Luca - I wanted the static PW status system to stay away from re-creating LDP in the control channel. Keep it Simple! [09:14:52] Sasha - it is important to support for static PWs ! [09:15:15] however, can send MAC withdrawal and status in same message ? [09:15:35] Sami - yes, can. This is a mode for MAC withdrawal [09:16:08] Giles - want to ask SPs if want to do statis VPLS ! [09:16:29] Rob - on static side would be spoke, applicability is not great [09:17:15] Sami - next draft. PW stitching with static segments [09:17:47] extension to segmented PWE [09:19:03] Luca - aggregating status messages for PWE [09:20:04] want to detect PWE restarts. But also found that we need to detect PE misconfiguration (useful in LDP and need this for static) [09:20:43] so simple and extensible refresh reduction for GAL/Gach [09:22:15] so this is one OAM channel for a whole bunch of PWEs [09:24:32] Yaakov - this is what I suggested back in CEOP (pre PWE3) days. can I refresh my draft from 1999? [09:24:41] Luca - but yeah, this is TP, not MPLS. So fate-sharing is by definition [09:25:22] Mach Chen. [09:25:37] issue around PWs binding to different PSN tunnels. no way to force co-routing. [09:26:54] 2 extensions to PW signalling. Make both ends bind to the same bidirectional LSP, or 2 co-routed unidirectional LSPs [09:27:40] asking for WG adoption [09:27:45] Matt - will take that to the list [09:28:11] Faizal Zhang [09:28:17] MPLS-TP PW OAM [09:29:14] new OAM type "MPLS-TP PW OAM". [09:29:24] various sub TLVs [09:29:31] Mahesh Jethanandani leaves the room [09:29:43] review of the configuration procedures [09:30:52] rolf.winter leaves the room [09:30:54] need to keep this aligned to MPLS-TP work. Again requesting WG adoption. [09:30:57] Matt - will take to list [09:31:05] Andy - we're done :) [09:31:08] giles.heron@gmail.com leaves the room [09:31:20] Stewart Bryant leaves the room [09:31:53] David Sinicrope leaves the room [09:32:20] Matt Bocci leaves the room [09:39:25] YJS leaves the room [10:57:30] Stewart Bryant joins the room [11:05:43] ndelregno joins the room [11:22:49] ndelregno leaves the room [11:37:10] cpignata leaves the room [11:37:11] Carlos leaves the room [12:01:52] adrianfarrel joins the room [12:03:20] adrianfarrel leaves the room [12:34:47] Stewart Bryant leaves the room [12:37:43] Stewart Bryant joins the room [13:45:19] Stewart Bryant leaves the room [15:30:59] Stewart Bryant joins the room [16:27:06] Stewart Bryant leaves the room [16:35:21] Stewart Bryant joins the room [17:11:29] Stewart Bryant leaves the room [21:33:25] Stewart Bryant joins the room [21:57:25] Stewart Bryant leaves the room [21:57:34] Stewart Bryant joins the room [22:30:02] Stewart Bryant leaves the room