Subject: draft-kompella-ppvpn-vpls-01.txt

From: "DECRAENE Bruno FTRD/DAC/ISS" <[email-masked]>
Date: Tue, 15 Apr 2003 18:50:31 +0200

We would like to support draft-kompella-ppvpn-vpls-01.txt, making this a working group draft.

Regarding management, the less work, the better.
- Using one -well known- protocol (MP-BGP) for discovery and signalling is easier to manage than two protocols (LDP + MP-BGP/RADIUS/DNS/?)
- BGP RR greatly reduces the number of sessions to monitor: o(N) vs o(N*N)
- With the large scale deployment of 2547 VPN, we gained valuable experience with MP-BGP (managing, scaling,...). Seems fine to re-use it.

As Rahul said, both drafts are interesting for various SP/customers. It would be better if -at least- the data plane description were the same. 

Regards,

Benoît, David, Bruno

> -----Original Message-----
> From: Rahul Aggarwal [mailto:[email-masked]]
> Sent: Monday, April 14, 2003 4:35 PM
> To: [email-masked]
> Subject: Regarding progressing VPLS docs
> 
> 
> 
> Hi Marco and Rick,
> 
> I would like to add my support for making both:
> 
>  draft-lasserre-vkompella-ppvpn-vpls-04.txt
>  draft-kompella-ppvpn-vpls-01.txt
> 
> as WG docs with the caveat that the common parts should not be
> repeated. draft-lasserre may be a good place to keep the common
> portion. In particular the data plane description that is 
> common to these
> specs can be left in draft-lasserre and pulled out of draft-kompella. 
> 
> Its possible to have a never ending discussion on the pros and cons of
> each. The bottomline is that LDP signaling + protocol X 
> auto-discovery or
> BGP signaling + BGP auto-discovery, both have their own 
> applicability. If
> down the road we figure out that one of these solutions doesn't have
> deployment traction, the respective doc doesn't have to be 
> moved to RFC
> status. 
> 
> Thanks,
> rahul
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 17 Apr 2003 13:50:58 -0400

A few short comments: 

> - Using one -well known- protocol (MP-BGP) for discovery and signalling is
>   easier to manage than two protocols (LDP + MP-BGP/RADIUS/DNS/?)  

Well,  that's exactly what  was said  in favor  of CR-LDP  ;-) In  fact, the
overwhelming majority of  2547 networks have LDP already,  so the comparison
really  is BGP+LDP  vs.  BGP+LDP,  with the  difference  being over  whether
certain functions go in one place or the other.

>- BGP RR greatly reduces the number of sessions to monitor: o(N) vs o(N*N)

Indeed, this  is its main  advantage.  (Well, every proposal  has advantages
and  disadvantages  ;-))  However,  you  still have  O(N*N)  pseudowires  to
monitor, (not  to mention  that learning and  multicast replication  must be
applied to each pseudowire) so the  overall scalability of the scheme is not
improved.

(Note also that in routing, RRs improve scalability by digesting the routing
information and  applying the decision process, thereby  reducing the amount
of  information that needs  to be  passed along.   This sort  of scalability
improvement is not possible in L2VPN.)

> Regarding management, the less work, the better. 

Typically, maintaining  a point-to-point circuit  requires maintaining state
at  both  its  endpoints.  If  the  control  information  that sets  up  and
maintains the  circuit must lay down state  in a third party  (RR), a fourth
party (two RRs), or more  (hierarchical RRs), the management work would seem
to be more rather than less.

>-  With the  large  scale  deployment of  2547  VPN,  we gained  valuable
>   experience with MP-BGP (managing, scaling,...). Seems fine to re-use it.  
 
I'd  be the  first to  agree that  2547  VPNs are  really a  great piece  of
technology ;-)  But even  I wouldn't say  that it  is the solution  to every
problem.

Some  SPs expect  to  have lots  more  PEs supporting  VPLS  than they  have
supporting L3VPN, perhaps hundreds or  even thousands more.  I don't know if
this applies to  you, but if it  does you will certainly need  to be putting
your experience to good use as  you add all these additional clients to your
RRs ;-)

---

From: "LIAN Franklin FTLD/IAP" <[email-masked]>
Date: Fri, 18 Apr 2003 15:41:16 -0400

FTRLD is the IP service division of France Telecom, we would like to 
echo our colleagues' support to draft-kompella-ppvpn-vpls-01.txt,
making this a working group draft.

Best regards,
Zidan Lian

---

From: Alex Zinin <[email-masked]>
Date: Fri, 18 Apr 2003 15:10:21 -0700

Zidan-

 The IETF does not recognize companies, especially when consensus is
 being gauged within a WG. You should express your *personal* and
 *technical* opinion.

 Cheers.

-- 
Alex
http://www.psg.com/~zinin/

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 18 Apr 2003 19:30:33 -0700 (PDT)

Hi Alex,

>  being gauged within a WG. You should express your *personal* and

Is it okay to mention one's affiliation, so that others can see
whether this opinion comes from a vendor or a provider?

Also, as far as I can judge, a hum or a raised hand or an email that
"we'd like to support this draft" are all equally technical.

Kireeti.

---

From: Alex Zinin <[email-masked]>
Date: Mon, 21 Apr 2003 13:39:18 -0700

Hi,

<AD>

To all WG participants: BTW, my comment was not specific to Zidan's
e-mail only. I've seen another 2 or 3 e-mails also stating a company's
opinion. My recommendation to guys posted those is to state their
personal opinion on the mailing list with their company's hat off.

</AD>

Kireeti, below, pls.

Friday, April 18, 2003, 7:30:33 PM, Kireeti Kompella wrote:
...

> "we'd like to support this draft" are all equally technical.

As a co-chair of an IETF WG, you know, of course, that in the IETF,
"Participation is by individual technical contributors, rather than by
formal representatives of organizations".

If operational nature of someone's personal feedback needs to be
stressed, something like "I am from a Service Provider, and I believe
that..." should work well. Something like "We think...", "I'm from
<company-blah> and we believe...", or "<company-blah> believes...", is
a wrong way of doing this, especially when the WG consensus is being
gauged.

IRET       ; Return from AD interrupt

Alex