IETF 74 - L3VPN Minutes WEDNESDAY, March 25, 2009 1300-1500 Chairs: Danny McPherson and Marshall Eubanks Scribe: Daniel King ====================================== 1) Administrivia - Light Agenda for today’s session. - No changes requested. 2) WG Status and Update - WG Status Update (http://tools.ietf.org/wg/l3vpn/) *http://tools.ietf.org/html/draft-ietf-l3vpn-v6-ext-communities Just finished WG last call. Authors updated the draft with new boilerplate text. *http://tools.ietf.org/html/draft-ietf-l3vpn-ospfv3-pece Authors were not ready to last call this document at the previous WG session. They have recently fixed some editorial nits. It is almost ready for WG last call. *http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-considerations Recently updated and was presented at today’s WG session. *http://tools.ietf.org/html/draft-ietf-l3vpn-e2e-rsvp-te-reqts Unknown status. No authors present in this WG session. *http://tools.ietf.org/html/draft-ietf-l3vpn-as4octet-ext-community As per draft-ietf-l3vpn-v6-ext-communities, recently updated, WG last call and being progressed. *http://tools.ietf.org/html/draft-ietf-l3vpn-acceptown-community No changes since initial draft. *http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast *http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp Both drafts are progressing and go to IESG in the next few weeks. 3) Multicast VPN fast upstream failover *http://tools.ietf.org/html/draft-morin-l3vpn-mvpn-fast-failover-01 Presented by Wim Hendrickx - Yiqun Cai: How would this work with PIM-based solutions? - Wim Hendrickx from Alcatel-Lucent: Currently, the solution is based on BGP. There is work continuing in the PIM WG. - Questioner Male from Cisco: So the solution is focused on BGP but would also work with RSVP-TE? - Wim Hendrickx from Alcatel-Lucent: Actually the solution is data plane agnostic. This will work with PIM, GRE, P2MP RSVP-TE. - Questioner Male from Cisco: OK. What is the targeted failover budget? If you have path protection for label based switching, it would be better for failover budget. - Wim Hendrickx from Alcatel-Lucent: The decision on the failover is local, and should be <50ms. - Questioner Male from Cisco: My next point is based on best failover budget. If you have two streams, both arriving at the egress PE, why do you need a new failover mechanism to indicate this is a join for the standby? - Wim Hendrickx from Alcatel-Lucent: Right now in an MVPN, the way you setup two trees (the upstream multicast hop selection), it’s picking one PE. - Questioner Male from Cisco: The reason we select one upstream PE, is that we do not want dual streams of traffic at the egress. If we would like to get two active streams at the egress (for fast failover), we should send two joins to two upstream routers and have both active. This would not require any protocol change. - Yakov Rekhter from Juniper: This is one possible choice [see slide 6] and it has a number of tradeoffs. The point is this [slide 6] tradeoff might not be acceptable to all providers in all cases. Restoration times will vary. As will bandwidth usage. - Wim Hendrickx from Alcatel-Lucent: Correct. We understood that different providers will require different solutions. - Greg Reaume from Telus: First of all I agree with the draft. Some assumptions were made but not clearly stated. The draft works with the scenarios you describe but when you expand and consider various possibilities and where state might preexist; it breaks some of these mechanisms. I could provide these examples to you. - Wim Hendrickx from Alcatel-Lucent: Let’s discuss those offline. But we have not include inter-AS examples. - Rahul Aggarwal from Juniper: Please send us text and comments. - Questioner Female (??): This scheme only works if the LSP tunnels are pre-setup? - Wim Hendrickx from Alcatel-Lucent: Nope. - Questioner Female (??): How would this work with a RR in the forwarding path or a inter-AS CE-to-CE LSP. - Wim Hendrickx from Alcatel-Lucent: Both tunnels will be up in the data-plane. The decision to forward traffic will be based on policy on the secondary upstream. - Yakov Rekhter from Juniper: Just to rephrase slightly. The forwarding state preexists for both the primary and secondary. What does not preexist is the multicast traffic that will flow across the forwarding state. - Danny McPherson WG Chair: Any the comments before we request this becomes a WG draft? - Wim Hendrickx from Alcatel-Lucent: We need to add the Inter-AS scenarios. - Danny McPherson WG Chair: OK you prefer to wait. How many people have read the draft? [good show of hands] Quite a few have read it. Any objections to this becoming a WG draft? [no objections] - Marshall Eubanks WG Chair: Do you see this being ready for Stockholm [IETF 75]? - Wim Hendrickx from Alcatel-Lucent: Yes. 4) Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution *http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-considerations/ Presented by Ben Niven-Jenkins - Danny McPherson WG Chair: When is updated draft with the final comments from Maria [Maria Napierala?]. - Ben Niven-Jenkins from BT: Sooner rather than later - Danny McPherson WG Chair: So as soon as the document is out, and if we have no objections, we will last call it. Ideally we should do this in the 6-8 weeks. 5) Additional agenda items MCAST-BGP - Marshall Eubanks WG Chair: – Yakov presented 22 corrects and suggestions. No objections to those corrections. Maria had complaints about section 13.1 but unfortunately could not attend the WG session. We are very close to finishing this stage of the document. - Marshall Eubanks WG Chair: Please check the IPR notice sent out and comment. - Danny McPherson WG Chair: Any other comments or questions? - Mark Fine from Alcatel–Lucent: I have a question regarding interoperability with [section?] 13 & 14. There seems to be some incompatibility between implementations depending on the strategy they are using in the draft. It states in the draft that this is determined during provisioning. But there is no way to determine which strategy is being used. We are concerned that there may be interoperation issues. There are messages being used by BGP differently [depending on the scenario] - Rahul Aggarwal from Juniper: As the specification currently states it has to be determined at provisioning time. In my mind this is not any different from PEs being configured for GRE and RSVP for tunnels and issues occurring. If the network is not configured correctly [things won’t work]. - Mark Fine from Alcatel–Lucent: But in those cases the PMSI will indicate the error. In this case the same messages are being reused between the two solutions and you cannot determine this unless you review the configurations. - Rahul Aggarwal from Juniper: If relying on provisioning configurations is not good enough than anything else is an optimization and has to go into a separate specification. At this point we should not modify the current specification to handle this. - Yakov Rekhter from Juniper: If this is an issue, we should create a short specification and add an auto discovery type, indicating which mode of operation we are running. - Marshall Eubanks WG Chair: Are you volunteering [to create the auto discovery specification]? - Yakov Rekhter from Juniper: No. But I am just suggesting its one possibility. If you think it’s really an issue. I will be glad to collaborate with you. - Mark Fine from Alcatel–Lucent: Yes, I’ll volunteer. 6) AOB - Danny McPherson WG Chair: With any luck you will see 5 [the active WG docs] moved into at least the publish state. Any comments please send to the mailing list. Close of WG session