Hi Tony,
> "reduce the paths of the packets" - I meant to say reduce number of paths > (presumably TE end to end paths) the packets may take to traverse a domain > from ingress to egress. Apologies for the shortcut. > > If you’re asking if this changes the number of LSPs in the network, it > does not. The goal is to consolidate existing LSPs together. > Before the optimization each ingress will have two LSPs (likely equal cost) to egress. If the optimization happens each ingress will be left with just one LSP. To me this is a reduction of the number of LSPs from 2 to 1 from each ingress node. I am not familiar with the term "LSP consolidation" nor "LSP de-consolidation" in the realm of RSVP-TE paradigm. That would be either poor path computation or colossally bad luck. > Presumably Ingress_1 has decided to move traffic for a good reason, based > on the available data. Even with make-before-break, latencies change and > can be performance impacting, so moving traffic is never done lightly. > > For Ingress_2 to look at the same state of the network and make the > opposite decision strongly suggests a bug in its path computation logic. > > If the path computations are not synchronized, then Ingress_2 would see > the results of Ingress_1’s action, providing further data to Ingress_2’s > computation. OK I think I am starting to get where you are heading ... yet still many parts of the machinery are cryptic. But at least for CSPF I think you are suggesting introduction of "stickiness" behaviour to alternative LSPs to traverse nodes with the destination of the specific egress. It's pretty interesting as so far we have been excluding links or nodes based on a zoo of flooded data. Here the action seems reversed. Smells like a patent to me :) That is out of scope for this document. Our job is to simply remove the > LSPs from the path that should be placed in sleep. Further mechanisms are > required. > Well sure you can say a number of things are out of scope. But don't you think that adding more flooding to link state protocols should at least be based on some framework or architecture document illustrating how new information passed in ISIS or OSPF is going to be used ? After all, don't we need a bit of interoperability when it comes to the ultimate goal which is power saving ? > Further mechanisms are required. Some of these may be implementation > dependent. Regardless, these are out of scope for this document and LSR. > I am not sure if shutting a line card or SFPs is an implementation matter. Quite contrary I would think they need to be very well and clearly defined to make vendor A to work in concern with vendor H in production networks when it comes to accomplishing the goal of some power savings. Many thx, Robert
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
