MINUTES:

1. Introduction and agenda bashing by chairs:

The chairs, Marco Carugi and Rick Wilder, started with agenda bashing. It was briefly explained that the charter of the previously proposed nbvpn working group would be expanded to include IPSec and Layer 2 VPNs within the scope of the new ppvpn working group. Thanks were expressed to Bryan Gleeson and Kireeti Kompella for preparing presentations on a short notice on IPSec and Layer 2 VPNs respectively.

Marco informed the audience that the term "nbvpn" would be changed to "ppvpn" on the mailing list, the website archive and all other relevant places to reflect the new name of the WG. The chairs also said that the charter of the new WG had not been finalized.

2. Message from Area Director - Rob Coltun :

The area director, Rob Coltun, said that in the interest of discussions on WG scope and charter, some of the presentations at the end of the agenda may lose out. Rob gave a brief overview of the proposed new area to include work on sub-IP technologies, generalized control, ppvpn etc. The idea would be to minimize/avoid potential overlap between WGs.

Questions/Comments:

Q. Eric Rosen : What are we trying to get done in the new area? Rob only mentioned better organization of work, but what is the actual work that will be done in the area, particularly the ppvpn WG?

A. Rob : This work didn't exist before, so we are doing new work and better organizing it.

Q. Rick Wilder: Rephrasing Eric's question, where are we at in terms of the status of this WG?

A. Rob: This effort (ppvpn) IS A WG at this time.

Q. Eric: We left Pittsburgh with an idea of a (nbvpn) WG. The IESG has been shuffling/adding/deleting work items. What is the clear criteria of this WG?

A. Rob: A revised charter has been proposed by the IESG. I admit the process has sucked and is frustrating!

Comment: Karthik Muthukrishnan : It would be good to discuss the charter now, rather than at the end.

The chairs took over and discussed the draft revised charter.

3. Draft charter - Rick Wilder:

Rick reiterated that the text was not finalized. Two main additions were made from the previous nbvpn charter -

1. Service scope: changed from network-based to provider-provisioned, hence broadened the scope.

2. Service providers may provide Layer 3 or Layer 2 services (introduction of Layer 2 is a change from previous charter). Examples include MPLS-based L2 vpns (Kompella draft).

IESG wants to highlight "service functional components"

Limits of scope:

- Service Provider's needs

- Functional architecture abstraction from transmission infrastructure

- Framework document

- Service requirements document

- Small number of ppvpn profiles (currently 2547bis-based and Virtual Router-based)

- foster interoperability between profiles

- document/identify gaps and shortcomings of each profile

Questions:

Q. Ananth Nagarajan: Since Layer 2 has been included within the scope of the charter, will ATM/Frame Relay based VPNs be also included?

A. Rick: Yes. IP-based VPNs over ATM/FR will not be excluded from scope.

Comment: Rob Coltun: Edge-to-edge encryption is also part of the scope of the WG.

A. Rick : Agreed.

4. Outline for a framework for NBVPN - Ross Callon 10 min

(draft-callon-NBVPN-outline-00.txt)

Main objectives: Discuss technical issues for ppvpns (since scope of original nbvpn has been widened, it will be necessary to update the draft to reflect the wider scope of ppvpn). Also describe trade-offs between the different approaches.

What the draft does not attempt to do :

- provide solutions for specific approaches

- Making choices in engineering tradeoffs

- protocol specifications

Why is this draft only an "outline for a framework" versus a "framework"?

- Authors could only agree on an outline in limited time available. Only rough text is currently in the draft, since the authors did not have time to agree on text. The outline will be "twiddled" as text is filled in.

- More people want to use VPNs than build VPNs. The former set of people should read the first four chapters and the latter should read the rest of the chapters

Questions/Comments:

Q. Bilel Jamoussi: Since you mentioned more people want to use VPNs, we need more service provider input in the draft. Would like to see more service providers among the co-authors.

