On 11/Jun/20 23:45, adamv0...@netconsultings.com wrote:
> Right I see what you are striving to achieve is migrate from BGP in a core to
> a BGP free core but not leveraging 6PE or 6VPE?
Yes sir.
> So considering you already had v4 FECs wouldn't it be simpler to do 6PE/6VPE,
> what do you
On 12/Jun/20 04:01, Michael Hare wrote:
> Mark (and others),
>
> I used to run loose uRPF on peering/transit links for AS3128 because I used
> to think that tightening the screws was always the "right thing to do".
>
> I instrumented at 60s granularity with vendor J uRPF drop counters on
Mark (and others),
I used to run loose uRPF on peering/transit links for AS3128 because I used to
think that tightening the screws was always the "right thing to do".
I instrumented at 60s granularity with vendor J uRPF drop counters on these
links. Drops during steady state [bgp
> From: Mark Tinka
> Sent: Thursday, June 11, 2020 3:59 PM
>
> > No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no
> point having them signalled also over v6 in parallel.
>
> It's not about signaling IPv4 LSP's over IPv6.
> LDPv4 creates IPv4 FEC's.
> LDPv6 creates
On 11/Jun/20 17:32, David Sinn wrote:
> Respectfully, that is deployment dependent. In a traditional SP topology that
> focuses on large do everything boxes, where the topology is fairly
> point-to-point and you only have a small handful of nodes at a PoP, labels
> can be fast, cheap and
> From: David Sinn
> Sent: Thursday, June 11, 2020 4:32 PM
>
> However if you move away from large multi-chip systems,
> to a system of fixed form-factor, single chip systems, labels fall
> apart at scale with high ECMP. Needing to enumerate every possible path
> within the network or having to
On Thu, 11 Jun 2020 at 21:04, David Sinn wrote:
> You've made my point for me. If you are building the core of your network out
> of MX's, to turn a phrase, in a past life "I fully support my competitors to
> do so". Large numbers of small boxes, as they have already shown in the
>
Addrex.net
I know some of the principles personally and would vouch for them.
On June 11, 2020 at 14:27 edwin.malle...@gmail.com (edwin.malle...@gmail.com)
wrote:
> Hi Nanog,
>
>
>
> I have need of a reputable IPv4 broker or service ? personal experience with
> said broker would
Hi
+1 for Hilco. I've made 2 deals with them, no problem, people are
professional,
Cheers
Pierre
Le jeu. 11 juin 2020 à 20:54, Martin Hannigan a écrit :
>
> For small needs? Honestly, don’t waste too much time. Overhead is expense.
>
> The market is competitive. You care about if it is
For small needs? Honestly, don’t waste too much time. Overhead is expense.
The market is competitive. You care about if it is clean, chain of custody
and can it legitimately transfer to you. BTW, IPV6? ARIN v6 NAT block? Make
sure you exhaust all options before paying.
I have never used it.
On 6/11/20, 1:19 PM, "Saku Ytti" wrote:
On Thu, 11 Jun 2020 at 19:49, Phil Bedard wrote:
> As for normal v6 forwarding, the way most higher speed routers made
recently work there is little difference in latency since the encapsulation for
the packet is done in a common function at
Wow. Full distorted vision of reality mode here…
uRPF doesn’t “break” anything. I stand by that. It’s not a religious position.
It’s an operational experience. One that I have multitudes of real world
examples of it working to SOLVE issues.
You seem to be willfully ignorant about how real
Replied off-list
Eric
On Jun 11 2020, at 2:27 pm, edwin.malle...@gmail.com wrote:
> Hi Nanog,
>
>
> I have need of a reputable IPv4 broker or service – personal experience with
> said broker would be preferred. These would be for small blocks - /23, 24s –
> in the US, so ARIN. I know, I know,
Hi Nanog,
I have need of a reputable IPv4 broker or service - personal experience
with said broker would be preferred. These would be for small blocks - /23,
24s - in the US, so ARIN. I know, I know, IPv6 for life and all that and I
agree, but . you know, the business. I'm happy to take
On Thu, Jun 11, 2020 at 9:35 AM Brian Johnson wrote:
> You are a dismissive little twit aren’t you. :/
Someone stood up and said, "Nope, nothing I did could possibly have
broken anything." I'm pretty sure that someone was you but feel free
to call me on it if I'm mistaken.
Look, at the risk of
Phil Bedard wrote on 11/06/2020 17:49:
Just to clarify the only routers who potentially need to inspect or
do anything with those headers are endpoints who require information
in the extension header or hops in an explicit path. In the simple
example I gave, there are no extension headers at
On Thu, 11 Jun 2020 at 19:49, Phil Bedard wrote:
> As for normal v6 forwarding, the way most higher speed routers made recently
> work there is little difference in latency since the encapsulation for the
> packet is done in a common function at the end of the pipeline and the
> lookups are
On 11/Jun/20 00:41, Job Snijders wrote:
>
> Back to basics: as Ytti suggested earlier in the thread, it might be more
> sensible to generate your own default route based on a 'stable anchor prefix'
> coming from the ISP rather than accepting the default your ISP originates
> towards you.
On 10/Jun/20 19:31, William Herrin wrote:
>
> Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
> here. Let me back up:
>
> The most basic spoofing protection is: don't accept remote packets
> pretending to be from my IP address.
>
> Strict mode URPF extends this to networks:
Just to clarify the only routers who potentially need to inspect or do anything
with those headers are endpoints who require information in the extension
header or hops in an explicit path. In the simple example I gave, there are no
extension headers at all.
I'm pretty agnostic to IPv6
> On Jun 10, 2020, at 6:40 PM, brad dreisbach wrote:
>
> On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote:
>> Am I correct in assuming loose mode RPF only drops packets from unannounced
>> address space in the global routing table? And the downside of doing so is
>> that
You are a dismissive little twit aren’t you. :/
> On Jun 11, 2020, at 9:56 AM, William Herrin wrote:
>
> On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson
> wrote:
>> I fully understand that I have not “broken” anything.
>
> Handwaving, la la la, only sunshine in the sky. Got it.
>
> -Bill
>
>
On Thu, Jun 11, 2020 at 9:08 AM brad dreisbach wrote:
> uRPF absolutely kills the pps performance or your hardware due to the packet
> having to be recirculated to do the check(at least this is the case on every
> platform that ive ever tested it on). use acl's to protect your edge.
Hi Brad,
Hello -
The 'whois.radb.net' IRR instance and the RADb services have been
updated to reflect ARIN's IRR updates.
- - Mitchell
Mitchell Kuch
and the RADb Team
On Wed, Jun 10, 2020 at 2:54 PM John Curran wrote:
>
> NANOGers -
>
> ARIN has released its updated IRR system - if you are relying on
On Thu, Jun 11, 2020 at 12:01:38AM +0200, Baldur Norddahl wrote:
Am I correct in assuming loose mode RPF only drops packets from unannounced
address space in the global routing table? And the downside of doing so is
that sometimes we do receive packets from that address space, usually back
On Thu, 11 Jun 2020 at 18:32, David Sinn wrote:
> However if you move away from large multi-chip systems, which hide internal
> links which can only be debugged and monitored if you know the the obscure,
> often different ways in which they are partially exposed to the operator, and
> to a
On 6/10/20 6:01 PM, Baldur Norddahl wrote:
> Am I correct in assuming loose mode RPF only drops packets from
> unannounced address space in the global routing table? And the downside
> of doing so is that sometimes we do receive packets from that address
> space, usually back scatter from
On 11/Jun/20 16:25, adamv0...@netconsultings.com wrote:
> Good PR might ;)
I'm old school - build something customers want to use, and the money
follows.
Care to guess how much PR Tik Tok do :-)? But I digress.
> No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no
On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson wrote:
> I fully understand that I have not “broken” anything.
Handwaving, la la la, only sunshine in the sky. Got it.
-Bill
--
William Herrin
b...@herrin.us
https://bill.herrin.us/
On 11/Jun/20 16:36, adamv0...@netconsultings.com wrote:
> Case in point.
>
> On the other hand not sure if any of the customers would care whether LSPs
> are signalled over v4 as opposed to v6.
They care if your core router CPU doesn't struggle from dealing with
churning BGP routes at
On 11/Jun/20 16:28, Saku Ytti wrote:
> I'm sure we can blame Job for this, why not. But probably because of
> his lobbying some customers are _requiring_, i.e. flat out told they
> will stop accepting transit offers from providers who don't do RPKI.
As my Chad friend would say, "I like the
> From: Saku Ytti
> Sent: Thursday, June 11, 2020 3:29 PM
>
> On Thu, 11 Jun 2020 at 16:45, Mark Tinka wrote:
>
> > Not sure if beating up on Job for months qualifies as "a customer
> > wanting RPKI from NTT" :-).
>
> I'm sure we can blame Job for this, why not. But probably because of his
>
On Thu, 11 Jun 2020 at 16:45, Mark Tinka wrote:
> Not sure if beating up on Job for months qualifies as "a customer
> wanting RPKI from NTT" :-).
I'm sure we can blame Job for this, why not. But probably because of
his lobbying some customers are _requiring_, i.e. flat out told they
will stop
> From: Mark Tinka
> Sent: Thursday, June 11, 2020 1:56 PM
>
> On 11/Jun/20 14:17, adamv0...@netconsultings.com wrote:
>
> > Well RPKI or DNSSEC is at least adding a value, even something you can
> brag about to your customers (we are part of the solution not part of the
> problem etc...).
>
>
On 11/Jun/20 15:34, Saku Ytti wrote:
>
> Unsure of others, but we didn't implement RPKI for shit and giggles,
> we implemented it, because customers wanted us to do RPKI.
I'll be honest, none of our customers ever asked us to deploy RPKI and
ROV. Will they benefit from it, sure? Is it about
On Thu, 11 Jun 2020 at 15:58, Mark Tinka wrote:
> > Well RPKI or DNSSEC is at least adding a value, even something you can brag
> > about to your customers (we are part of the solution not part of the
> > problem etc...).
>
> Bragging doesn't bring in income, it's just PR :-).
Unsure of
> On Jun 10, 2020, at 3:05 PM, William Herrin wrote:
>
> On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson
> wrote:
>> Disagree with Bill here. It will depend on the complexity of the network as
>> to use of uRPF in any mode (loose or strict). In general, I never use uRPF
>> on transit links
On 11/Jun/20 14:43, Gert Doering wrote:
>
> Not "in addition to" but "to throw out the IPv4 part" :-)
That's another view-point, yes.
There are plenty of networks that can't afford to keep buying IPv4 on
the open market. They want to go single-stack IPv6.
Today, you would need to build a 6PE
On 11/Jun/20 14:17, adamv0...@netconsultings.com wrote:
> Well RPKI or DNSSEC is at least adding a value, even something you can brag
> about to your customers (we are part of the solution not part of the problem
> etc...).
Bragging doesn't bring in income, it's just PR :-).
>
> But
> From: Mark Tinka
> Sent: Thursday, June 11, 2020 10:21 AM
>
>> -what additional revenue stream am I getting by enabling v6 in the
>> underlay/management plane that would offset the pain of dealing with the
>> increased bug surface?
>
> Also, if you link every feature to a revenue stream,
On 11/Jun/20 13:03, Drikus Brits wrote:
> We're deploying some new POPs with a mix of IOS-XR as borders, BNG and
> PEs and IOS-XE for LNSs. LDPv6 would be awesome to have availabke on
> IOS-XE alongside LDPv4. We're being pushed by Cisco to go one flavour
> or another of SR as well by Cisco,
On Thu, 11 Jun 2020 at 12:57, Robert Raszuk wrote:
> Nope that was not the main reason.
>
> Main reason was the belief that labels MUST be locally significant - and not
> domain wide unique. Just look at Juniper's SRm6 or now SRH ... they keep this
> notion of locally significant SIDs. It is
On 11/Jun/20 11:57, Robert Raszuk wrote:
>
> Nope that was not the main reason.
>
> Main reason was the belief that labels MUST be locally significant -
> and not domain wide unique. Just look at Juniper's SRm6 or now SRH ...
> they keep this notion of locally significant SIDs. It is deep in
On 11/Jun/20 11:58, Nick Hilliard wrote:
> Nearly impossible, apparently.
>
> It would require a change of mindset.
I'll leave that to the Coronavirus - it will open eyes.
Mark.
Mark Tinka wrote on 11/06/2020 10:48:
We are asking for LDP to extended to support IPv6. Really, how hard
is that?
Nearly impossible, apparently.
It would require a change of mindset.
Nick
On 11/Jun/20 09:58, Radu-Adrian FEURDEAN wrote:
> Well, given their (Cisco's) braindead policy regarding non-implementation of
> LDPv6 on XE, no wonder people are looking for alternatives, and SRv6 is one
> of them.
Which doesn't track because there are a number of IOS XE boxes that do
not
On 11/Jun/20 10:32, adamv0...@netconsultings.com wrote:
> Hey Mark,
> My stance is that should I go with anything "new" for label distribution the
> MPLS SR/SPRING is getting to a point where it might be mature enough.
"Getting to a point" doesn't really work if you are actively running a
Saku Ytti wrote on 11/06/2020 05:51:
Unfortunately SRv6 is somewhat easy to market with the whole 'it's
simple, just IP' spiel.
it's not "just IP": it's ipv6 with per-router push / pop operations on
ipv6 extension headers, i.e. high touch in areas which are known to be
deeply troublesome on
> Mark Tinka
> Sent: Wednesday, June 10, 2020 6:19 PM
>
> Hi all.
>
> Just want to sample the room and find out if anyone here - especially
those
> running an LDP-based BGPv4-free core (or something close to it) - would be
> interested in LDPv6, in order to achieve the same for BGPv6?
>
> A
On 11/Jun/20 09:42, Saku Ytti wrote:
>
> I don't like to conflate these two; SR is great, SRv6 is horrible
> abomination. SR is what MPLS should have been day1, but it probably
> was easier to market LDP than to say 'we need to change all IGP
> protocols'.
Fair point.
Mark.
On Wed, Jun 10, 2020, at 20:51, Mark Tinka wrote:
> Well, according to them, SRv6 is winning customers over, and nobody
> wants LDPv6. Then again, they have LDPv6 in IOS XR; figures.
Well, given their (Cisco's) braindead policy regarding non-implementation of
LDPv6 on XE, no wonder people are
On Thu, 11 Jun 2020 at 10:37, Mark Tinka wrote:
> Mine have sighed in disbelief that I don't share their vision of an
> SR(v6) world :-).
I don't like to conflate these two; SR is great, SRv6 is horrible
abomination. SR is what MPLS should have been day1, but it probably
was easier to market
On 11/Jun/20 06:51, Saku Ytti wrote:
> Every HW designer
> has sighed in relief when I've said I don't care about it, because
> it's also very HW unfriendly, like IPv6 generally. Unfortunately SRv6
> is somewhat easy to market with the whole 'it's simple, just IP'
> spiel.
Mine have sighed
53 matches
Mail list logo
