Re: BFD for routes learned trough Route-servers in IXPs
On Wed, 16 Sep 2020 at 23:15, Chriztoffer Hansen wrote: > On 16/09/2020 04:01, Ryan Hamel wrote: > > CoPP is always important, and it's not just Mikrotik's with default low > > ARP timeouts. > > > > Linux - 1 minute > > Brocade - 10 minutes > > Cumulus - 18 minutes > > BSD distros - 20 minutes > > Extreme - 20 minutes > Juniper - 20 minutes > > HP - 25 minutes IOS - 4 hours Why are these considered (by Ryan) low values? Does low have a negative connotation here? ARP timeout should be lower than MAC timeout, and MAC timeout usually is 300 seconds. Anything above 300seconds is probably poor BCP for default value, as defaults should interoperate in a somewhat sane manner. Of course operators are free to configure very high ARP timeout, as long as they also remember to equally configure higher MAC timeout. -- ++ytti
RE: SRm6 (was:SRv6)
Robert, Absolutely nothing. In fact, that is very close to what we had in mind in RFC 4797. But couldn't the same argument be used with regard to SRv6 when the network operator wants traffic to take the least-cost path from PE to PE? Ron Juniper Business Use Only From: Robert Raszuk Sent: Wednesday, September 16, 2020 5:51 PM To: Ron Bonica Cc: nanog@nanog.org Subject: Re: SRm6 (was:SRv6) [External Email. Be cautious of content] Hi Ron, > If you want an IPv6 underlay for a network offering VPN services And what's wrong again with MPLS over UDP to accomplish the very same with simplicity ? MPLS - just a demux label to a VRF/CE UDP with IPv6 header plain and simple + minor benefit: you get all of this with zero change to shipping hardware and software ... Why do we need to go via decks of SRm6 slides and new wave of protocols extensions ??? Best, Robert. On Wed, Sep 16, 2020 at 10:17 PM Ron Bonica via NANOG mailto:nanog@nanog.org>> wrote: Folks, If you want an IPv6 underlay for a network offering VPN services, it makes sense to: * Retain RFC 4291 IPv6 address semantics * Decouple the TE mechanism from the service labeling mechanism Please consider the TE mechanism described in draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism described in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and match basis. For example can deploy: * Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow the least-cost path from PE to PE. * Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy method (VXLAN, RFC 4797) to label services. In all cases, the semantic of the IPv6 address is unchanged. There is no need to encode anything new in the IPv6 address. Ron Juniper Business Use Only
Re: SRv6
Mark, > On 16 Sep 2020, at 10:32, Mark Tinka wrote: > > On 15/Sep/20 19:00, aar...@gvtc.com wrote: > >> Sorry guys, I'm not aware of much of what you mention as far as agenda, >> vendor motive, and hardware support, etc > > I'm not shy... this would be Cisco. And that’s fine. The fact that some Intellectual Property[1] was created by one vendor or another (disclaimer - I work for Cisco) shouldn’t be by default something that discredits the idea. And BTW, if You look into the history of how SR started, it was close feedback loop with at least some of the ISPs wanting to have “easier” and SDN-ish control over the network so the blame should be shared :) Having support from other vendors was de facto requirement to even think about deploying it widely and that's better approach IMHO than “lets patent everything out and force everyone into our black-box-architecture that’s best in the world”. I’m observing the discussions over the last couple of months and generally they boil down to “leave us alone, everything sucks, we’ll stay with what we have”. And sure, as you indisputably proven during last 30 years, running modern ISP network can be done over IP, MPLS, and the network can even survive introduction of IPv6. And I get it - vendors have generally failed to address your ideas and problems in timely manner, and when we did, quality was simply not there. But really, is that all what’s interesting in life? I doubt it. Unless the whole point of discussing here would be to start from technical topics (because of ‘rules’) and end up with everybodys favorite part - beating virtual Pinata made to look like representation of most hated salesman/vendor. Then sorry, I somehow missed that :) While I personally find the idea of stacking IPv6 labels gruesome for any non-trivial label depth[2] (and I'm really worried about software guys coming in from the “mobile app” world soon, and finding out that they can create those IPv6 EH stacks easily), going forward we have to think about what will keep networks running in for the next 5, 10 or 20 years. IPv4 with MPLS+LDP+RSVP-TE will work fine of course, so will SRoMPLS, but IPv6 is gaining adoption and need to multiplex/demultiplex more and more services and users will only grow. And BTW, MPLS forwarding between ASes in the internet is still something that works mainly on slides, highly paid consulting “proposals” and of course on the CCIE exam. On the other side, there’s Elon Musk moving us to Mars, wretched IoT world with “build, sell and forget" mentality w/r to firmware and good network stacks. And yet only 59% people around the world today have internet access. At least good portion of that heavily filtered one by the way. IPv6 seems to be good plan forward (and would potentially unify architecture of normal routing and overlay routing with SRv6), even if things like MPLSoUDP or GRE would really solve everything if pushed with enough force[3] ;) It’s worth observing, that from this perspective IPinIP would be as good as SRv6 if everyone would agree 20 years ago that source routing is acceptable. LDP or RSVP-TE would never gain any usage and maybe we wouldn’t learn lesson or two. BTW, we tried to somehow get back to this simplification with LISP[4], and in the long run it seems overloading address semantics is not something that is happily accepted everywhere, and it doesn’t matter if that's IPv4 or IPv6. So much hated middleboxes will also adopt faster to IPv6, as adopting MPLS data plane after those 20 years on firewalls, load balancers and what-you looks kind of dissapointingly. And if we are talking about network functions - I believe it’s more important right now to agree on one way of doing service chaining, than discussing SR or SRv6 as evil seed created to conquer the world. SR takes out state out, and SRv6 has the same address format on the outside as well as inside. You can happily run it with both data planes, and while today maybe you can’t provide migration of ALL services, SR+IGP quite nicely interworks with MPLS+LDP. Will HW evolve? It has to anyway, no previous change was done day one and 128 bits times 5 or 8 or 12 seems horrible only today. Over the years, people got used to bigger horrors ;) — ./ [1]. https://patents.google.com/patent/US20140169370 [2]. Yeah, Binding SIDs of course, but that’s a solution to self-made problem as Ivan Pepelnjak would say. [3]. https://tools.ietf.org/html/rfc1925 point 2.3. [4]. https://tools.ietf.org/html/rfc6830
geofeeds over is-is (was: how would draft-ymbk-opsawg-finding-geofeeds work in noam)
$ubject changed as it is now where to put the pointer [ we have email suggesting putting the geoloc pointer in dns, routing databases, ... no one has suggested bgp yet, but i assume it is coming ] > I assume that someone (entity) publishes a geo-feed > I assume that location of this feed (and others) is the goal of this > work/draft. yep > I don't see how you can easily link (correctly/securely) the publisher > with the correct data location, without something that clearly ties > the publisher to be the owner/authorized-user of the ip space included > in the geofeed. the draft discusses that, see sec 4 and the sec cons > use of rpki for geo-feed-URL seems like the simple way to tie > owner/publisher. i suspect 'simple' is not the term you want. perhaps 'authoritative' folk want to publish usefully now, and in fact are doing so. this scheme, admittedly a compromise, allows immediate incremental deployment with optional authentication using the rpki; the best of both worlds. also trying to minimize the silo bridging problem in large orgs but, if you write a draft to put a geofeed pointer in the rpki, send me an email, as i no longer read sidrops.
Re: SRm6 (was:SRv6)
Hi Ron, > If you want an IPv6 underlay for a network offering VPN services And what's wrong again with MPLS over UDP to accomplish the very same with simplicity ? MPLS - just a demux label to a VRF/CE UDP with IPv6 header plain and simple + minor benefit: you get all of this with zero change to shipping hardware and software ... Why do we need to go via decks of SRm6 slides and new wave of protocols extensions ??? Best, Robert. On Wed, Sep 16, 2020 at 10:17 PM Ron Bonica via NANOG wrote: > Folks, > > > > If you want an IPv6 underlay for a network offering VPN services, it makes > sense to: > > > >- Retain RFC 4291 IPv6 address semantics >- Decouple the TE mechanism from the service labeling mechanism > > > > Please consider the TE mechanism described in > draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism described > in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and match > basis. For example can deploy: > > > >- Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow the >least-cost path from PE to PE. >- Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy method >(VXLAN, RFC 4797) to label services. > > > > In all cases, the semantic of the IPv6 address is unchanged. There is no > need to encode anything new in the IPv6 address. > > > > > Ron > > > > Juniper Business Use Only >
Re: SRv6
My backyard is private. It offers no privacy with its chain link fence against a major street. On 9/16/20 4:38 PM, Randy Bush wrote: Privacy != encryption. cleartext == privacy * 0 cleartext * complexity == privacy * 0 randy
Re: SRv6
> It depends on the definition of VPN. in my definition, the P stands for privacy not plaintext > In terms of services like MPLS-based VPNs, it refers to the extension > of a Private network over a shared infrastructure, allowing entities > using the shared infrastructure to have their own private address > space and routing tables. i think we wrote the paper on that :) http://www.ieee-infocom.org/2003/papers/36_02.PDF randy
Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam
I have a question which might be about data flow here... I assume that someone (entity) publishes a geo-feed I assume that location of this feed (and others) is the goal of this work/draft. (I have no idea how this is done today.. aside from 1 implementation that requires a user to 'login' to a system and provide a url) I don't see how you can easily link (correctly/securely) the publisher with the correct data location, without something that clearly ties the publisher to be the owner/authorized-user of the ip space included in the geofeed. To get to that tie, I'd just expect to see this published in RPKI. Does that work for all/most cases? I think we heard terry manderson's proposal in SIDR 'a long time ago' and 'everyone' said: "but what about the privacy!!!" (we could have / did overreact maybe) but that use of rpki for geo-feed-URL seems like the simple way to tie owner/publisher. On Tue, Sep 15, 2020 at 4:52 PM Randy Bush wrote: > > perchance is RDAP implemented by all RIRs? > > randy
Re: SRv6
On Tue, Sep 15, 2020 at 5:08 PM Randy Bush wrote: > > You might be on to something, but I'm unsure... are you suggesting that > it's > > any less private over SRv6 than it was over MPLS ? > > neither srv6, srmpls, mpls, gre, ... provide privacy. they all > transport the payload in nekkid cleartext. > > Dance like no one's watching. Encrypt like everyone is. > It depends on the definition of VPN. In terms of services like MPLS-based VPNs, it refers to the extension of a Private network over a shared infrastructure, allowing entities using the shared infrastructure to have their own private address space and routing tables.
Re: BFD for routes learned trough Route-servers in IXPs
On Wed, Sep 16, 2020 at 4:55 PM Randy Bush wrote: > > >>> So, I was searching on how to solve that and I found a draft (8th release) > >>> with the intention to solve that... > >>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 > >>> > >>> If understood correctly, the effective implementation of it will depend on > >>> new code on any BGP engine that will want to do that check. > >>> It is kind of frustrating... At least 10 years after the release of RFC > >>> until the refresh os every router involved in IXPs in the world. > >> > >> you have a better (== easier to implement and deploy) signaling path? > >> > >> the draft passed wglc in 1948. it is awaiting two implementations, as > >> is the wont of the idr wg. > > > > I think you also mean to say: "this is actually still a DRAFT and not > > an RFC, so really no BGP implementor is beholden to this document, > > unless they have coin bearing customers who wish to see this feature > > implemented" > > if i had meant to say that, i probably would have. no one on this > thread has called it anything other than a draft, so i am quite unsure > what your point is; and i will not put words in your mouth. I think the OP said: " At least 10 years after the release of RFC > >>> until the refresh os every router involved in IXPs in the world." it's not an rfc yet. > sadly, these years, vendors do not seem to care a lot about drafts, > rfcs, ... anything which sells. sure :(
Re: BFD for routes learned trough Route-servers in IXPs
>>> So, I was searching on how to solve that and I found a draft (8th release) >>> with the intention to solve that... >>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 >>> >>> If understood correctly, the effective implementation of it will depend on >>> new code on any BGP engine that will want to do that check. >>> It is kind of frustrating... At least 10 years after the release of RFC >>> until the refresh os every router involved in IXPs in the world. >> >> you have a better (== easier to implement and deploy) signaling path? >> >> the draft passed wglc in 1948. it is awaiting two implementations, as >> is the wont of the idr wg. > > I think you also mean to say: "this is actually still a DRAFT and not > an RFC, so really no BGP implementor is beholden to this document, > unless they have coin bearing customers who wish to see this feature > implemented" if i had meant to say that, i probably would have. no one on this thread has called it anything other than a draft, so i am quite unsure what your point is; and i will not put words in your mouth. sadly, these years, vendors do not seem to care a lot about drafts, rfcs, ... anything which sells. randy
Re: BFD for routes learned trough Route-servers in IXPs
On Tue, Sep 15, 2020 at 9:40 PM Randy Bush wrote: > > > So, I was searching on how to solve that and I found a draft (8th release) > > with the intention to solve that... > > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 > > > > If understood correctly, the effective implementation of it will depend on > > new code on any BGP engine that will want to do that check. > > It is kind of frustrating... At least 10 years after the release of RFC > > until the refresh os every router involved in IXPs in the world. > > you have a better (== easier to implement and deploy) signaling path? > > the draft passed wglc in 1948. it is awaiting two implementations, as > is the wont of the idr wg. I think you also mean to say: "this is actually still a DRAFT and not an RFC, so really no BGP implementor is beholden to this document, unless they have coin bearing customers who wish to see this feature implemented"
Re: SRv6
> Privacy != encryption. cleartext == privacy * 0 cleartext * complexity == privacy * 0 randy
SRm6 (was:SRv6)
Folks, If you want an IPv6 underlay for a network offering VPN services, it makes sense to: * Retain RFC 4291 IPv6 address semantics * Decouple the TE mechanism from the service labeling mechanism Please consider the TE mechanism described in draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism described in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and match basis. For example can deploy: * Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow the least-cost path from PE to PE. * Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy method (VXLAN, RFC 4797) to label services. In all cases, the semantic of the IPv6 address is unchanged. There is no need to encode anything new in the IPv6 address. Ron Juniper Business Use Only
BFD for routes learned trough Route-servers in IXPs
On 16/09/2020 04:01, Ryan Hamel wrote: > CoPP is always important, and it's not just Mikrotik's with default low > ARP timeouts. > > Linux - 1 minute > Brocade - 10 minutes > Cumulus - 18 minutes > BSD distros - 20 minutes > Extreme - 20 minutes Juniper - 20 minutes > HP - 25 minutes -- Chriztoffer smime.p7s Description: S/MIME Cryptographic Signature
Re: Cogent emails
My reply to Cogent sales reps is usually something along the lines of "We have a corporate policy of only taking connections from providers that can give us a full Internet connection." They get defensive when I point out that they have large holes in their IPv6 routing table, but it usually gets them to go away for a while. On Mon, Sep 14, 2020 at 2:23 PM Ryan Wilkins wrote: > > All I did was express interest a few years ago and ever since then they’ve > called and emailed me pretty regularly. Just got one yesterday. I’m > probably on the fourth sales guy now since I first asked. > > Ryan Wilkins > > > On Sep 14, 2020, at 3:00 PM, Jesse DuPont > > wrote: > > > > We started getting emails the moment we got our own AS (earlier this year). >
Re: CenturyLink -> Lumen
Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions. On Wed, Sep 16, 2020 at 9:31 AM Tom Hill wrote: > On 16/09/2020 11:18, Matt Hoppes wrote: > > Quantum Fiber? Sounds like a misbranding. I highly doubt they are using > > Quantum technology. > > > Very prescient for when it becomes commercially possible though, eh? :) > How will they know if they have enough slack to patch a cut? They won't know until they observe it...
Re: SRv6
On Tue, 15 Sep 2020 at 19:14, Randy Bush wrote: > > > I'm still learning, but, It does seem interesting that the IP layer > > (v6) can now support vpn's without mpls. > > as the packet payload is nekkid cleartext, where is the P in vpn? Define "privacy". In the kind of VPN I think you're suggesting (e.g. an IPSEC based VPN) they implement the classic CIA acronym (Confidentiality, Integrity and Authentication, with the "C" essentially meaning "encrypted" in practice however, privacy requires all three of "CIA", encryption alone isn't privacy). "VPN" is not mutually dependent on "CIA", the two things can and do exist separately. WIth MPLS L3 VPNs for example, the traffic isn't encrypted, but by creating a layer of abstraction (at the control plane, by signalling via MP-BGP using RDs and RTs, and at the forwarding plane by using MPLS tunneling) a customer's routing data and forwarding data is kept private (not encrypted!) from my physical infa forwarding- and control-planes, and from each other L3 VPN customer on my infra [1]. In fact, the point that customer (control- and forwarding-plane) data is kept private from MY INFRA, is *the* fundamental aspect of MPLS L3 VPNs; they wouldn't scale at all without it. Privacy != encryption. Cheers, James. [1] This doesn't mean there aren't security flaws in MPLS (there are, but there are in things like IPSEC too), and "how secure" it is, is a separate subject.
Re: CenturyLink -> Lumen
On 16/09/2020 11:18, Matt Hoppes wrote: > Quantum Fiber? Sounds like a misbranding. I highly doubt they are using > Quantum technology. Very prescient for when it becomes commercially possible though, eh? :) -- Tom
Re: SRv6
On 16/09/2020 01:31, aar...@gvtc.com wrote: > then, yes, I may have and didn't know it. Hey, was it you? LOL Very unlikely. You may do well to peruse some of the objections to the network-programming draft in the SPRING WG. There are many. :) -- Tom
Re: CenturyLink -> Lumen
I think this is just someone trying to pull the stock price out of the dumps by branding themselves a “tech company”. There are still things from the TWTelecom days they haven’t finished integrating into the control panel, this should be fun watching them try to change the name at the same time. From: NANOG on behalf of "R. Leigh Hennig" Reply-To: "R. Leigh Hennig" Date: Wednesday, September 16, 2020 at 12:51 AM To: "nanog@nanog.org" Subject: CenturyLink -> Lumen https://www.fiercetelecom.com/telecom/centurylink-rebrands-re-defines-enterprise-sector-as-lumen-technology Curious. Any thoughts on how this changes their business approach, if any? Obviously something like this has to be planned far in advance, but I can’t help but wonder what impact the recent outage and bad press might have had on their plans here, possibly accelerating them? Probably not. But it’s an interesting move regardless. . | R. Leigh Hennig, Principal Network Architect ..| Markley Group https://markleygroup.com Sent from ProtonMail Mobile
Re: CenturyLink -> Lumen
Quantum Fiber? Sounds like a misbranding. I highly doubt they are using Quantum technology. That’s how Lowe’s got in a lawsuit for selling 8” boards that were 7.6” long and similar. > On Sep 16, 2020, at 12:53 AM, R. Leigh Hennig wrote: > > > https://www.fiercetelecom.com/telecom/centurylink-rebrands-re-defines-enterprise-sector-as-lumen-technology > > Curious. Any thoughts on how this changes their business approach, if any? > Obviously something like this has to be planned far in advance, but I can’t > help but wonder what impact the recent outage and bad press might have had on > their plans here, possibly accelerating them? Probably not. But it’s an > interesting move regardless. > > > . | R. Leigh Hennig, Principal Network Architect > ..| Markley Group https://markleygroup.com > > > Sent from ProtonMail Mobile
Re: BFD for routes learned trough Route-servers in IXPs
Ryan Hamel wrote on 16/09/2020 03:01: Install a route optimizer that constantly pings next hops or if you want a more reliable IXP experience, don't install a route optimiser and if you do, don't make it ping next-hops. - you're not guaranteed that the icmp reply back to the route optimiser will follow the forward path. - you are guaranteed that icmp is heavily deprioritised on ixp routers - the busier the IXP, the busier the control planes of all the IXP routers you're going to ping, and the more likely they are to drop your ping packets. This will lead to greater route churn. If this approach is widely deployed it will lead to wider-scale routing oscillations due to control plane mismanagement. - route optimisers are associated with serious bgp leakage issues. if you're doing this at an IXP, the danger is significantly magnified because bi-lat peering sessions rarely, if ever, implement prefix filtering. It is true that IXPs occasionally see forwarding plane failures. These tend to be pretty unusual these days. Be careful about optimising edge cases like this. You'll often end up introducing new failure modes which may be more serious and which may occur more regularly. Nick
Re: SRv6
On 16/Sep/20 02:05, Randy Bush wrote: > neither srv6, srmpls, mpls, gre, ... provide privacy. they all > transport the payload in nekkid cleartext. C'mon, Randy. Don't tell the kids Santa isn't real. Where's your humanity :-)... Mark.
Re: SRv6
On 15/Sep/20 21:07, Nick Hilliard wrote: > This gets complicated quickly, and that complication can only be > solved by adding complication to silicon, which is what you want not > to do when the speed of your underlying forwarding plane is increasing > by leaps and bounds. Good, cheap, fast. Choose two - or maybe one. More complex silicon means tons of R, which means big prices to recover that from operators who "want want want" that R in their networks. > > As Mark points out, many companies have made their fortunes with a > full stack product offering, from hardware and software to design, > engineering and operations. It's not a bad business model as long as > you realise that it's time-limited to the technology of the day. When > it draws to a close, it's hard to turn companies around that have been > used to a single-product or single-vertical cash trough which no > longer exists. Some have done this successfully; others have floundered. The one thing you have to give Cisco is they know how to market... in slides. That boring RFC document looks colorful, bright and full of promi$e when Cisco have turned into a marketing slide. It takes a lot of find the "boring" slides of some other vendors more appealing, as a solution. Mark.
Re: SRv6
On 15/Sep/20 20:57, James W. Laferriere wrote: > > > So then here we are back at the older days of hard wired devices > configured on site by vendor 'X' to do what buyer 'Y' was told it > would do . > And Buyer 'Y' is still wondering WHEN it will be that kitchen sink > it ordered . Don't you just love Project Manager from vendor and Project Manager from operator occupying a board room for all 365 days of the year, pointing fingers at each other :-). All the while, they are still mailing you their monthly Managed Services invoice... Mark.
Re: SRv6
On 15/Sep/20 20:12, Randy Bush wrote: > > as the packet payload is nekkid cleartext, where is the P in vpn? On a piece of paper filed under "It feels good to know it sort of does the same thing" :-). Mark.
Re: SRv6
On 15/Sep/20 19:05, Saku Ytti wrote: > Ultimately it is very simple, we need tunneling, then the question is > how much does it cost to look up those tunnel headers and how much > space they take on the wire (relevant for overspeed), everything else > is noise. As we've said many times before, MPLS is not a bad tunneling service. And while things can always be better, it's a bit hard to find anything else, today, that is reasonably well baked-in and efficient (as it can be). Mark.
Re: SRv6
On 15/Sep/20 19:00, aar...@gvtc.com wrote: > Sorry guys, I'm not aware of much of what you mention as far as agenda, > vendor motive, and hardware support, etc I'm not shy... this would be Cisco. And somehow, they've managed to "convince" other vendors to go down this rabbit hole, because it is seemingly clear that network operators (especially mobile providers) may actually buy this cockamamie. Mark.
Re: BFD for routes learned trough Route-servers in IXPs
Hi, In some IXPs, getting a BFD protected BGP sessions with their route-servers is possible. However, it is usualy optional, so there is no way how to discover know who of your MLPA peering partners has their sessions protected the same way and who don't. You can also ask peers you have a session with to enable BFD there. If they run carrier-grade border routes connected to IXP switches just with fibers, it works pretty well. So just try to talk with your peers about BFD. -- S pozdravem/Best Regards, Zbyněk Pospíchal Dne 16.09.20 v 2:55 Douglas Fischer napsal(a): > Time-to-time, in some IXP in the world some issue on the forwarding > plane occurs. > When it occurs, this topic comes back. > > The failures are not big enough to drop the BGP sessions between IXP > participants and route-servers. > > But are enough to prejudice traffic between participants. > > And then the problem comes: > "How can I check if my communication against the NextHop of the routes > that I learn from the route-servers are OK? > If it is not OK, how can I remove it from my FIB?" > > Some other possible causes of this feeling are: > - ARP Resolution issues > (CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a > bombastic recipe) > - MAC-Address Learning limitations on the transport link of the > participants can be a pain in the a..rm. > > > So, I was searching on how to solve that and I found a draft (8th > release) with the intention to solve that... > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 > > If understood correctly, the effective implementation of it will depend > on new code on any BGP engine that will want to do that check. > It is kind of frustrating... At least 10 years after the release of RFC > until the refresh os every router involved in IXPs in the world. > > > Some questions come: > A) There is anything that we can do to rush this? > B) There is any other alternative to that? > > > P.S.1: I gave up of inventing crazy BGP filter polices to test > reachability of NextHop. The effectiveness of it can't even be compared > to BFD, and almost kill de processing capacity of my router. > > P.S.2: IMHO, the biggest downside of those problems is the evasion of > route-servers from some participants when issues described above occurs.
Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam
Hi, Shouldn't that be solved...? Maybe a task-force under NRO...? :-) Regards, Carlos On Wed, 16 Sep 2020, Job Snijders wrote: On Tue, Sep 15, 2020 at 01:52:05PM -0700, Randy Bush wrote: perchance is RDAP implemented by all RIRs? Yes, but in 5 slightly different ways :-) Kind regards, Job
Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam
On Tue, Sep 15, 2020 at 01:52:05PM -0700, Randy Bush wrote: > perchance is RDAP implemented by all RIRs? Yes, but in 5 slightly different ways :-) Kind regards, Job