A. Ross: Agreed.

5. Update of a framework for NBVPN - Muneyoshi Suzuki 13 min

(draft-suzuki-nbvpn-framework-02.txt)

Goals: Interworking, common service framework and common management framework.

Contents: assumed services, logical architecture and reference models, requirements for interfaces and MIBs.

Update from previous version:

- models updated to apply to Virtual Routers (VR) and VPN Routing/Forwarding (VRF) models

- Definitions of VR and VRF

- Addition to classification of interfaces : network-facing-side, intra-subnetwork and subnetwork interfaces.

Muneyoshi also mentioned that the targets of standardization work should include:

- customer facing side interface

- network facing side interface

- customer MIBs

- Device MIBs

Requirements for identifiers, interfaces and MIBs were also presented.

In conclusion, Muneyoshi mentioned that the draft needed to be revised to reflect the wider scope of the updated charter.

Questions/comments:

Q. Bilel: Will the two framework documents be merged?

A. Marco: A framework team will be formed and its task may include merging the two documents and developing a separate service requirement document and framework document.

Comment. Dave McDysan: The first goal of the framework doc is interworking. This goal is not achievable with the expansion of the scope to include managed CPE along with network-based VPNs. Suggest the use of the term "interconnect" instead.

A. Rick: Agreed. Interoperability will continue to be a goal.

6. Update of the MPLS VPN work at ITU SG13 - Carugi 5 min

