Subject: New draft notification: draft-gu-l2vpn-vpls-analysis-00

From: Jie Dong <[email-masked]>
Date: Fri, 18 Mar 2011 01:52:40 +0000

Hi all, 

A new Internet-Draft is available from the on-line Internet-Drafts directories.

    Title         : Analysis of Virtual Private LAN Service (VPLS) Deployment
    Author(s)     : R. Gu, J. Dong, et al
    Filename      : draft-gu-l2vpn-vpls-analysis-00.txt
    
This document analyses the deployment of typical VPLS network with 
   existing solutions, and discusses the features of each solution. In 
   addition, this document indicates that the advantages of the 
   existing VPLS mechanisms may be integrated to achieve easier and 
   more efficient VPLS provisioning. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gu-l2vpn-vpls-analysis-00.txt

Any comments are welcome.

Best regards,
Jie

---

From: "Rogers, Josh" <[email-masked]>
Date: Fri, 18 Mar 2011 22:08:40 -0400

Jie (and other authors),

Thanks much for your work on this, I wish this was available back when I first started evaluating deployment options for VPLS.  While my overall impression is that this is a rather complete and well written draft on the subject, I'd like to submit a few comments:

+ Mention of 'maintaining VE-IDs' seems to sound like its difficult or administratively costly, but managing VPLS-ID (for LDP) is not mentioned on the comparison table, or mentioned as a negative anywhere.  Was this intentional because VE-ID must be globally unique, where VPLS-ID must only be unique among the PE's that are in the instance?  I'd expect that operators would maintain a globally unique list, regardless of whether they use LDP-VPLS or BGP-VPLS, just to avoid accidental overlaps, or problems with adding additional sites to an instance.
+ Comparison of 'full mesh' targeted LDP sessions and BGP may look similar due to the N*(N-1) sessions of each, however I don't think that is completely accurate.  If I understand most vendors implementation, you'd need N*(N-1) PER INSTANCE, where BGP only requires the a full mesh of sessions for the PE's involved.  For example, using Figure 1 as an example, there would be 6 configured BGP peers (two per PE), but would be 12 configured LDP peers (2 per VPLS instance per PE).
+ At the end of section 3, it seems that a proposed improvement to BGP-VPLS (adding on-demand label allocation, MAC withdrawal, and status notification) is suggested.  While I think this is an excellent notion, it should probably be included in a separate draft proposing those enhancements (and maybe also include other BGP based messages, such as VPMS signaling)

If I've misunderstood anything here, I'd really appreciate a detailed explanation that would set me straight.

Thanks much,
Josh

> Any comments are welcome.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Jie Dong <[email-masked]>
Date: Mon, 21 Mar 2011 07:38:42 +0000

Hi Rogers, 

Thanks a lot for your comments, and hope this document still helps in evaluating VPLS options:)

Please see some replies inline.

> + Mention of 'maintaining VE-IDs' seems to sound like its difficult or
> administratively costly, but managing VPLS-ID (for LDP) is not mentioned on
> the comparison table, or mentioned as a negative anywhere.  Was this
> intentional because VE-ID must be globally unique, where VPLS-ID must only
> be unique among the PE's that are in the instance?  I'd expect that
> operators would maintain a globally unique list, regardless of whether they
> use LDP-VPLS or BGP-VPLS, just to avoid accidental overlaps, or problems
> with adding additional sites to an instance.

Yes this version did not discuss lot about VPLS-ID (LDP) management, we could add some description in next revision to make the comparison clearer.
In section 2.1 , the third paragraph briefly describes the assignment of VPLS-ID:
"When using LDP based mechanism to deploy a VPLS network, one unique VPLS Identifier needs to be assigned for each VPLS instance."
VPLS ID needs to be globally unique among different VPLS instances, but for each instance all the participating PEs are using the same VPLS ID. Thus operators only need to maintain a global list of VPLS IDs and do not need to care about number of PEs in each instance. The management is at the granularity of VPLS instance. 
As for VE-IDs, in each VPLS instance it MUST be unique for every participating PE, hence the management is at the granularity of PE. Operators need to maintain different lists of VE-IDs for different VPLS instances. And the list needs be updated when adding additional sites to an instance. 
>From this perspective, this draft takes "management of VE-ID" as a disadvantage compared with "management of VPLS ID".

> + Comparison of 'full mesh' targeted LDP sessions and BGP may look similar
> due to the N*(N-1) sessions of each, however I don't think that is completely
> accurate.  If I understand most vendors implementation, you'd need N*(N-1)
> PER INSTANCE, where BGP only requires the a full mesh of sessions for the
> PE's involved.  For example, using Figure 1 as an example, there would be 6
> configured BGP peers (two per PE), but would be 12 configured LDP peers (2
> per VPLS instance per PE).

The difference in configurations between BGP and LDP in your example may due to BGP membership auto-discovery, thus in LDP (without BGP AD) operators need to configure remote participating PEs in each instance, while using BGP operators only need to configure the BGP peers and the VPLS members are auto-discovered.
Since signaling of different VPLS instances in LDP is identified using different PW FEC elements, hence multiple VPLS instances may share the same underlying T-LDP session. 
While signaling overhead in the full-mesh scenario may be similar, BGP signaling could have better scalability with use of Route Reflector. 

> + At the end of section 3, it seems that a proposed improvement to
> BGP-VPLS (adding on-demand label allocation, MAC withdrawal, and status
> notification) is suggested.  While I think this is an excellent notion, it should
> probably be included in a separate draft proposing those enhancements (and
> maybe also include other BGP based messages, such as VPMS signaling)

Agreed. This analysis draft is mainly to compare existing VPLS deployment options. After such comparison, it may be straight to ask whether we could obtain all the advantages and avoid most the disadvantages, hence section 3 gives some general description of a possible solution. Such solution (including protocol extensions) would be specified in detail in a separate draft. 

> explanation that would set me straight.

Thanks for these comments, and hope the replies could be helpful.

Further comments are more than appreciated.

Many thanks,
Jie

> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not the
> intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.