Layer 3 Virtual Private Networks (Internet Area) Friday, July 14, 2006 ======================= Chairs: Rick Wilder Ron Bonica Agenda: Minutes: Steven Blake (slblake@petri-meat.com) Chair (Ron) presents agenda /* Note: didn't catch names of Y and W. */ 09:00-09:10 Working Group Status - R. Bonica Document status Question on a document's desired track (which document?) - Eric Rosen: informational Proposal for MVPN MIB, went on back burner. Authors have asked to make it a wg draft (placeholder). Consensus call on draft-sidea (sp) Rahul ?: MIB is way off from the solution. 09:10-10:00 Multicast Solutions - E. Rosen draft-ietf-l3vpn-2547bis-mcast-02.txt draft-raggarwa-l3vpn-2547bis-mcast-bgp-02.txt MVPN update - progressing - some sites receive-only, some transmit-only Issues to discuss today - Eliminating (S,G,R) prunes from BGP control plane - reduces state and complexity - two alternatives: - 1. MSDP-based - each C-RP talke MSDP to a PE Comment Toerless Eckert: MSDP is only experimental - 2. Coordinated switch - CE switches to (S,G) Comment Toerless: reemphasize that we shouldn't depend on MSDP (took five years to realize it wouldn't work). Comment Yakov R: would it be better to use PIM register messages to get active sources? Comment Rahul Aggarwal: proposal uses MSDP from CE-PE, and BGP source actives from PE-P & PE-PE - both methods use BGP-based source active messages Comment Eric R: PIM was experimental for 10 years - Support for C-bidir trees (from enterprise) - assume unidirectional P-tunnels - PIM bi-dir has complex forwarding rules - choose one ingress PE for bidir tree - multi-AS C-bidir - Use of MP2MP P-LSPs - intra-AS tunnels - for every mcast flow - single ingress PE designated transmitter (have procedure for this) - really a matter of aggregating p2mp tunnels into an mp2mp tunnel - dependency on work-in-progress in MPLS wg Toerless: why do you need to identify where it is coming from? Eric R: which is downstream, which is upstream? If you don't, and there is not complete agreement as to the designated forwarder Toerless: sure, like LAN, not doing any strong RPF check in PIM, don't need to know the "l2 identify" of the device. Eric: PIM has 40 pages on selecting designated forwarder Toerless: Only matters during DF election. If this makes sense, it shouldn't only apply to MVPN. Eric: that was the original design choice, but there might be some period of time (during convergence) where two routers might think they are the DF. BGP procedures might not converge fast enough. Toerless: goes against IETF's decision for PIM standard Thomas ?: we are not relying on dataplane procedures to prevent multiple senders to sending downstream. Only works as soon as all downstream PEs have the same view of unicast routing. Definitely a need to identify the sender of the mcast traffic. Toerless: what about bidir PIM? Eric: Mcast tunnel? Will work that out. Y: PIM-SSM has check there already. Don't know why you have to do this in PIM-SSM case. Rahul: If you are using undir trees in the backbone, you already know the sender. Toerless: if using GRE tunnels, you already know the sender. - MP2MP LSPs aggregating segments of inter-AS tunnels - inter-AS tunnels always p2mp - inter-AS segments of inter-AS tunnels are therefore inherently p2mp. - would like to aggregate these within an AS Rahul Aggarwal presents: - New auto-discovery (AD) route types - S-PMSI AD route - Source Active AD route - used to advertise active source - C-Multicast routing protocol - C-multicast route dampening described (prunes, joins, leaf AD routes) - C-mcast route aggregation (via RR and ASBR) - Next steps - procedures for MSDP or PIM Anycast RP between C-RP and PE based scheme - procedures for using BGP or RSVP-TE as the PE-CE protocol for Carrier's Carrier model (for future study) 10:00-10:15 Reqs for MPLS Services Over L3VPN - Kenji Kumaki (KDDI) draft-kumaki-l3vpn-e2e-rsvp-te-reqts-01 - Motivation - robust MPLS services to customers - can offer e2e paths using LDP - can't offer e2e paths using RSVP extensions - offer CE-CE TE LSPs with guaranteed BW - want VRF instances per-customer to avoid security issues - customer can't join SP's routing/MPLS signaling domain - Reference model diagram - C-TE LSPs - P-TE LSPs (encapsulates C-TE LSPs) - Reqs - C-TE LSPs over BGP/MPLS IP-VPN (carrier's carrier & basic BGP/MPLS IP-VPN) - Changes from -00 - added author Raymond Zhang - changed problem statement - changed terminology - added admission control support - Other requirements? - Next actions - need wg feedback - request wg accept ID Andy Malis: premature to accept as wg document, need to discuss mor on the list Mark Townsley: engage L1VPN as well Kenji: motivation is l3vpn (already deployed) Mark: question of review, see overlap, don't want to step on toes (because CEs are setting up LSPs), want to make sure not solving problem in two places. PWE3 also talking about generic PW. Several areas are reacting to this motivation (CE-originated LSPs). Add "work with other wgs" in next-actions. Yakov: L1VPN is optical LSPs only. Should you recharter L1VPN to work on packet environment. Mark: understand, but same control plane Yakov: please recharter L1VPN JP Vassur: Mark is right. Is this part of the discussion in l3vpn? Chair Rick: yes Adrian Farrel: circulate this in other wgs Kireeti: important that the mechanisms used be common (l3 service & l1 service)o can use common mechanisms. Eric: Want a PW, need to find out CE router to peer with Rahul: You want RSVP-TE for carrier's carrier, right? carrier's carrier fits within scope of this wg. 10:15-10:30 Proposal for MPLS Services Over L3VPN - R. Bonica draft-bonica-mplsvpn-00 - Imagine L3VPN service provider - Customer wants to purchase a customer LSP from C0 to C3. - Problem: customer wants to use RSVP-TE to signal the LSP, but that won't work. - Solution: - Carrier's carrier nearly solves the problem. Build SP-LSP between PE1 and PE2, use BGP to advertise labeled paths between CE1 and CE2 - Need to build LSP between C0-CE1 and CE2-C3, CE1-CE2 is a virtual path - Challenges: - RSVP signal C0-CE1-CE2-C3 - Make CE1 beleive that next-hop to C3 is CE2 - not PE1 - three proposed solutions - BGP next-hop attribute - iBGP - policy manipulation - Partial ERO calculation - C0-CE2 - CE2-C3 - TE considerations - C0 and C3 need to see CE1-CE2 LSP for TE purposes - Questions? Rahul: Think this is carrier's carrier. Why doesn't it fit in the wg's charter? Chair Rick: Think it does. Packet-based CE-CE LSPs are in charter Yakov: what new is required to implement this (on top of 2547) Ron: from customers pov, nothing. From SP's pov, need a few things (missed them). Yakov: policy doesn't require standards work. Is it correct to say that the only thing needed is a TE attribute, why do we need to recharter wg. JP: Where do we do the work? Yakov: in the bar Kireeti: someone needs to provide the napkin Eric: Does this depend on carrier's carrier. Might not want carrier's carrier service. Need to find the CE endpoint if not using carrier's carrier, need a mechanism. Have you thought about multihoming? Ron: Yes, but not presented here. Kireeti: please show slide with two PE1s Emphasize that CE LSPs takes C0-CE1-CE2-C3, don't drop state in PEs. Ron: required that CEs cannot create RSVP state in PE routers Kireeti: this is different from l1vpn, where they are dropping state in PEs. CE1-CE2 is a pseudo-TE path, depends on accuracy of TE info propogated from PEs; PE1-PE2 LSP could be oversubscribed. Ron: right Kireeti: not a req that provider actually runs RSVP-TE Rajiv Asati: might be missing the CE-PE link BW reservation Ron: agreed Luyuan Fang: does this force provider to implement certain TE mechanisms? Rajeev: (missed comment) Eric: why focus on TE? could use LSP for anything. Are the reqs focused on TE? Ron: could expand reqs Rajeev: has something like multi-hop RSVP been considered? Ron: no Rahul: it works today Rajeev: has it been considered Ron: no Lee Ann: req needs to be more clear, what is the req for the SP. SP must also promise to offer TE. Yakov: 2547 allows customer to originate RSVP-TE request from CE1-PE1, will be propogated to PE2 Loa: security issues with running LSP across customer-SP border Ron: traffic restricted to VPN sites of the same customer; cannot install state in SP network Loa: not convinced, some malicious party in customer net could launch DoS, need to address this in security considerations Lee Ann: if I offer carrier's carrier, then I am basically done. If customer wants a TE LSP, then somthing additional needs to be done (protocol change) Ron: need to leak TE info Yakov: been implemented by Cisco, part of communities, can spec different attribute Ron: need to keak info in BGP Rajeev: could be running IGP & LDP on PE-CE Ron: must use BGP for carrier's carrier Rajeev: no; works today Ron: you're right W: ask previous authors if the services discussed are the same (IP over LSP) Kenji: provide both cases Mark Townsley: WG charter needs updating in general. Carrier's carrier not in charter, TE (QoS) is excluded. AD will recharter. Consensus call on this work item: do in this wg? - favorable; confirm on mailing list, updating of charter Meeting adjourned