(see "related ITU work" at //nbvpn.francetelecom.com)

Marco described the work being done in Question 20/Study Group 13 of the ITU-T under the study period 2000-2003 to develop a recommendation on network-based IP VPNs. The previous draft recommendation y.ipvpn is now split into draft y.1311 (generic recommendation on network-based vpn architectures) and y.1311.1 (network-based vpn architecture and service specifically using MPLS).

The work was initiated in the SG 13 meeting in Kyoto and continued in the interim meeting in Ottawa in September and the SG13 meeting in Geneva in November. In the Geneva meeting, additional requirements were specified, most of which will be moved to the generic recommendation y.1311. There was also a discussion on service models and the decomposition of VPNs to a Virtual Service Network and Virtual Transport Network.

Marco mentioned that an interim meeting would be held in Boston in February 2001 to progress work on the recommendations, especially y.1311.1 in time for the SG13 plenary in May 2001.

One of the main goals of the ITU-T work is to continue cooperation with the IETF. For example, the IETF may re-use some of the service requirements and service deployment scenarios that have been contributed by various service providers for the ITU-T recommendations. Further details on the ITU-T work are available at http://nbvpn.francetelecom.com/ituRelated.html

Marco also presented an outline of Y.1311.1 and mentioned that any sub-recommendation y.1311.X could be produced in the future based on market requirements.

Questions/Comments:

Q. Geoff Huston: Does the IETF have open access to the ITU-T documents?

A. Marco: no official answer to this from the ITU. The mentioned documents are informally accessible from the France Telecom PPVPN (NBVPN) web site.

Q. Dave McDysan: Charter of y.1311 looked adequate. Why not adopt this for PPVPN?

A. Rick: PPVPN also includes Layer 2 services which are outside the scope of y.1311

A. Rob Coltun: IETF work will also include "IpSec" VPNs (for lack of a better name) besides L2 VPNs.

Q. Yakov Rekhter: What is the reason for including Frame Relay and ATM (Layer 2) and not including SDH-based VPNs?

A. Rick: The scope of the WG is based on scaling, sharing and other practical considerations. Customer networks are using Frame Relay and ATM. This does not mean we are precluding SDH (will include based on customer feedback).

A. Rob: There would be potential overlap between PPVPN and the CEOT BOF.

7. IPSEC VPNs : context and main issues - Bryan Gleeson - 10 min

Bryan presented an overview of IPSec VPNs. The main objectives of this talk were to describe where IPSec can be used and to solicit requirements. CPE-based IPSec VPNs have existed for a long time. IPSec can be deployed in three scenarios : CPE-CPE, PE-PE and PE-CPE.

The CPE-CPE scenario would involve voluntary IPSec tunnels. These are typically site-to-site VPNs with arbitrary topologies (hub and spoke is most common). They include remote host dial-up, IPSec clients wherever available. The service provider only sees IP packets.

In the PE-PE scenario, we could have either Layer 3 or Layer 2 VPNs (wherein IPSec is tunneled within MPLS, as an example).

The CPE-PE scenario would provide secure remote access to a network-based VPN via compulsory IPSec tunnels.

Bryan mentioned the current IPSec-related WGs like IPSec, IPSP and IPSRA and their respective scopes. Requirements were solicited for the following:

- ability to associate IPSec tunnel with a VPN (example, add a VPN-ID to IKE2 negotiation)

- ability to run routing protocols over IPSec tunnels

- allow null encryption and null authentication

- more flexible diffserv marking rules.

Questions/Comments:

Q. Eric Rosen: Confused about what this WG needs to do in this space, since all the work has been done in other WGs. What is the specific additional requirement for service-provider-managed CPE-to-CPE IPSec VPNs versus unmanaged CPE-to-CPE VPNs?

A. Bryan: Agree with what Eric said. No answer to these questions.

A. Rick: To start with, this scope will just be included in the framework document. Then, we will be able to determine whether any additional work needs to be done.

Q. Suresh Krishnan: No need for "flexible" diffserv marking rules. What is meant by this?

A. Bryan: This is a specific requirement within IPSec specifications.

A. Shahram Davari: RFC 2983 describes Diffserv for IPSec tunnels.

8. Layer 2 VPNs : general introduction (context, main issues) ,

MPLS-based L2 VPNs - Kireeti Kompella 15 min

(draft-kompella-mpls-l2vpn-02.txt) min

Kireeti started off with a disclaimer that this was an example using MPLS, but it was independent of any Layer 2 technology under MPLS. The disadvantages of traditional Layer 2 VPNs are:

- multiple networks to manage

- complex provisioning

- topology dictated by cost rather than traffic patterns

- multiple networks - adds to the service providers' administrative burden

The first question that arises is how to decouple the edge (CE-facing) technology from the core technology and have a single network infrastructure for the desired service. One answer is MPLS, since it is layer 2 agnostic. One can have several services over MPLS. MPLS also provides label stacking and uses IP signaling, which works great and is highly extensible. One could use diffserv and traffic engineering mechanisms with MPLS. MPLS-based Layer 2 VPNs are independent of Layer 3 (IPX, IP etc). The service provider is not responsible for routing. Also, MPLS transport decouples the edge and core. It also enables the autoprovisioning of VPNs, and provides a single architecture for both Internet and VPN traffic.

The second question is whether the "P" (Private) in VPN is good enough? In other words, is the concept of different virtual circuits per VPN (e.g. ATM, FR, MPLS) good enough? Privacy is not equivalent to security. Encryption is a MUST if you want security. In CE-CE VPNs, IPSec should be used for security. In PE-PE VPNs, security should be achieved per-VPN and per PE-PE session.

The contrast between Layer 2 and Layer 3 VPNs is that, in the latter, the service provider participates in the customer's routing. This adds to the service provider's responsibilities. However, since the provider is able to look at IP packets, value-added services can be provided, but at an additional cost.

Questions/Comments:

Q. Bilel: What additional work needs to be done in L2 MPLS VPNs?

A. Andy Malis: Signaling

Comment. Ananth: This was just an example using MPLS. Suppose ATM/FR were used instead, then the work to be done would include ATM and FR signaling, which is clearly outside the scope of the IETF.

Q. Chandrasekhar Kathirvelu - There are clearly more advantages for L3 VPNs over L2. How is this approach different from BGP-MPLS VPNs (rf2547bis)?

A. Kireeti: Two things - one is the large number of routes in L2 VPNs,

Second is that L3 VPNs are independent of customers size.

Comment. Yakov: Since customers are asking for both L2 and L3 VPNs, we must do both.

9. OSPF as the PE-CE protocol in BGP/MPLS VPNs - Rosen 10 min

(draft-rosen-vpns-ospf-bgp-mpls-00.txt)

In the rfc2547-bis proposal, if the provider backbone runs OSPF as the IGP, VPN-IP routes from BGP must be imported by OSPF. OSPF tends to treat BGP routes as "second-class citizens" i.e., as external routes as opposed to inter or intra-area. This may be appropriate for BGP routes from the Internet, but not for BGP routes from a VPN. This draft attempts to address this issue by running OSPF between PE and CE. The main requirements are: a) to include routes from other VPN sites b) the VPN backbone should be able to connect two Area 0 segments c) Stick as much as possible to the basic principle of using BGP to distribute routes.

