Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
RFC 4761

Received changes through RFC Editor sync (changed abstract to 'Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]')

[Ballot discuss]
Please add text similar to the following taken from RFC 4364 to the
security considerations section:

  MPLS-in-IP and MPLS-in-GRE tunneling are specified in
  [MPLS-in-IP-GRE].  If it is desired to use such tunnels to carry VPN
  packets, then the security considerations described in Section 8 of
  that document must be fully understood.  Any implementation of
  BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described
  in that document MUST contain an implementation of IPsec that can be
  used as therein described.  If the tunnel is not secured by IPsec,
  then the technique of IP address filtering at the border routers,
  described in Section 8.2 of that document, is the only means of
  ensuring that a packet that exits the tunnel at a particular egress
  PE was actually placed in the tunnel by the proper tunnel head node
  (i.e., that the packet does not have a spoofed source address).
  Since border routers frequently filter only source addresses, packet
  filtering may not be effective unless the egress PE can check the IP
  source address of any tunneled packet it receives, and compare it to
  a list of IP addresses that are valid tunnel head addresses.  Any
  implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to
  be used without IPsec MUST allow the egress PE to validate in this
  manner the IP source address of any tunneled packet that it receives.

[Note]: 'Asked authors to clarify IANA issue from Pekka S. described in David Kessen''s DISCUSS comment. Asked chairs to come up with new names for this and vpls-ldp document. Part of Sam''s general block on L2VPN.' added by Mark Townsley

[Note]: 'Asked authors to clarify IANA issue from Pekka S. described in David Kessen''s DISCUSS comment. Asked chairs to come up with new names for this and vpls-ldp document.' added by Mark Townsley

[Ballot discuss]
[This discuss is  part of an ongoing discussion with Mark.
We should better understand this issue after I send some mail this weekend.]

According to section 2 of this document, this can be used to set up
both IP and MPLS pseudowires to provide VPLS.

Assuming that this is true, then this protocol needs to provide
mechanisms for discovering and configuring security.

If this is false, then section 2 needs to be clarified.

[Ballot comment]
Just for future reference, please include a Table of Contents in all documents over ~9 or 10 pages.  Not including a Table of Contents makes it much harder to review a document this long/complex.

[Ballot comment]
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.

[Ballot discuss]
I would like to see a title change in both vpls-bgp and vpls-ldp to make it clear that they're different.  In particular, I don't think "over MPLS" accurately captures the difference between the two protocols.

[Ballot comment]
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..

[Ballot discuss]
First of all, I agree with Ted.

In addition, I have the following issues:

I received the following review from the Ops Directorate by Pekka Savola.

Please clarify the IANA issues regarding the extended attribute, review the reference section as suggested by Pekka amd issue 5.

I leave issue 6&7 to the security area directors to decide whether they
believe that further discussion is necessary.

The other issues are serious enough that it would be useful to take a look at them, but I don't consider them blocking.

-----

Summary of substantial issues:
                                                                                                     
1) a few references should likely be normative; hopefully
    [13] (draft-kompella-l2vpn-l2vpn-00) isn't required...
2) is IANA action required of "Layer2 Info Extended Community"?
3) multi-AS VPN data plane solution is not described
4) how does the CE know whether it needs to run STP or not?
5) encapsulation depends on 'P'-bit which isn't defined
6) the use of IPsec to secure PE-to-PE communication should be
    described, now it's the infamous "just use IPsec".
7) there doesn't appear to be any security model whatsoever for
    verifying BGP updates.  Any valid BGP peer can join any VPLS
    it wants.  This may even apply in inter-AS case (not sure).
    This should be described better and specified as necessary;
    mechanisms equivalent to unicast inbound "prefix-lists"
    should at least be available (this might not even need
    on-the-wire changes!).
                                                                                                     
Many of these are important, most of them should be easy to fix; I'm most
concerned about 7) though.

subtantial
----------
                                                                                                     
1)
                                                                                                     
3.1.2.  Protocol Specification
                                                                                                     
  The specific mechanism for autodiscovery described here is based on
  [13] and [10]; it uses BGP extended communities [4] to identify
  members of a VPLS, in particular, the Route Target community, whose
  format is described in [4].  The semantics of the use of Route
  Targets is described in [10]; their use in VPLS is identical.
                                                                                                     
==> this seems that at least [10] should be a normative reference.
Also, text doesn't make it clear enough whether specification given in
[4] and [10] is sufficient to implement this, or whether you need
[13] as well.  If that'd be true, some serious action would be needed.
                                                                                                     
2)
  The following extended attribute, the "Layer2 Info Extended
  Community", is used to signal control information about the
  pseudowires to be setup for a given VPLS.  This information includes
  the Encaps Type (type of encapsulation on the pseudowires), Control
  Flags (control information regarding the pseudowires) and the Maximum
  Transmission Unit (MTU) to be used on the pseudowires.
                                                                                                     
  The Encaps Type for VPLS is 19.
                                                                                                     
      +------------------------------------+
      | Extended community type (2 octets) |
      +------------------------------------+
...
                                                                                                     
==> did you define anywhere what this community type should be or that IANA
should allocate it?  Not here, and not in this doc's IANA considerations
section at least.
                                                                                                     
3)
3.4.  Multi-AS VPLS
...
  However, sites in a VPLS may connect to PEs in different ASes.  This
  leads to two issues: 1) there would not be an I-BGP connection
  between those PEs, so some means of signaling across ASes is needed;
  and 2) there may not be PE-to-PE tunnels between the ASes.
                                                                                                     
  A similar problem is solved in [10], Section 10.  Three methods are
  suggested to address issue (1); all these methods have analogs in
  multi-AS VPLS.
                                                                                                     
==> Have you solved issue (2)?  Not at least in this section, if yes, please
provide a pointer.
==> should [10] be a normative reference?  It seems to be on the
borderline...
                                                                                                     
