Provider Provisioned Virtual Private Network (VPN) Terminology
draft-ietf-l3vpn-ppvpn-terminology-04

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net,rbonica@juniper.net,loa@pi.se, tove@niebelungen.net from rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com,loa@pi.se, tove@niebelungen.net

[Ballot comment]
I was very close to putting in a DISCUSS based on the following:

This document depends heavely on a long list of informational references.
Strictly speaking,
they are indeed informational (that is why this is a COMMENT and not a DISCUSS), but several sections would become fairly hard to read if work
doesn't progress or changes substantially. I think it would be a good idea
to review the list of references and see if the document can become
less depended on work in progress.

Comments received from the ops directorate by Pekka Savola:

- there is just one normative reference, RFC2119, which is not even
used (remove!).  This document relies so heavily on other L2/3VPN
documents that going forward without making them normative seems like
a bad approach for two reasons: reading the framework/reqs documents
seem to be necessary for understanding this document, and because if
the those documents haven't been approved yet, the contents might
still change.

Editorial issues:

- abstract, introduction and section 2 in particular have language
which will no longer be valid 5 years from now when this is an RFC.
Maybe the wording needs to be tuned a bit to be more future-proof?
This also happens throughout the document.

- should section 3.1 on IPLS be tuned a bit to state IPv6 explicitly?
(This was updated in the l2vpn documents recently.)