Eric described the solution for Inter-area and AS-external VPNs. The PE router is designated as Area 0 router and receives AS-external/inter-area routes from CE. The PE re-originates inter-area LSAs/external LSAs. Loop prevention in re-originated LSAs is achieved by route tag in external LSA and flag bit in inter-area LSA.

Eric also mentioned that the intra-area case (where 2 VPNs are in the same OSPF area) is complicated. It is only needed if the IGP backdoor link can't be an area0 link.

Questions/Comments:

Q (name not known): One of the advantages of rfc2547bis is not to have to manage PE-CE link. This draft introduces that problem. What is the value?

A. Eric: Somewhat agree, but this work was requested by a large number of people! It is also useful in transitional situations.

10. Using BGP as an Auto-Discovery Mechanism for NBVPN -

Hamid Ouldbrahim 10 min (draft-ouldbrahim-bgpvpn-auto-00.txt)

The motivations for this work are:

- to define a common BGP-based autodiscovery mechanism

- allow VPNs to autodiscover members

- useful for both, the Virtual router approach and the 2547bis approach , individually or for interworking between the two approaches.

Information that can be autodiscovered include - membership, topology, tunnel information (endpoints) and reachability. The mechanism is based on BGP and uses BGP-4 multiprotocol extensions. VPN-specific information associated with an NLRI is encoded as an attribute of the NLRI (NLRI is the VPN-IP address or labeled VPN-IP address). The address provided in BGP next-hop is in the service providers addressing space.

The interpretation of information for 2547bis approach is based on the Route Target attribute. For the virtual router approach, the interpretation is based on RFC 2685 (new extended communities for VPN-ID and 4 bytes for VPN topology).

Two interworking scenarios were described between 2547bis and virtual router approaches. The first scenario showed the PE-CE interworking between the VR and the VRF via a secured IPSec link (for example). The second scenario showed PE-PE interworking using BGP as a common mechanism to connect to the backbone from both the VR and the VRF.

Questions/Comments:

Comment: Bilel: Since autodiscovery is a general building block, suggest adopting this scheme as a common scheme.

A. Marco: the requirements have to come from providers. It is too early to standardize this work.

11. Update of "NB IP VPN Architecture Using Virtual Routers" -

Ouldbrahim 5 min (draft-ouldbrahim-vpn-vr-02.txt)

Hamid described the changes from the previous version of the draft. The following changes were made:

- added extranet support

- added autodiscovery

- VPNs/VRs across domains were included

- MPLS and IPSec tunnels were included

- reorganized the requirements section

12. Update of "A Core MPLS IP VPN Architecture" - Muthukrishnan 10 min

(draft-muthukrishnan-rfc2917bis-00.txt)

Chandrasekhar Kathirvelu presented this draft. The basic motivation was that there was no omnipresent provider, a bridge is needed to connect regional and global carriers. The concept of hierarchical VPNs is also introduced.