4)
  It is often desired to multi-home a VPLS site, i.e., to connect it to
  multiple PEs, perhaps even in different ASes.  In such a case, the
  PEs connected to the same site can either be configured with the same
  VE ID or with different VE IDs.  In the latter case, it is mandatory
  to run STP on the CE device, and possibly on the PEs, to construct a
  loop-free VPLS topology.  How this can be accomplished is outside the
  scope of this document; however, the rest of this section will
  describe in some detail the former case.
                                                                                                     
==> how does the customer know whether the same or different VEs are used,
i.e., whether it needs to run STP on its systems or not?  Wasn't the point
of VPLS that it's transparent to the CEs?
                                                                                                     
5)
                                                                                                     
4.1.  Encapsulation
                                                                                                     
  Ethernet frames received from CE devices are encapsulated for
  transmission over the packet switched network connecting the PEs.
  The encapsulation is as in [5], with one change: a PE that sets the P
  bit in the Control Flags strips the outermost VLAN from an Ethernet
  frame received from a CE before encapsulating it, and pushes a VLAN
  onto a decapsulated frame before sending it to a CE.
                                                                                                     
==> where is the "P" bit defined?  Control Flags is described in section
3.2.4, but it doesn't have a P bit.
                                                                                                     
6)
                                                                                                     
  The focus in Virtual Private LAN Service is the privacy of data,
  i.e., that data in a VPLS is only distributed to other nodes in that
  VPLS and not to any external agent or other VPLS.  Note that VPLS
  does not offer security or authentication: VPLS packets are sent in
  the clear in the packet-switched network, and a man-in-the-middle can
  eavesdrop, and may be able to inject packets into the data stream.
  If security is desired, the PE-to-PE tunnels can be IPsec tunnels.

==> I think you need to describe better how you'd use IPsec to secure
PE-to-PE interactions or give pointers to it.  You're basically already
requiring the use of PWE3, so that limits the IPsec tunnel options a bit.
                                                                                                     
7)
                                                                                                     
  There are two aspects to achieving data privacy in a VPLS: securing
  the control plane, and protecting the forwarding path.  Compromise of
  the control plane could result in a PE sending data belonging to some
  VPLS to another VPLS, or blackholing VPLS data, or even sending it to
  an eavesdropper, none of which are acceptable from a data privacy
  point of view.  Since all control plane exchanges are via BGP,
  techniques such as in [2] help authenticate BGP messages, making it
  harder to spoof updates (which can be used to divert VPLS traffic to
  the wrong VPLS), or withdraws (denial of service attacks).  In the
  multi-AS options (b) and (c), this also means protecting the inter-AS
  BGP sessions, between the ASBRs, the PEs or the Route Reflectors.

==> I think the security considerations needs to be more upfront about the
threats.  AFAICS, verifying the contents of BGP updates (coming from a valid
peer) is not possible -- or is it?  I.e., any valid peer (even in a
different AS) could join any VPLS it wanted to.  Compare the situation to
BGP with unicast prefixes: operators can perform inbound and outbound
filtering with e.g., prefix-lists, only authorizing certain advertisements.
Are similar mechanisms possible with VPLS?  I'd certainly hope so.
                                                                                                     
This issue is not just about attacks, it's also about unintentional
misconfiguration: most network outages (I recall seeing studies saying even
80%) are caused by misconfiguration.  Here it'd be awfully simple to
misconfigure the VPLS, and bang.. suddenly the traffic of separate VPLS's
would be mixed up just by misconfiguring (for example) RT.

[Ballot discuss]
First of all, I agree with Ted.

In addition, I have the following issues:

I received the following review from the Ops Directorate by Pekka Savola.

Please clarify the IANA issues regarding the extended attribute, review the reference section as suggested by Pekka amd issue 5.

The other issues are serious enough that it would be useful to take a look at them, but I don't consider them blocking.

-----

Summary of substantial issues:
                                                                                                     
1) a few references should likely be normative; hopefully
    [13] (draft-kompella-l2vpn-l2vpn-00) isn't required...
2) is IANA action required of "Layer2 Info Extended Community"?
3) multi-AS VPN data plane solution is not described
4) how does the CE know whether it needs to run STP or not?
5) encapsulation depends on 'P'-bit which isn't defined
6) the use of IPsec to secure PE-to-PE communication should be
    described, now it's the infamous "just use IPsec".
7) there doesn't appear to be any security model whatsoever for
    verifying BGP updates.  Any valid BGP peer can join any VPLS
    it wants.  This may even apply in inter-AS case (not sure).
    This should be described better and specified as necessary;
    mechanisms equivalent to unicast inbound "prefix-lists"
    should at least be available (this might not even need
    on-the-wire changes!).
                                                                                                     
Many of these are important, most of them should be easy to fix; I'm most
concerned about 7) though.

subtantial
----------
                                                                                                     
1)
                                                                                                     
3.1.2.  Protocol Specification
                                                                                                     
  The specific mechanism for autodiscovery described here is based on
  [13] and [10]; it uses BGP extended communities [4] to identify
  members of a VPLS, in particular, the Route Target community, whose
  format is described in [4].  The semantics of the use of Route
  Targets is described in [10]; their use in VPLS is identical.
                                                                                                     
==> this seems that at least [10] should be a normative reference.
Also, text doesn't make it clear enough whether specification given in
[4] and [10] is sufficient to implement this, or whether you need
[13] as well.  If that'd be true, some serious action would be needed.
                                                                                                     
2)
  The following extended attribute, the "Layer2 Info Extended
  Community", is used to signal control information about the
  pseudowires to be setup for a given VPLS.  This information includes
  the Encaps Type (type of encapsulation on the pseudowires), Control
  Flags (control information regarding the pseudowires) and the Maximum
  Transmission Unit (MTU) to be used on the pseudowires.
                                                                                                     
  The Encaps Type for VPLS is 19.
                                                                                                     
      +------------------------------------+
      | Extended community type (2 octets) |
      +------------------------------------+
