[10:28:34] --- lllmartini has joined
[18:09:56] --- yjs has joined
[18:21:03] <yjs> Starting session
[18:21:26] <yjs> Danny - agenda is full
[18:21:42] <yjs> One new RFC 5003 (17 RFCs all together)
[18:21:51] --- kenichi has joined
[18:22:15] <yjs> Danny going through status of drafts
[18:23:42] --- cpignata has joined
[18:24:37] <yjs> Other items - protection and restoration issues (Muley) need progress
[18:24:59] <yjs> MPLS PW - do we want to work on this?
[18:25:17] <lllmartini> Yaakov , I think we can hear the audio just fine , maybe you can ID the person speaking ....
[18:25:20] <yjs> Multipoint PWs - also not sure work is required
[18:25:27] <lllmartini> Danny speaking now.
[18:25:51] <yjs> Luca - as usual I am documenting the items discussed for posterity
[18:26:29] <yjs> 1. Giles standing in for Tom N about to speak
[18:28:05] <yjs> BFD was split off of the VCCV draft, now separate draft
[18:28:38] <yjs> the draft has 4 CV types
[18:29:57] <yjs> <YJS> If Luca is listening in and the others in the jabber room are physically here, then I will only document the minimum
[18:31:36] <yjs> matthew up next
[18:32:19] <yjs> standing in for Marc Lasserre standing in for Marc on PW redundancy
[18:34:03] <yjs> showing slide explaining "request switchover"
[18:34:34] <yjs> T-PE1 communicating with T-PE2 with 3 S-PEs in between
[18:34:54] <yjs> draft muley up to version 02
[18:35:36] <yjs> <someone knocking on back door of room>
[18:35:49] <yjs> authors requesting to move to WG status
[18:35:57] <yjs> Dave M at mike
[18:36:09] <yjs> proposes requirements be settled first
[18:36:47] <yjs> also request cross-referencing other drafts, and explaining terminology
[18:36:59] <yjs> Stewart asks what alignment is required
[18:37:13] <yjs> Dave - IEEE protection, and possibly ITU
[18:37:35] <yjs> Matthew - that is part of requirements draft
[18:37:51] <yjs> Dave - the solution seems to rely on correct configuration
[18:38:27] <yjs> automatic identification of master and slave would be nice
[18:38:53] <yjs> Danny - are you volunteering to help ?
[18:39:03] <yjs> Dave - yes
[18:39:24] <yjs> Dave says he is happy that Luca is now working on this draft as well
[18:39:54] <lllmartini> hey ! , this is a very different document since the time i made that statement !
[18:39:56] <yjs> matthew now moving on to his presentation of PSN congestion status bit
[18:40:32] <yjs> Matthew: PWE3 needs to provide congestion handling mechanism
[18:41:04] <yjs> Talking about congestion of underlying PSN, PW needs to be TCP friendly
[18:41:37] <yjs> This new draft talks about how egress PE signaling ingress PE on congestion detection
[18:42:14] <yjs> control plane mechanism : reliable, scalable, avoids using scarce bits in PW header
[18:42:40] <yjs> Showing slides
[18:43:06] <yjs> egress PE2 detects congestion by packet loss/VCCV/ECN
[18:43:10] <lllmartini> Andy : there's a mouse running around the front of the room. It's hiding under the table that's holding up the screen.
[18:43:26] <yjs> it sends congestion status back to PE1, which applies control
[18:43:37] <yjs> Second case - MS-PW
[18:44:01] <yjs> T-PE2 sends message to S-PE which forwards to T-PE1
[18:44:53] <yjs> When congestion ceases - egress PE sends PW status with status bit cleared
[18:45:14] <yjs> need to avoid flapping (when resume it causes congestion again)
[18:45:25] <yjs> need to work details out
[18:45:44] <yjs> matthew asks for feedback to the list, and to move to WG draft
[18:45:57] <yjs> Stewart: need feedback from TSV area
[18:46:12] <yjs> since they are the ones that want it
[18:46:20] <yjs> Mark - have you asked them?
[18:46:25] <yjs> Stewart - not yet, will now
[18:46:52] <yjs> Mark T: In MS-PW case, can we get a broadcast storm?
[18:47:11] <yjs> Matthew - limited to one per T-PE
[18:47:35] <yjs> Stewart - only at the start
[18:48:00] <yjs> mark - let the transport people work on this
[18:49:21] <yjs> Shah: better to have transport parameter
[18:49:44] <yjs> Matthew - might be that only the ingress PE knows if the traffic is elastic
[18:51:05] <lllmartini> answer: the mitigation function is PW technology specific
[18:51:25] <yjs> Rob: do you indicate to source to increase policing?
[18:51:28] <yjs> Matthew: yes
[18:51:28] <lllmartini> it varies from shutting down a pw ( TDM ) to applying a policer
[18:51:50] <yjs> Danny: need feedback, make sure aligned with TSV (Allison)
[18:52:30] <yjs> next: Joerg on fat PWs
[18:52:51] <yjs> (small problem with PC)
[18:53:52] <yjs> Danny looking for slides on his laptop
[18:54:21] <yjs> still can't find the slides
[18:56:43] <yjs> Fat PWs - problem is load balancing
[18:57:24] <yjs> problem when BW of AC is same order to magnitude as trunk lines
[18:57:52] <yjs> deep packet inspection is difficult due to packet structure, and would be computationally expensive
[18:58:32] <yjs> next try was PW label range ("label block"), whereby several PW labels mapped to AC
[18:58:50] <yjs> showing diagram with 2 PWs (could be more, e.g. 16)
[18:58:57] <yjs> hash on PW label
[18:59:43] <yjs> showing format - header has ethernet + IP header + PW label, hashing to get transport label
[19:00:07] <yjs> final solution - new label after PW label, finer granularity
[19:00:30] <yjs> primary hashing based on load balancing label
[19:00:43] <yjs> need to pop 2 labels at PE
[19:01:01] <yjs> in either case need new TLVs for signalling
[19:01:23] <yjs> conclusion - need at least one solution to this problem
[19:01:44] <yjs> label range is easy to implement, lad balancing label solution is better since more generic
[19:02:13] <yjs> since not interoperable, should we choose one, or put both in one draft?
[19:03:06] <yjs> Stewart: since draft came out other operators have expressed interest
[19:03:25] <yjs> need to compare possible solutions
[19:03:38] <yjs> Ali: have you considered OAM issues?
[19:03:52] <lllmartini> Correction : only Level3 expressed interest
[19:04:03] <yjs> Stewart - discussed with Luca, majority interest is for IP
[19:04:25] <yjs> (operators expressed interest - DT and others on list in last 2 days)
[19:05:00] <yjs> Giles: customer's IGP is easy, SP IGP harder
[19:05:09] <yjs> Stewart: SP should self repair
[19:05:30] <yjs> Kireeti: answering a few questions
[19:05:44] <yjs> important problem, but may not need a draft
[19:06:00] <yjs> either solution can live with LSP ping as OAM
[19:09:57] <yjs> sorry to everyone - the network dropped here
[19:10:12] <yjs> george at mike
[19:10:22] <lllmartini> Audio feed is dead too
[19:10:39] <yjs> is the audio back?
[19:10:47] <lllmartini> yes
[19:10:50] <yjs> Stewart: authors want input from list
[19:11:08] <yjs> Giles: only a subset is being handled here
[19:11:47] <yjs> Stewart: IP case is the most urgent
[19:12:06] <yjs> Giles: but perhaps IP with tunnels hiding header is the most urgent
[19:12:47] <yjs> Andy D up next - on OSPF Extensions for Dynamic Multi-segment Pseudo Wires
[19:13:34] <yjs> updates on OSPF MS PW draft presented at Prague
[19:15:24] <yjs> changes based on comments - advertise AIIs in OSPF domains without T-LDP
[19:15:44] <yjs> opaque LSA mechanism to flood is algoruthm of choice
[19:16:08] <yjs> PW switching LSA carry AIIs attached at T-PEs or routable through S-PE
[19:16:19] <lllmartini> I worked on removing the parts that did not function properly in this draft - what is left is a simple opaque LSA mechanism to support distribution PW routing information as external information.
[19:16:33] <yjs> how routers learn AIIs to advertise is out of scope
[19:16:48] <yjs> showing diagram
[19:17:10] <yjs> (Luca - do you want me to comment at mike on what you are doing w/ respect to this draft?)
[19:17:36] <lllmartini> no.
[19:17:47] <lllmartini> this was just for the jebbar log
[19:18:02] <yjs> animation shows how information propagates from first area all the way to T-PE
[19:18:41] <yjs> asks adoption as WG draft, and proposes an IS-IS version too
[19:18:51] <yjs> this is also being proposed to OSPF WG
[19:19:29] <yjs> Danny: spoke with OSPF WG, need to determine where work needs to be done
[19:19:58] <yjs> Stewart: technical point - is there a plan to integrate path costs?
[19:20:15] <yjs> Andy: can include
[19:20:29] <yjs> Stewart: then this is becoming a full routing protocol - need to be careful
[19:20:48] <yjs> Stewart: there is work to be sure routing is not damaged by extra load
[19:21:25] <yjs> Andy: mechanism is very simple, and shouldn't overload the basic routing info
[19:21:44] <yjs> however, separation from basic routing info is possible
[19:21:56] <yjs> Stewart: the routing WGs need to decide
[19:22:00] <yjs> Raoul at mike
[19:22:22] <yjs> are you flooding customer state through the backhaul network?
[19:22:28] <yjs> This violates the VPN concept
[19:22:42] <yjs> Andy - not customer state info, this is summarized first
[19:23:06] <yjs> Raoul: T-PE would advertise AC info
[19:23:29] <yjs> Andy: could be, but not necessarily every entry
[19:23:46] <yjs> Matthew: just TLV saying "I'm here", not detailed AC info
[19:24:00] <yjs> Andy - like MW-PW mechanism
[19:24:39] <yjs> Raoul - you haven't specifically stated that customer state is NOT sent
[19:24:59] <yjs> Raoul - the only argument for using OSPF is that the routers are NOT running BGP?
[19:25:34] <yjs> Luca via Stewart : customer info is commonly distributed
[19:26:00] <yjs> Ali: in access network low cost network elements don't run BGP
[19:26:39] <yjs> Alex Z: about separation of resources in routing protocols
[19:27:26] <yjs> difference between IS-IS and OSPF on this
[19:27:47] <yjs> Danny - how many people interested?
[19:27:53] <yjs> small number of hands
[19:28:28] <yjs> Ali: need to discuss if single instance or multiple
[19:28:59] <yjs> Also may need to update PW architecture as P-nodes are no longer completely transparent
[19:29:16] <yjs> Stewart: isn't it the ASBRs, not the P nodes?
[19:29:24] <yjs> need to discuss
[19:29:48] <yjs> Danny: take to mailing list 1) should we do 2) where to do
[19:29:56] <lllmartini> nono , OSPF is just a transport protocol for the external routes
[19:29:59] <lllmartini> P nodes install no state !
[19:30:14] <yjs> next Frederic Jounay on Dynamic Update of PW parameters
[19:30:31] <lllmartini> haa yes ..
[19:30:44] <lllmartini> THe old argument from eric rosen
[19:31:13] <yjs> Fred: the important use case is CESoPSN PWs which are inflexible in BW
[19:31:38] <yjs> if need to add capacity, we need to update the PW parameters
[19:32:08] <yjs> (today we need a new PW, which would effect customers)
[19:32:58] <yjs> the solution is a new update mechanism which keeps the FEC, but distributes new parameters
[19:35:02] <yjs> going through the draft - I assume everyone knows this already
[19:35:18] <lllmartini> rfc4447: "Note that as the "interface parameter sub-TLV" is part of the FEC, the rules of LDP make it impossible to change the interface parameters once the pseudowire has been set up. Thus, the interface parameters field must not be used to pass information, such as status information, that may change during the life of the pseudowire. Optional parameter TLVs should be used for that purpose. "
[19:35:59] <yjs> (Yes, we know - otherwise a new draft wouldn't be needed)
[19:36:32] <yjs> (however, it IS a problem - can't take down a PW serving 1000s of users to add some BW!)
[19:38:09] <yjs> Fred showing a diagram illustrating the concept
[19:38:37] <lllmartini> You need a new notification message
[19:38:45] <lllmartini> same solution as for PW status
[19:39:36] <yjs> (that's basically what it is)
[19:41:11] <yjs> Stewart: this is a radical change in PW architecture - do we need a requirements doc?
[19:41:30] <yjs> hani : Shah did a draft like this a few years ago
[19:41:40] <cpignata> Yaakov, the draft proposes a new LDP TLV Type, right?
[19:42:39] <yjs> Stewart: let's gather requirements into a draft first
[19:43:31] <yjs> (yes, there is a new LDP TLV) Nitin at mike - if setup a new PW with make before break, do we need anything else?
[19:43:53] <yjs> Fred: this is also make before break - but slightly different method
[19:44:05] <yjs> Nitin: still not convinced that need anything new
[19:44:13] <yjs> Danny: need req doc
[19:44:34] <yjs> Fred still at mike - P2MP req doc
[19:45:08] <yjs> also previously presented at Prague, need charter update
[19:46:15] <yjs> proposes a unidirection P2MP service over PSN
[19:46:54] <cpignata> [someone mentioned in mpls today that there were too many new ldp tlv types] A notification with a new status code for updated int-param (like the pw status) can serve as well, w/o new ldp tlv, as Luca mentioned
[19:47:18] <yjs> new version introduced - VPMS (M for P2MP Muulticast)
[19:47:46] <yjs> (yes, I agree, and in fact had suggested this to Fred. Let's talk about it afterwards)
[19:48:17] <yjs> showing ASCII diagram for P2MP SS-PW
[19:50:06] <yjs> requests comments, and perhaps should propose to L2VPN
[19:50:18] <yjs> Stewart: is the WG interest in P2MP ?
[19:51:06] <yjs> matthew at mike
[19:51:20] <yjs> what is the difference between this an MP VPN solution?
[19:51:47] <yjs> Stewart - need clean differentiation between this and L2VPN work
[19:51:56] <lllmartini> why do ne need more then one PW per multicast tree ?
[19:52:06] --- histerrier has joined
[19:53:18] <yjs> (the issue is that want to do PWs over multicast infrastructure)
[19:53:44] <yjs> Rahul at mike on PMP PW Signaling and Auto-Discovery in L2VPNs
[19:53:56] <yjs> same problem as Fred described
[19:54:56] <yjs> motivations: L2 (encoded via L2 or IP) multicast service
[19:55:20] <yjs> this draft describes a L2 multicast VPN
[19:55:29] <yjs> there are sender sites and receiver sites
[19:55:38] --- histerrier has left
[19:56:09] <yjs> how do you build a VPN topology for this?
[19:56:34] <yjs> use BGP! there is a draft in L2VPN
[19:57:35] <yjs> need autodiscovery, but mechanisms already developed in L2VPN WG
[19:58:30] <yjs> signaling from root PE to leaf PEs, with upstream assigned labels
[19:59:21] <yjs> this draft only adds a few minor nits, instead focuses on how to deliver the service based on the techniques already proposed
[20:00:43] <yjs> here too, we need to decide where the work needs to be done
[20:01:12] <yjs> Ali at mike
[20:01:28] <yjs> autodiscovery and signaling are both handled by L2VPN
[20:02:28] <yjs> Stewart: authors of both drafts need to convince PWE that this work needs to be done here
[20:02:44] <yjs> Stewart up - updates on T-MPLS and the ITU
[20:03:44] <yjs> ITU is redefining IETF technologies in T-MPLS
[20:04:21] <yjs> IAB+IESG sent joint liaison to ITU-T expressing concern
[20:06:18] <yjs> 2 options were proposed - either work together or ITU needed to completely separate T-MPLS from MPLS
[20:07:07] <yjs> ITU management sent the liaison to SG15: Q12, Q11, Q9, and SG13Q5
[20:08:26] <yjs> An SG15Q12 meeting at Stuttgart with IETF participation discussed the liaison, and first option was selected
[20:08:49] <yjs> joint working team is to be formed
[20:10:10] <yjs> Ben NJ: what is proposed is not realistic - what will happen when inconsistencies are found?
[20:17:18] <yjs> Giles: what if OAM type is not agreed upon?
[20:17:49] <yjs> Stewart - depends on management of both organizations
[20:19:22] <yjs> Italo: comments on slides 1) OAM is of interest to both groups and not yet agreed between IETF and ITU
[20:19:46] <yjs> The crucial issue that don't break the Internet
[20:20:06] <yjs> 2) need to clarify the problems and propose other solutions
[20:20:16] <yjs> 3) still plenty of time to fix in Q14
[20:21:56] <yjs> Mark - tired of hearing about MPLS and T-MPLS in different domains.
[20:22:21] <yjs> strong message from IAB and IESG was if same Ethertype then need IETF approval
[20:22:58] <yjs> Kireeti: echo Ben's statement that agreement may be meaningless, CCAMP had similar agreement that didn't work
[20:23:36] <yjs> Monique: many liaisons explained extent of damage that may be made
[20:24:00] --- yjs has left
[20:26:30] --- kenichi has left
[20:26:46] --- cpignata has left
[20:26:46] --- cpignata has joined
[20:27:06] --- lllmartini has left
[20:29:19] --- cpignata has left: Logging off