- would it make sense to subsectionize 3 so that you'd first have the
"current terminology", and then a separate "legacy terminology" (such
as (TLS, VPSN, etc.etc.) -- this might make it clearer? (or just move
the legacy terms under the last 3.x subsection as their own 3.x.y
subsections).  Some wording should probably be inserted in 5.4 as
well.

Nits:
- spell out PPVPN in the title
- in section 2, I-D.ietf-l3vpn-framework is listed twice.
- in section 5.1.1.2, s/CE-bS/CE-S/ ?

[Ballot comment]
In the title of section 5.1.1.2, I believe CE-bS should be CE-S

In section 7.3, what's [DTLS-xxx] mean?  Is it an unresolved reference, or another name for an MTU, or something else?

[Ballot discuss]
This is a mild problem, and the document author is welcome to push back on it, but
I found structuring the abbreviations in 3 alphabetically ended up forcing a lot
of look-ahead and dependencies.  See 3.1, for example:

3.1  IP-only LAN-like Service (IPLS)


  An IPLS is very like a VPLS (see 3.8), except that:


  o  it is assumed that the CE devices (see 5.1) are hosts or routers,
      not switches
  o  it is assumed that the service will only need to carry IP packets,
      and supporting packets such as ICMP and ARP; otherwise layer 2
      packets which do not contain IP are not supported.


  While this service is a functional subset of the VPLS service, it is
  considered separately because it may be possible to provide it using
  different mechanisms, which may allow it to run on certain hardware
  platforms that cannot support the full VPLS functionality
  [I-D.ietf-l2vpn-l2-framework].

I am concerned that this limits the usability of the documents.  Restructuring
the definitions (so they are group logically) or the rewording them (so they
contain duplicate definitions) might help.

More seriously, in 5.1.2, the document says:

5.1.2  Service based CE naming


  The list below is just examples and it will be extended as the number
  of services increases.

Not in this RFC it won't.  This needs to be rephrased so that the reader
understands that this archival document only contains examples.

[Ballot comment]
In 3.3,
An L3VPN is a solution that interconnects several sets of hosts and
  routers and allows them to communicate based on L3 addresses, see
  [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have hosts dissolved into a L3vpn solvent...
"An L3VPN interconnects hosts and routers based on Layer 3 addresses,
see[]"?

In 3.6, the document confuses the purpose of a vlan with the mechanism used
to create one:

  A VLAN is a way of separating traffic on a LAN, e.g., between
  different departments within a company.  This acronym is not defined
  by former PPVPN working group, but is defined by IEEE 802.1Q.  The
  VLANID is used to mark an Ethernet frame with a tag to create user
  groups on a LAN.

  "Ther term VLAN was specified by IEEE 802.1Q; it defined a method to differentiate
    traffic on a LAN by tagging the Ethernet frames.  By extension, VLAN is used to mean
    the traffic separated by Ethernet frame tagging or similar mechanisms."

In 3.11:


  A Virtual Private Wire Service (VPWS) is a point-to-point circuit
  (link) connecting two Customer Edge devices.  The CE in the customer
  network is connected to a PE in the provider network via an
  Attachment Circuit (see 6.1); the Attachment Circuit is either a
  physical or a logical circuit.

Should the first sentence also note that the point-to-point circuit
at issue may be a logical one?  Otherwise it looks like a not-so-virtual
Private Wire.

In 5:

The building
  blocks are often used in day-to-day talk treated as if it were
  physical boxes, common for all services.

"treated' seems unnecessary, and there is a number disagreement
between the noun (blocks) and the pronoun (it).

In 6.4  Flooding


  Flooding is a function related to L2 and L3 services; when a PE
  receives a frame with an unknown destination MAC-address, that frame
  is send out over (flooded) every other interface.

So the L3 service uses MAC addresses?

[Ballot discuss]
This is a mild problem, and the document author is welcome to push back on it, but
I found structuring the abbreviations in 3 alphabetically ended up forcing a lot
of look-ahead and dependencies.  See 3.1, for example:

3.1  IP-only LAN-like Service (IPLS)


  An IPLS is very like a VPLS (see 3.8), except that:


  o  it is assumed that the CE devices (see 5.1) are hosts or routers,
      not switches
  o  it is assumed that the service will only need to carry IP packets,
      and supporting packets such as ICMP and ARP; otherwise layer 2
      packets which do not contain IP are not supported.


  While this service is a functional subset of the VPLS service, it is
  considered separately because it may be possible to provide it using
  different mechanisms, which may allow it to run on certain hardware
  platforms that cannot support the full VPLS functionality
  [I-D.ietf-l2vpn-l2-framework].

I am concerned that this limits the usability of the documents.  Restructuring
the definitions (so they are group logically) or the rewording them (so they
contain duplicate definitions) might help.

More seriously, in 5.1.2, the document says:

5.1.2  Service based CE naming


  The list below is just examples and it will be extended as the number
  of services increases.

Not in this RFC it won't.  This needs to be rephrased so that the reader
understands that this archival document only contains examples.

[Ballot comment]
In 3.3,
An L3VPN is a solution that interconnects several sets of hosts and
  routers and allows them to communicate based on L3 addresses, see
  [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have hosts dissolved into a L3vpn solvent...
"An L3VPN interconnects hosts and routers based on Layer 3 addresses,
see[]"?

In 3.6, the document confuses the purpose of a vlan with the mechanism used
to create one:

  A VLAN is a way of separating traffic on a LAN, e.g., between
  different departments within a company.  This acronym is not defined
  by former PPVPN working group, but is defined by IEEE 802.1Q.  The
  VLANID is used to mark an Ethernet frame with a tag to create user
  groups on a LAN.

  "Ther term VLAN was specified by IEEE 802.1Q; it defined a method to differentiate
    traffic on a LAN by tagging the Ethernet frames.  By extension, VLAN is used to mean
    the traffic separated by Ethernet frame tagging or similar mechanisms."

In 3.11:


  A Virtual Private Wire Service (VPWS) is a point-to-point circuit
  (link) connecting two Customer Edge devices.  The CE in the customer
  network is connected to a PE in the provider network via an
  Attachment Circuit (see 6.1); the Attachment Circuit is either a
  physical or a logical circuit.

Should the first sentence also note that the point-to-point circuit
at issue may be a logical one?  Otherwise it looks like a not-so-virtual
Private Wire.

In 5:

The building
  blocks are often used in day-to-day talk treated as if it were
  physical boxes, common for all services.

"treated' seems unnecessary, and there is a number disagreement
between the noun (blocks) and the pronoun (it).

[Ballot comment]
In 3.3,
An L3VPN is a solution that interconnects several sets of hosts and
  routers and allows them to communicate based on L3 addresses, see
  [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have hosts dissolved into a L3vpn solvent...
"An L3VPN interconnects hosts and routers based on Layer 3 addresses,
see[]"?

In 3.6, the document confuses the purpose of a vlan with the mechanism used
to create one:

  A VLAN is a way of separating traffic on a LAN, e.g., between
  different departments within a company.  This acronym is not defined
  by former PPVPN working group, but is defined by IEEE 802.1Q.  The
  VLANID is used to mark an Ethernet frame with a tag to create user
  groups on a LAN.

  "Ther term VLAN was specified by IEEE 802.1Q; it defined a method to differentiate
    traffic on a LAN by tagging the Ethernet frames.  By extension, VLAN is used to mean
    the traffic separated by Ethernet frame tagging or similar mechanisms."

In 3.11:


  A Virtual Private Wire Service (VPWS) is a point-to-point circuit
  (link) connecting two Customer Edge devices.  The CE in the customer
  network is connected to a PE in the provider network via an
  Attachment Circuit (see 6.1); the Attachment Circuit is either a
  physical or a logical circuit.

Should the first sentence also note that the point-to-point circuit
at issue may be a logical one?  Otherwise it looks like a not-so-virtual
Private Wire.

[Ballot comment]
In 3.3,
An L3VPN is a solution that interconnects several sets of hosts and
  routers and allows them to communicate based on L3 addresses, see
  [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have hosts dissolved into a L3vpn solvent...
"An L3VPN interconnects hosts and routers based on Layer 3 addresses,
see[]"?

In 3.6, the document confuses the purpose of a vlan with the mechanism used
to create one:

  A VLAN is a way of separating traffic on a LAN, e.g., between
  different departments within a company.  This acronym is not defined
  by former PPVPN working group, but is defined by IEEE 802.1Q.  The
  VLANID is used to mark an Ethernet frame with a tag to create user
  groups on a LAN.

  "Ther term VLAN was specified by IEEE 802.1Q; it defined a method to differentiate
    traffic on a LAN by tagging the Ethernet frames.  By extension, VLAN is used to mean
    the traffic separated by Ethernet frame tagging or similar mechanisms."

[Ballot comment]
In 3.3,
An L3VPN is a solution that interconnects several sets of hosts and
  routers and allows them to communicate based on L3 addresses, see
  [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have hosts dissolved into a L3vpn solvent...
"An L3VPN interconnects hosts and routers based on Layer 3 addresses,
see[]"?

[Ballot comment]
In 3.3,
An L3VPN is a solution that interconnects several sets of hosts and
  routers and allows them to communicate based on L3 addresses, see
  [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have a solvent interconnecting the hosts.

[Ballot discuss]
This is a mild problem, and the document author is welcome to push back on it, but
I found structuring the abbreviations in 3 alphabetically ended up forcing a lot
of look-ahead and dependencies.  See 3.1, for example:

3.1  IP-only LAN-like Service (IPLS)


  An IPLS is very like a VPLS (see 3.8), except that:


  o  it is assumed that the CE devices (see 5.1) are hosts or routers,
      not switches
  o  it is assumed that the service will only need to carry IP packets,
      and supporting packets such as ICMP and ARP; otherwise layer 2
      packets which do not contain IP are not supported.


  While this service is a functional subset of the VPLS service, it is
  considered separately because it may be possible to provide it using
  different mechanisms, which may allow it to run on certain hardware
  platforms that cannot support the full VPLS functionality
  [I-D.ietf-l2vpn-l2-framework].

I am concerned that this limits the usability of the documents.  Restructuring
the definitions (so they are group logically) or the rewording them (so they
contain duplicate definitions) might help.

[Ballot comment]
Typo in the Security Considerations:

"This is a terminology document and as such don't have direct security implications."

s/don't/doesn't/
or something else like "there are no direct security implications".

[Note]: '2004-06-03: revised ID submitted to cleanup some formatting issues, no substantive change. Putting on telechat agenda even though -01 has not appeared yet.' added by Thomas Narten

[Note]: '2004-06-03: revised ID submitted to cleanup some formatting issues, no substantive change. Putting on telechat agenda even though -06 has not appeared yet.' added by Thomas Narten

From: Thomas Narten
To: loa@pi.se, tove@niebelungen.net
cc: "Rick Wilder" , Ross Callon ,
    Ron Bonica ,
    "Vach Kompella"
Date: Tue, 11 May 2004 16:06:39 -0400
Subject: AD review of draft-ietf-l3vpn-ppvpn-terminology-00.txt

Sorry, I actually reviewed this a couple of weeks back and then didn't
send out the comments. :-(

They are all editorial/nit type comments, but I think it would be good
to respin to clean them up. Any chance we can get a revised version by
middle of next week? That would line up with the deadlines for getting
it onto the IESG telechat in two weeks.

Thomas

editorial:

>      The provider provisioned VPN solutions have attracted a great deal

s/provider provisioned FOO/provider-provisioned FOO/ (multiple
occurances, i.e., when used as an adjective)

> Conventions used in this document
>
>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
>      in this document are to be interpreted as described in RFC-2119
>      [RFC2119].

This can be removed  as the terms aren't used (nor are they needed...)

>        There is a comparatively large number of memos being submitted to

s/is a/are a/

>      This document intends to fully cover the concepts within five core
>      documents from the L2VPN and L3VPN working groups the "Generic
>      Requirements for Provider Provisioned VPN" [GENERIC], the "A
>      Framework for Layer 3 Provider Provisioned Virtual Private
>      Networks" [L3VPN-frmwrk], the "Service requirements for Layer 3
>      Provider Provisioned Virtual Private Networks" [PPVPN-req], the
>      "L2VPN Framework [L2VPN-frmwrk] and "Service Requirements for
>      Layer 2 Provider Provisioned Virtual Private Networks" [L2VPN-
>      req]. The intention is to create a comprehensive and unified set
>      of concepts for these documents, and by extension for the entire
>      PPVPNarea.Todosoitisalsonecessarytogivesomeofthe
>      development the concepts of the area have been through.

Do we want to include the titles? Are they correct (i.e., have they or
will they possibly change)? You don't do this in general.

>      the different services that has been/will be specified, Section 5

s/has/have/

>      of the building blocks and architecture constructs with the point
>      to multipoint solutions, e.g. PE (see 5.2) and CE (see 5.1). An

point-to-multipoint solutions

>      used e.g. in the now dated draft-lasserre-tls-mpls-00.txt. This

s/e.g./, e.g.,/

Also, take ID name out of text and use a regular reference.

>      A VLAN is a way of separating traffic on a LAN, e.g. between

s/e.g./e.g.,/

>      The VLLS has been replaced by VPWS. VPWS was used in now dated
>      document intended to create metrics by which it should have been
>      possible to compare different L2VPN solutions (draft-ppvpn-
>      metrics.00.txt). This document has now expired and the work
>      terminated.

fix reference to ID (put in references). This should be done
throughout.

Also, should VPWS in second sentence be VLLS?

>      In a VPLS the provider network emulates a learning bridge and

comma after VPLS?

>      A VPSN is replaced by VPLS. The VPSN abbreviation was used e.g. in

s/A VPSN is replaced by /The Term VPSN has been replaced by/ Similar
wording changes would also help elsewhere where deprecated terms are
given.


>      ThistermhasnowbeenreplacedbyBGP/MPLSIPVPNs.

?? :)

> 5.1 Customer Edge device (CE)
>
>      A CE is the name of the device with the functionality needed on
>      the customer premises to access the services specified by the
>      former PPVPN working group.

is there a better reference than "services specified by the former
PPVPN WG"?

>      A CE is the name of the device with the functionality needed on
>      the customer premises to access the services specified by the
>      former PPVPN working group.

This is pretty squishy. What services did the PPPVN group specify?
Can't you say (for example) that it is equipmented that resides at the
customer site and/or is owned or controlled by the customer?

>    addresses that needs to be learnt in the provider network.

s/learnt/learned/

>      APE-SisaL2devicethatparticipatesine.g.aswitched

spacing?

>      ThePisdefinedasarouterinthecorenetworkthatdoesnot

> 5.4.3 PE-CLE
>
>      An alternative name for the U-PE suggested in now dated Internet
>      Draft "VPLS architectures".

Don't understand. Does "now dated" mean expired/abandoned?

> 5.4.6 PE-POP
>
>      An alternative name for the U-PE suggested in now dated Internet
>      Draft "VPLS architectures".

ditto. "dated" is perhaps not the best word. "old" might be better. I
think you are looking for a word that indicates "abandoned". Right?

>      deviceusedbyaprovidernetworktohandoffaVPLStoa

>      togetherwitha4byteIPv4addressidentifiesaVPN-IPv4address

>      family. If two VPNs use the same IPv4 address prefix, the PEs
>      translates these into unique VPN-IPv4 address prefixes. This

s/translates/translate/?

>      traversing the tunnel to make possible to decide to which instance

s/make/make it/

>      In an MPLS enabled IP network a VC label is an MPLS label, used to

s/MPLS enabled/MPLS-enabled/

>      i.e. the VC label is the tunnel multiplexer in networks that uses
>      MPLS labels.

s/uses/use/

Needs a security consderations section (even if it just says
terminology documents don't have security implications, or some such.