**DRAFT L3VPN Minutes - IETF 73*** 2008-11-20 Chairs: Danny McPherson and Marshall Eubanks Scribe: Steven Blake --- WG Status Update - Danny - Draft status on L3VPN tools page - Add accept-own-community draft as WG item - OSPFv3 PE-CE draft as WG item - WG last call two solutions drafts Planned for WG LC (MVPN solutions drafts) - draft-ietf-l3vpn-2547bis-mcast-bgp -mcast - Accepted for WG item (Morin draft): - draft-ietf-l3vpn-mvpn-considerations - Consensus call on mailing list: - Accept draft-morin-l3vpn-mvpn-considerations-03 AND - Turn this into a requirements draft with mandatory to implement features - MVPN Considerations draft - only reference existing solutions drafts - required to get the solutions drafts thru the IESG - set of building blocks to enable interoperable implementations - WG review to determine whether the existing components are sufficient - draft-mnapierala-vpn-part-reqt - Call was made, no clear consensus either way - BiDir work may be able to be accommodated with current solutions drafts - MVPN Considerations draft will be modified to accommodate BiDir - Marie will likely become co-editor when text is provided - For partitioning, Maria will provide commentary and proposed solutions draft text - case MUST be made that these changes are necessary in the base solutions drafts - else it will be done in subsequent document - if there is consensus the changes need to be made before solutions drafts will be WG last called > Eric Rosen: you stated it in a way so that everyone gets what they want. We know there is follow-on work that comes afterwards. Little confused > Danny: case made that solutions drafts accommodate BiDir, can be put in considerations draft also. Partitioning being considered because it could not be added after soltuions approved. we need to make a explicit consensus call. > Eric R: Not sure that makes sense. Last time I got into a situation where a draft was held up by another, it lasted 7 years. > Danny: told Maria that we could consider this, hope that this can be done after the fact. > Marshall Eubanks: send text if you are interested. > Danny: consensus call will happen well before next meeting. > Yakov R: what is the timeline where we will find out whether partitioning is needed. > Danny: want the two solutions draft to go to IESG before the next meeting. > Rahul : as a co-author of the solution document, whatever is there does not preclude partitioning. We need to resolve this in the next few weeks; need a deadline; as authors we don't want a theoretical concern that will block this work. > Danny: will work with Maria. Will make the case in the next 4 weeks. > Eric: Agree with Rahul. If we want to make progress, go forward with what we have. Nothing in the solutions draft that preclude follow-on work. Should declare everything that we want to add later out of scope now. > Yakov: it's time to move. > Danny: completely agree, draw a line in the sand, make a case in the next few weeks, or move forward. > Yakov: we could be debating this until next year. > Eric: any requirements not satisfied should be handled in follow-on work. > Danny: completely understand and agree. Maria & co need to make the case. Once they (solutions and considerations drafts) go to IESG then we can take on new work. Will be handed to IESG the week after WG LC. Issue is that chairs can't send to IESG if there are unresolved issues. > Yakov: we don't have consensus on partitioning in the WG. How are we going to get this. Understand that Maria has ideas, but these are not WG consensus. > Danny: Maria has to provide text, then WG has to accept, or it will be dropped. > John Drake: violating WG process. We should have consensus of whether we need partitioning or not. > Rahul: No clear consensus to adopt partitioning. > Danny: consensus call was whether to accept this particular draft. > Rahul: we are stakeholders too. > Adrian: surprised that there is no consensus to not do this work. have we ever needed consensus not to do something. > Marshall: consensus was 50:50. > Yakov: co-chairs are violating IETF process; there is no WG consensus to address partitioning requirements. > Danny: we are going to make a call for consensus on addressing partitioning. > Yakov: you are asking whether solution documents preclude partitioning. > Marshall: we are violating process by calling for consensus? > Danny: will make a consensus call whether solutions draft should not preclude partitioning. > Rahul: last call the solutions drafts, if partitioning is an issue it will come up. Let everyone be happy. > Danny: anyone who has something to say, speak up. > Ross Callon: understanding why the previous AD ran away. He made a line in the sand that we get the two main protocol specs done, so that service providers can hit their vendors over the head. Line in the sand was to get the docs out in six months. If this doesn't stop this from being out in six months, then I don't see a problem. At the next IETF we can be working on new work. Would like to see it prior to the next meeting. We are talking about whether there is time for a little bit of extra tweaking before the next meeting. > Danny: that may be a viable path forward. > Eric: two solutions drafts have been around for a long time; no changes have been made recently, no energy to make other changes > Marshall: considerations draft will not go to last call yet > Eric: we have two drafts ready for last call, Danny said that we will not submit until the considerations draft is ready. > Danny: meant that IESG will likely have a problem with solutions drafts and nothing enable interoperable implementations (mandatory to implement) > Eric: can't understand whether the solutions draft will be held hostage by the considerations draft > Marshall: discussion with IESG indicates that they will be held hostage. > Danny: they are tied > Eric: heard a lot about what the IESG will or will not do > Thomas: pretty clear that the best interest of the WG is to move quickly on solutions drafts and considerations drafts. Would be nice to indicate that we have quick feedback on the considerations draft. > Danny: would like to LC considerations doc well before the next IETF. Trust editors will accommodate any tweaks. > Ross: if the two protocol drafts are submitted without the considerations draft, then I can put them on the agenda, and we will see what comments we get. Would not shock me if there are comments that there is no specification of what is mandatory to implement. Will tell them that WG is working on a considerations draft. Would be preferable to move forward on the considerations draft. > Ron Bonica: can't speak for other IESG members, but if you put something in the proto writeup about the considerations draft is coming, that will help. > Eric: is the considerations doc going to last call soon. I think it needs a lot of work still. Is it going to be changed into a requirements document? > Marshall: we clearly haven't seen the next version. It is coming; we will ask the WG for feedback. You can't know whether it is ready for LC until we see it. Major reasons for LCs is to find if something is missing. When we say we are ready to LC, immediately get comments. > Danny: point well taken Eric. WG item now, Thomas & team are editors. > Ben: confused. Summary of my understanding - two solutions drafts will be last called, then handed to the IESG. Any discussions will be due to the IESG, not the WG. Meanwhile will work on the considerations draft. > Maria: agree with Eric, believe there is more work to make the considerations draft useful for operators. If authors of the solutions drafts think that parititioning is possible, then it should not be a problem. > Thomas: we just ask that feedback happen soon. Feedback so far has not been helpful. > Danny: announcement of LC is intended to expedite feedback. > ? from Cisco: we pretty much agree that there is only one single item to be worked on in the considerations draft. Don't understand why we have to block to consider the partitioning draft. > Marshall: we haven't last called the draft, this is normal process. Received responses from 78 different individuals in the last LC. --- 3) http://tools.ietf.org/html/draft-ietf-l3vpn-ospfv3-pece-01 Padma Pillay-Esnault - Discuss latest changes - Request input from WG 15 mins - OSPFv3 as a PE-CE Routing Protocol (see slides) - OSPFv2 PE-CE spec in RFC 4577 - provided inter-area connectivity between VPN sites - intra-area connectivity between VPN sites (sham links) - OSPFv3 as PE-CE has similar requirements - Differences in this draft vs. 4577 basically because of differences between OSPFv2 and v3. - OSPFv3 allows multiple instances of a single PE interface; sham link (interface ID in OSPFv3 header used to distinguish instances). - BGP OSPFv3 Route Extended Community similar to OSPFv2 extended community. - Modifications from -00: - see slide - Way forward: - ensure synchronization with draft-ietf-ospf-af-alt-07 in OSPF WG - determine whether or not to provide support for connectivity between OSPFv2 and OSPFv3 instances across teh BGP/MPLS backbone > Danny: should send that query to the mailing list. > Padma: might be an interesting deployment scenario- > ? : mentions that IPv4 or IPv6 prefixes can be carried in OSPFv3, new extended community could be attached to both of them. What happens to old extended community? > Padma: not a problem because we have instance IDs. If we had to have any communications between v3 address family and v2, one way to do this would be to attach v2 attributes here. Didn't add it yet because it makes it more complex > ? (same as before): do we want to clarify what happens if multiple type 3 LSAs are aggregated. Need to say ... (DN bit set). > Padma: trying to understand. Worried about aggregation? > ? : Inter-area routes propagated by BGP. On other end will generate type 3 LSA. Address range might be configured there, and type 3 LSA might fall into it. Need to specify that the DN bit needs to be set. > Padma: what you are saying applies to v2 as well. Haven't seen people do this aggregation. This seems like a configuration issue. > ? : up to the user; should we clarify the protocol behavior > Padma: I think the recommendation is don't do it. It is a broken configuration. > Danny: you said you wanted to align this with the ospf-af-alt draft. Is that a blocker, or is this draft ready for last call. > Padma: Ross asked me to present in both WGs. Want to let it simmer for a while before last call. > Danny: bring that up on the list. > Yakov: if you want to bring this draft to the last call, it depends on the IPv6 extended communities draft. --- 4) http://tools.ietf.org/html/draft-rosen-l3vpn-mvpn-mspmsi-02 Eric Rosen - Discuss latest changes, specificially, new section entitled "Extranets using PIM as the MVPN Control Plane" - Request input from WG 15 mins - Extranets with PIM Control Plane - reversed architecture from Cisco implementation - similar to PIM-over-MS-PMSI; presentation focuses on MI-PMSI model. - See slides > Danny: if you have two transmitters at the same time, and there is a conflict, won't there be a collision. > Eric: couldn't set up an extranet that uses that address as a source > Danny: is this specified somewhere? > Eric: there is an actual requirement for extranet support; didn't make it into base specifications. Should be interesting to the WG if we are allowed to talk about it. > Danny: can't take this up as a WG item until we make progress on current work. > Thomas: requirements in RFC 4873, 4874. Think there are many things that are common with BGP-based multicast routing. Suggest that you factorize this work. Think that there will be a need to fix 2547bis-mcast document related to the dataplane; will send email to the list. Would be beneficial for this to be correct in the architecture draft. --- 5) http://tools.ietf.org/html/draft-ietf-l3vpn-e2e-rsvp-te-reqts-02 Kenji Kumaki - Discuss latest changes - Request input from WG 15 mins - Requirements for supporting Customer RSVP over BGP VPN (?) - changes from -01 - clarified problem statement - clarified specification requirements in Sec ? - See slides - Next steps: go for last call? > Danny: any comments > Dave McDyson (sp?): think more work needs to be done to take the requirements to split out C-TE over ???. Document needs editing to make it clearer. My comments are 26 pages long (doc is 22 pages long). Want my comments addressed before last call. PCE has to handle the fact that you may have duplicate IP addresses coming from customers; may need to extend protocol. > Kenji: for PCE features, we submitted a draft to the PCE working group. > Dave: need to reference that draft in this one. Issue is more than discovery. Haven't had a chance to see that other draft. > Adrian Farrel (chair of PCE WG): this PCE work has been brought to PCE WG but hasn't been adopted. > Danny: not yet ready for last call. Address feedback, and then we will see if it is ready for last call. --- > Danny & Marshall: Any other business? No > Danny: will see some WG last calls on the solutions documents. Meeting adjourned.