Re: Networks ignoring prepends?
> On Jan 22, 2024, at 6:53 PM, Jeff Behrns via NANOG wrote: > >>> William Herrin wrote: > Until they tamper with it using localpref, BGP's default behavior with > prepends does exactly the right thing, at least in my situation. > > I feel your pain Bill, but from a slightly different angle. For years the > large CDNs have been disregarding prepends. When a source AS disregards BGP > best path selection rules, it sets off a chain reaction of silliness not > attributable to the transit AS's. At the terminus of that chain are > destination / eyeball AS's now compelled to do undesirable things out of > necessity such as: > 1) Advertise specifics towards select peers - i.e. inconsistent edge routing > policy & littering global table > 2) Continuing to prepending a ridiculous amount anyway > Gotta wonder how things would be if everyone just abided by the rules. > One might argue that the global routing system should allow for sites to signal their ingress traffic engineering preferences to remote sites in ways other than bloating the global routing table. But that ship seems to have sailed. Regards, -Darrel
Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block
> On Jan 12, 2024, at 11:47 AM, Seth David Schoen wrote: > > Michael Thomas writes: > >> I wonder if the right thing to do is to create a standards track RFC that >> makes the experimental space officially an add on to rfc 1918. If it works >> for you, great, if not your problem. It would at least stop all of these >> recurring arguments that we could salvage it for public use when the >> knowability of whether it could work is zero. > > In 2008 there were two proposals > > https://datatracker.ietf.org/doc/draft-fuller-240space/ > https://datatracker.ietf.org/doc/draft-wilson-class-e/ > > where the former was agnostic about how we would eventually be able to > use 240/4, and the latter designated it as RFC 1918-style private space. > Unfortunately, neither proposal was adopted as an RFC then, so we lost a > lot of time in which more vendors and operators could have made more > significant progress on its usability. Well, we were supposed to all be using IPv6 (only) by now, and making 240/4 useable was just going to slow that process down. IMHO, this is what you get when religion is mixed with engineering. -Darrel
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote: On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. That's a fairly simplistic version of why shim6 failed. A better reason (appart from the fact the building an upper layer overlay of the whole internet on an ip protocol that's largely unedeployed was hard) is that it leaves the destination unable to perform traffic engineering. I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. That fundementaly is the business we're in when advertising prefixes to more than one provider, ingress path selection. That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion basement multihomers with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream. When discussing 'why shim6 failed' I think its only fair to include a link to a (well reasoned, imho) network operator's perspective on what it did and did not provide in the way of capabilities that network operators desired. http://www.nanog.org/meetings/nanog35/abstracts.php?pt=NDQ3Jm5hbm9nMzU=nm=nanog35 -Darrel
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
\
I have found my input on the LISP list completely ignored because, as
you suggest, my concerns are real-world and don't have any impact on
someone's pet project. LISP as it stands today can never work on the
Internet, and regardless of the fine reputations of the people at
Cisco and other organizations who are working on it, they are either
furthering it only because they would rather work on a pet project
than something useful to customers, or because they truly cannot
understand its deep, insurmountable design flaws at Internet-scale.
You would generally hope that someone saying, LISP can't work at
Internet-scale because anyone will be able to trivially DoS any LISP
ITR ('router' for simplicity), but here is a way you can improve it,
well, that remark, input, and person should be taken quite seriously,
their input examined, and other assumptions about the way LISP is
supposed to work ought to be questioned. None of this has happened.
Jeff I've spend many hours working through the issues you brought up (indeed
cache management, population, and security are three of my focus areas in LISP,
and something we considered when we started this), have been socializing them
with the LISP team, and can personally say that I take your comments very
seriously. Or testing group in house as well as on the LISP beta network have
been working through these issues. Also, we've had an email thread going on
about this for, by my count, 3-4 replies back and forth.
While I appreciate your opinions above, I have to say that I disagree with
them, and also with the conclusions you draw.
-Darrel
P.S. oh and Randy Bush is pretty damn smart. :-)