Questions/comments:

Q. Bryan Gleeson: Is multicast still a requirement for discovery, as it was in RFC 2917?

A. Working on other discovery mechanisms.

Q. Rob Coltun: Thought that it was agreed upon to merge both the Virtual Router approaches into one draft at the last IETF.

A. Karthik - working with co-authors of other approach.

Comments : Bryan: Virtual router concept should not dictate what specific approach to take using virtual routers. So, have different approaches as categories of virtual router.

Marco: The proposed framework team will go deeper in detail on functionalities associated. A recommendation on a pragmatic approach will be made. The virtual router may be used as a single "profile" implemented differently using different approaches.

Bryan: Membership aspect may make merging very difficult.

Bilel: Merging the two virtual router approaches, just because they are based on virtual routers would be like merging rfc2547bis and the virtual router approach because BGP-based autodiscovery was common between them. So it doesn't make sense to merge the approaches.

Rob: We don't want 100 different profiles. But from the current discussion, it looks like merging of the virtual router approaches is not possible as agreed earlier.

13. BGP/MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure - Jeremy De Clercq 5 min (draft-nguyen-bgp-ipv6-vpn-00.txt)

This draft describes the mechanisms/extensions required to carry an IPv6 VPN over an already existing IPv4 backbone with rfc2547bis-based VPN offering. This approach reuses all the rfc2547bis principles. The PE uses IPv6 VRFs for IPv6 sites. A new address family (VPN-IPv6) family is defined, which includes the Route Distinguisher and the private IPv6 address. The BGP next-hop is an IPv4-compatible IPv6 address.

14. Multicast in MPLS/BGP VPNs - Rosen 12 min (draft-rosen-vpn-mcast-00.txt)

Ordinary multicast over IP backbone requires core routers to maintain distribution trees for multicast groups, with a route to the root of each tree. This state in the core for enterprise trees is undesirable for VPNs. This approach assumes PIM and introduces multicast VRFs. Three alternatives were described:

Alternative 1 - extended ordinary multicast. The disadvantage of this alternative is that it introduces state in the core.

Alternative 2 - Ingress PE replicates. This overcomes the problem of state in the core, but requires replication at the IP ingress.

Alternative 3 - Core has one distribution tree per VPN. This approach uses PIM LAN. This approach introduces one state in the core per VPN. Enterprise multicasts are aggregated. However, multicast routing in the core is non-optimal.

Eric mentioned that the third alternative was the best tradeoff. Optimality can be increased by increasing state.

Questions/comments:

Comment (name not known): Alternative 3 is good, but alternative 2 is more bandwidth efficient. The service provider does not need to have multicast in the backbone.

A. Eric : no disagreement. Choice depends on how common multicast will be.

Comment : Yakov: None of the alternatives are perfect. Provider may choose to provide more than one alternative.

17. Charter discussion and organization of items to be worked on - Co-chairs - 13 min

Time was running out and Rob advised the chairs to discuss the charter before going on to the next presentations.

Rick asked for volunteers for the different design teams and proposed a possible interim meeting to progress work. Volunteers for the design team were asked to sign up after the meeting and send email to the chairs. The design teams that were proposed include:

- Framework (to include service requirement and framework documents (sub-teams); a transversal efforts including various domains such as routing, security, management etc.)

- BGP/MPLS-based (2547) approach

- Virtual Router-based approach

- Layer 2 VPNs

- IPSec VPNs

- Inter-AS VPNs (depending on needs expressed by requirements/framework work)

The teams would be finalized in 4 weeks (scope, participants, editors).

The milestones include:

- first version of deliverables (one service requirement document, one framework document and one document per profile team) for next IETF meeting

- Possible interim meeting (contents, date, host to be decided)

- Area Directors will help organize the activity.

Questions/Comments:

