Re: [PWE3] PWE3 question

[Robert Raszuk <raszuk@cisco.com>]

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.

> neil.2.harrison@bt.com 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
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3