Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
RFC 4761
Discuss
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Alex Zinin; former steering group member) Discuss
Implementation & interop report is needed for this document.
(Mark Townsley; former steering group member) Yes
(Bert Wijnen; former steering group member) No Objection
I agree with TED's DISCUSS. And in fact MIB Doctor revieq also raised the question as to why there are 2 solutions for the same problem. So pointing it out clearly on the front page makes sense to me.
(Bill Fenner; former steering group member) (was Discuss) No Objection
(Brian Carpenter; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(David Kessens; former steering group member) (was Discuss) No Objection
More comments by Pekka Savola from the Ops Directorate:
editorial
---------
Alternative approaches include: [13], which allows one to build a
Layer 2 VPN with Ethernet as the interconnect; and [12]), which
allows one to set up an Ethernet connection across a packet-switched
network.
==> s/)// ?
they know that a VPLS service is being offered. We will call these
VPLS edge devices, which could be either a PE or an u-PE, a VE.
==> what is a "VE"? Please expand. It seems to be used extensively in
later parts of the doc, but never explained.
The term "demultiplexor" refers to an identifier in a data packet
that identifies both the VPLS to which the packet belongs as well as
the ingress PE. In this document, the demultiplexor is an MPLS
label.
==> what about L2VPN's if it wouldn't be implemented over MPLS but rather
IP, GRE, .. etc. tunnels? Do those still use MPLS labels? Is this doc
compatible with that approach (1st paragraph of 2.2 seems to imply that it
should be)?
The Service Provider Network is a packet switched network. The PEs
are assumed to be (logically) fully meshed with tunnels over which
packets that belong to a service (such as VPLS) are encapsulated and
forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS
tunnels, established by RSVP-TE or LDP. These tunnels are
established independently of the services offered over them; the
signaling and establishment of these tunnels are not discussed in
this document.
...
All the PEs participating in a VPLS are assumed to be fully meshed in
the data plane, i.e., there is a bidirectional pseudowire between
every pair of PEs participating in that VPLS, and thus every
(ingress) PE can send a VPLS packet to the egress PE(s) directly,
without the need for an intermediate PE (see Section 4.2.5.) This
requires that VPLS PEs are logically fully meshed in the control
plane so that a PE can send a message to another PE to set up the
necessary pseudowires. See Section 3.6 for a discussion on
alternatives to achieve a logical full mesh in the control plane.
==> aren't you saying much the same things twice? Either reword or suggest
clarifying the differences.
VPLS is a "LAN Service" in that CE devices that belong to VPLS V can
interact through the SP network as if they were connected by a LAN.
==> "VPLS _V_"? You don't use 'V' until section 3.1.1, so it would be
clearer to remove it in here.
A VPLS BGP NLRI has the following information elements: a VE ID, a VE
Block Offset, a VE Block Size and a label base. The format of the
VPLS NLRI is given below. The AFI is the L2VPN AFI (to be assigned
by IANA), and the SAFI is the VPLS SAFI (65). The Length field is in
octets.
==> it might not hurt to state explicitly whether the Length field include
the length field itself or only the subsequent fields..
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
I agree with the issues raised by Pekka Savola in his review, but I have no further objection.
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
Please delete sections 1.3, 1.4, and 1.5 prior to publication. Shift Figure 6 to the left so that it does not exceed the right page margin.
(Sam Hartman; former steering group member) (was Discuss) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) (was Discuss) No Objection