Q. Bilel: A clarification on L2 VPNs - regarding encapsulation. Thought that the home for encapsulation in MPLS was in CEOT, but that BOF did not really succeed. So, does L2VPN include multiservice over MPLS? Will this WG be the home for such work or will there be a public forum?

A. Rob: Unclear at this point. Profile may be defined in this WG and CEOT may be responsible for protocols. The IESG is working on this. No, there is no public forum.

Comment: Marco: The main aim is to deploy services as per requirements. Therefore, one should start with a pragmatic approach, as will be described by the framework team. New teams may be added as per requirements.

Comment: Andy Malis: All CEOT work belongs in some place.

Q. (name not known) - Since Layer 2 VPNs are now within the scope, does that only mean MPLS-based L2 VPNs? What about Ethernet over PPP and so on? Do you want to separate L2 VPNs from L3 VPNs?

A. Rob: The condition is that the tunneling mechanism should be IP-based.

Q. (same person as above)- IESG does not want to take over foo-over-mpls.

A. Rob: Reiterates, everything running IP is part of IESG.

Q. (name not known) - IESG wants to focus on IP signaling, not IP data?

A. Rob: This may or may not be, the focus is on IP!

Comment. (name not known) - I have an opposition to including Layer 2 VPNs.

A Rob: This work was explicity included by the IESG.

Q. (name not known) - Does L2 mean specific to MPLS?

A. Rob: No. It is generalized.

Comment (name not known)- It is explicitly stated in the charter that the scope is not limited to MPLS.A. Rob: Agreed. No specific MPLS focus.

Q. Tom Worster: I question the split between Layer 2 and Layer 3 VPNs. Don't see the separation as necessary.

A. (Kireeti): Both are needed - vendors will do both.

Q. Tom : the question was, does the WG want to do both L2 and L3?

A. Rick: Don't want to take a position on that today.

Q. Yakov: I see an inter-service provider (inter-AS) team. Don't see the need for that since current approaches described cover the inter service provider scenario.

A. Rick : This was just a proposed starting point. This team may be put off depending on number of volunteers and requirements.

Comment. Yakov: This shouldn't be a separate design team. This should be included withing the VR or rfc2547bis teams.

A. Marco: Good point. The main work will be decided in the framework team.

Q (name not known). What is our stand on SLAs? Do we need to standardize SLAs? The SLS BOF said that diffserv was not mature to talk about SLAs.

A. Marco: Good point. Framework team will include people with different sets of expertise, including people with QoS expertise.

Q (name not known): The framework document does talk about SLAs. What is the scope?

A. Marco: SLAs basically involve an agreement on QoS parameters. How to achieve these with generic mechanisms will be a starting point.

Comment : Start a focused group on SLAs here.

Q (name not known): Does the answer to the previous question apply to QoS in general? Is that on the priority list?

A. Rick: Don't know well enough yet how much is dependent or independent on the design approach. This will be another goal for the framework document.

15. MPLS/BGP VPN MIB - Nadeau 10 min (draft-nadeau-mpls-vpn-mib-00.txt)

This draft was presented by Luyuan Fang. The MIB is for rfc2547bis approach only. The MIB described three scenarios - enterprise VPN, interprovider backbone VPN and carrier's carrier.

16. Implementing BGP/MPLS VPN in Provider's IP Backbone - Luyuan Fang 7 min

Luyuan described experiences with MPLS VPNs (based on 2547bis approach) at AT&T.

The implementation description involved MPLS with LDP, MPLS with RSVP and LDP/RSVP interoperability. The deployment issues described included:

- feature availability versus optimality

- multivendor interoperability

- incremental deployment plans

- scalability (achieved using route reflectors).

- performance impacts on PE router

- Load sharing between CE-PE links

- Security (further study needed)

- multi-AS interworking

Various network management issues were described, which included the need for MIBs, configuration and provisioning management, performance management and security management.

Summary: Awaiting charter finalization from IESG and finalization of teams for various work items in about four weeks.