RE: [PWE3] PWE3 question

[neil.2.harrison@bt.com]

> 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
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3