13:02 Agenda Bashing Ron: Two presentations and one tutorial about L3VPN multicast. 13:03-13:07 Working Group Status - R. Bonica, R.Wilder See slides. 13:07-14:04 Multicast VPN tutorial - Bruce Davie draft-ietf-l3vpn-2547bis-mcast-03 Bruce: Motivation: customers with IP multicast traffic would like to use VPN services. Current deployments: -Based on draft-rosen-vpn-mcast-08.txt -PE routers do not hold (S, G) state for individual customers. However there is some per customer state in P routers. -PE routers exchange customer routing information using PIM. -Maps all (S, G) of any single VPN to single (S, G) group in P-network. Uses GRE encapsulation to perform this mapping. -All PEs participating same VPN joint to same Default-MTD. Additional data-MTDs can be created for high bandwidth C-groups. -Default MTD is also used by for PIM peering between PEs. -Shortcomings: at least one multicast P-group per customer, multicast packets are not MPLS encapsulated, only PIM is supported for building core trees, inter-AS challenges, use of PIM between PE-routers. Dimitri Papadimitriou: Is there considerations for using MPLS P2MP trees in the draft? Bruce: New draft contains that option. The presentation so far has been about the old draft. Yiqun Cai: One of the reasons in rosen draft for using regular multicast was to support existing networks that already have non-VPN multicast capability. This should be kept in mind, as we can not require upgrades in all P-routers for MVPN support. Bruce: (continuing presentation) PMSI: P-Multicast Service Interface. Separates tree from service. Groundwork that allows use of multiple protocols. Three types PMSIs: -MI-PMSI: multi-point all->all. -UI-PMSI: unidirectional some->all. -S-PMSI: unidirectional selective some->some. Types of trees: -Inclusive: all PEs for given MVPN -Selective: some PEs for given MVPN -Aggregate: all/some PEs for multiple MVPNs PMSI is scoped to single tunnel. PMSI can be instantiated by one or more tunnels. Tunnels may be instantiated by various protocols Ron: Question for slow learners: PEs build PIM adjacencies although there may be multiple hops between them. To do this tunnel is needed. MI-PMSI scales well, other types are more efficient. Go on now, I get it now ;) Bruce: You are jumping ahead. This will become clear when I go on with the presentation. Ron: ??? Dimitri Papadimitriou: Clarification question: why S-PMSI are only unidirectional? Bruce: Don't worry about uni/multi directional trees. The slides are simplified. Thomas Morin: S-PMSI would typically be uni-directional. Bi-directional trees would be possible, however motivation for this is be unclear. Bruce: "You meant bidir-PMSI not bidir-trees" Eric Rosen: Amused about people already pointing missing options, when there are so many of them already. Bruce: Can map multiple PMSIs onto one tunnel and reduce P-state. Mapping of old terminology: -Default MTD is MI-PMSI instantiated by PIM shared tree or set of PIM source trees. -Data MTD is S-PMSI instantiated by PIM source tree. Moving to presenting the new draft. Auto-discovery -New address-family to discovering PEs belonging to MVPN and tunnel information for these PEs. -Tunnel information is not intended for negotiation of tunnel methods -- all PEs must be configured with compatible tunneling settings. Yakov Rekhter: Clarification: tunnel attribute contains also tunnel ID that PE will use transmitting traffic. Dimitri Papadimitriou (?): Does tunnel id identify source or destination? Bruce: Source. Ron: Does auto-discovery replace PIM-adjacency for multicast membership discovery? Bruce: No. This is only auto-discovery. Yakov Rekhter: Ingress replication is exception -- for it auto-discovery advertisements contain receive information, Bruce: (continuing presentation) Aggregation: -Two conflicting goals: P-state (scalability) and optimality. -Original Rosen draft allowed either, however no middle road. -New draft solves this by allowing lots of options. PE-PE routing exchange: -Per customer PIM peering among PEs over emulated LAN. -PIM hellos can be eliminated, bug Join/Prunes remain. -In new draft BGP is proposed as PIM replacement. -BGP is more in line with regular VPNs. However information carried by BGP is basically same that is transmitted in PIM. -BGP router reflectors performs join suppression. Inter-AS -Old rosen draft approach: tunnels spans multiple ASes. -New draft also allows splicing tunnels from different ASes. -Inter-AS overlay tunnels Other issues: -RPF establishment -Duplicate detection -C-RP engineering. Try to avoid traffic via SP-network to RPs. Two solutions described in the new draft. Conclusions: -WG draft builds on rosen draft without obsoleting it -Rosen draft not yet obsolete -- it describes what is currently deployed. -Separation of service and mechanism. -Aggregation support. -More inter-AS options. -Allow single instance of BGP to carry C-(S,G) information between PEs instead of multiple PIM instances. Who is less after presentation? A: Quite many. Dimitri Papadimitriou: Question about how much overhead PIM really causes. Bruce: After hellos are suppressed, there still remains periodic joins prunes. Dimitri Papadimitriou: Applicability of PIM and BGP are implementation dependent. Which should be used. Thomas Morin: Suitable set of mandatory options is missing. Draft is currently patchwork and this is concern for operators. Yakov Rekhter: PIM hellos might be useful -- BGP session only indicates that BGP is up, not that PIM is up. With PIM you follow VR model, so with multiple operators there is direct peering and no hierarchy. This subverts ASBR control on peering. Venu Hemige: All of PIM is transported in BGP. This make it quite complex. Upstream targeted messages in BGP are complex. While lightweight, it makes BGP lot more complex and more hard to manage. Thomas Morin: Disagrees. People should read draft -- the mechanism are actually quite simple. Yakov Rekhter: MLDP is also supported as CE-PE protocol. Thomas Morin: "applicable to not only carrier's carrier but enterprise MPLS" 14:04-14:15 Clarification to 4364 regarding BGP RD - Luca Martini draft-martini-l3vpn-rd-zero-00 Luca: -RD has 3 types, 2 types use AS numbers. AS value 0 is reserved, so RD value 0 violates RD type 0. -Make RD value 0 to illegal to receive (in non-nexthop). Yakov Rekhter: few questions. Also as 65k is also reserved. Should it also be outlawed. Should also RDs containing invalid IPs be outlawed. Luca: RFC speaks about RD 0, so it is special case. Luca: What you propose? Yakov Rekhter: Nothing. Ron: It goes without question that if it can not be sent, it should not be accepted. Yakov Rekhter: RFC is not clear enough, ???10: Should update in next version of the draft. Yakov Rekhter: file bug report to RFC editor. ???10: RFC editor is quick way to fix it. ???11: There is nothing wrong about creating new RFC for fixing this. ???10: Either way is ok. Bill ?: RFC editor bug fix queue is 2 year long, so procedure is broken. ???10: There will be attempt to fix RFC editor process eventually. Ron: Errata or new RFC. Ron: Hard to compare. Yakov Rekhter: must be in mailing list. Ron: Will be decided in mailing list. 14:15-14:23 Requirements for delivering MPLS Services over L3VPN - Kenji Kumaki draft-kumaki-l3vpn-e2e-rsvp-te-reqs-02 Kenji: draft to clarify issues for e2e MPLS TE LSP over MPLS VPNs. -Presented several application scenarios (see slides) -PEs choose correct P-TE tunnels based on local policy -PEs perform CAC on P-TE tunnels -Fast protection between CEs. -Changes from -01: added applications scenarios. -Remaining issues: more requirements? -Next actions_ need more comments and feedback from WG. Request WG to accept this as WG documents. Ron: can we discuss it now or in mailing list? ???10: We are in middle of rechartering, so either is ok. Ron: show of hands: is this within charter? More yes than no. No clear margin so will discuss on mailing list. Ron: thats all.