Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
Note: This ballot was opened for revision 08 and is now closed.
(Alex Zinin) Discuss
Discuss (2006-02-16 for -)
Implementation & interop report is needed for this document.
(Mark Townsley) Yes
(Ross Callon) No Objection
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
Comment (2006-02-16 for -)
I agree with the issues raised by Pekka Savola in his review, but I have no further objection.
(Bill Fenner) (was Discuss) No Objection
(Ted Hardie) (was Discuss) No Objection
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) (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.
(Cullen Jennings) No Objection
(David Kessens) (was Discuss) No Objection
More comments by Pekka Savola from the Ops Directorate: editorial --------- Alternative approaches include: , which allows one to build a Layer 2 VPN with Ethernet as the interconnect; and ), 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) No Objection
Magnus Westerlund No Objection
(Bert Wijnen) No Objection
Comment (2006-01-19 for -)
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.