On 1/Jul/20 09:10, James Bensley wrote:
> True, but what's changed in two weeks with regards to LDv6 and SR?
>
> What was your use case / requirement for LDv6 - to remove the full
> table v6 feed from your core or to remove IPv4 from your IGP or both?
Give me a year to work this and report
On Tue, 30 Jun 2020 at 22:07, Mark Tinka wrote:
>
>
>
> On 30/Jun/20 20:37, James Bensley wrote:
>
> > Mark, does someone have a gun to your head? Are you in trouble? Blink
> > 63 times for yes, 64 times for no ;)
>
> You're pretty late to this party, mate...
True, but what's changed in two
On 30/Jun/20 20:37, James Bensley wrote:
> Mark, does someone have a gun to your head? Are you in trouble? Blink
> 63 times for yes, 64 times for no ;)
You're pretty late to this party, mate...
Mark.
On Wed, 17 Jun 2020 at 23:19, Mark Tinka wrote:
> Yes, we all love less state, I won't argue that. But it's the same question
> that is being asked less and less with each passing year - what scales better
> in 2020, OSPF or IS-IS. That is becoming less relevant as control planes keep
>
On Wed, 17 Jun 2020 at 18:08, Mark Tinka wrote:
>
> Hi all.
>
> When the whole SR concept was being first dreamed up, I was mildly excited
> about it. But then real life happened and global deployment (be it basic
> SR-MPLS or SRv6) is what it is, and I became less excited. This was back in
>
On Wed, 17 Jun 2020 at 22:09, wrote:
>
> > From: NANOG On Behalf Of Mark Tinka
> > Sent: Wednesday, June 17, 2020 6:07 PM
> >
> >
> > I've heard a lot about "network programmability", e.t.c.,
> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for
Hi Baldur,
>From memory mx204 FIB is 10M (v4/v6) and RIB 30M for each v4 and v6.
And remember the FIB is hierarchical -so it’s the next-hops per prefix you are
referring to with BGP FRR. And also going from memory of past scaling testing,
if pfx1+NH1 == x, then Pfx1+NH1+NH2 !== 2x, where x
> From: NANOG On Behalf Of Masataka Ohta
> Sent: Friday, June 19, 2020 5:01 PM
>
> Robert Raszuk wrote:
>
> > So I think Ohta-san's point is about scalability services not flat
> > underlay RIB and FIB sizes. Many years ago we had requests to support
> > 5M L3VPN routes while underlay was just
On 21/Jun/20 23:01, Robert Raszuk wrote:
>
> Nope. You need to get to PQ node via potentially many hops. So you
> need to have even ordered or independent label distribution to its
> loopback in place.
I have some testing I want to do with IS-IS only announcing the Loopback
from a set of
> Wouldn't T-LDP fix this, since LDP LFA is a targeted session?
Nope. You need to get to PQ node via potentially many hops. So you need to
have even ordered or independent label distribution to its loopback in
place.
Best,
R.
On Sun, Jun 21, 2020 at 10:58 PM Mark Tinka wrote:
>
>
> On
On 21/Jun/20 22:21, Robert Raszuk wrote:
>
> Well this is true for one company :) Name starts with j
>
> Other company name starting with c - at least some time back by
> default allocated labels for all routes in the RIB either connected or
> static or sourced from IGP. Sure you could
On 21/Jun/20 21:15, adamv0...@netconsultings.com wrote:
> I wouldn't say it's known to many as not many folks are actually limited by
> only up to ~1M customer connections, or next level up, only up to ~1M
> customer VPNs.
It's probably less of a problem now than it was 10 years ago.
>
> I should point out that all of my input here is based on simple MPLS
> forwarding of IP traffic in the global table. In this scenario, labels
> are only assigned to BGP next-hops, which is typically an IGP Loopback
> address.
>
Well this is true for one company :) Name starts with j
On 21/Jun/20 19:34, Robert Raszuk wrote:
>
> That is true for P routers ... not so much for PEs.
>
> Please observe that label space in each PE router is divided for IGP
> and BGP as well as other label hungy services ... there are many
> consumers of local label block.
>
> So it is always
> From: NANOG On Behalf Of Mark Tinka
> Sent: Friday, June 19, 2020 7:28 PM
>
>
> On 19/Jun/20 17:13, Robert Raszuk wrote:
>
> >
> > So I think Ohta-san's point is about scalability services not flat
> > underlay RIB and FIB sizes. Many years ago we had requests to support
> > 5M L3VPN
> The LFIB in each node need only be as large as the number of LDP-enabled
routers in the network.
That is true for P routers ... not so much for PEs.
Please observe that label space in each PE router is divided for IGP and
BGP as well as other label hungy services ... there are many consumers
On 21/Jun/20 15:48, Robert Raszuk wrote:
>
>
> Actually when IGP changes LSPs are not recomputed with LDP or SR-MPLS
> (when used without TE :).
>
> "LSP" term is perhaps what drives your confusion --- in LDP MPLS there
> is no "Path" - in spite of the acronym (Labeled Switch *Path*). Labels
>
On 21/Jun/20 14:58, Baldur Norddahl wrote:
>
> Not really the same. Lets say the best path is through transit 1 but
> the customer thinks transit 1 sucks balls and wants his egress traffic
> to go through your transit 2. Only the VRF approach lets every BGP
> customer, even single homed ones,
> I'm saying that, if some failure occurs and IGP changes, a
> lot of LSPs must be recomputed, which does not scale
> if # of LSPs is large, especially in a large network
> where IGP needs hierarchy (such as OSPF area).
>
> Masataka Ohta
>
Actually
On Sun, Jun 21, 2020 at 1:30 PM Mark Tinka wrote:
>
>
> On 21/Jun/20 12:45, Baldur Norddahl wrote:
>
>
> Yes I once made a plan to have one VRF per transit provider plus a peering
> VRF. That way our BGP customers could have a session with each of those
> VRFs to allow them full control of the
On 21/Jun/20 12:45, Baldur Norddahl wrote:
>
> Yes I once made a plan to have one VRF per transit provider plus a
> peering VRF. That way our BGP customers could have a session with each
> of those VRFs to allow them full control of the route mix. I would of
> course also need a Internet VRF
On 21/Jun/20 12:10, Masataka Ohta wrote:
>
> It was implemented and some technology was used by commercial
> router from Furukawa (a Japanese vendor selling optical
> fiber now not selling routers).
I won't lie, never heard of it.
> GMPLS, you are using, is the mechanism to guarantee QoS
On Sun, Jun 21, 2020 at 9:56 AM Mark Tinka wrote:
>
>
> On 20/Jun/20 22:00, Baldur Norddahl wrote:
>
>
> I can't speak for the year 2000 as I was not doing networking at this
> level at that time. But when I check the specs for the base mx204 it says
> something like 32 VRFs, 2 million routes in
Mark Tinka wrote:
There are many. So, our research group tried to improve RSVP.
I'm a lot younger than the Internet, but I read a fair bit about its
history. I can't remember ever coming across an implementation of RSVP
between a host and the network in a commercial setting.
No, of course,
On 20/Jun/20 22:00, Baldur Norddahl wrote:
>
> I can't speak for the year 2000 as I was not doing networking at this
> level at that time. But when I check the specs for the base mx204 it
> says something like 32 VRFs, 2 million routes in FIB and 6 million
> routes in RIB. Clearly those numbers
On 21/Jun/20 00:54, Sabri Berisha wrote:
> That will be very advantageous in a datacenter environment, or any other
> environment dealing with a lot of ECMP paths.
>
> I can't tell you how often during my eBay time I've been troubleshooting
> end-to-end packetloss between hosts in two
> On Jun 20, 2020, at 2:27 PM, Mark Tinka wrote:
>
>
>
> On 20/Jun/20 00:41, Anoop Ghanwani wrote:
>
>> One of the advantages cited for SRv6 over MPLS is that the packet contains a
>> record of where it has been.
>
> I can't see how advantageous that is, or how possible it would be to
>
- On Jun 20, 2020, at 2:27 PM, Mark Tinka wrote:
Hi Mark,
> On 20/Jun/20 00:41, Anoop Ghanwani wrote:
>> One of the advantages cited for SRv6 over MPLS is that the packet contains a
>> record of where it has been.
> I can't see how advantageous that is,
That will be very advantageous
On 20/Jun/20 00:41, Anoop Ghanwani wrote:
> One of the advantages cited for SRv6 over MPLS is that the packet
> contains a record of where it has been.
I can't see how advantageous that is, or how possible it would be to
implement, especially for inter-domain traffic.
Mark.
On Sat, Jun 20, 2020 at 12:38 PM Mark Tinka wrote:
>
>
> On 20/Jun/20 11:27, Baldur Norddahl wrote:
>
>
>>
> We run the Internet in a VRF to get watertight separation between
> management and the Internet. I do also have a CGN vrf but that one has very
> few routes in it (99% being subscriber
On 20/Jun/20 14:41, Masataka Ohta wrote:
>
> There are many. So, our research group tried to improve RSVP.
I'm a lot younger than the Internet, but I read a fair bit about its
history. I can't remember ever coming across an implementation of RSVP
between a host and the network in a
Mark Tinka wrote:
At the time I proposed label switching, there already was RSVP
but RSVP-TE was proposed long after MPLS was proposed.
RSVP failed to take off, for whatever reason (I can think of many).
There are many. So, our research group tried to improve RSVP.
Practically, the most
On 20/Jun/20 11:27, Baldur Norddahl wrote:
>
>
> We run the Internet in a VRF to get watertight separation between
> management and the Internet. I do also have a CGN vrf but that one has
> very few routes in it (99% being subscriber management created, eg.
> one route per customer). Why would
On Sat, Jun 20, 2020 at 11:08 AM Mark Tinka wrote:
> > MPLS with hierarchical routing just does not scale.
>
> With Internet in a VRF, I truly agree.
>
> But if you run a simple global BGP table and no VRF's, I don't see an
> issue. This is what we do, and our scaling concerns are exactly the
On 19/Jun/20 18:00, Masataka Ohta wrote:
> There seems to be serious confusions between label switching
> with explicit flows and MPLS, which was believed to scale
> without detecting/configuring flows.
>
> At the time I proposed label switching, there already was RSVP
> but RSVP-TE was
On 19/Jun/20 17:40, Masataka Ohta wrote:
>
> As the first person to have proposed the forwarding paradigm of
> label switching, I have been fully aware from the beginning that:
>
> https://tools.ietf.org/html/draft-ohta-ip-over-atm-01
>
> Conventional Communication over ATM in a
>
> One of the advantages cited for SRv6 over MPLS is that the packet contains
>> a record of where it has been.
>>
>
Not really ... packets are not tourists in a bus.
First there are real studies proving that most large production networks
for the goal of good TE only need to place 1, 2 or 3
On Wed, Jun 17, 2020 at 11:40 AM Dave Bell wrote:
>
>
> On Wed, 17 Jun 2020 at 18:42, Saku Ytti wrote:
>
>> Hey,
>>
>> > Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
>>
>> I don't like this, SR-MPLS and SRv6 are just utterly different things
>> to me, and no answer meaningfully
> On Jun 19, 2020, at 11:34 AM, Randy Bush wrote:
>
>
>>
>> MPLS was since day one proposed as enabler for services originally
>> L3VPNs and RSVP-TE.
>
> MPLS day one was mike o'dell wanting to move his city/city traffic
> matrix from ATM to tag switching and open cascade's hold on tags.
>
> But, today, people are seems to be using, so called, MPLS, with
>
explicitly configured flows, administration of which does not
> scale and is annoying.
>
I am actually not sure what you are talking about here.
The only per flow action in any MPLS deployments I have seen was mapping
flow
On 19/Jun/20 17:13, Robert Raszuk wrote:
>
> So I think Ohta-san's point is about scalability services not flat
> underlay RIB and FIB sizes. Many years ago we had requests to support
> 5M L3VPN routes while underlay was just 500K IPv4.
Ah, if the context, then, was l3vpn scaling, yes, that
Robert Raszuk wrote:
MPLS was since day one proposed as enabler for services originally L3VPNs
and RSVP-TE.
There seems to be serious confusions between label switching
with explicit flows and MPLS, which was believed to scale
without detecting/configuring flows.
At the time I proposed label
Mark Tinka wrote:
I wouldn't agree.
MPLS is a purely forwarding paradigm, as is hop-by-hop IP.
As the first person to have proposed the forwarding paradigm of
label switching, I have been fully aware from the beginning that:
https://tools.ietf.org/html/draft-ohta-ip-over-atm-01
> MPLS was since day one proposed as enabler for services originally
> L3VPNs and RSVP-TE.
MPLS day one was mike o'dell wanting to move his city/city traffic
matrix from ATM to tag switching and open cascade's hold on tags.
randy
Hi Mark,
As actually someone who was at that table you are referring to - I must say
that MPLS was never proposed as replacement for IP.
MPLS was since day one proposed as enabler for services originally L3VPNs
and RSVP-TE. Then bunch of others jumped on the same encapsulation train.
If at that
On 19/Jun/20 16:45, Masataka Ohta wrote:
> The problem of MPLS, or label switching in general, is that, though
> it was advertised to be topology driven to scale better than flow
> driven, it is actually flow driven with poor scalability.
>
> Thus, it is impossible to deploy any technology
Mark Tinka wrote:
MPLS has been around far too long, and if you post web site content
still talking about it or show up at conferences still talking about it,
you fear that you can't sell more boxes and line cards on the back of
"just" broadening carriage pipes.
The problem of MPLS, or label
> Saku Ytti
> Sent: Friday, June 19, 2020 8:50 AM
>
> On Fri, 19 Jun 2020 at 10:24, Radu-Adrian Feurdean adrian.feurdean.net> wrote:
>
>
> > > I don't understand the point of SRv6. What equipment can support
> > > IPv6 routing, but can't support MPLS label switching?
> >
> Maybe these inferior
On 19/Jun/20 10:57, Radu-Adrian Feurdean wrote:
>
> Yes, exactly that one.
> Which also happens to spill outside the DC area, because the main "vertical"
> allows it to be sold at lower prices.
These days, half the gig is filtering the snake oil.
Mark.
On Fri, Jun 19, 2020, at 10:11, Mark Tinka wrote:
>
> On 19/Jun/20 09:20, Radu-Adrian Feurdean wrote:
> >
> > A whole ocean of "datacenter" hardware, from pretty much evey vendor.
>
> You mean the ones deliberately castrated so that we can create a
> specific "DC vertical", even if they are,
On 19/Jun/20 09:50, Saku Ytti wrote:
> I'm sure such devices exist, I can't name any from top of my head. But
> this market perversion is caused by DC people who did not understand
> networks and suffer from not-invented-here. Everyone needsa tunnel
> solution, but DC people decided before
On 19/Jun/20 09:20, Radu-Adrian Feurdean wrote:
>
> A whole ocean of "datacenter" hardware, from pretty much evey vendor.
You mean the ones deliberately castrated so that we can create a
specific "DC vertical", even if they are, pretty much, the same box a
service provider will buy, just
On Fri, 19 Jun 2020 at 10:24, Radu-Adrian Feurdean
wrote:
> > I don't understand the point of SRv6. What equipment can support IPv6
> > routing, but can't support MPLS label switching?
>
> A whole ocean of "datacenter" hardware, from pretty much evey vendor. Because
> many of them
On Wed, Jun 17, 2020, at 20:40, Dave Bell wrote:
>
> I don't understand the point of SRv6. What equipment can support IPv6
> routing, but can't support MPLS label switching?
A whole ocean of "datacenter" hardware, from pretty much evey vendor. Because
many of them automatically link MPLS to
On 18/Jun/20 14:30, adamv0...@netconsultings.com wrote:
> Hence our current strategy is to stay on IPv4 control-plane (and IPv4
> management plane) as it suits, and for the foreseeable future will suite, all
> our needs (which are to transport v4 data packets via L2 MPLS VPN
> services),
> From: Mark Tinka
> Sent: Thursday, June 18, 2020 12:51 PM
>
> On 18/Jun/20 13:23, adamv0...@netconsultings.com wrote:
>
> > is the current state is not the end state, this is a pretty dynamic
> > industry
> that I'm sure is converging/evolving towards a v4:v6 parity, however the pace
> may
On 18/Jun/20 13:23, adamv0...@netconsultings.com wrote:
> You do have the LDP vs SR choice (in v4 anyways) yes there's not a good 1:1
> feature parity with v6, but the important point...
But the lack of IPv4/IPv6 parity is a crucial one.
There is only so long we can stretch IPv4, if one can
> From: NANOG On Behalf Of Mark Tinka
> Sent: Thursday, June 18, 2020 8:13 AM
>
> There are probably as many networks running SR-MPLS as there are running
> LDPv6, likely fewer if your SR deployment doesn't yet support OSPFv3 or SR-
> ISISv6. I concede that for some networks looking to go
On Thu, 18 Jun 2020 at 13:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does not.
> That is first fundamental difference. There are customers using both all over
> the world and therefore any suggestion to just use OSPFv3 is IMHO quite
>
On 18/Jun/20 12:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does
> not. That is first fundamental difference. There are customers using
> both all over the world and therefore any suggestion to just use
> OSPFv3 is IMHO quite unrealistic.
Are
Hi Saku,
To your IGP point let me observe that OSPF runs over IP and ISIS does not.
That is first fundamental difference. There are customers using both all
over the world and therefore any suggestion to just use OSPFv3 is IMHO
quite unrealistic. Keep in mind that OSPF hierarchy is 2 (or 3 with
> From: Saku Ytti
> Sent: Thursday, June 18, 2020 6:26 AM
>
> On Thu, 18 Jun 2020 at 01:17, Mark Tinka wrote:
>
> > Yes, we all love less state, I won't argue that. But it's the same question
> that is being asked less and less with each passing year - what scales better
> in
> 2020, OSPF or
On 18/Jun/20 09:30, Saku Ytti wrote:
> Yes work left to be done. Ultimately the root problem is, no one cares
> about IPv6. But perhaps work with vendors in parallel to LDPv6 to get
> them to fix OSPFv3 and/or ISIS.
Yes, this.
Vendor feedback for those not supporting LDPv6 is that there is
On Thu, 18 Jun 2020 at 10:13, Mark Tinka wrote:
> Which is great for you, me, and a ton of other folk that run IS-IS on
> Juniper. What about folk that don't have Juniper, or run OSPF?
>
> I know, not your or my problem, but the Internet isn't just a few networks.
Yes work left to be done.
On 18/Jun/20 07:25, Saku Ytti wrote:
> The IGP mess we are in is horrible, but I can't blame SR for it. It's
> really unacceptable we spend NRE hours developing 3 identical IGP
> (OSPFv2, OSPFv3, ISIS). We all pay a 300-400% premium for a single
> IGP.
>
> In a sane world, we'd retire all of
On 18/Jun/20 00:29, Robert Raszuk wrote:
>
> Example: If your hardware ASICs do not support IPv6 while support IPv4
> - LDPv4 will work just fine while LDPv6 will have a rather a bit of
> hard time :)
Well, safe to say that if your box doesn't support IPv6, MPLSv6 is
probably the least of your
On Thu, 18 Jun 2020 at 01:17, Mark Tinka wrote:
> IOS XR does not appear to support SR-OSPFv3.
> IOS XE does not appear to support SR-ISISv6.
> IOS XE does not appear to support SR-OSPFv3.
> Junos does not appear to support SR-OSPFv3.
The IGP mess we are in is horrible, but I can't blame SR for
>
> Anything that can support LDPv4 today can support LDPv6, in hardware.
>
While I am trying to stay out of this interesting discussion the above
statement is not fully correct.
Yes in the MPLS2MPLS path you are correct,
But ingress and egress switching vectors are very different for LDPv6 as
On 17/Jun/20 23:46, Tom Hill wrote:
> Unsurprisingly, there would be no way on Earth that I could have said
> that better, so you shall find only loud cheering from over here.
Out of pure curiousity, have you deployed (or are you deploying)?
Mark.
On 17/Jun/20 23:07, adamv0...@netconsultings.com wrote:
> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for MPLS since ever works the same way for SR.
I see it the same way.
> Yes anything that works for RSVP-TE (i.e. PCEP), if you want
On 17/Jun/20 20:40, Dave Bell wrote:
> I don't understand the point of SRv6. What equipment can support IPv6
> routing, but can't support MPLS label switching?
Indeed.
Anything that can support LDPv4 today can support LDPv6, in hardware.
SRv6 and SRv6+ is a whole other issue, not to mention
On 17/Jun/20 19:38, Saku Ytti wrote:
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
I know they are different, but that was on purpose, because even with
SR-MPLS, there are a couple of things to consider:
* IOS XR
On 17/06/2020 18:38, Saku Ytti wrote:
>> Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
>
> I would ask, why do we need LDP, why not use IGP to carry labels?
>
> From: NANOG On Behalf Of Mark Tinka
> Sent: Wednesday, June 17, 2020 6:07 PM
>
>
> I've heard a lot about "network programmability", e.t.c.,
First of all the "SR = network programmability" is BS, SR = MPLS, any
programmability we've had for MPLS since ever works the same way for SR.
> but
On Wed, 17 Jun 2020 at 18:42, Saku Ytti wrote:
> Hey,
>
> > Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
>
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
>
I don't understand the point of SRv6. What
Hey,
> Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
I don't like this, SR-MPLS and SRv6 are just utterly different things
to me, and no answer meaningfully applies to both.
I would ask, why do we need LDP, why not use IGP to carry labels?
Less state, protocols, SLOC, cost, bug
76 matches
Mail list logo
