Layer 3 Virtual Private Networks (Internet Area) Wednesday, December 5, 2007 ========================= Chairs: Rick Wilder Ron Bonica Agenda: 09:00-09:10 Working Group Status and Charter - R. Bonica, R.Wilder Ron did a brief update, we only have multicast VPN left to do. 09:10-09:40 T. Morin - draft-morin-l3vpn-mvpn-considerations-01 Thomas presented slides on the draft. goal: discuss the options proposed and choose the better candidate Question from Cisco, clarification do you need a colocated RP? Yes. would like additional clarification of colocated RP and usage in the draft. Plan for refining the following subjects (slides) 5 test abou tspmsi for the inter AS context comparison of segmented/nonseg inter as depending on unicast option b or c security or OAM related issues that cand ifferenciate the different propsoed options Contributions welcom expanding scope of document is not planned need to identifiy a core set of mandatory procedures to make document useful as a standard proposed as a WG draft. those that read the draft agreed to make it a WG draft to be confirmed on the list. Ron will post email asking if objections to making it a WG draft. 09:40-10:00 M. Napiera - draft-mnapierala-mvpn-part-reqt Maria was not present to present the draft. No substitutes identified so draft presentation postponed for now. 10:00-10:30 B. Davies - draft-davie-tsvwg-rsvp-l3vpn bruce presented slides... need to determine the wg for the draft tsvwg or l3vpn problem addmission control desired on ce-pe links of l3vpns running rsvp across these links presents issues need to associate rsvp with vrf context need to intercept path messages at egress pe but router alert IP option not visible may also wish to do admission control across backbone. need inter AS operation and make sure admission control works in all cases. This is where work on draft was. problem to solve is when Path or Resv received at PE which VRF should be operating in. P routers need to stay uninvolved. Messages must be transparently passed. A fair number have read a version of the draft. New objects placed in RSVP messages in service provider network to allow routers to figure out which VRF they apply to. normally PATH message sent to end point, but instead sent directly to next router so that router alert processing not needed. can use 4804 for admission control over provider backbones Inter AS operation - in most recent version of the draft Option A - just works ASBRs operate like PEs, two separate networks implement solution all information on the links. Option C - just works using a PE to PE LSP ASBRs in the middle transparent to RSVP. If need to do ad control across backbone then use TE tunnel accross Option B - all heavy lifing here. requries ASBRs to process Pathand resv messages and store state to enable revers fwding of RESV OK solution if you want to do CAC on ASBR link. IF no CAC needed then storing state for no benefit. Will ddress in next draft revision Also dealt with all messages that weren't PATH or RESV. Details spelled out in draft. When no CAC offered to customers don't just throw away RSVP messages, treat as IP data grams Appendix A added to record rejected approaches so not revisited. Should eventually be removed. Open Issues the VRF_ID in current draft led to state storage in ASBRs evenif CAC not needed. - solution instead of VRF_ID (used to identify VRF, but needs to be recorded and stored as ASBRs. locally significant) use VPNv4 PHOP (globally significant) generated by ingress PE, can use LSP that leads to that VPNv4 address. Transparent to ASBRs. A suggestion made (Yakove Rekhter) that Path messages should carry the VPN_v4 address of the path message vs. the VPN label. They are 1:1 and can forward PATH to destination. Kumaki et al requested support for RSVP-TE from CEs - authors believe feasible, but not yet done. Next draft version. Summary solution sticks to principle of no changes to 4364. Authors think that with one more rev, draft would be pretty complete. Draft will be presented in TSV - they own change control for RSVP. Where do we go with the draft. Not as much interest in TSV. ADs could pursue work in this WG and have TSV review. Is changing the addressing a change to RSVP? Yes because changing the objects. If given the OK to pursue document here would people support making it a WG document? Question withdrawn Is there agreement to tackle the problem here? Agreement to tackle problem Is there agreement that this document should form the basis for the work? agreement that this document should form the basis for the work Concern that changing semantic of session object is significant and shoudl be described before agreeing to wg document. Comment noted but does not reflect consensus of room. Support that most of problems addressed by this is related to L3VPN wg. Some concern that after a reboot there would be inconsistency between up and downstream and this is an RSVP issue. Will be presented at TSV tomorrow. Next draft anticipated in a few weeks. Call for whether it should be a WG document should be made on the list after that. 10:30-11:00 E. Rosen & R. Aggarwal - draft-ietf-l3vpn-2547bis-mcast Rahul presented the draft with slides (not uploaded) Some technical loose ends presented (see slide 2) Goal is to take draft to last call before next IETF Rahul presented changes from previous version (slide 3, 4, 5) review is encouraged particularly from those familiar with 2547 and multicast Maria met with Rahul to address her issues from the last meeting. Attempts have been made to accomodate her comments in the current draft. Further discussions with Maria to examine the requirement that this be transparent to the customer to address move from FR, ATM to IPVPN. Chair's note: too few folks are looking at drafts. The chair asked for volunteers to review and offer objective, constructive techncial comments to the WG. Dimitri P. John Drake Bruce Davie There are implementations, so this work has not been done in a vacuum. The work should not be given any special treatment. However, if there is a last call and there are few comments and it looks like it has not had adequate review, it is appropriate for the chairs to ask for volunteers to explicitly review the work. 11:00-11:30 E. Rosen - draft-rosen-l3vpn-mvpn-profiles-00 MPVN profiles The framework allows many choices at different layers by design. Not desireable to reduce the set of options to one set and no consensus But - no vendor wants to implement all combinations of options Need to define profiles to group options that make sense and can be implemented as a set for a particular applciations reducing the options forces once size fits all, not enough experience to show one set is enough and no consensus Eric gave brief rationale for including PIM Briefly overview of potential BGP for multicast risks In the draft there is focus on PIM+GRE and PIM+MPLS Legacy subprofile addresses prestandard from 1999 that doesn't exactly conform to existing set of documents. PIM+GRE gives interop with deployed base and helps move deployment to standards(???) PIM+GRE Profile Legacy does not support MPLS data plane. PIM+MPLS profile based on MP to MP LSPs for data and conrol packet. Draft currently an individual draft to be pursued as Informational RFC after WG documents go to RFC. Does the group want to adopt profiles and stnadardize some? Discussion One participant wants a mandatory set of options in solutions draft and then profile others. Profiles long winded. Mark T. Progressing after may not be timely to give this work to the IESG. Also need an applicability statement for each profile to say why and where the profile is applicable. Either have one mandatory set or have more than one mandatory set and position them. What is the diff between a BCP and a profile. A BCP has IETF consensus and informational document does not. Participant (T. Morin) should use profile approach as last step. (Eric) Don't want to turn this into a PIM vs. BGP because still not clear which is right. Was debated in the past. Not enough facts because not enough deployments. There is a document (T. Morin) written by services providers to capture requirements that has been accepted by WG. A contribution by any service provider to add to it is welcome. Does this document compete with the Morin document? The Morin document tries to achieve a single mandatory profile, this one does not The requirements should be added to the Morin document This document is more than a profile, it has protocol spec that is non standard and should not be called a profile or profile should be defined. For informational document it is valid to document protocols used rather than leave them up in the air. Concerned that there was some misleading information concerning PIM LAN procedures. It was countered that there are no PIM LAN procedures but rather PIM is used in a different way on a LAN. For many building blocks there is one solution. There should be one set of mandatory procedures in the framework, but should not exclude other procedures. Unicast 2547 does not have profiles why do we have them for multicast. Multicast deployment predates the standards by a few years and is more complicated than unicast. Do we want to forward the framework document with options and then profile it? or do we want to define a mandatory set of options and forget the profiles? WG must decide. It was countered that even with a set of mandatory options profiles will be needed to define what makes sense of the others. It was felt that the authors are using the profiles to document their pre-standard implementation. Let the architecture draft reflect the services provider consensus. WG needs to decide if one mandatory profile or multiple, if multiple need text to show tradeoffs. Mark T proposed if the Morin draft describes the mandatory profile then the profile work needs to be folded into it. A home needs to be found for the additional protocol spec. It can be found after the standards are done. The work needs to be done for the pros and cons of the different profiles so the working group can make a decision. AP Morin draft question to the WG to adopt as a WG doc AP two volunteers to review document Meeting was adjourned.