hi les, please see inline.
On Mon, Nov 29, 2021 at 10:39:17PM +0000, Les Ginsberg (ginsberg) wrote: | Hannes - | | | | Thanx for bringing a new voice into the discussion. | | Please see inline. | | | | > -----Original Message----- | | > From: Hannes Gredler <[email protected]> | | > Sent: Monday, November 29, 2021 1:27 AM | | > To: Aijun Wang <[email protected]> | | > Cc: 'Robert Raszuk' <[email protected]>; 'lsr' <[email protected]>; Les | Ginsberg | | > (ginsberg) <[email protected]>; 'Tony Li' <[email protected]>; 'Shraddha | | > Hegde' <[email protected]>; Peter Psenak (ppsenak) | | > <[email protected]> | | > Subject: Re: [Lsr] BGP vs PUA/PULSE | | > | | > On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote: | | > | | > [ ... ] | | > | | > | Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the | | > different | | > | is how to propagate such “DOWN” information. Considering we have | | > observed | | > | that all P/PE router in other areas may be interested such | information, | | > | your proposal will require every P/PE router run BGP-LS, which is | not the | | > | aimed deploy scenarios for BGP-LS. | | > | | > HG> BGP-LS has been conceived to solve the very problem of providing | | > visibility of other | | > area's link state. I fail to see what is out of scope here. | | > | | [LES:] BGP-LS only advertises what the IGPs themselves advertise. HG> That is an implementation choice; the protocol allows multiple sources of information. https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#protocol-ids And even standalone implementations are fine as the LSVR WG suggests. | In this case, both IGP proposals involve ephemeral advertisements - so | even if we were to define BGP-LS support for these new advertisements - | they wouldn't persist long enough to be reflected in BGP-LS. HG> you could model the liveliness tracker as a "source protocol" and advertise the state of your endpoint. | So, I really don’t know why we are discussing BGP-LS in the context of | this thread. HG> because some people think it's a bad a idea to put this corner-case app in the very core of our networks. | (This seems to be one example of what Acee correctly identified as this | discussion going "off track".) HG> please do not derail the discussion. It is well within the mandate of LSR to discuss solution space and have a healthy discussion about the scalingaspects of a proposal. If the WG has concerns on the scaling properties and brings up alternatives to make a given use-case work that is IMO fine and we may just use some airtime for that. After all it's link-state routing, right ? | | | | > | Then, if IGP has such capabilities, why bother BGP? What is the | benefit? | | > | | > HG> simply put: seperation of concerns. Agreed consensus is to mostly | use | | > the | | > IGP for topology discovery and put the bulk of carrying reachability | | > information | | > into BGP which gives us: | | > | | [LES:] I am not convinced either side can claim "consensus" in this | discussion. That is a work in progress. 😊 HG> by consensus i meant that the BGP/IGP split is common practise of building large scale networks. | However, when you say IGPs are (exclusively?) for topology discovery - it | seems to suggest that IGP shouldn’t be advertising prefix reachability at | all. Hopefully, that is not what you intend. HG> did not say that. of course we need minimal IP reachability for bootstrapping the iBGP transport mesh. but we certainly do not use the IGP for carrying bulk routes at (Internet) scale. | One of the points that still baffles me is the assertion of an | architectural violation in the IGP proposals. | HG> did not say that. | | It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do | not summarize). | | It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s | instead of a single /16). | | It is even OK for IGPs to advertise some prefixes covered by a summary | along with the summary (don’t know if any implementations do this - but | they could). | | None of this is an "architectural violation". | HG> Again - Don't think its an architectual violation - I just think in it's current state it has a lot of havoc potential under load. | But advertising a summary and signaling the loss of reachability to a | specific prefix covered by the summary is seen by some as an architectural | violation. | | Sorry, I still don't understand this argument. | | | | You can not like the approach. You can be concerned about scaling | properties (more on that below). You can question the effectiveness of | ephemeral advertisements. | | These kinds of objections/concerns I can easily understand - even if we | don’t agree on their significance. | | But claiming that "IGPs are not supposed to do this"?? | | Not grokking this. | | | | We have not added any new information to the IGP itself. We are only | suggesting a new form of advertisement to signal some information already | known to the IGP, but which is currently not advertised (in some | deployments) by the configuration of summaries. | | | | | | > 1) flow-control capabilities (=by virtue of TCP) and | | > 2) furthermore operators can scale and isolate the distribution vehicle | for a | | > given AFI/SAFI service | | > using a dedicated RR infrastructure which does not mess with your | bread | | > and butter service | | > infra. | | > | | > IMO it is not a good idea to put (negative) reachability information | back into | | > the IGP as you | | > would loose this "seperation of concerns" aspect and potentially | de-stabilize | | > your topology discovery | | > tool and hence *all* your bread-and-butter services. | | > | | [LES:] The questions of scale (as I have previously commented) are very | legitimate - and more has to be specified before an IGP solution would be | considered ready for deployment. But there are tools easily applicable to | address this (rate limiting, embedded summarization, perhaps others). | | The more significant point is to focus on the goal - which in this usage | is improved convergence time. | | When the network is largely stable, convergence improvements can be | achieved w/o risk. HG> Ok. To me scaling under load is *the* issue. The question is what happens if the network gets unstable and your vanilla LSPs have to compete for I/O and CPU resources with your "negative updates". Can you see situations where this resource contention has destabilizing potential ? | When widespread failures occur, real time signaling of any type is | unlikely to provide improved convergence - which is why the IGPs today | shift the focus from convergence to stability by slowing down the rate of | updates sent and SPFs performed. This is STILL true even in the fast | convergence/FRR era. | | I see no reason why the same tools should not be used in this case. HG> well when the fun starts - and 1000s of LSPs fly like bullets, good luck pacing that ... _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
