IETF
pwe3
pwe3@jabber.ietf.org
Thursday, 29 March 2012< ^ >
Room Configuration

GMT+0
[06:36:38] Andy Malis joins the room
[06:36:48] <Andy Malis> Opening the PWE3 jabber room in Paris
[06:37:18] David Sinicrope joins the room
[06:37:44] <David Sinicrope> I'm here, really!
[06:38:12] David Sinicrope leaves the room
[06:38:15] David Sinicrope joins the room
[06:39:27] <David Sinicrope> Adium isn't keeping up
[06:45:44] dtaht joins the room
[06:47:47] scott.mansfield joins the room
[06:48:41] <David Sinicrope> Hi Scott
[06:48:53] <scott.mansfield> hello
[06:49:00] <scott.mansfield> welcome to PWE3
[06:51:33] <scott.mansfield> If anyone who is remote needs an intervention, I can take it to the microphone
[06:56:09] <scott.mansfield> Chairs: Matthew Bocci and Andy Malis
[06:56:35] jpc joins the room
[06:57:36] YJS joins the room
[06:58:37] <scott.mansfield> Is there anyone on jabber that is not physically in the room in Paris?
[06:58:56] Stewart Bryant joins the room
[07:01:54] <YJS> Matthew welcoming us
[07:02:01] <YJS> Andy is here as well
[07:02:05] <YJS> Dave sectrarying
[07:02:29] <YJS> agenda - Tom doesn't have slides ...
[07:02:33] <YJS> no comments on agenda
[07:02:52] <YJS> goal slide needs updating
[07:03:00] <YJS> done with packet PW
[07:03:33] <YJS> some milestones were pushed back to be more realistic
[07:03:43] <YJS> info will be updated on web page
[07:03:52] <YJS> no new RFCs since last IETF
[07:04:05] <YJS> draft-ietf-pwe3-fc-encap in RFC editor queue
[07:04:19] <YJS> draft-ietf-pwe3-static-pw-status held in rfc-ed queue with miss-ref
[07:04:27] <YJS> draft is back in Auth48
[07:04:44] <YJS> Stewart : still one author needs to sign off (Luca)
[07:04:54] <YJS> need to encourage him to do that soon
[07:05:28] <YJS> PW redundancy drafts (draft-ietf-pwe3-redundancy and redundancy-bit) with IESG
[07:05:45] <YJS> packet PW approved but IESG comments
[07:06:05] <YJS> Stewart (as author) : there were some comments, will respin after meeting
[07:06:15] <YJS> after that signed off straight away
[07:06:31] <YJS> Ethernet OAM interworking (new version in process)
[07:06:50] <YJS> VCCV implementation survey was last called and shpeherd (minor) comments need to be fixed
[07:07:11] <YJS> P2MP requirements - AD has concerns
[07:07:28] <YJS> Stewart : authors approach not good - mixes architecture and reqs
[07:07:36] <YJS> lacks clarity of other arch docs
[07:08:09] <YJS> authors have incorporated p2p wholesale and confusingly made changes
[07:08:20] <YJS> MPLS P2MP doc is much cleaner
[07:08:55] <YJS> SS and MS P2MP can be written much better. hopes chairs can find someone to write such a doc
[07:09:02] <YJS> otherwise will hold up other work
[07:09:11] <YJS> Matthew : chairs looking for volunteers
[07:09:31] <YJS> Andy : not asking. NEED someone!
[07:09:55] <YJS> Matthew : will also need to cover OAM for P2MP case
[07:10:04] <YJS> Stewart : discussed in MPLS-TP version
[07:10:22] <YJS> without OAM shouldn't considering doing this at all
[07:10:35] <YJS> draft-ietf-pwe3-dynamic-ms-pw had ER TLV and procedures split off into draft-ietf-pwe3-mspw-er
[07:10:46] <YJS> both drafts should be LC'ed soon
[07:10:54] <YJS> draft-ietf-pwe3-ldp-aii-reachability waiting for dynamic MS-PW
[07:11:10] <YJS> draft-ietf-pwe3-cbit-negotiation - ready ?
[07:11:11] <YJS> yes
[07:11:23] <YJS> same with draft-ietf-pwe3-iccp
[07:11:32] <YJS> same with draft-ietf-pwe3-status-reduction
[07:11:42] <YJS> Andy : anyone in room think they are not ready ?
[07:12:07] <YJS> Daniel : need more detail for iccp draft
[07:12:22] <YJS> draft-ietf-pwe3-oam-config needs scoping vs. new draft VCCV for GAL (on agenda)
[07:12:34] <YJS> new WG draft VCCV-for gal
[07:12:39] <YJS> lead in to Tom's talk
[07:12:48] <YJS> Tom Nadeau - VCCV for GAL (draft-ietf-pwe3-vccv-for-gal)
[07:13:04] <YJS> doesn't have slides, just need to discuss a few issues
[07:13:13] <YJS> new draft was based on feedback from Nick's survey
[07:13:22] <YJS> simplify modes for interop
[07:13:44] <YJS> bring down to one mode with CW and one without (Type 4)
[07:14:01] <YJS> questions - what to do with the other mode?
[07:14:56] <YJS> 2 options : don't address in this doc (do a bis) just new GAL type
[07:15:00] <YJS> or do
[07:15:55] <David Sinicrope> YJS: agree with looking at what to do with other modes.
[07:16:10] <David Sinicrope> cant remove old modes because too much that depends on them out there
[07:16:18] <YJS> Y(J)S at mike - leave this draft with Type 4
[07:16:22] <YJS> Nick : agrees
[07:16:36] <YJS> Tom : how to we address the old modes ?
[07:18:44] <YJS> Y(J)S at mike - there is a lot of non-TP stuff out there
[07:18:50] <YJS> please separate CP from data plane
[07:19:07] <YJS> Carlos : right approach put changes into a 5085bis draft
[07:19:23] <YJS> agrees with Yaakov that can't remove modes completely
[07:20:13] <YJS> Tom : even if capability not advertised, can syslog
[07:20:31] <YJS> Carlos : with CW will look at first nibble anyway
[07:21:05] <YJS> Nick : not sure will resolve this now
[07:21:24] <YJS> survey was a snapshot, but utilization of CW vs others was roughly even
[07:22:15] <YJS> Carlos : agree with Nick
[07:22:32] <YJS> can radically simplify the CP
[07:22:50] <YJS> Tom: augment capability advertisement for "VCCV-2"
[07:24:57] <YJS> Greg : if deprecate TTL case, then don't react to TTL expiry ?
[07:26:08] <YJS> Missed a few remarks at mike (because I was at mike)
[07:28:09] <YJS> Y(J)S : leave the old modes for another 5 years and Nick will do another survey
[07:28:13] <YJS> Nick says he is willing
[07:28:28] <YJS> Nick : TTL expiry can't be dropped, CW is used
[07:29:18] <YJS> Tom : carriers can specify in RFP which modes they want, NOT "5085"
[07:30:56] <YJS> Dave : BBF has deprecated RA
[07:31:08] <YJS> Dave A : other SDOs have as well
[07:31:39] <YJS> Himanshu : deprecating TTL ? agree with Yaakov's concern. NEED TTL expiry
[07:33:42] <YJS> Matthew : raise hand if want to remove RA mode
[07:34:05] <YJS> 20 hands for depraction and none against
[07:34:53] <YJS> Y(J)S volunteers to co-author 5085-bis
[07:35:02] <YJS> Greg Mirsky - VCCV MPLS-TP CV Capability advertisement (draft-mirsky-mpls-tp-cv-adv)
[07:35:17] <YJS> straightforward - a PE can support multiple CV Types
[07:35:21] <YJS> 6 bits adequate
[07:35:41] <YJS> RFC 6428 introduces Coordinated and Independent modes of CV monitoring
[07:35:56] <YJS> combination of 2 modes with 2 functional use of BFD message (FD only or FD + status) requires 4 CV Types !
[07:36:34] <YJS> need extension of CV advertisement\
[07:36:45] <YJS> suggestion : VCCV Extended CV Advertisement sub-TLV
[07:36:55] <YJS> 0x01 independent mode for PW FD
0x02 independent mode for PW FD + status signaling
0x04 coordinated mode for PW FD
0x08 coordinated mode for PW FD + status signaling
[07:37:04] <YJS> 8 bits still reserved
[07:37:27] <YJS> that's it.
[07:37:45] <YJS> Carlos : 2 questions _ is this mandatory ?
[07:37:46] <YJS> no
[07:37:59] <YJS> extended VCCV not mandatory, but if use need VCCV subTLV
[07:38:04] <YJS> Carlos : perfect
[07:38:20] <YJS> 2) will have same problem later (bit mask format)
[07:38:29] <YJS> Greg : still 8 bits reserved!
[07:40:11] <YJS> Y(J)S proposed calling VCCV - PWCC !
[07:40:15] <YJS> (laughter)
[07:40:32] <YJS> but it makes more sense
[07:41:31] <YJS> Matthew : lot of MPLS-TP OAM could potentially be used for PW
[07:42:22] <YJS> ? from ZTE : sorry couldn't understand what he said
[07:42:40] <YJS> Greg did understand and answered
[07:42:51] <YJS> Lizhong Jin - static pseudowire configuration checking using GACh Advertisement Protocol
[07:42:59] <YJS> (draft-jc-pwe3-mpls-tp-static-checking)
[07:43:08] <YJS> with Ran Chen
[07:43:10] <YJS> uses GAP
[07:43:40] <YJS> motivation: manual configuration of static PW in MPLS-TP requires configuring many parameters at two PE
[07:43:49] <YJS> parameters must be consistent, if mis-matched hard to trouble shoot
[07:44:02] <YJS> introduce an application of GACh advertisement Protocol (GAP)
[07:44:13] <YJS> to transfer PW configuration parameters
[07:44:45] <YJS> PE can now check PW parameter consistency
[07:46:21] <YJS> Loa : if you really want to understand GAP need to read 2 drafts (co-authored by Matthew) 1 is TP specific other generic
[07:46:39] <YJS> Matthew - this draft is for static PWs, so not necessarily TP
[07:46:49] <YJS> Lizhong - currently TP, but can be generic
[07:46:59] <YJS> Loa : then please remove "TP"
[07:47:58] <YJS> Dan Frost : just need MPLS draft, not the TP one, to understand this
[07:48:41] <YJS> giving overview of how PE processes
[07:48:55] <YJS> this is a checking tool, not a signalling protocol
[07:49:20] <YJS> showing protocol timeline (aren't you happy that this is not ASCII art?)
[07:49:54] <YJS> Configuration check process
[07:50:03] <YJS> check CW and PW type - must be the same on both sides
[07:50:10] <YJS> check interface parameters
[07:50:19] <YJS> check In&Out PW label
[07:50:46] <YJS> report problems
[07:51:09] <YJS> response to feedback received : only for static PW, this is not an alternative to LDP signaling, just checking
[07:51:17] <YJS> only uses FEC 129 since TP only uses it
[07:53:32] <YJS> Y(J)S at mike : 1) do we require CW same in both directions 2) what is FEC 129 for static PW ?
[07:53:43] <YJS> Matthew : FEC-129 "like" (no FEC)
[07:54:02] <YJS> missed some discussion (was at mike)
[07:54:47] <YJS> someone from IPfusion : was is frequency of GAP messages ?
[07:55:24] <YJS> answer : send messages immediately upon finishing check, no specific timer
[07:55:40] <YJS> suggested times in draft
[07:56:16] <YJS> Matthew as coauthor of GAP draft : like PE generic parameter advertisement (section layer, not per-PW layer)
[07:56:32] <YJS> since 10s of thousands of PWs need to be careful with timers
[07:59:10] <YJS> Stewart : PWE control protocol assures that CW consistent in both directions (not support wins)
[07:59:38] <YJS> Greg is back, doc was presented at CCAMP
[07:59:47] <YJS> LDP Extensions for Lock Instruct and Loopback of Pseudowire in MPLS-TP
[07:59:54] <YJS> (draft-dong-pwe3-mpls-tp-li-lb)
[08:00:14] <YJS> with Jie Dong and Mach Chen
[08:00:21] <YJS> background inband/NMS based LI & LB is in RFC 6435
[08:00:43] <YJS> proposing 2 new flags "K" and "B"
[08:01:07] <YJS> Lock is MEP to MEP
[08:01:15] <YJS> S-PEs can update status of PW
[08:01:32] <YJS> Loopback instruction
[08:01:41] <YJS> MEP to MIP or MEP to MEP
[08:01:51] <YJS> Loopback on S-PE: target node is identified using S-PE TLV
[08:02:14] <YJS> straightforward procedures
[08:02:59] <YJS> Sami : when writing 6435 agreed that OAM relies on LSPs
[08:03:12] <YJS> Greg : problem is that OAM does not allow putting into LB
[08:03:42] <YJS> Sami : originally was such a command, but was taken out because of security concerns
[08:03:50] <YJS> Greg : this is only a proposal
[08:05:06] <YJS> processing of OAM
[08:05:22] <YJS> Y(J)S : standard feature - why do it different here
[08:05:28] <YJS> Himanshu agrees with Sami
[08:06:11] <YJS> Sami Boutros - Signaling Root-Initiated p2mp PWs using LDP
[08:06:24] <YJS> (draft-ietf-pwe3-p2mp-pw)
[08:06:48] <YJS> draft describes how to signal P2MP PW tree with LDP
[08:06:54] <YJS> version 4 of this draft
[08:07:07] <YJS> refreshing of draft and what has changed
[08:07:19] <YJS> draft describes how to signal P2MP PW tree with LDP
[08:07:26] <YJS> supports unidi P2MP traffic from Root-PE to Leaf-PE(s)
[08:07:35] <YJS> with optional P2P traffic from Leaf-PE to Root-PE
[08:07:42] <YJS> supports RSVP-TE or mLDP transport LSPs
[08:07:50] <YJS> introduces new FECs, TLVs, and LDP capabilities
[08:07:57] <YJS> Label Mapping Message for Upstream-Assigned Label
[08:08:05] <YJS> mandatory message sent by Root-PE to all Leaf-PE(s)
[08:08:14] <YJS> contains: P2MP Upstream PW FEC element, interface parameters TLV, group ID TLV
[08:08:22] <YJS> transport LSP sub-TLV, label TLV for the upstream-assigned label for root to leaf traffic
[08:08:32] <YJS> Label Mapping Message for Downstream-Assigned Label
[08:08:40] <YJS> optional message sent by a Root-PE to A Leaf-PE
[08:09:05] <YJS> just in case need to send traffic back to root
[08:09:10] <YJS> contains: P2P Downstream PW FEC element
[08:09:16] <YJS> label TLV for the downstream-assigned label for leaf to root traffic
[08:09:24] <YJS> Selective Tree Interface Parameter Sub-TLV
[08:09:31] <YJS> new Interface Parameter sub-TLV to support selective multicast traffic
[08:09:40] <YJS> also new P2MP PW LDP Capability
[08:09:54] <YJS> P2MP capabile LSR MUST recognize both upstream and downstream FEC elements in binding message
[08:10:04] <YJS> Typed Wildcard FEC Format
[08:10:11] <YJS> another addition to ver 4
[08:10:27] <YJS> also wild card FEC draft in LC
[08:10:29] <YJS> RFC5918 typed wildcard can be for FEC 128 or 129
[08:10:40] <YJS> here we extend "Type" field to include "P2MP PW Upstream" and "P2P PW Downstream" types
[08:11:05] <YJS> as well as add an additional "PMSI Tunnel Type" (=FF for wildcard)
[08:11:24] <YJS> need a bunch of new IANA Allocations
[08:13:10] <YJS> Andy reminding about bluesheets ...
[08:13:34] <YJS> Liu Guoman - P2MP PW protection for MPLS-TP
[08:13:48] <YJS> (draft-liu-pwe3-mpls-tp-p2mp-pw-protection)
[08:14:13] <YJS> motivation : must be able to provide protection for MPLS-TP w/o IP forwarding
[08:14:22] <YJS> and TP data plane should be independent of CP
[08:14:39] <YJS> for p2mp bad to set up return path for each branch
[08:14:48] <YJS> here provide protection for p2mp service without IP forwarding, CP, or return path
[08:14:58] <YJS> showing diagram with 2 egress PEs and node between them, and 2 CEs
[08:16:59] <YJS> needs three egress PEs to customer network
[08:17:06] <YJS> showing forwarding PW failure, egress PE failure, egress AC failure
[08:18:26] <YJS> showing status message format
[08:19:10] <YJS> next steps - get comments and update draft
[08:22:22] <YJS> Matthew : this is for TP, and P2MP isn't yet addressed there
[08:22:46] <YJS> probably have to wait for MPLS WG to work on this first
[08:23:40] <YJS> Loa : if you have P2MP TP LSPs, then PW problem is solved, only need to signal to the end node
[08:23:53] <YJS> source-endpoint signaling is easy
[08:24:04] <YJS> but if this is based on P2MP LSPs, then harder
[08:24:15] <YJS> Matthew : this is a CPless protection mechanism
[08:24:31] <YJS> Loa : static PWs on TP is out of scope till now
[08:24:41] <YJS> Matthew : need to wait
[08:25:20] <YJS> Loa : one more comment, sometimes have drafts which are out of scope, but OK to publish them to say we might need to sove in the future
[08:25:35] <YJS> Matthew : sure - will keep as an individual draft
[08:25:47] <YJS> Qilei Wang - LDP Extensions for PW Transfer in MPLS-TP
[08:25:56] <YJS> (draft-bao-pwe3-pw-transfer)
[08:26:07] <YJS> with Muliu Tao, Lizhong Jin, Xihua Fu, Ruiquan Jing, Xiaoli Huo
[08:26:18] <YJS> changes in new version : ER-TLV added to carry PW path info
[08:26:25] <YJS> added clarification about transfer failure
[08:26:43] <YJS> LDP extensions : PW Transfer Capability TLV, PW Ownership Transfer TLV, SP-PE TLV or ER-TLV
[08:27:20] <YJS> advantages as compared to MBB (make before break)
[08:27:28] <YJS> FEC label binding not modified
[08:27:34] <YJS> PW LSP binding not modified
[08:28:40] <YJS> showing MP to CP transfer Procedure (SS)
[08:28:56] <YJS> now showing MP to CP transfer Procedure (MS)
[08:29:14] <YJS> T-PEs perform procedures in MP2CP SS-PW, encode PW path into SP-PE TLV or ER-TLV
[08:29:45] <YJS> S-PE creates PW LDP signaling state in CP, decodes SP-PE TLV or ER-TLV to find the next hop
[08:29:55] <YJS> forward Label Mapping message to the next hop
[08:30:03] <YJS> CP to MP Transfer Procedure :
[08:30:10] <YJS> T-PEs send CP2MP PW transfer notification message
[08:30:16] <YJS> delete T-LDP session (local policy)
[08:30:23] <YJS> S-PEs forward notification message, deletes T-LDP session
[08:30:54] <YJS> next will refine according to feedback
[08:31:44] <YJS> Ping - LDP extensions for explicit PW to transport LSP mapping
[08:31:53] <YJS> (draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp)
[08:32:02] <YJS> with Mach Chen, Wei Cao, Attila Takacs
[08:32:05] dtaht leaves the room
[08:32:11] <YJS> motivation : desirable to aggregate user circuits since easier to manage (protection)
[08:33:05] <YJS> the diagram is datacenter scenario
[08:33:12] <YJS> note delay issues
[08:33:18] <YJS> gives predictable service parameters and can deliver over multiple transport domains
[08:33:32] <YJS> problems : it's a PW to LSP binding problem
[08:33:43] <YJS> forward and reverse PWs -> co-routed LSPs
[08:34:11] <YJS> need to support MS PWs (FEC 129)
[08:34:35] <YJS> issues : PEs locally place PWs in unidi LSPs - easy to do manually for one direction
[08:34:51] <YJS> hard to manage for bidi LSP binding - MS is a nightmare
[08:35:13] <YJS> showing solution for single hop (strict mode)
[08:35:40] <YJS> optional TLV asking other side "I am going to use LSP XYZ, will you accept it ?"
[08:35:49] <YJS> other side can accept or reject
[08:35:59] <YJS> one exchange will be enough to map
[08:36:32] <YJS> most critical point : solution for MS (strict mode)
[08:36:40] <YJS> setup segment 1 forward and reverse in one PSN and similarly for segment 2
[08:36:48] <YJS> S-PE will remember PW and LSP info
[08:37:32] <YJS> protocol extensions : PSN tunnel binding TLV, IPv4 tunnel sub-TLV
[08:37:39] <YJS> (current proposal only)
[08:37:56] <YJS> changes in this version (5th revision!) - new abstract and intro, editorial
[08:38:11] <YJS> trying to make minimal impact to existing procedures
[08:38:22] <YJS> this is a real-life problem - large volume
[08:38:47] <YJS> community suggested to change procedures to withdraw binding
[08:39:04] <YJS> objective - make it easy to implement
[08:39:04] <YJS> need better explanation of FEC 128 (for SS-PW) and 129 (for SS and MS)
[08:39:28] <YJS> may support 128 for backward compatibility
[08:39:38] <YJS> gong forward - this is a real problem. asks to adopt
[08:40:04] <YJS> Himanshu : good draft, this is missing functionality
[08:40:45] <YJS> PW has unsolicited liberal, do you have steps to renegotiate binding ?
[08:41:22] <YJS> 2) takes away freedom to map to a suitable PSN, because need to renegotiate if current PSN not OK
[08:41:57] <YJS> Ping : 2nd q : don't want to take away from existing implementation, but also need to support this case
[08:42:16] <YJS> so this is an optional TLV. if was not in original advert, then do as today
[08:42:36] <YJS> 1st question - no answer yet
[08:43:00] <YJS> Andy : do respin and ask list to make a WG doc
[08:43:11] <YJS> Yimin Shen - PW endpoint fast failure protection
[08:43:19] <YJS> (draft-shen-pwe3-endpoint-fast-protection)
[08:43:25] <YJS> with Rahul and Wim
[08:43:39] <YJS> recap : desirable to protect (locally repair) every link and node
[08:44:18] <YJS> egress AC + PE and S-PE are unprotected
[08:44:26] <YJS> global repair is slow since driven by ingress CE/PE depending on CP convergence
[08:44:43] <YJS> this draft proposes local repair with restoration in 10s of msec
[08:44:51] <YJS> based on upstream label assignment + multihoming + redundant PWs
[08:45:00] <YJS> supports LDP for SS and MS PWs
[08:45:11] <YJS> explaining egress AC failure - bypass LSP set up to protection egress PE
[08:45:40] <YJS> protecting egress PE learns working PW's label
[08:45:52] <YJS> local repair by sending packets to protection egress PE
[08:46:17] <YJS> PE4 (protection) uses context specific label space
[08:46:27] <YJS> packet will have 2 labels
[08:46:46] <YJS> egress PE failure - PLR is PH (similar to previous case but PH to protection egress PE)
[08:46:54] <YJS> S-PE failure - PLR is PH of previous segment
[08:48:10] <YJS> updates in rev 1: added S-PE protection, FEC128/129, IPv6 context ID, co-located and centralized models, IGP advertisement of context ID
[08:49:02] <YJS> simplified path computation, global and local revertive modes
[08:49:31] <YJS> asks to adopt as WG draft (it's in good sape)
[08:49:46] <YJS> Andy asking for comments
[08:50:05] <YJS> Yimin Shen : this is only local repair
[08:50:31] <YJS> Greg : from diagram you do have PW redundancy and on top of that preprovisioned local repair
[08:50:36] <YJS> is this not overkill ?\
[08:50:50] <YJS> answer : look at egress AC filaure diagram
[08:51:44] <YJS> see that we need backup PW fro CE1 - CE2 traffic (and in both directions)
[08:51:52] <YJS> Greg : stable or transit state ?
[08:52:13] <YJS> Yimin : may be only for a certain amount of time
[08:52:27] <YJS> Greg : LDP session will not be affected if only AC failure
[08:52:35] <YJS> Yimin : depends on implementation
[08:52:56] <YJS> in diagram of PE failure after PE2 fails LDP sessions affected
[08:53:18] <YJS> Greg : operational task is complex
[08:54:05] <YJS> need to coordinate timeouts of local and end-end protection
[08:54:12] <YJS> Matthew : same as other forms of protection
[08:54:31] <YJS> Greg : if FRR and end-end may not be operationally sound
[08:54:52] <YJS> someone from Huawei - there is another draft that may solve this problem
[08:56:57] <YJS> someone from Ericsson - similar to IP FRR
[08:57:18] <YJS> Yimin : local repair is same for any technology
[08:57:56] <YJS> could use LDP or RSVP bypass
[08:58:29] <YJS> Sami : PLR has transport label and PW label underneath, doesn't need to add something ?
[08:58:44] <YJS> Yimin : PE2 tells PE4 of label
[08:59:25] <YJS> bypass LSP label is context specific non-reserved label
[08:59:35] <YJS> needs to be signalled
[09:00:03] <YJS> Lou Berger : 1) creating PW protection overlaid over several control maehcanisms ?
[09:00:20] <YJS> will take advantage of redundant PW
[09:01:02] <YJS> Lou : bundling PW and underlying control! we have done a lot of work to separate the LSP and PW CPs
[09:02:00] <YJS> Lou : this makes it worse, since PW protection needs to be bundled into LSP protection
[09:02:33] <YJS> Yimin : this helps with PW protection until slower LSP protection kicks in
[09:04:44] <YJS> someone from Alcatel : similar to L2VPN local repair
[09:04:56] <YJS> (supporting this approach)
[09:06:05] <YJS> Sri - how many additional labels needed ?
[09:06:12] <YJS> Yimin : double number of labels
[09:06:37] <YJS> and 2 lookups !
[09:06:49] <YJS> Sri - need to mention, this is substantial overhead
[09:07:03] <YJS> Sri - need link state IGP ?
[09:07:08] <YJS> Yimin - yes
[09:07:14] <YJS> need OSPF or IS-IS
[09:07:45] <YJS> Himanshu - PW BFD OAM will continue to work, but you want it to fail
[09:08:15] <YJS> Yimin : VCCV BFD may fail, if continues to work then OK since traffic continues
[09:08:53] <YJS> Jon : OAM packets to PE4 will be lost
[09:10:21] <YJS> someone from Cisco : struggling to understand, dual homing protocol, what happens to return traffic ?
[09:10:48] <YJS> for simple case need to handle from CE perspective
[09:11:00] <YJS> Yimin : this is active/active too
[09:11:12] <YJS> value is same as traditional FRR
[09:13:22] <YJS> discussion continuing, but I don't hear anything new
[09:14:22] <YJS> George S : how does PLR differentiate between PE2 failure and link failure ?
[09:14:45] <YJS> the node upstream from PLR may repair
[09:14:58] <YJS> Yimin " global repair may come afterwards, and that's OK
[09:16:39] <YJS> George : then, may have flipping back and forther between PE4 and PE2
[09:19:18] <YJS> Andy : need to continue discussion on list before considering to progress as WG doc
[09:19:22] Stewart Bryant leaves the room
[09:19:23] <YJS> end of agenda
[09:19:31] scott.mansfield leaves the room
[09:19:56] David Sinicrope leaves the room
[09:21:00] <YJS> nothing else - nice to see that everyone had coffee before session
[09:21:08] Andy Malis leaves the room
[09:21:30] YJS leaves the room
[09:25:43] jpc leaves the room
[10:17:27] dtaht joins the room
[10:31:29] dtaht leaves the room
[11:18:25] Stewart Bryant joins the room
[12:58:22] Stewart Bryant leaves the room
[13:20:05] Stewart Bryant joins the room
[15:12:44] Stewart Bryant leaves the room
[15:43:03] dtaht joins the room
[15:49:13] Stewart Bryant joins the room
[17:42:48] Stewart Bryant leaves the room
[19:33:12] dtaht leaves the room
[21:39:25] Stewart Bryant joins the room
[21:42:51] Stewart Bryant leaves the room
[21:43:16] Stewart Bryant joins the room
[22:23:54] Stewart Bryant leaves the room