A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
RFC 4110

rfc-ed 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.

The spec is tentatively approved subject to addressing the following editorial issues. An rfc-ed note is being prepared by the authors.

> In 4.2.1.1, "VPN configuration information could be
> entered into the network management application and distributed via
> SNMP, XML, CLI, or other means to the remote sites."
>
> I think this is confusing the formats and methods for entering
> data into the application and the distribution mechanism.  A
> command-line interface doesn't distribute anything, and XML
> is a data format, not a distribution protocol.
>
> In Section 4.3.6.2, one of the sentences related to security is
> repeated:
>
>      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.
>
> In Section 5.2:
>
>
>    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.
>
> Is this a typo for "With layer 2 VPNs"?

the one above is rather a question...

> > - I find it amusing/strange to read on top of page 64:
> >    NMS system.  This must be achieved using standard
> protocols such as
> >    SNMP, XML, or LDAP.  Use of proprietary command-line
> interfaces is
> >    highly undesirable for this task, as they do not lend
> themselves to
> >    standard representations of managed objects.
> >  And then a few paragraphs down on same page:
> >    employed.  Examples of how this can be achieved include
> encrypted
> >    telnet sessions for CLI-based management, IPsec
> tunnels, or SNMP V3
> >    encryption for SNMP-based management.
> >  That is, the first para strongly discourages use of CLI while the
> >  other para lists as first item how to secure CLI-based management.

> - IPR section is NOT according to the sorts of IPR
>  sections that we normally see based on RFC2026 sect 10.4
>  2 paragraphs are missing

2003-03-06 - allison comments
4.6.1

  For TCP traffic, L3 PPVPN devices should support Random Early
  Detection (RED) to provide graceful degradation in the event of
  network congestion.

It would be very inappropriate for RED to work on TCP only!  This
must mean Internet traffic.

5.5.2

The document says that it goes with ITU Y.1311.1 in supporting
endpoint markings of DSCP to be preserved and not changed through
the SP network.  This is for genuine discussion:  how do we reconcile
this with the diffserv model?  We are raising two different models in
under the big IETF tent?  It seems potentially damaging to diffserv.

6.10.4 Security Considerations
  If a tunnel traverses multiple SP networks and it passes through an
  unsecured SP, POP, NAP, or IX, then security mechanisms must be
  employed.

This refers to the security requirements for QoS brokering inter-AS,
I believe.  It would be nice if the draft did not present the reader with
this empty statement but had some substantial suggestion about how to
provide an approach to securing the process, for instance by referencing
another part of the document.

2003-03-06 - additional nit
In section 5.3 it mentions the followin:

    o globally unique addresses obtained by the customer from IANA

remove reference to IANA

2003-03-06 - note to WG chairs

see ID tracker - a revised ID is needed

fix teh number of authors

correct text on IPR statement (see rfc 2026 sec 10.4(D))

update LDAP references

fix SNMP V3

2003-03-06 - bert comments

- Has some 9 or 10 people on front page ??!!

- Has twice (page 18), once on page 23

    The customer management function may use a combination of SNMP
    manager, directory service (e.g., LDAP [RFC1777] [RFC2251]), or
    proprietary network management system.
 
  RFC1777 is HISTORIC, so os this wise?

  In section 4.2.1.2 it even claims that LDAP [RFC1777] is standadard:

  used to distribute it.  LDAP [RFC1777] is a standard directory
  protocol which makes it possible to use a common mechanism for both

 
- I see them use "SNMPv3" but also "SNMP V3"
  That would be better done consistent with "SNMPv3"

- I find it amusing/strange to read on top of page 64:
    NMS system.  This must be achieved using standard protocols such as
    SNMP, XML, or LDAP.  Use of proprietary command-line interfaces is
    highly undesirable for this task, as they do not lend themselves to
    standard representations of managed objects.
  And then a few paragraphs down on same page:
    employed.  Examples of how this can be achieved include encrypted
    telnet sessions for CLI-based management, IPsec tunnels, or SNMP V3
    encryption for SNMP-based management.
  That is, the first para strongly discourages use of CLI while the
  other para lists as first item how to secure CLI-based management.

  Oh well..

- Is this the new form for an IPR statement??:
  Intellectual Property

  Intellectual property rights may have been claimed with regard to
  some of the techniques and mechanisms described in this framework
  document.  For more information consult the online list of claimed
  rights maintained by the IETF at http://www.ietf.org/ipr.html.

I always wonder when I read these sort of docs:

  MMMmmm... is this a FRAMEWORK ???
  Or just an overview of all sorts of different ways to do things?

2003-02-06 - note from authors

As I announced on the PPVPN ML, the L3 framework design team submitted
draft-ietf-ppvpn-framework-07.txt as an update document. We believe the
draft reflects all of your comments and our discussions about it.
We are confident that the draft is now achieved sufficient quality to
publish as an Info RFC. We are looking forward to hear your further
comments on it.

Thanks,

Muneyoshi Suzuki

2002-11-02 - iesg discussion - comments to come
note to WG chairs

sorry - I should have seen this earlier - there are too many
authors on draft-ietf-ppvpn-framework - the current (and
for teh last 6 months) rules are a max of 5 - but most commonly
a doc of this type will have one or two editors and the rest of
the people get moved to the acknowledgements section or a new
contributor's section gets added for the other folk

see draft-ietf-mpls-generalized-cr-ldp for an example

I expect to get some specific IESG comments (I hope soon) on
teh document

State Changes to In WG                                            from New Version Needed (WG/Author)                    by sob

State Changes to New Version Needed (WG/Author)                    from Reading List                                      by sob

State Changes to Reading List                                      from In WG                                            by sob