...
                                                                                                     
==> did you define anywhere what this community type should be or that IANA
should allocate it?  Not here, and not in this doc's IANA considerations
section at least.
                                                                                                     
3)
3.4.  Multi-AS VPLS
...
  However, sites in a VPLS may connect to PEs in different ASes.  This
  leads to two issues: 1) there would not be an I-BGP connection
  between those PEs, so some means of signaling across ASes is needed;
  and 2) there may not be PE-to-PE tunnels between the ASes.
                                                                                                     
  A similar problem is solved in [10], Section 10.  Three methods are
  suggested to address issue (1); all these methods have analogs in
  multi-AS VPLS.
                                                                                                     
==> Have you solved issue (2)?  Not at least in this section, if yes, please
provide a pointer.
==> should [10] be a normative reference?  It seems to be on the
borderline...
                                                                                                     
4)
  It is often desired to multi-home a VPLS site, i.e., to connect it to
  multiple PEs, perhaps even in different ASes.  In such a case, the
  PEs connected to the same site can either be configured with the same
  VE ID or with different VE IDs.  In the latter case, it is mandatory
  to run STP on the CE device, and possibly on the PEs, to construct a
  loop-free VPLS topology.  How this can be accomplished is outside the
  scope of this document; however, the rest of this section will
  describe in some detail the former case.
                                                                                                     
==> how does the customer know whether the same or different VEs are used,
i.e., whether it needs to run STP on its systems or not?  Wasn't the point
of VPLS that it's transparent to the CEs?
                                                                                                     
5)
                                                                                                     
4.1.  Encapsulation
                                                                                                     
  Ethernet frames received from CE devices are encapsulated for
  transmission over the packet switched network connecting the PEs.
  The encapsulation is as in [5], with one change: a PE that sets the P
  bit in the Control Flags strips the outermost VLAN from an Ethernet
  frame received from a CE before encapsulating it, and pushes a VLAN
  onto a decapsulated frame before sending it to a CE.
                                                                                                     
==> where is the "P" bit defined?  Control Flags is described in section
3.2.4, but it doesn't have a P bit.
                                                                                                     
6)
                                                                                                     
  The focus in Virtual Private LAN Service is the privacy of data,
  i.e., that data in a VPLS is only distributed to other nodes in that
  VPLS and not to any external agent or other VPLS.  Note that VPLS
  does not offer security or authentication: VPLS packets are sent in
  the clear in the packet-switched network, and a man-in-the-middle can
  eavesdrop, and may be able to inject packets into the data stream.
  If security is desired, the PE-to-PE tunnels can be IPsec tunnels.

==> I think you need to describe better how you'd use IPsec to secure
PE-to-PE interactions or give pointers to it.  You're basically already
requiring the use of PWE3, so that limits the IPsec tunnel options a bit.
                                                                                                     
7)
                                                                                                     
  There are two aspects to achieving data privacy in a VPLS: securing
  the control plane, and protecting the forwarding path.  Compromise of
  the control plane could result in a PE sending data belonging to some
  VPLS to another VPLS, or blackholing VPLS data, or even sending it to
  an eavesdropper, none of which are acceptable from a data privacy
  point of view.  Since all control plane exchanges are via BGP,
  techniques such as in [2] help authenticate BGP messages, making it
  harder to spoof updates (which can be used to divert VPLS traffic to
  the wrong VPLS), or withdraws (denial of service attacks).  In the
  multi-AS options (b) and (c), this also means protecting the inter-AS
  BGP sessions, between the ASBRs, the PEs or the Route Reflectors.

==> I think the security considerations needs to be more upfront about the
threats.  AFAICS, verifying the contents of BGP updates (coming from a valid
peer) is not possible -- or is it?  I.e., any valid peer (even in a
different AS) could join any VPLS it wanted to.  Compare the situation to
BGP with unicast prefixes: operators can perform inbound and outbound
filtering with e.g., prefix-lists, only authorizing certain advertisements.
Are similar mechanisms possible with VPLS?  I'd certainly hope so.
                                                                                                     
This issue is not just about attacks, it's also about unintentional
misconfiguration: most network outages (I recall seeing studies saying even
80%) are caused by misconfiguration.  Here it'd be awfully simple to
misconfigure the VPLS, and bang.. suddenly the traffic of separate VPLS's
would be mixed up just by misconfiguring (for example) RT.

[Ballot discuss]
Would it be valuable to add an IESG note pointing out that there are two solutions and pointing in each to the other?  The "let the market decide" result from L2vpn is clearly within their purview, but should the IESG highlight that in the document itself, as it is in Mark's write-up?

[Ballot comment]
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.

[Ballot discuss]
In Section 6, 1st paragraph, includes:
  >
  > Note that VPLS does not offer security or authentication ...
  >
  The term "security" is very vague in this context.  I propose:
  >
  > Note that VPLS does not offer confidentiality, integrity, or
  > authentication ...
  >
  I think this sets the context for "security" in the rest of the
  paragraph.

[Note]: 'This document and draft-ietf-l2vpn-vpls-ldp are different solutions to similar problems. L2VPN agreed to advance both and essentially "let the market decide."' added by Mark Townsley

[Note]: 'This document will go forward simultaneously with draft-ietf-l2vpn-vpls-ldp-07.txt - Waiting on new version incorporating gen-art review comments (see GEN-ART REVIEW RESPONSE comment).' added by Mark Townsley

GEN-ART REVIEW RESPONSE

Kireeti,

