Subject: RE: Truly Generalized VPLS (?)

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 22 Jul 2003 15:11:57 -0400

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Tuesday, July 22, 2003 1:51 PM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]'
> Subject: Re: Truly Generalized VPLS (?) 
> 
> 
> 
> The point  of the decoupled  procedures is to  reduce the 
> number  of control
> connections (e.g., LDP connections) which must be maintained 
> by any one U-PE
> device.  By using  decoupled proceudres, a (spliced) PW  can 
> run between two
> U-PEs without there being an LDP  connection between the 
> U-PEs.  This is the
> scalability  consideration.   I don't  see  how  you  get 
> that  without  the
> splicing methodology.  

Since for a given VPLS, a U-PE needs PWs to a limited number of remote U-PEs, I thought it would make more sense to use RSVP-TE instead of LDP.

In any case, I don't think that control connections would exist between U-PEs. PW labels need to be assigned on every segment of the end-to-end PW and I don't know how you would do that without involving the intermediate hops. Hence, if you use LDP, a U-PE would have an LDP control connections with its neighboring N-PEs, not with its remote U-PE peers. This would be the same as in the spliced approach. But again, I think that it would make more sense to use RSVP-TE.

> 
> Peter> Since the forwarding  function in the N-PEs is  
> essentially a form of
> Peter> label switching, the  question is: why don't we  treat 
> the connection
> Peter> between two U-PEs as a  regular Label Switched Path 
> that goes through
> Peter> multiple intermediate  hops and  is set up  and 
> managed  with regular
> Peter> MPLS protocols and tools?
> 
> Because that requires an LDP connection between the two U-PEs. 
> 
> Peter> Draft-radoaca-ppvpn-gvpls  prescribes a  fixed  
> topology:  U-PEs  are
> Peter> connected  to N-PEs  and  there is  a  full mesh  of 
> tunnels  between
> Peter> N-PEs. Hence, a PW goes at maximum through two 
> intermediate hops.
> 
> Not necessarily.  See,  e.g., the related material in  
> section 5.5 of draft-
> rosen-ppvpn-l2-signaling.   There  is  no  fundamental  
> restriction  on  the
> topology. 
> 

You are right. However, the problem I have with the splicing approach is that it looks very much like manual provisioning. Where do the local lists and remote lists that you specify in 5.5 come from? I guess that with a smart usage of autodiscovery algorithms you can come pretty far, but is this not a problem that begs for the use of the routing and signaling protocols that we all know and love?

> One may ask of  course whether it is worthwhile to reduce  
> the number of LDP
> connections.  After all, the signaling load is, to first 
> order, proportional
> to the  number of PWs supported, not  to the number of  LDP 
> connections, and
> the splicing  approach does not  reduce the number  of PWs.  
> In  most common
> cases I think that a reduction in  the number of LDP 
> connections is not that
> big a  deal.  However, there are  a couple of  cases where it 
> might  be very
> useful: 
> 
> - A "low end" U-PE with limits on its TCP support. 
> 
> - When PWs  go between SPs, the control connections need  to 
> be secured, and
>   this requires management; having fewer means less management. 
> 

> With regard to the extra "control word" and to the MAC-in-MAC 
> stuff, well, I
> agree that those particular pieces are not likely to go anywhere. 
> 
> 
> 
> 
> 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Wed, 23 Jul 2003 12:13:00 -0400

Peter> Since  for a given  VPLS, a  U-PE needs  PWs to  a limited  number of
Peter> remote  U-PEs, I  thought it  would make  more sense  to  use RSVP-TE
Peter> instead of LDP.  

I don't understand why you think so. 

Peter> However, the  problem I  have with the  splicing approach is  that it
Peter> looks very much like manual provisioning 

I guess I don't really understand  your alternative, and just how it differs
from the splicing approach.  Can you describe it in a bit more detail?