Skip to main content

Provider Provisioned Virtual Private Network (VPN) Terminology
RFC 4026


(Thomas Narten)

No Objection

(Alex Zinin)

Note: This ballot was opened for revision 04 and is now closed.

Thomas Narten Former IESG member
Yes () Unknown

Alex Zinin Former IESG member
No Objection
No Objection () Unknown

Bill Fenner Former IESG member
No Objection
No Objection (2004-06-10) Unknown
In the title of section, 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?
David Kessens Former IESG member
No Objection
No Objection (2004-06-10) Unknown
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

 - spell out PPVPN in the title
 - in section 2, I-D.ietf-l3vpn-framework is listed twice.
 - in section, s/CE-bS/CE-S/ ?
Scott Hollenbeck Former IESG member
No Objection
No Objection (2004-06-07) Unknown
Typo in the Security Considerations:

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

or something else like "there are no direct security implications".
Steven Bellovin Former IESG member
No Objection
No Objection (2004-06-09) Unknown
I was expecting to see relevant security terminology listed, and in particular terms used to distinguish VPNs with cryptographic traffic authentication and/or separation.
Ted Hardie Former IESG member
(was Discuss) No Objection
No Objection (2004-06-09) Unknown
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

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

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?