Sounds like you are going to rev the document with somewhat substantive changes based on the gen-art review. As such, I'm defering this document from this week's telechat. I will put it back on as soon as I see a -06. Note that I am going to be on paternity leave for a few weeks starting sometime between now and Oct 28 - if you can get the document revved before next Wednesday (and the baby hasn't been born yet) I will ask for it to be added to the next telechat (Oct 11).

Thanks,

- Mark

Kireeti Kompella wrote:

> Thanks for the updated review.
>
> On Mon, 26 Sep 2005, Elwyn Davies wrote:
>
> 
>
>> Document: draft-ietf-l2vpn-vpls-bgp-05.txt
>> Intended Status: Proposed Standard
>> Shepherding AD: Mark Townsley
>> Review Trigger: IESG Telechat 29/9/05
>>
>> Summary:
>> Technically this is probably almost ready for PS.  In terms of
>> comprehensibility for the the future there are a number of areas
>> which I feel it is really important to improve by adding a couple of
>> sentences of explanation as to the purpose and motivation, firstly
>> of the document as a whole and then to a couple of subsections - it
>> almost feels as if the document is trying to avoid saying that VPLS
>> is about extending e****net. There are also a few editorial nits.
>> Having reviewed the draft defining the alternative way of setting up
>> VPLS using LDP, there appear to be a number of areas where this
>> document does not address technical issues that are covered by the
>> LDP document.  In some cases these may not be relevant to this
>> document, but I think that it ought to cover MAC address aging and
>> scaling. Incidentally the LDP based document is much less reticent
>> about VPLS being about extending Ethernet LANs.
>> 
>
>
> Okay.  I agree with most of the comments, so I'll rev the document
> with those and send you and updated version.  Below, I'll discuss some
> of the comments that may need further elaboration.
>
> 
>
>> Review:
>>
>> Technically the document appears to be very well written  My major
>> concern is that the purpose and motivation both of the whole document
>> and some individual parts needs to be spelt out up front.  Also I am unsure as
>> to whether some of the issues covered in the LDp based VPLS specification should
>> be covered in this document as well. [The SAFI issue previously suggested has
>> been cleared.]
>>
>> Clarifications of purpose/motivation needed:
>> Abstract/Intro/General: A reader with no previous experience of the
>> l2vpn wg coming to this document will potentially be confused by the
>> generic words used in the title, abstract and introduction which may
>> lead them to expect this document to be concerned with more generic l2
>> services than is apparently the case.  I had to go back through the
>> framework document to the l2vpn charter to find that the VPLS service is
>> specifically intended for extending Ethernet LANs. It would greatly
>> reduce confusion if this was made clear up front.  Then it is more
>> obvious why ss3.4.x talk only about 'carrying Ethernet traffic' etc.,
>> and s4 talks only about Ethernet frames.
>> 
>
>
> Okay.
>
> 
>
>> s3: particularly s3.2.1 and s3.3, para 1: A paragraph on the motivation
>> for the use of VBO, VBS, LB would help (presumably to do with partition
>> and allocation of the label space).  Some brief advice on allocation
>> strategy would help both implementors and users.
>> 
>
>
> Okay.
>
> 
>
>> s3.1.2: What is the point of the statement "A more generic autodiscovery
>> mechanism is described in [8]."? Is the reader being pointed to this for
>> general review of autodiscovery mechanisms?  Is this an alternative
>> mechanism? If so how could it be used? Or is this just to indicate that
>> the mechanism used is a particular implementation or specialization of
>> that in [8]?
>> 
>
>
> The first: a general review of autodiscovery.  I'll make that clear.
>
> 
>
>> 3.4 introduction:  It would be helpful to make a general statement that
>> the various solutions constrain the inter-AS infrastructure in different
>> ways - as it stands the various statements are confusing - leading to
>> reactions like my next comment...
>> s3.4.1: Why does this suddenly mention Ethernet specifically (probably
>> because of the first clarification point above, but..)?  I would have
>> thought that the Inter-AS link has to be able to carry Ethernet frames
>> but does it have to be Ethernet?
>> s3.4.2: The first sentence of the last para ought to be placed much
>> earlier in the section: as it stands the talk of label swapping comes
>> before this statement and is confusing.
>> s3.4.3: appears to require inter-AS MPLS (talk of LSPs between PE1 and
>> PE2) but this is not stated explicitly (as compared with 3.4.1 and 3.4.2)
>> 
>
>
> Okay.  Will tweak wording.
>
> 
>
>> Consistency between this document ('LDP') and draft-ietf-l2vpn-vpls-bgp-05 ('BGP'):
>> - LDP talks about MAC address aging but BGP doesn't
>> 
>
>
> (1) Some background:  both the BGP and LDP specs are about the control
> plane -- signaling and (in the case of BGP) auto-discovery.  The data
> plane is identical.  Thus, MAC address learning, aging, the treatment
> of .1p bits, multicast/broadcast, etc. is *identical* in both schemes.
>
> There was once talk of a common "data plane" document that captured
> these aspects in a single document.  Ideally, this should have been
> done; however, there was not enough incentive or enthusiasm to follow
> through.  Also, the data plane part mostly just says "this works just
> like Ethernet bridging."
>
> Thus, whether one should talk about MAC aging or not is judgment call.
> If you say that VPLS learning is similar to MAC learning, then it
> follows that aging works similarly.  I suppose it doesn't hurt to say
> so, though.  Similarly for multicast, or the treatment of .1p bits.
>
> At this stage, it would be a fair amount of work to separate the
> control and data plane descriptions.  The easy way out is to try to
> keep the material as much in sync as possible.  (Thanks for your help
> in this.)
>
> 
>
>> - BGP recommends encapsulation via PWE3-CTRL whereas intro of LDP goes directly
>> to PWE3-ETH and doesn't mention the encapsulation in PWE3-CTRL
>> 
>
>
> Historical.  All encaps were originally in PWE3-CTRL, then they got
> broken out.  Will fix.
>
> 
>
>> - LDP talks about treatment of multicast (s4) by e.g. using broadcast etc which
>> is barely treated in BGP
>> 
>
>
> See (1)
>
> 
>
>> - Scaling issues: LDP discusses a number of hierarchical solution but BGP
>> doesn't: LDP s7.1 talks about specialised encapsulations which may be of
>> relevance.  LDP hardly mentions scaling.
>> 
>
>
> Actually, I would really like the LDP document to talk about scaling!
> The LDP doc acknowledges a control plane scaling issue, and proposes
> H-VPLS as a solution.  However, H-VPLS has serious implications on the
> scaling of the data plane, which is not mentioned at all.
>
> BGP has long since addressed the control plane scaling issue (with
> Route Reflectors and/or BGP confederations).  I'll be happy to mention
> that.
>
> 
>
>> - Encapsulation: LDP s7.1 has a deal of discussion of 'service delimiting'
>> encapsulation that is missing from BGP.. is this a drop off in BGP or not
>> necessary? or is equivalent to the stuff regarding the P bit in s4.1 of BGP
>> 
>
>
> Again, see (1).  This really orthogonal to how VPLS is signaled, or
> the specifics of forwarding Ethernet frames in a VPLS.  However, I'll
> do my best to make the data plane aspects the same between the two docs.
>
> 
>
>> - LDP Qualified/Un-qualified learning: not clear if this is
>> interesting/available in BGP
>>
>> - BGP: Does this support 802.1p bits as is claimed for LDP - 802.1p is not
>> mentioned.
>> 
>
>
> In LDP, the only mention I found is:
>
>  The Ethernet VLAN PW provides a simple way to preserve customer
>  802.1p bits.
>
> Did I miss something?
>
> 
>
>> Editorial:
>> global: Need to decide between 'fully-meshed' and 'fully meshed'.
>> s1, para 1: s/glues/glues together/
>> s1, next to last para: acronym PE is not defined until s2
>> s1: It may be a bit pedantic but LAN is not expanded.
>>
>> s2.1: SP is not expanded.
>> s2.2, s4.2.3: s/full-meshed/fully-meshed/
>>
>> s2.2: The statement that PEs are fully(-)meshed is duplicated (para 1
>> and para 3).
>> 
>
>
> The two "full meshes" are at different levels -- all PEs are fully
> meshed with *tunnels* and all PEs in a given VPLS are fully meshed
> with *PWs*.  I'll clarify.
>
> 
>
>> s3.4.1: There ought to be a reference for the Spanning Tree protocol.
>>
>> s6: The term 'P router' (which comes from [9], I think) is used without
>> any introduction: It should probably be introduced in s2.1.
>> 
>
>
> Thanks, I'll fix these.
>
> 
>
>> Tail: Yakov's email address is same as Kireeti's!
>> 
>
>
> Good catch!  Cut-and-paste error when migrating from nroff to xml.
>
> Kireeti.
> -------
>
> 
>

GEN-ART REVIEW

-------- Original Message --------
Subject: Gen-art Review: draft-ietf-l2vpn-vpls-bgp-05
Date: Sun, 25 Sep 2005 13:55:21 +0100
From: Elwyn Davies
To: gen-art@ietf.org
CC: Mary Barnes , Mark Townsley , kireeti@juniper.net, yakov@juniper.net



Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

Document: draft-ietf-l2vpn-vpls-bgp-05.txt
Intended Status: Proposed Standard
Shepherding AD: Mark Townsley
Review Trigger: IESG Telechat 29/9/05

Summary:
Technically this is almost ready for PS.  I have one possible issue
relating to the appropriateness of the use of a private allocation SAFI
number in a standards track document. In terms of comprehensibility for
the the future there are a number of areas which I feel it is really
important to improve by adding a couple of sentences of explanation as
to the purpose and motivation, firstly of the document as a whole and
then to a couple of subsections - it almost feels as if the document is
trying to avoid saying that VPLS is about extending e****net. There are
also a few editorial nits.

Review:

Technically the document appears to be very well written  My major
concern is that the purpose and motivation both of the whole document
and some individaul parts needs to be spelt out up front.

Substantive:
s3.2.2: Is it appropriate to use a 'private' category SAFI identifier here?

Clarifications of purpose/motivation needed:
Abstract/Intro/General: A reader with no previous experience of the
l2vpn wg coming to this document will potentially be confused by the
generic words used in the title, abstract and introduction which may
lead them to expect this document to be concerned with more generic l2
services than is apparently the case.  I had to go back through the
framework document to the l2vpn charter to find that the VPLS service is
specifically intended for extending Ethernet LANs. It would greatly
reduce confusion if this was made clear up front.  Then it is more
obvious why ss3.4.x talk only about 'carrying Ethernet traffic' etc.,
and s4 talks only about Ethernet frames.

s3: particularly s3.2.1 and s3.3, para 1: A paragraph on the motivation
for the use of VBO, VBS, LB would help (presumably to do with partition
and allocation of the label space).  Some brief advice on allocation
strategy would help both implementors and users.

s3.1.2: What is the point of the statement "A more generic autodiscovery
mechanism is described in [8]."? Is the reader being pointed to this for
general review of autodiscovery mechanisms?  Is this an alternative
mechanism? If so how could it be used? Or is this just to indicate that
the mechanism used is a particular implementation or specialization of
that in [8]?

3.4 introduction:  It would be helpful to make a general statement that
the various solutions constrain the inter-AS infrastructure in different
ways - as it stands the various statements are confusing - leading to
reactions like my next comment...
s3.4.1: Why does this suddenly mention Ethernet specifically (probably
because of the first clarification point above, but..)?  I would have
thought that the Inter-AS link has to be able to carry Ethernet frames
but does it have to be Ethernet?
s3.4.2: The first sentence of the last para ought to be placed much
earlier in the section: as it stands the talk of label swapping comes
before this statement and is confusing.
s3.4.3: appears to require inter-AS MPLS (talk of LSPs between PE1 and
PE2) but this is not stated explicitly (as compared with 3.4.1 and 3.4.2)

Editorial:
global: Need to decide between 'fully-meshed' and 'fully meshed'.
s1, para 1: s/glues/glues together/
s1, next to last para: acronym PE is not defined until s2
s1: It may be a bit pedantic but LAN is not expanded.

s2.1: SP is not expanded.
s2.2, s4.2.3: s/full-meshed/fully-meshed/

s2.2: The statement that PEs are fully(-)meshed is duplicated (para 1
and para 3).

s3.4.1: There ought to be a reference for the Spanning Tree protocol.

s6: The term 'P router' (which comes from [9], I think) is used without
any introduction: It should probably be introduced in s2.1.

Tail: Yakov's email address is same as Kireeti's!

New version needed based on Gen-art review and associated thread between Brian and Kireeti.


-------- Original Message --------
Subject: Re: Gen-art Review: draft-ietf-l2vpn-vpls-bgp-05 (updated)
Date: Mon, 26 Sep 2005 13:26:39 -0700 (PDT)
From: Kireeti Kompella
To: Elwyn Davies
CC: gen-art@ietf.org, Mary Barnes , Mark Townsley , yakov@juniper.net, Kireeti Kompella
References: <43383A78.7040806@dial.pipex.com>


Thanks for the updated review.

On Mon, 26 Sep 2005, Elwyn Davies wrote:


>> Document: draft-ietf-l2vpn-vpls-bgp-05.txt
>> Intended Status: Proposed Standard
>> Shepherding AD: Mark Townsley
>> Review Trigger: IESG Telechat 29/9/05
>>
>> Summary:
>> Technically this is probably almost ready for PS.  In terms of
>> comprehensibility for the the future there are a number of areas
>> which I feel it is really important to improve by adding a couple of
>> sentences of explanation as to the purpose and motivation, firstly
>> of the document as a whole and then to a couple of subsections - it
>> almost feels as if the document is trying to avoid saying that VPLS
>> is about extending e****net. There are also a few editorial nits.
>> Having reviewed the draft defining the alternative way of setting up
>> VPLS using LDP, there appear to be a number of areas where this
>> document does not address technical issues that are covered by the
>> LDP document.  In some cases these may not be relevant to this
>> document, but I think that it ought to cover MAC address aging and
>> scaling. Incidentally the LDP based document is much less reticent
>> about VPLS being about extending Ethernet LANs.


Okay.  I agree with most of the comments, so I'll rev the document
with those and send you and updated version.  Below, I'll discuss some
of the comments that may need further elaboration.


>> Review:
>>
>> Technically the document appears to be very well written  My major
>> concern is that the purpose and motivation both of the whole document
>> and some individual parts needs to be spelt out up front.  Also I am unsure as
>> to whether some of the issues covered in the LDp based VPLS specification should
>> be covered in this document as well. [The SAFI issue previously suggested has
>> been cleared.]
>>
>> Clarifications of purpose/motivation needed:
>> Abstract/Intro/General: A reader with no previous experience of the
>> l2vpn wg coming to this document will potentially be confused by the
>> generic words used in the title, abstract and introduction which may
>> lead them to expect this document to be concerned with more generic l2
>> services than is apparently the case.  I had to go back through the
>> framework document to the l2vpn charter to find that the VPLS service is
>> specifically intended for extending Ethernet LANs. It would greatly
>> reduce confusion if this was made clear up front.  Then it is more
>> obvious why ss3.4.x talk only about 'carrying Ethernet traffic' etc.,
>> and s4 talks only about Ethernet frames.


Okay.


>> s3: particularly s3.2.1 and s3.3, para 1: A paragraph on the motivation
>> for the use of VBO, VBS, LB would help (presumably to do with partition
>> and allocation of the label space).  Some brief advice on allocation
>> strategy would help both implementors and users.


Okay.


>> s3.1.2: What is the point of the statement "A more generic autodiscovery
>> mechanism is described in [8]."? Is the reader being pointed to this for
>> general review of autodiscovery mechanisms?  Is this an alternative
>> mechanism? If so how could it be used? Or is this just to indicate that
>> the mechanism used is a particular implementation or specialization of
>> that in [8]?


The first: a general review of autodiscovery.  I'll make that clear.


>> 3.4 introduction:  It would be helpful to make a general statement that
>> the various solutions constrain the inter-AS infrastructure in different
>> ways - as it stands the various statements are confusing - leading to
>> reactions like my next comment...
>> s3.4.1: Why does this suddenly mention Ethernet specifically (probably
>> because of the first clarification point above, but..)?  I would have
>> thought that the Inter-AS link has to be able to carry Ethernet frames
>> but does it have to be Ethernet?
>> s3.4.2: The first sentence of the last para ought to be placed much
>> earlier in the section: as it stands the talk of label swapping comes
>> before this statement and is confusing.
>> s3.4.3: appears to require inter-AS MPLS (talk of LSPs between PE1 and
>> PE2) but this is not stated explicitly (as compared with 3.4.1 and 3.4.2)


Okay.  Will tweak wording.


>> Consistency between this document ('LDP') and draft-ietf-l2vpn-vpls-bgp-05 ('BGP'):
>> - LDP talks about MAC address aging but BGP doesn't


(1) Some background:  both the BGP and LDP specs are about the control
plane -- signaling and (in the case of BGP) auto-discovery.  The data
plane is identical.  Thus, MAC address learning, aging, the treatment
of .1p bits, multicast/broadcast, etc. is *identical* in both schemes.

There was once talk of a common "data plane" document that captured
these aspects in a single document.  Ideally, this should have been
done; however, there was not enough incentive or enthusiasm to follow
through.  Also, the data plane part mostly just says "this works just
like Ethernet bridging."

Thus, whether one should talk about MAC aging or not is judgment call.
If you say that VPLS learning is similar to MAC learning, then it
follows that aging works similarly.  I suppose it doesn't hurt to say
so, though.  Similarly for multicast, or the treatment of .1p bits.

At this stage, it would be a fair amount of work to separate the
control and data plane descriptions.  The easy way out is to try to
keep the material as much in sync as possible.  (Thanks for your help
in this.)


>> - BGP recommends encapsulation via PWE3-CTRL whereas intro of LDP goes directly
>> to PWE3-ETH and doesn't mention the encapsulation in PWE3-CTRL


Historical.  All encaps were originally in PWE3-CTRL, then they got
broken out.  Will fix.


>> - LDP talks about treatment of multicast (s4) by e.g. using broadcast etc which
>> is barely treated in BGP


See (1)


>> - Scaling issues: LDP discusses a number of hierarchical solution but BGP
>> doesn't: LDP s7.1 talks about specialised encapsulations which may be of
>> relevance.  LDP hardly mentions scaling.


Actually, I would really like the LDP document to talk about scaling!
The LDP doc acknowledges a control plane scaling issue, and proposes
H-VPLS as a solution.  However, H-VPLS has serious implications on the
scaling of the data plane, which is not mentioned at all.

BGP has long since addressed the control plane scaling issue (with
Route Reflectors and/or BGP confederations).  I'll be happy to mention
that.


>> - Encapsulation: LDP s7.1 has a deal of discussion of 'service delimiting'
>> encapsulation that is missing from BGP.. is this a drop off in BGP or not
>> necessary? or is equivalent to the stuff regarding the P bit in s4.1 of BGP


Again, see (1).  This really orthogonal to how VPLS is signaled, or
the specifics of forwarding Ethernet frames in a VPLS.  However, I'll
do my best to make the data plane aspects the same between the two docs.


>> - LDP Qualified/Un-qualified learning: not clear if this is
>> interesting/available in BGP
>>
>> - BGP: Does this support 802.1p bits as is claimed for LDP - 802.1p is not
>> mentioned.


In LDP, the only mention I found is:

  The Ethernet VLAN PW provides a simple way to preserve customer
  802.1p bits.

Did I miss something?


>> Editorial:
>> global: Need to decide between 'fully-meshed' and 'fully meshed'.
>> s1, para 1: s/glues/glues together/
>> s1, next to last para: acronym PE is not defined until s2
>> s1: It may be a bit pedantic but LAN is not expanded.
>>
>> s2.1: SP is not expanded.
>> s2.2, s4.2.3: s/full-meshed/fully-meshed/
>>
>> s2.2: The statement that PEs are fully(-)meshed is duplicated (para 1
>> and para 3).


The two "full meshes" are at different levels -- all PEs are fully
meshed with *tunnels* and all PEs in a given VPLS are fully meshed
with *PWs*.  I'll clarify.


>> s3.4.1: There ought to be a reference for the Spanning Tree protocol.
>>
>> s6: The term 'P router' (which comes from [9], I think) is used without
>> any introduction: It should probably be introduced in s2.1.


Thanks, I'll fix these.


>> Tail: Yakov's email address is same as Kireeti's!


Good catch!  Cut-and-paste error when migrating from nroff to xml.

Kireeti.
-------

Write up for the draft-ietf-l2vpn-vpls-bgp-05.txt:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.


2) Has the document had adequate review from both key WG members and
  key non-WG members?

