Re: [Lsr] LANs in IGPs
Robert – Having one circuit (or even 2 or 3) run in LAN mode “unnecessarily” does not represent a significant scale issue. The need for the extension you suggest would come only when there are many such circuits which could change from 2 nodes only to > 2 (and possibly back again). Unless that is a real world deployment case I would not consider the extension worth the trouble. Les From: Robert Raszuk Sent: Wednesday, April 03, 2019 11:17 AM To: Les Ginsberg (ginsberg) Cc: Robert Raszuk ; lsr@ietf.org Subject: Re: [Lsr] LANs in IGPs Well imagine I am building DMZ with two gateways and a firewall connected to L2 switch. I run IGP between them so my iBGP next hops can resolve. Later I may perhaps add third and fourth gateway. I can not normally set it as p2p IGP day one, but it could operate fine for the first few years as such. Thx, R. On Wed, Apr 3, 2019 at 8:10 PM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: If you want a way to more easily enable P2P mode by default – speak to your favorite vendor. That is a feature – not a protocol extension. Completely disagree. To detect how many IGP peers are on the interface and to do the switchover gracefully between 2 vs N or N vs 2 protocol extension is needed. It is not a single side local hack. [Les:] You are saying that customers today need to deploy circuits on which they are uncertain whether they will connect two nodes or more than two nodes? This is the first I have heard of such a requirement. If this really is a deployment requirement then such an extension could be considered. But since the extension isn’t trivial and isn’t backwards compatible I would not take this on without justification. Be interested to hear if anyone else on the deployment side of things believes this is needed. Les Thx, R. ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LANs in IGPs
> What extension are you proposing? If you have only two routers on LAN based on IIH multicast discovery you are still forming an adj between them (you do that anyway as one of them will be DIS). But for flooding reduction point of view you can treat it as p2p link (so it must be signaled as such). When Nth (N >= 3) router comes up you fall back to LAN mode and here you can support it or not. I guess your take is that since you want to support it anyway when N >= 3 there is no point of building the special case for the N=2. Thx, R. On Wed, Apr 3, 2019 at 7:56 PM wrote: > > Hi Robert, > > But I really think this isn’t relevant. The use of LANs in the flooding >> topology is only meaningful if we have a multi-access circuit which is used >> for transit traffic. And at least some of us are leaning to allowing for >> that possibility – which is not at all the same thing as saying you SHOULD >> run in LAN mode even if you don’t have to. Nor is it encouraging the use of >> multi-access LANs. >> > > I guess this is the question ... is dynamic flooding a new flooding > paradigm in IGPs to be used everywhere or is it only applicable to densely > connected topologies ? > > > > It is only sensible in dense topologies. In sparse topologies, such as > you would find in a WAN, there is very little improvement to be had. > > For example, at Prague I showed an 8x8 grid. The FT improvement was only > 36%. Given the computational cost, it’s probably not worth it. > > > If this is former - by all means support of real LANs is must have. If > this is the latter - I doubt. > > In fact if this is the latter more simplification in computing flooding > graph, less complexity in signalling and therefor less bugs will IMHO yield > much better outcome. > > In such cases it may be actually a feature to limit dynamic flooding to > p2p topologies only. > > > > Well, I have to disagree. While it’s nice to say that you will limit that > feature to those topologies, real operators push the envelope all of the > time. Things happen operationally. Folks can definitely use LANs > advantageously in dense topologies. It makes sense to support them. > > If you want a way to more easily enable P2P mode by default – speak to >> your favorite vendor. That is a feature – not a protocol extension. >> > > Completely disagree. To detect how many IGP peers are on the interface > and to do the switchover gracefully between 2 vs N or N vs 2 protocol > extension is needed. It is not a single side local hack. > > > > What extension are you proposing? > > Tony > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LANs in IGPs
If you want a way to more easily enable P2P mode by default – speak to your favorite vendor. That is a feature – not a protocol extension. Completely disagree. To detect how many IGP peers are on the interface and to do the switchover gracefully between 2 vs N or N vs 2 protocol extension is needed. It is not a single side local hack. [Les:] You are saying that customers today need to deploy circuits on which they are uncertain whether they will connect two nodes or more than two nodes? This is the first I have heard of such a requirement. If this really is a deployment requirement then such an extension could be considered. But since the extension isn’t trivial and isn’t backwards compatible I would not take this on without justification. Be interested to hear if anyone else on the deployment side of things believes this is needed. Les Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LANs in IGPs
Hi Robert, > But I really think this isn’t relevant. The use of LANs in the flooding > topology is only meaningful if we have a multi-access circuit which is used > for transit traffic. And at least some of us are leaning to allowing for that > possibility – which is not at all the same thing as saying you SHOULD run in > LAN mode even if you don’t have to. Nor is it encouraging the use of > multi-access LANs. > > > I guess this is the question ... is dynamic flooding a new flooding paradigm > in IGPs to be used everywhere or is it only applicable to densely connected > topologies ? It is only sensible in dense topologies. In sparse topologies, such as you would find in a WAN, there is very little improvement to be had. For example, at Prague I showed an 8x8 grid. The FT improvement was only 36%. Given the computational cost, it’s probably not worth it. > If this is former - by all means support of real LANs is must have. If this > is the latter - I doubt. > > In fact if this is the latter more simplification in computing flooding > graph, less complexity in signalling and therefor less bugs will IMHO yield > much better outcome. > > In such cases it may be actually a feature to limit dynamic flooding to p2p > topologies only. Well, I have to disagree. While it’s nice to say that you will limit that feature to those topologies, real operators push the envelope all of the time. Things happen operationally. Folks can definitely use LANs advantageously in dense topologies. It makes sense to support them. > If you want a way to more easily enable P2P mode by default – speak to your > favorite vendor. That is a feature – not a protocol extension. > > > Completely disagree. To detect how many IGP peers are on the interface and > to do the switchover gracefully between 2 vs N or N vs 2 protocol extension > is needed. It is not a single side local hack. What extension are you proposing? Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] LANs in IGPs
Hi Les, Sorry – but I really think you are taking this thread off topic. > If asking a question which is outside of the box is equal to thread hijacking then sorry. But you won - subject line changed. But I really think this isn’t relevant. The use of LANs in the flooding > topology is only meaningful if we have a multi-access circuit which is used > for transit traffic. And at least some of us are leaning to allowing for > that possibility – which is not at all the same thing as saying you SHOULD > run in LAN mode even if you don’t have to. Nor is it encouraging the use of > multi-access LANs. > I guess this is the question ... is dynamic flooding a new flooding paradigm in IGPs to be used everywhere or is it only applicable to densely connected topologies ? If this is former - by all means support of real LANs is must have. If this is the latter - I doubt. In fact if this is the latter more simplification in computing flooding graph, less complexity in signalling and therefor less bugs will IMHO yield much better outcome. In such cases it may be actually a feature to limit dynamic flooding to p2p topologies only. > If you want a way to more easily enable P2P mode by default – speak to > your favorite vendor. That is a feature – not a protocol extension. > Completely disagree. To detect how many IGP peers are on the interface and to do the switchover gracefully between 2 vs N or N vs 2 protocol extension is needed. It is not a single side local hack. Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
