Subject: Re: PWE3 question

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 May 2002 10:55:47 +0200

Hi Neil,

> NH=> I am failing to understand the issue here Eric.  Why is an ER LSP used
> for application X any different to an ER LSP used for application Y?  IMO
> the LSP should be agnostic to what it is carrying.

Yes - true, but I am afraid network and it's elements are not agnostic
to the amount of state you load on them. /

So to balance a bit what has been already said I would say that using
single level of label or encapsulation may run great for any application
it carries over it until it is far from the limit of scalability numbers
of any routers in your network. When you get close you have three
choices: 

* discontinue the service,
* upgrade/replace all devices in the net,
* use hierarchy (label stacking or other edge-edge encapsulation) hiding
P boxes from the # of instances of your PE-PE pipes.

The choice is yours :).

R.

> [email-masked] wrote:
> 
> > Our original assumption long  ago was that no one with a
> > clue would want to
> > use a  scheme in  which each pseudowire  lays down  state in
> > the  P routers.
> > Otherwise it would be as bad (unscalable) as ATM.
> NH=> This 'scalability' and 'what is bad' issue needs some qualification.
> Sure, mp2p LSPs scale better than p2p LSPs but at what latent cost?
> -       complex fault and performance management......probably relying on
> customers as the defect detection device for within-MPLS failures, or the L1
> networks for failures there which have decent fault management (courtesy of
> those pagans in the ITU);
> -       an inability to offer solid/measureable SLAs in VPN applications
> (where XoverMPLS is a subset of these in principle) because QoS and
> survivability get kludged together.  Connectivity is not the only criteria
> to judge the merit of a given approach here.
> -       operators have to throw BW (=money) at the VPN problem......cf with
> FR where overbooking is common, but because FR is p2p you can still
> prioritise properly on survivability.  So will a MPLS-based VPN network
> consume (=cost) maybe >4x (?) that of a FR-based VPN network?  OK, its not
> that simple I know....but senior managers like looking at utilisation
> figures and margins, and these days post the bubble bursting in our industry
> efficient network solutions are gaining in importance.
> 
> I also don't buy the N^2/2 reduction argument either.....if A wants to talk
> to B 'something' has to be configured p2p to allow this.....so mp2p LSPs
> simply push the problem up a layer, they don't get rid of it (and the BGP4
> LSPs in rfc2457 do exactly this function).   The use of hierachical networks
> is also an important factor wrt addressing scaling (though this is going in
> the other direction towards the duct).  What operators need are better
> OSS/NMS config tools to address the N^2/2 scaling problem properly.
> 
> The bottom-line is there is no free-lunch and merging is a blunt tool.....in
> generic public networks it might be OK, but for some applications (like
> VPNs) it fails to meet some basic service requirements IMO.  Scaling is not
> the only criteria to judge bad/good.
> >
> > Given that  one wants instead to  tunnel the pseudowires,
> > there  needs to be
> > some  applicable  signaling protocol  which  is  mandatory
> > to implement  in
> > devices  that set up  tunneled pseudowires.  This is
> > necessary in  order to
> > ensure multi-vendor interoperability.
> >
> > If  someone  wants to  standardize  a  method  for setting
> > up  non-tunneled
> > pseudowires, there is nothing to stop them, and no particular
> > reason why LDP
> > should be involved.
> >
> > I imagine the networks which want to do non-tunneled
> > pseudowires will be the
> > same  networks which  have deployed  CR-LDP, ITU's  standard
> > MPLS signaling
> > protocol, so you may wish to  look into that, perhaps within
> > the auspices of
> > ITU.
> >
> > There is  already an  i-d proposing  to use RSVP-TE  to set
> > up non-tunneled
> > pseudowires, though  I did try to  discourage the authors on
> > the grounds of
> > the assumption in the first paragraph above.
> NH=> I am failing to understand the issue here Eric.  Why is an ER LSP used
> for application X any different to an ER LSP used for application Y?  IMO
> the LSP should be agnostic to what it is carrying.  If you have a degenerate
> p2p LDP 1-hop LSP you will still need a lower level (transport) LSP....so
> you have to signal 'something' in the p2p LDP and also 'something' in the
> lower LSP......which also has to be an ER p2p LSP IMO if you want to offer
> proper QoS/management of such.  Further, because these LSPs are forming a
> client/server relationship, the server LSP has to meet the 'service' demands
> of its client LSP, ie the service requirement is recursively related.
> 
> The only argument I can see for discouraging people is to force everyone to
> use the LDP approach which some have already adopted....but architecturally
> dual LSP stacking seems an unecessary requirement, and I think that was all
> that was originally being pointed out by Shahram.
> 
> regards, Neil
> 
> >
> >
> >
> >
> >
> >
> >
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Eric Rosen <[email-masked]>
Date: Mon, 13 May 2002 13:10:08 -0400

Neil> I also don't buy the N^2/2 reduction argument either.....if A wants to
Neil> talk to B 'something' has to be configured p2p to allow this

I guess you mean "if A wants to  talk to B over a pseudowire ...".  If layer
3 connectivity is all that  is required, then there's this newfangled notion
of connectionless  networking that eliminates  the p2p stuff.   Nah, that'll
never catch on ;-)

Assuming  the context  here is  pseudowires, then  for a  full mesh  among N
endpoints  of course  one  needs N**2  PWs.   However, there  is no  O(N**2)
scaling problem in the network because  (a) any given PW endpoint only has N
PWs, and (b)  in the core of the  network one only needs state  for one mp2p
LSP per endpoint.  So the endpoints scale O(N) and the core scales O(N).

It is  true on  the other hand,  that the  PW provisioning system  scales as
O(N**2).  Not  much to do about that,  layer 2 just doesn't  scale nearly as
well as layer  3; that's an inherent  problem of layer 2 which  can never be
eliminated by NMS systems or even by VPLS-like schemes. 

Neil> mp2p LSPs simply push the problem up a layer, they don't get rid of it
Neil> (and the BGP4 LSPs in rfc2457 do exactly this function). 

The  BGP-distributed  labels of  RFC2547  do  not  create p2p  anything.  In
RFC2547, mp2p LSPs based on  BGP-distributed labels are carried in mp2p LSPs
based on LDP-distributed labels.  (That's why it's a layer 3 VPN service.)