Yes.

  Do you have any concerns about the depth or breadth of the reviews
  that have been performed?

No.


3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

Security considerations are well understood.


4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.


5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

Strong agreement.


6) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarize what are they upset about.

No.


7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.


8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

Yes.


9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary
This document describes the Virtual Private LAN Service (VPLS), also  known as Transparent LAN Service and Virtual Private Switched Network  service.  The service offers a Layer 2 Virtual Private Network (VPN);  however, in the case of VPLS, the customers in the VPN are connected  by a multipoint network, in contrast to traditional Layer 2 VPNs,  which are point-to-point in nature.  This document describes the  functions required to offer VPLS, a mechanism for signaling a VPLS  using BGP, and rules for forwarding VPLS frames across a packet  switched network.

  - Working Group Summary
The VPLS solutions have been one of great controversies within the  VPN working groups ever since the PPVPN days.  There have been two  sets of solutions and much debate on the relative merits of these  solutions.  An agreement was reached that it is not really the choice  of signaling protocol that is the major difference between the LDP  and BGP based solutions, but the kind of environment they are  targeted at.  VPLS-LDP is aimed at a market of networks built on  relatively small and functionally simple switches, while VPLS-BGP is  primarily suited for use by high-end routers.  There is a  comparatively good understanding for this agreement in the working  group.  Within the working group there is no one that wants to go  over that debate again.  VPLS-BGP has been through a number of  reviews, including reviews in the L2VPN working group and the IDR  WG.  We know that Alex has requested that it shall be reviewed in  routing directorate.

  - Protocol Quality
