The IESG has approved 'A Framework for Layer 3 Provider Provisioned
Virtual Private Networks' <draft-ietf-ppvpn-framework-08.txt> as an
Informational RFC. This document is the product of the Provider
Provisioned Virtual Private Networks Working Group.
The IESG contact persons are Bert Wijnen and Scott Bradner.
========
Alex:
Generally, I liked this document _much_ better than the
requirements doc, Ross did a great job, still it needs
more work, I believe.
A meta meta issue:
M0: why is this work in SUB area? It is all about routing
and hopefully not MPLS-specific... Randy would have
another chance to say that a more experienced person
would his mouth shut, and it is not that we don't have
enough stuff to deal with in RTG, but really...
Meta issues:
M1: In many, many places the document talks about a SP's network
as opposed to edge-to-edge through the Internet. I don't know
if this is intentional or not, but it seems to me that we
should want the WG to develop a solution that is able to
work very well across the Internet as well as within a single
SP as a special case... So far what I've seen is something like
"we'll deal with this later". Specifically section 5 talking
about this is really weak...
M2: In some places, a PE-based scenario is implicitly assumed
M3: I would like the doc to be more careful in places where it
talks about using RPs to make sure this does not sound like
a permission to use RPs that we're signing off on.
More detailed comments follow below.
Alex
> 1.2 Overview of Virtual Private Networks
>
> ............ ................. ............
> . . . . . .
> . +---+ +-------+ +-------+ +---+ .
> . r3---| | | | | |----|CE2|---r5 .
> . | | | | | | +---+ .
> . |CE1|----| PE2 | | PE2 | : .
^^^
PE1?
> . | | | | | | +---+ .
> . r4---| | | | | |----|CE3|---r6 .
> . +---+ +-------+ +-------+ +---+ .
> . Customer . . Service . . Customer .
> . site 1 . . provider(s) . . site 2 .
> ............ ................. ............
>
> Figure 1.1: VPN interconnecting two sites.
>
>
> In general Provider Edge (PE) and Customer Edge (CE) devices may be
> either routers, LSRs, or IP switches. Some approaches may limit the
^^^^^^^^^^^
What is this?
> type of PE and/or CE device that can be used. For example, in some
> approaches the PE devices may be required to be routers.
>
> In this document, scope of the SP network is an IP or MPLS network.
> It is desired to interconnect the customer network sites via the SP
> network.
>
> In many cases, customer networks will make use of private IP
> addresses [RFC1918] or non-unique IP address (e.g., unregistered
> addresses). This implies that there is no guarantee that the IP
> addresses used in the customer network are globally unique. In the
> case that a single PE device provides services to multiple different
> customer networks, this implies that the addresses used in the
> different customer networks may overlap. The internal operation of
> the PE device needs to maintain a level of isolation between the
> packets from different customer networks.
M2 above.
> 2.1 Reference Model for Layer 3 PE-based VPN
>
> This subsection describes functional components and their
> relationship for implementing layer 3 PE-based VPN.
>
> Figure 2.1 shows the reference model for layer 3 PE-based VPNs and
> Figures 2.2 and 2.3 show relationship between entities in the
> reference model.
Minor: looking at 2.3 from this place, some things (like hierarchical tunnel)
have not yet been introduced.
> 2.1.1 Entities in the reference model
...
> o P router
>
> A router within a provider network which is used to interconnect PE
> devices, but which does not have any VPN state and does not have
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
it was great to see this--very important
and very correct.
...
> o VPN forwarding instance (VFI)
>
> A VFI is a logical entity that resides in a PE, that includes the
> router information base and forwarding information base for a VPN.
> A VFI enables router functions dedicated to serving a particular
> VPN. In general a VFI terminates VPN tunnels for interconnection
> with other VFIs and also terminates access connections for
> accommodating CEs. The interaction between routing and VFIs is
> discussed in section 4.4.2.
This definition does not really give the reader any idea
about why we need VFIs, such as overlapping addressing
schemes.
...
> 3.1.2 Layer 3 provider provisioned CE-based VPN
>
> In the context of layer 3 provider provisioned CE-based VPNs, the PE
> devices have no knowledge of the establishment of VPNs at their
> customer interface.
>
> CE devices have IP/MPLS connectivity via a connection to a PE device.
^^^^^^^
can we make this "IP or MPLS" from here on?
some can read this as "IP MPLS", i.e., "MPLS for IP"
> The IP connectivity may be via a static binding, or via some kind of
> dynamic binding.
>
> The establishment of the VPNs is done at the CE devices, making use
> of the IP/MPLS connectivity to the SP network.
^^^^^^^^^^
M1
...
> 3.2.2 Layer 3 provider provisioned CE-based VPN
>
> The data exchanged at the customer interface are always normal IP
> packets that are routable in the SP's network or MPLS frames that can
^^^^^^^^^^^^
M1
> be label-switched across the SP network.
^^^^^^^^^^
M1
> The PE device does not
> assign any VPN meaning to IP or MPLS packets on the access
> connection; all VPN meaning is confined to the CE devices.
>
...
> 3.3.1.2 Routing for extranets
>
> In the extranet case the sites to be interconnected belong to
> multiple different administrations. In this case IGPs (such as OSPF,
> IS-IS, or RIP) are normally not used across the interface between
> organizations. Either static routes or BGP may be used between
> sites. If the customer network administration wishes to maintain
> control of routing between its site and other networks, then either
> static routing or BGP may be used across the customer interface. If
> the customer wants to outsource all such control to the provider,
> then an IGP or static routes may be used at this interface.
>
> The use of BGP between sites allows for policy based routing between
> sites. This is particularly useful in the extranet case.
No consideration on overlapping address spaces here?
It's definitely more complicated than just policing
the route exchange.
> 3.3.1.3 CE and PE devices for layer 3 PE-based VPNs
>
> When using a single IGP area across an intranet, the entire customer
> network participates in a single area of an IGP. In this case, for
> layer 3 PE-based VPNs both CE and PE devices participate as normal
> routers within the area.
>
>
>
>
> Design Team Expires October 2002 [Page 27]
>
> INTERNET-DRAFT A Framework for L3 PPVPNs April 2002
>
>
> The other options make a distinction between routing within a site,
> and routing between sites. In this case, the CE devices would
> normally be considered as part of the site where they are located.
> However, there is an option regarding how the PE devices should be
> considered.
>
> In some cases, from the perspective of routing within the customer
> network, the PE devices (or more precisely the VFI within a PE
> device) may be considered to be internal to the same area or routing
> domain as the site to which they are attached. This simplifies the
> management responsibilities of the customer network administration,
> since inter-area routing would be handled by the provider.
>
> For example, suppose that either static routes or BGP are used
> between sites. With this approach each site could operate as a
> single IGP area, and the access connection would simply be configured
> as internal links within that area. Static routes or BGP for inter-
> site routing can be handled by the provider.
What about IGPs used for inter-site?
>
> In other cases, from the perspective of routing within the customer
> network, the CE devices may be the "edge" routers of the IGP area.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What is this?
> In this case, static routing, BGP, or whatever routing is used in the
> backbone, may be used across the customer interface.
>
> 3.3.2 Customer view of routing for layer 3 provider provisioned CE-based
> VPNs
>
> For layer 3 provider provisioned CE-based VPNs, the PE device and P
> router are not aware of the reachability within the customer sites.
> The CE and PE devices don't exchange customer's routing information.
> The routing in the customer VPN is transparent to the SP's network.
>
> This means no VPN routes need to be maintained in any of the SP's
> PE/P devices.
>
> Customer sites that belong to the same VPN may exchange routing
> information through the VPN tunnels that are seen as CE to CE
> interconnecting links from the customer's perspective.
> Alternatively, instead of exchanging routing information through the
> VPN tunnels, the SP's management system may take care of the
> distribution of the routing information of one site towards the other
> sites in the VPN.
Management system taking care about routing... Should probably be more
specific and say that static routes are meant, not that we'll inject
dynamic info from VPN sites into whatever management system the SP
uses.
...
> 4. Network Interface and SP Support of VPNs
>
> 4.1 Functional Components of a VPN
>
> The basic functional components of an implementation of a VPN are:
>
> o A mechanism to acquire VPN membership/capability information
>
> o A mechanism to tunnel traffic between VPN sites
>
> o For layer 3 PE-based VPNs, a means to learn customer routes,
> distribute them across the provider network, and to advertise
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
M1 + can we be more specific here
and say between PEs?
> reachable destinations to customer sites.
...
> VPN membership and capability information can be distributed via
> routing protocols such as BGP,
M3
> central management system such as LDAP
> or manual configuration. Manual configuration does not scale and is
> error prone, and therefore is discouraged.
...
> 4.2.1 VPN discovery
>
...
> A number of different approaches are possible for VPN discovery. One
> scheme uses the network management system to configure and provision
> the PEs (or CEs for layer 3 provider provisioned CE-based VPN). This
> approach can also be used to distribute VPN discovery information,
> either using proprietary protocols or using standard management
> protocols and MIBs. Another approach is where the PEs (or CEs) act
> as clients of a centralized directory or database server that
>
>
>
> Design Team Expires October 2002 [Page 33]
>
> INTERNET-DRAFT A Framework for L3 PPVPNs April 2002
>
>
> contains VPN discovery information. Another is where VPN discovery
> information is piggybacked onto a routing protocol running between
> the PEs (or CEs) [VPN-DISC].
M3.
...
> 4.2.1.1 Network management for membership information
>
> SPs use network management extensively to configure and monitor
> various devices in their network, which may be distributed across
> geographically separate sites. The same approach could be used for
> distributing VPN related information as well. A network management
> system (either centralized or distributed) could be used by the SP to
> configure and provision VPNs on PE devices (or CEs devices for layer
> 3 provider provisioned CE-based VPN) at various locations. VPN
> configuration information could be entered into the network
> management application and distributed via SNMP, XML, CLI, or other
> means to the remote sites. This approach can be very effectively
> used within an SP network, since the SP has access to all PEs (or
> CEs) in its domain. Security and access control are important, and
> could be achieved for example using SNMPv3, SSH, or IPsec tunnels.
> Standardized MIBs will need to be developed before this approach can
> be used to configure PEs (or CEs) across SP boundaries.
Hmmm.. does this implicitly assume that one SP would configure a PE in
another SP's network?
...
> 4.2.1.2 Directory servers
>
> An SP typically needs to maintain a database of its customer's
> configuration/membership information regardless of the mechanisms
> used to distribute it. LDAP [RFC1777] is a standard directory
> protocol which makes it possible to use a common mechanism for both
> storing such information and distributing it.
>
> LDAP defines a schema, which is a standard format for representing
I though schemas were defined independently _for_ LDAP, not by it,
might be wrong though, not an LDAP expert.
> information that will be stored in an LDAP server. Having a standard
> schema ensures interoperability between different implementations of
> LDAP servers and clients. Moreover, LDAPv3 [RFC2251] supports
> authentication of messages and associated access control, which can
> be used to limit access to VPN information to authorized entities.
>
> 4.2.1.3 Augmented routing for membership information
>
> BGP supports extensions which allows it to carry VPN information.
> This allows the VPN discovery information and routing information to
> be combined in a single protocol. BGP is also widely deployed by SPs
> [VPN-2547BIS].
>
>
>
>
>
> Design Team Expires October 2002 [Page 34]
>
> INTERNET-DRAFT A Framework for L3 PPVPNs April 2002
>
>
> BGP also contains mechanisms to control route distribution. Route
> filters can be used to constraining the distribution of routing
> information. Information needed to establish per-VPN tunnels can
> also be carried by this routing instance.
>
> Augmented routing may be done in combination with aggregated routing,
> as discussed in section 4.4.4.
M3 in this section.
Also, more considerations are necessary for Inet edge-to-edge
scenarios.
> 4.2.1.4 Multi-SP VPNs
>
> When two sites of a VPN are connected to different SP networks, there
> must be a common mechanism for exchanging membership/capability
> information. At least one mechanism for VPN information discovery
> must be standardized and supported across multiple SPs. Inter-SP
> trust relationships will need to be established that will allow for
> exchange of membership information across SP boundaries. Also, some
> mechanisms will be needed to control which membership information is
> exchanged between SPs.
M3. Seems a bit too weak.
What about amount of info, scaling distribution of it,
its growth and dynamics, its uniqueness?
> 4.2.2 Constraining distribution of VPN routing information
>
> With layer 3 provider provisioned CE-based VPNs, the VPN service
> provides tunnels between CE devices. In this case, distribution of
> IP routing information occurs between CE devices on the customer
> sites and is therefore outside of the scope of the provider aspects
> of VPN support.
> A possibility for layer 3 provider provisioned CE-
> based VPNs though, is that the SP takes care of the inter-site
> distribution of routing information, while the intra-site
> distribution remains outside of the scope of the provider's control.
I stumbled here... So, how does this fit within the global
picture of PE/CE separation? What is the management model?
Another instances of M3, btw.
...
> 4.2.3 Controlling VPN topology
>
...
> The selection of a topology for a VPN is an administrative choice,
> but it is useful to examine protocol mechanisms that can be used to
> automate the construction of the desired topology, and thus reduce
> the amount of configuration needed. To this end it is useful for a
> PE (or CE) to be able to advertise per-VPN topology information to
> other PEs (or CEs). Typically this per-VPN topology information is
> advertised using the same mechanism that is used to advertise
> membership information.
> The topology information may be associated
> with a PE (or CE), or with subsets of routes reachable via that PE
> (or CE).
Huh? Topology associated with routes???
...
> For layer 3 provider provisioned CE-based VPNs, as it is not common
> to have inter-CE distribution protocols, the VPN topology is
> restricted by configuring every CE only with the other CEs it has to
> establish tunnels to. As such, when a new CE is added to an existing
> VPN, the VPN topology will dictate which other CEs need to be
> notified.
What's wrong with CE-based VPNs from this perspective?
If I have a bunch of CEs in a VPN, I still want to control
the topology of tunnels between them...
> 4.3 VPN Tunneling
>
> VPN solutions use tunneling in order to transport VPN packets across
> the SP network.
M1 !
> There are different types of tunneling protocols,
...
> One motivation for the use of tunneling is that the packet addressing
> used in a VPN may have no relation to the packet addressing used
> across the SP network.
M1
> For example the customer VPN traffic could
...
> forwarding the packet across the SP network.
M1
...
>
> The specific tunneling protocols considered in this section are MPLS,
> GRE, IPsec, and IP-in-IP as these are the most suitable for carrying
Nice ordering ;) Let's make it alphabetic ;)
> VPN traffic across an SP backbone.
M1
> Other tunneling protocols, such
> as L2TP [RFC2661], are used primarily to tunnel users across an
> access network to a PE or access server, or are used in a CE-based
> VPN. As the tunneling protocol used across the SP network between
M1
> PEs is orthogonal to how sites and subscribers access the VPN, these
> access side tunneling protocols are not discussed here.
So, I don't get it. The sentence above says L2TP is used in CE-based
VPNs, but then it says it is not considered here... Hmmm...
> 4.3.1 Tunnel encapsulations
>
> All tunneling protocols use an encapsulation that adds additional
> information to the packet that is used for forwarding across the SP
> network. Examples are provided in section 4.3.6.
M1
> One characteristic of a tunneling protocol is whether per-tunnel
> state is needed in the SP network in order to forward the tunneled
> packets. For IP tunneling schemes (GRE, IPsec, and IP-in-IP) no such
> per-tunnel state is needed since forwarding is carried out using the
> outer IP header. When forwarding packets core routers make no
> distinction between tunneled and non-tunneled packets.
^^^^^^^^^^^^^^^^^^^^^^^^^
maybe what is really meant here is
"encapsulating and non-encapsulating"
packets?
> For MPLS,
> per-tunnel state is needed, since the top label in the label stack
> must be examined and swapped by intermediate LSRs. The amount of
> state required can be minimized by hierarchical multiplexing, and by
> use of multi-point to point tunnels, as discussed below.
>
> Another characteristic is the tunneling overhead introduced. With
> IPsec the overhead may be considerable as it may include, for
> example, an ESP header, ESP trailer and an additional IP header. The
> other mechanisms listed use less overhead, with MPLS being the most
> lightweight. The overhead inherent in any tunneling mechanism may
> result in additional IP packet fragmentation, if the resulting packet
> is too large to be carried by the underlying link layer. As such it
> is important to report any reduced MTU sizes via mechanisms such as
> path MTU discovery in order to avoid fragmentation wherever possible.
Other considerations here, such as transparency to the Internet?
...
> 4.3.3 Tunnel establishment
...
> Multiplexing field values can also be exchanged without the use of an
> explicit signaling protocol. For example MPLS labels can be
> piggybacked on the protocol used for the distribution of VPN routes,
> or on a protocol used for VPN membership. GRE and IP-in-IP have no
> associated signaling protocol, and thus by necessity the multiplexing
> values are distributed via some other mechanism, such as via
> configuration, control protocol, or piggybacked in some manner on a
> VPN membership or VPN routing protocol.
^^^^^^^^^^^^^^^^^^^^
I thought we were talking about _tunnel_
mux'ing, not route mux'ing.
> The resources used by the different tunneling establishment
> mechanisms may vary. With a full mesh VPN topology, and explicit
> signaling, each PE (or CE for layer 3 provider provisioned CE-based
> VPNs) has to establish a tunnel to all the other PEs (or CEs) for
> every VPN. The resources needed for this on a PE (or CE) may be
> significant and issues such as the time needed to recover following a
> device failure may also be taken into account, due to the need to
> have to reestablish a large number of tunnels.
Looks like we need more thought put into this part.
For example, scaling characteristics of signalling devices
in PE- and CE-based scenarios will vary, as CEs are normally
busy with one VPN.
> 4.3.4 Scaling and hierarchical tunnels
>
...
> One example using hierarchical tunnels is the use of an MPLS label
> stack. A single PE-PE LSP is used to carry all the per-VPN LSPs.
> The mechanisms used for label establishment are typically different.
> The PE-PE LSP could be established using LDP, as part or normal
> backbone operation, with the per-VPN LSP labels established by
> piggybacking on VPN routing (e.g., using BGP).
Has "VPN routing" been defined?
M3 as well.
> 4.3.5 Tunnel maintenance
...
> A tunneling protocol may have a built-in keep alive mechanism that
> can be used to detect loss connectivity. The base IPsec standard
> does not contain such a mechanism but there are proposals to extended
> IPsec in this manner. GRE and IP-in-IP tunneling have no such
> mechanism.
^
and usually rely on IGP hello mechanisms.
> MPLS detects failures as part of the signaling protocols.
>
> With hierarchical tunnels it may suffice to only monitor the
> outermost tunnel for loss of connectivity. However there may be
> failure modes in a device where the outermost tunnel is up but one of
> the inner tunnels is down.
>
> 4.3.6 Survey of tunneling techniques
>
> Tunneling mechanisms provide isolated and secure communication
^^^^^^
hmmm... in what sense?
> between two CE/PE devices. Available tunneling mechanisms include
> (but are not limited to): MPLS [RFC3031] [RFC3035], GRE [RFC2784]
> [RFC2890], IPsec [RFC2401] [RFC2402], and IP-in-IP encapsulation
> [RFC2003] [RFC2473].
Should we stick with the alphabetic order here and below?
> 4.3.6.1 MPLS [RFC3031] [RFC3035]
>
> Multiprotocol Label Switching (MPLS) is a method for forwarding
> packets through a network. Routers at the edge of a network apply
> simple labels to packets. A label may be inserted between the data
> link and network headers, or may be carried in the data link header
> (e.g., the VPI/VCI field in an ATM header). Routers in the network
>
>
>
> Design Team Expires October 2002 [Page 42]
>
> INTERNET-DRAFT A Framework for L3 PPVPNs April 2002
>
>
> switch packets according to the labels with minimal lookup overhead.
> A path, or a tunnel in the PPVPN, is called a "label switched path
> (LSP)."
Here and onwards for other tunneling mechanisms, I'd like
to see another two characteristics:
o State maintained by tunnel end points and intermediated
routers
o Internet transparency and requirements for contiguous support
> o Multiplexing
>
> LSPs may be multiplexed into another LSP.
>
> o Multiprotocol transport
>
> MPLS can carry data packets other than IP.
Let's be frank and admit that only one protocol per LSP
is allowed.
> 4.3.6.2 GRE [RFC2784] [RFC2890]
...
> o Multiprotocol transport
>
> GRE is assumed to support any type of payload protocol.
^^^^^^^^^^
? why so unsure compared to "MPLS can carry"?
> 4.3.6.4 IP-in-IP encapsulation [RFC2003] [RFC2473]
...
> o Multiprotocol transport
>
> IP-in-IP needs extensions to carry packets other than IP.
Can we still call it "IP-in-IP" then? :)
...
> 4.4 Routing for VPNs Across the SP Network
M1 is a meta meta issue for this section....
...
> The SP network needs to carry two types of information: (i) Routing
> information about the public network (including routes to the public
> Internet); (ii) Routing information about routes within the customer
> networks served by the VPNs. Routing for the Internet or for public
> IP networks are outside of the scope of this document.
In this para above, I don't see why the SP network as whole needs
to know this data, not just PEs...
...
> 4.4 Routing for VPNs Across the SP Network
Hmmm.. I see scalability considerations in the previous
section talking about tunneling, but not in this one,
which has more potential problems... We need it here.
> 4.4.1 Options for VPN routing in the SP
^^^^^^^^^^^
defined?
> The following technologies can be used for exchanging routing
> information within an SP network:
which "routing info" SP's or VPN?
M1.
> o Static routing (see section 3.3.3)
>
> o RIP (see section 3.3.3)
>
> o OSPF (see section 3.3.3)
>
3.3.3 talks about customer-visible routing.
what is it doing here?
> o BGP (see section 3.3.3)
>
> o Multiprotocol BGP-4 [RFC2858]
>
> BGP-4 has been extended to support IPv6, IPX, and others as well as
> IPv4 [RFC2283]. Multiprotocol BGP-4 carries routes from multiple
> "address families," such as the "VPN-IPv4 address family" discussed
> in [VPN-2547BIS].
I would suggest that we do not separate "BGP" and "Multiprotocol BGP".
It is still one protocol--our dear BGP, which we use for Internet routing,
not a separate piece of code running on a separate set of boxes...
> 4.4.2 VPN forwarding instances (VFIs)
>
...
> In general, a routing protocol instance may populate multiple VFIs,
> or a single VFI. Also, a VFI may be populated by a single routing
> protocol, or multiple routing protocols. Therefore there is not
> necessarily a one to one correspondence between VFI and routing
> protocol instance.
M3
Please be more specific here, what is meant by populating VFIs?
I don't see any considerations on the drawbacks that this
approach induces.
> There are several options for how VPN routes are carried across the
> SP network, as discussed below.
>
> 4.4.3 Per-VPN routing
...
> This approach minimizes the interactions between multiple different
> VPNs
as well as with the SP's backbone and the Internet routing system.
> , in that routing is done independently for each VPN. However,
> with this approach each PE device implements the capabilities of
> multiple different routers. This implies that some sharing of
> resources may occur within the PE device.
...
> 4.4.4 Aggregated routing model
>
> Another option is to use one single instance of a routing protocol
> for carrying VPN routing information across the SP network. With
> this method the routing information for multiple different VPNs is
> aggregated into a single routing protocol. This implies that
> whichever routing protocol is used in the SP network needs to be
> enhanced to allow routes from different VPNs to be distinguished.
M3
No. This implies that routes from VPNs can be distributed together,
but this does not mean that the SP's routing system should be
used for this purpose.
> In this approach, the number of routing protocol instances in a PE
> device does not depend on the number of CEs supported by the PE
> device, if the routing between PE and CE devices is static or BGP-4.
> However, CE and PE devices in a VPN exchange route information inside
> a VPN using a routing protocol except for BGP-4, the number of
> routing protocol entities in a PE device depends on the number of CEs
> supported by the PE device.
>
> In principle it is possible for routing to be aggregated using either
> BGP or on an IGP.
I'd like to see more detailed analysis on this particular approach
(aggregated routing). Specifically, please explore the topics of
scalability, stability, and transparency to the Internet routing
system.
> 4.4.4.1 Aggregated routing with OSPF or IS-IS
...
> broadcast to all routers in the area, even routers which don't want
> to know about any one particular VPN.
> Given the potential magnitude
> of the total routing information required for supporting a large
> number of VPNs, this broadcast may have unfortunate scaling
> implications.
Remember this one. Magically, this potential magnitude does not
bother us when we talk about BGP...
...
> 4.4.4.2 Aggregated routing with BGP
M3 in this whole section...
Needs considerations on Inet edge-to-edge scenarios, potential
impact on SP's and Internet BGP infrastructure...
...
> 5. Interworking Interface
This section is quite weak. It does not talk about scenarios where
no end-to-end service required for a specific VPN solution (such
MPLS/BGP) is provided. No considerations on exchanging of VPN
membership info, etc...
--the end---
Randy:
> M0: why is this work in SUB area? It is all about routing
> and hopefully not MPLS-specific... Randy would have
> another chance to say that a more experienced person
> would his mouth shut, and it is not that we don't have
> enough stuff to deal with in RTG, but really...
what are the routing aspects of ipsec and other L3 tunneling
technologies? of course, they're not very sub-ip either,
are they?
> M1: In many, many places the document talks about a SP's network
> as opposed to edge-to-edge through the Internet. I don't know
> if this is intentional or not, but it seems to me that we
> should want the WG to develop a solution that is able to
> work very well across the Internet as well as within a single
> SP as a special case... So far what I've seen is something like
> "we'll deal with this later". Specifically section 5 talking
> about this is really weak...
and it continues to confuse provider PROVISIONED with provider
PROVIDED. i.e. providers provision cpe-based L2 and L3 vpn kit.
> M2: In some places, a PE-based scenario is implicitly assumed
'zactly
> M3: I would like the doc to be more careful in places where it
> talks about using RPs to make sure this does not sound like
> a permission to use RPs that we're signing off on.
<smile>
i was 1/3 through this one when your message came in. thank you
for saving me from the other 2/3.
RFC Editor Note:
Section 4.2.1.1, 1st paragraph
Replace OLD:
VPN configuration information could be
entered into the network management application and distributed via
SNMP, XML, CLI, or other means to the remote sites.
With NEW:
VPN configuration information could be
entered into a network management application and distributed to the
remote sites via the same means used to distribute other network
management information.
----------------------------------------------
Section 4.3.6.2, 6th paragraph (5th item)
Replace OLD:
An SP network which supports VPNs must do extensive IP address
filtering at its borders to prevent spoofed packets from
penetrating the VPNs. An SP network which supports VPNs must do
extensive IP address filtering at its borders to prevent spoofed
packets from penetrating the VPNs.
With NEW:
An SP network which supports VPNs must do extensive IP address
filtering at its borders to prevent spoofed packets from
penetrating the VPNs.
----------------------------------------------
Section 4.7.1, 4th paragraph
Replace OLD:
Use of proprietary command-line interfaces is
highly undesirable for this task, as they do not lend themselves to
standard representations of managed objects.
With NEW:
Use of proprietary command-line interfaces has
the disadvantage that proprietary interfaces do not lend themselves
to standard representations of managed objects.
----------------------------------------------
Section 5.2, 3rd paragraph
DELETE OLD:
With layer 3 VPNs it is normal for PEs to have a physical link per
VPN. In this case the PEs which terminate the interworking interface
have a tunnel per VPN.
----------------------------------------------
Intellectual Property, 1st paragraph
Replace OLD:
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
With NEW:
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
