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.