The protocol is implemented and deployed.  There is one vendor who is  known to have implemented, and widely deployed, the VPLS-BGP spec.  There is believed to be two other implementations, but that hasn't  been confirmed.  The number of deployments is larger, but I don't  have figures.  We have not had any reviewer stand up and saying there  is any need for major re-work.  This is most likely attributable to  the fact that this specification is rather limited in scope,  specifically: signaling and discovery of VPLS instances.

IANA Last Call Comment:
Upon approval of this document the IANA will assign an AFI for L2VPN information (suggested value: 25). 
This assignment will be placed in the following registry:
http://www.iana.org/assignments/address-family-numbers

[Note]: 'WG writeup from Loa. I believe this had fallen through the cracks during the transition from Thomas to me. -------- Original Message --------
Subject: FW: last piece of the write up for the vpls-bgp
Date: Tue, 26 Apr 2005 16:11:35 -0700
From: Vach Kompella
Reply-To:
Organization: Alcatel USA
To: 'W. Mark Townsley'  > -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, March 01, 2005 8:21 AM
> To: Thomas Narten
> Cc: Vach Kompella; Rick Wilder; Margaret Wasserman; Mark Townsley
> Subject: last piece of the write up for the vpls-bgp
> > > Thomas,
> > find the write up for the vpls-bgp. I will request that the > vpls-ldp is reviewed to become an rfc on the standard tracks > soon. it just takes time to write everything.
> > /Loa
> > > Write up for the draft-ietf-l2vpn-vpls-bgp-05.txt:
> > Technical Summary
> > The service described in this document, the Virtual Private > LAN Service > (VPLS), also known as Transparent LAN Service, and Virtual Private > Switched Network service, offers a variant of a Layer 2 > Virtual Private > Network (L2VPN). In the case of VPLS, a multipoint network, > in contrast > to the more traditional Layer 2 VPNs, which are point-to-point in > nature, connects the VPN customers. This document describes the > functions required to offer VPLS, mechanisms for signaling a VPLS, to > discovery VPN end-points and rules for forwarding VPLS frames > across a > packet switched network, separate traffic in different VPN and to > de-multiplex traffic at the PE routers.
> > Working Group Summary
> > The vpls solutions have been one of the headaches of the VPN working > groups ever since the PPVPN days. There have been two sets of > solutions > and much arguing on the relative merits of these solutions.
> An agreement were reached it is not really the choice of signaling > protocol that is the major difference between the ldp and bgp based > solutions, but the kind of environment they are targeted for. > While the > vpls-ldp target a market of networks built on relative small and > function sparse switches the vpls-bgp targets the high-end routers. > There is a comparatively good understanding for this agreement in the > working group. Within the working group there is no one that > wants to go > over that debate again.
> The vplsd-bgp has been through a number of reviews, including > reviews in > the l2vpn working group and the idr group. We know that Alex has > requested that it shall be reviewed in routing directorate. These > many-facetted  reviews could in themselves become a problem if the > different reviewers do not agree upon what they are reviewing.
> > Protocol Quality
> > The protocol is implemented and deployed. The number of potential > vendors implementing the spec is "less than ten, but more > than three" as > far as I can get people talking. The number of deployments is larger, > but I don't have figures. We have not had any reviewer > standing up and > saying that there is any need for major rework, after all there is a > rather limited scope of this specification, how to signal and > discover > vplses.
> > -- > Loa Andersson
> > Principal Networking Architect
> Acreo AB                          phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson@acreo.se
>                                            loa@pi.se
>' added by Mark Townsley

