Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management
draft-ietf-l3vpn-mgt-fwk-08

[Ballot discuss]
Holding this discuss for Harald, so see his text for details. I've asked Joel (the reviewer) if he is satisfied with the new version.

[Ballot comment]
I am not so sure if this is a "framework" or if it is more an
overview of all sorts of management aspects of L3VPN.
I have had simialr feelings woth earlier "framework" documents,
so I will leave it to the responsible AD to see if the title
might better be changed.

Section 1.1 (inlcuding reference to RFC2119) seems completely
useless, becasue these terms are not used in this document
(as far as I can tell)

I see IPSec spelles with capital S. I am sure the sec ADs want
it spelled as IPsec!

Section 4.
I would not speak of "information bases" but instead about
"management information" ormaybe "management objects"

I would change "standard MIB" into "standards track MIB Module"

sect 4.1 again speaks about "standard protocols such as..."
Much better to speak of "standards track protocols..."
But even then, NetConf is target for standards track but is still
in WG last Call.

I doubt that RFC2629 is a NORMATIVE reference!

[Ballot discuss]
Joel Halpern's review seems to point out some issues with scoping of this document - use of rather grandiose titles of some sections without the content to support it. Comments solicited.

Review by Joel Halpern, Gen-ART:

This document is close to ready for publication as an Information RFC.
There are some issues of clarity of purpose and clarity of wording
that should be addressed.


Section 2, called "Service Operation and Management" is actually an
effort to talk about customer facing service interfaces.  While this
is an interesting topic, I repeatedly found myself wondering why I was
reading it.  And where the rest of "Service Operations and Management"
(which is much broader than the customer facing function) had gone.  I
suspect that section 2 needs a different title, and an explanation of
how its contents relate to any expected other work.  I am tempted to
wonder if this was intended to provide a context for customer facing
SNMP views?

Section 2.1 claims "this section presents the information model that
is used for L3VPN service management at the SML."  This statement is
inaccurate in several ways.  What follows it is not even an
information model.  There probably is not and should not be "the"
information model for this.  And even in an informational document,
defining this model in an IETF document seems a stretch.  If we
actually intend to produce protocol solutions in this space, and if
this section is intended to be relevant, than it needs a lot more
detail.

Section 2.2.7 is a very clear and well put together description of
some issues relating to authenticating VPN participants.  However, I
can no understand what it is doing in the middle of a Customer
Management section.  Possibly it does belong, but if so some
additional text is needed to relate it to the rest of the section.

Section 2.3 might generously be described as a Customer Management
Decomposition.  It isn't an architecture (the section is called
"Customer Management Architecture")

As a whole, section 3 is nicely put together.  The usage of "must" in
many of the items is odd, but probably accurate.  The document tends
to use "must" without qualification when it really means "must, if it
is meaningful".  This is particularly noticeable in 3.2.6, and to a
lesser degree in 3.2.7.  (3.2.7 makes an effort to first state "these
things may not be present.")  For example "Managed firewalls must be
supported on a per-VPN basis" is really saying ~If you include
firewalls in the service, then make sure they are manageable on a
per-VPN basis.~ and saying it oddly.

From: Thomas Narten
To: arnaud.gonguet@alcatel.fr, khchan@nortelnetworks.com,
    mohamed.boucadair@francetelecom.com, tnadeau@cisco.com,
    yacine.el_mghazli@alcatel.fr
cc: "Rick Wilder" , Ross Callon ,
    "Ronald Bonica"
Date: Wed, 09 Feb 2005 12:43:38 -0500
Subject: AD review of draft-ietf-l3vpn-mgt-fwk-03.txt

I have no major issues with this document. One question though:

>    [I-D.ietf-mpls-oam-requirements]
>              Nadeau, T., "OAM Requirements for MPLS Networks",
>              draft-ietf-mpls-oam-requirements-04 (work in progress),
>

is listed as a normative reference. Is this really necessary? And what
is the status of this document? (It is apparently still in the mpls
WG).

With the current normative reference, this document can't be published
until the mpls-oam document is also in the RFC Editor's queue.

I'm going to go ahead and put this document on the IESG's agenda for
next week's telechat.

Minor nits/comments:

>      Provider Provisioned VPN denotes VPNs for which a service provider

should be "provider-provisioned"

>    L3VPN:
>      A L3VPN is a VPN that interconnects several sets of hosts and
>      routers and allow them to communicate based on their L3 addresses.
>      See [I-D.ietf-l3vpn-ppvpn-terminology] and
>      [I-D.ietf-l3vpn-framework].

Not the clearest defintion...

>      quality garantuees and retribution procedures when service levels

misspelling of guarantuees.

>    users to configure and provisions each instance from a central

s/provisions/provision/

>    A SP must be able to manage the capabilities and characteristics of

s/A SP/An SP/

>      service information.  Customer specific information includes data

s/Customer specific/Customer-specific/

>    In both models, the service manager administrates customer specific

s/customer specific/customer-specific/

>    receive response from the SP network in response to these requests

s/response/responses/

>    associated with each customer's VPN in terms of set of relevant

s/set/a set/???

>    the customer visible services, high availability service for the

s/customer visible/customer-visible/

>    could be a protocol that systematically checks all constraints have

s/all/that all/

>      be configured on a per VPN basis.  The Provider Network Manager

s/per VPN/per-VPN/

>      must support configuration of CE routing protocol for each access

s/CE/a CE/

> 3.2.8  Provisioning Hybrid VPN Services
>
>    Configuration of inter-working L3VPN solutions should also be
>    supported.  Ensuring that security and end-to-end QoS issues are
>    addressed.

last sentence is not a sentence...

Thomas

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, arnaud.gonguet@alcatel.fr, khchan@nortelnetworks.com, mohamed.boucadair@francetelecom.com, tnadeau@cisco.com, yacine.el_mghazli@alcatel.fr from rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net