[Note]: '
WG writeup from Loa. I believe this had fallen through the cracks during the transition from Thomas to me.

-------- Original Message --------
Subject: FW: last piece of the write up for the vpls-bgp
Date: Tue, 26 Apr 2005 16:11:35 -0700
From: Vach Kompella
Reply-To:
Organization: Alcatel USA
To: ''W. Mark Townsley''

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se]
> Sent: Tuesday, March 01, 2005 8:21 AM
> To: Thomas Narten
> Cc: Vach Kompella; Rick Wilder; Margaret Wasserman; Mark Townsley
> Subject: last piece of the write up for the vpls-bgp
>
>
> Thomas,
>
> find the write up for the vpls-bgp. I will request that the
> vpls-ldp is reviewed to become an rfc on the standard tracks
> soon. it just takes time to write everything.
>
> /Loa
>
>
> Write up for the draft-ietf-l2vpn-vpls-bgp-05.txt:
>
> Technical Summary
>
> The service described in this document, the Virtual Private
> LAN Service
> (VPLS), also known as Transparent LAN Service, and Virtual Private
> Switched Network service, offers a variant of a Layer 2
> Virtual Private
> Network (L2VPN). In the case of VPLS, a multipoint network,
> in contrast
> to the more traditional Layer 2 VPNs, which are point-to-point in
> nature, connects the VPN customers. This document describes the
> functions required to offer VPLS, mechanisms for signaling a VPLS, to
> discovery VPN end-points and rules for forwarding VPLS frames
> across a
> packet switched network, separate traffic in different VPN and to
> de-multiplex traffic at the PE routers.
>
> Working Group Summary
>
> The vpls solutions have been one of the headaches of the VPN working
> groups ever since the PPVPN days. There have been two sets of
> solutions
> and much arguing on the relative merits of these solutions.
> An agreement were reached it is not really the choice of signaling
> protocol that is the major difference between the ldp and bgp based
> solutions, but the kind of environment they are targeted for.
> While the
> vpls-ldp target a market of networks built on relative small and
> function sparse switches the vpls-bgp targets the high-end routers.
> There is a comparatively good understanding for this agreement in the
> working group. Within the working group there is no one that
> wants to go
> over that debate again.
> The vplsd-bgp has been through a number of reviews, including
> reviews in
> the l2vpn working group and the idr group. We know that Alex has
> requested that it shall be reviewed in routing directorate. These
> many-facetted  reviews could in themselves become a problem if the
> different reviewers do not agree upon what they are reviewing.
>
> Protocol Quality
>
> The protocol is implemented and deployed. The number of potential
> vendors implementing the spec is "less than ten, but more
> than three" as
> far as I can get people talking. The number of deployments is larger,
> but I don''t have figures. We have not had any reviewer
> standing up and
> saying that there is any need for major rework, after all there is a
> rather limited scope of this specification, how to signal and
> discover
> vplses.
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson@acreo.se
>                                             loa@pi.se
>

' added by Mark Townsley