Mailing List Archive

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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 their
> DNA ... still. 
>
> We argued about it a lot in cisco back in TDP days - and we lost.

I get this for VLAN's, being only 4,096 per broadcast domain and all.

But are we struggling with scaling label space?

Just my 1+1, since I may be over-simplifying the issue.


>
> - - -
>
> Now to your runt that MPLS is great because of exact match perhaps you
> missed it but number of solutions on the table (including RbR[**] I
> recently proposed) use exact match 4B locator based lookup in the v6
> packets to get from segment end to segment end. 
>
> On the other hand your comments about greatness of MPLS ... simplified
> data plane and depending on the hardware difference in jitter (in sub
> ms ranges - if that even matters) comes up with a lot of control plane
> complexity when you want to build a network across all continents, yet
> keep it scoped from IGP to areas or levels. No summarization in MPLS
> in FECs is something we should not sweep under the carpet.

I found multi-level IS-IS to be useless in an MPLS network because you
still need to leak routes between L2 and L1 in order to form MPLS FEC's.
So you simplify the network by having a single L2 (or just Area 0 in
OSPF), because today's control planes can handle it. And yes, some are
brave enough to run RFC 3107 if it becomes a problem, but if you can
afford to string a network together across all continents, I doubt an
x86-based control plane with 64GB of RAM is topping the list of your
problems.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 11 Jun 2020 at 12:57, Robert Raszuk <robert@raszuk.net> 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 their DNA ... still.

Seems weird, because neither LDP or SR implies globally significant
labels, implementation choice. What SR does imply is a continuous
block of labels of equal size in domain.

> Now to your runt that MPLS is great because of exact match perhaps you missed it but number of solutions on the table (including RbR[**] I recently proposed) use exact match 4B locator based lookup in the v6 packets to get from segment end to segment end.

Which is making a simple thing a complex thing.

> On the other hand your comments about greatness of MPLS ... simplified data plane and depending on the hardware difference in jitter (in sub ms ranges - if that even matters) comes up with a lot of control plane complexity when you want to build a network across all continents, yet keep it scoped from IGP to areas or levels. No summarization in MPLS in FECs is something we should not sweep under the carpet.

MPLS complexity is trivial in control-plane and forwarding-plane
compared to IPV6 or SRv6 or RbR[**]. I'm not saying we can't do better
than MPLS, but the proposal here is blatantly worse.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

/* removing nanog list as I am not subscribed there and it bounces back */

> I found multi-level IS-IS to be useless in an MPLS network because you
still need to leak routes between L2 and L1 in order to form
> MPLS FEC's. So you simplify the network by having a single L2 (or just
Area 0 in OSPF), because today's control planes can handle it.

Spot on ! OSPF is not any better.

And yes you can build a global flat IGP. But this is not a design I would
endorse in most networks.

Reason is that most networks do not have latest connectivity restoration
techniques and still wait for typical "IGP convergence" So if you flood
globally you need to adjust your IGP & SPF timers with the notion of global
flooding.

If you however scope your flooding domains to be relatively small (say per
1-few regions in a continent) you can easily and safely make those timers
much more aggressive hence significantly reducing connectivity restoration
times upon failures.

Many thx,
R.




On Thu, Jun 11, 2020 at 12:15 PM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> 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 their DNA ...
> still.
>
> We argued about it a lot in cisco back in TDP days - and we lost.
>
>
> I get this for VLAN's, being only 4,096 per broadcast domain and all.
>
> But are we struggling with scaling label space?
>
> Just my 1+1, since I may be over-simplifying the issue.
>
>
>
> - - -
>
> Now to your runt that MPLS is great because of exact match perhaps you
> missed it but number of solutions on the table (including RbR[**] I
> recently proposed) use exact match 4B locator based lookup in the v6
> packets to get from segment end to segment end.
>
> On the other hand your comments about greatness of MPLS ... simplified
> data plane and depending on the hardware difference in jitter (in sub ms
> ranges - if that even matters) comes up with a lot of control plane
> complexity when you want to build a network across all continents, yet keep
> it scoped from IGP to areas or levels. No summarization in MPLS in FECs is
> something we should not sweep under the carpet.
>
>
> I found multi-level IS-IS to be useless in an MPLS network because you
> still need to leak routes between L2 and L1 in order to form MPLS FEC's. So
> you simplify the network by having a single L2 (or just Area 0 in OSPF),
> because today's control planes can handle it. And yes, some are brave
> enough to run RFC 3107 if it becomes a problem, but if you can afford to
> string a network together across all continents, I doubt an x86-based
> control plane with 64GB of RAM is topping the list of your problems.
>
> Mark.
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> Seems weird, because neither LDP or SR implies globally significant
> labels, implementation choice. What SR does imply is a continuous
> block of labels of equal size in domain.
>

LDP or MPLS LSPs require hop by hop label swapping (directly connected or
over say IP tunnels). So labels in LDP are always locally significant.

SR-MPLS implies globally (domain wide) label significance. Index in the IGP
extensions is there just to relax requirement to use the same block on all
nodes - so the block does not need to be continuous in an SR domain. It is
recommended by Cisco but not required by standard.

Thx
R.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 11/Jun/20 12:28, Robert Raszuk wrote:

>
> Spot on ! OSPF is not any better. 
>
> And yes you can build a global flat IGP. But this is not a design I
> would endorse in most networks. 
>
> Reason is that most networks do not have latest connectivity
> restoration techniques and still wait for typical "IGP convergence" So
> if you flood globally you need to adjust your IGP & SPF timers with
> the notion of global flooding. 
>
> If you however scope your flooding domains to be relatively small (say
> per 1-few regions in a continent) you can easily and safely make those
> timers much more aggressive hence significantly reducing connectivity
> restoration times upon failures.

Well, we operate a single IS-IS L2 domain across 3 continents.

We use what-I'd-call aggressive IS-IS detection and convergence timers,
in addition to BFD and LFA/IP-FRR.

We do very okay.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> Well, we operate a single IS-IS L2 domain across 3 continents.
>
> We use what-I'd-call aggressive IS-IS detection and convergence timers,
> in addition to BFD and LFA/IP-FRR.
>
> We do very okay.
>

No doubt.

However one network is not equal the other. Especially SP/ISP network
requirements and any to any traffic patterns there are very different from
typical hub and spoke connectivity in the content or service serving
enterprise.

So if I am to put 1000 routers in the flat network, reduce OSPF timers and
inject all 1000 BGP next hops with label to all 999 PEs while I only need
999 PEs to ever reach 10 next hops I would keep to argue flat IGP is not
the right choice.

Moreover as one of the best industry IGP developer and expert I highly
respect stated very recently the end to end flooding time should stay below
200 ms. That is not your ICMP RTT ... that is time to receive the LSA/LSP
to local RE, install in LSDB and send it back. That determines the flooding
radius you should try not to exceed. And the time packet takes to even get
from LC to RE is very platform dependent as I am sure most of you know very
well :)

Cheers,
R.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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, but i'd much prefer to have LDPv4 &
LDPv6 right now.

We have some buying power with Cisco at the moment, so let me know how
I can help from the land 'down under'.

Drikus.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 11/Jun/20 12:54, Robert Raszuk wrote:

> No doubt. 
>
> However one network is not equal the other. Especially SP/ISP network
> requirements and any to any traffic patterns there are very different
> from typical hub and spoke connectivity in the content or service
> serving enterprise.

Totally agree, which is why I said if you are building a backbone across
all continents, the ability of your hardware is the least of your problems.

You'll probably spend more time dealing with backbone and license issues.


>
> So if I am to put 1000 routers in the flat network, reduce OSPF timers
> and inject all 1000 BGP next hops with label to all 999 PEs while I
> only need 999 PEs to ever reach 10 next hops I would keep to argue
> flat IGP is not the right choice.

While I don't use OSPF, that almost sounds like something you'd do at an
EBC with a vendor in the lab.

Real networks may operate slightly less over-zealously :-).

But who knows, only time will tell. The problem is each time we seem to
reach the peak of what control planes can do, they up the ante.

If I was having this discussion with you 10 years ago, I'd be in total
agreement.


>
> Moreover as one of the best industry IGP developer and expert I highly
> respect stated very recently the end to end flooding time should stay
> below 200 ms. That is not your ICMP RTT ... that is time to receive
> the LSA/LSP to local RE, install in LSDB and send it back. That
> determines the flooding radius you should try not to exceed. And the
> time packet takes to even get from LC to RE is very platform dependent
> as I am sure most of you know very well :)

I won't diss the IGP developers, they help us to eat. But after being in
the game this long, I've often found that caution and real life don't
always align.

Naturally, we will take the considerations, and see what feedback we get
from the actual network, and adjust accordingly.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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, but i'd much prefer to have LDPv4 &
> LDPv6 right now.
>
> We have some buying power with Cisco at the moment, so let me know how
> I can help from the land 'down under'.

Thanks, Drikus.

If you can get your AM to get in touch with the ASR920 and ASR1000 BU's
to ask for LDPv6, that will help a great deal. Cisco are saying "no one"
is asking for LDPv6, forgetting that it's more about IPv6, than other
lower/higher-level services it can support, LDPv6 included.

As with you, they are trying to shove SRv6 down our throats, which can
only come on an NCS540 for the moment, which is odd since that runs IOS
XR, which supports LDPv6. So basically, swap out tons of boxes to get a
feature that can easily be coded for in existing hardware... makes you
wonder about the thought-process;

It's been a crazy two weeks with our Cisco AM's and the platform TME's
on heated calls about this that it's almost old testament biblical :-).
It's at the stage where it's going up the chain to the BU's who will
make the final call. So if they can get some noise from you as well, it
certainly won't hurt.

You don't need new hardware features on the ASR920 or ASR1000 to support
LDPv6. You might do for SRv6. Either way, both platforms would need both
features developed in code, and I think it's safe to assume which one
will be practically easier to build and roll-out to the entire MPLS
customer base, today.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 11 Jun 2020 at 13:33, Robert Raszuk <robert@raszuk.net> wrote:

> SR-MPLS implies globally (domain wide) label significance. Index in the IGP extensions is there just to relax requirement to use the same block on all nodes - so the block does not need to be continuous in an SR domain. It is recommended by Cisco but not required by standard.

As all need to agree on having label at a given offset for the
application, the range either needs to be continuous or have the same
holes which are not used by anyone. It is slightly more convenient to
an equal size continuous label.
This is not unlike VPLS.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> From: Mark Tinka <mark.tinka@seacom.mu>
> 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, you'll never deploy
> RPKI or DNSSEC :-).
>
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...).

But running MPLS over IPv6 in addition to already running it over IPv4, gaining new functionality or features in the process that could be ultimately monetized in providing better service to customers? -maybe even exposing the network to a new set of bugs? -I don't know, that doesn’t sound like a good use of company resources especially in these uncertain times . Maybe I'm being overly harsh here maybe if you could please explain the drivers or expected net value out of this exercise please?


adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Thu, Jun 11, 2020 at 01:17:55PM +0100, adamv0025@netconsultings.com wrote:
> But running MPLS over IPv6 in addition to already running it over IPv4,

Not "in addition to" but "to throw out the IPv4 part" :-)

More relevant to strongly growing networks that do not need to roll out
IPv4 to new parts, though.

(If I had LDPv6 today, I wouldn't actually change the existing network
today. But for the next round of rebuilding things, it would be something
to consider...)

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

On 11/Jun/20 14:17, adamv0025@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 running MPLS over IPv6 in addition to already running it over IPv4, gaining new functionality or features in the process that could be ultimately monetized in providing better service to customers? -maybe even exposing the network to a new set of bugs? -I don't know, that doesn’t sound like a good use of company resources especially in these uncertain times . Maybe I'm being overly harsh here maybe if you could please explain the drivers or expected net value out of this exercise please?

Oh dear, you sound like our Finance department now; "drivers" and "net
value" :-).

If I take your line of reasoning, deploying SRv6 likely requires new
hardware, which means $$. How much money will I charge customers for my
shiny new SRv6?

LDPv6 builds on LDPv4. Just like IPv6 builds on IPv4. At best, you can
remove BGPv6 from your core, which lowers your administration costs in
that part of the network even further, costing you less in human time
running it, resources you can otherwise re-deploy to other time- and
money-saving activities. At worst, you get IPv4/IPv6 feature parity, and
who doesn't like that :-).

And how much money did LDPv6 cost you to deploy? $0.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 network if you want MPLS support in
your IPv6-only network, which still requires IPv4. Private IPv4 address
space works, but some people like it, some don't, and more importantly,
you still carry around IPv4.

You could try the SRv6 gravy, but now you probably need new kit. What's
the SRv6 business-case? Well, one would say you save millions of $$ not
buying IPv4, but now you've spent money supporting SRv6.

LDPv6 can be supported by any platform that supports MPLS today. No
money out the door. Cisco would need to develop code for both LDPv6 and
SRv6 anyway, so no harm done on that side.

As we used to say in Vladivostok, "It's simple physics :-)".


> (If I had LDPv6 today, I wouldn't actually change the existing network
> today. But for the next round of rebuilding things, it would be something
> to consider...)

Give your favorite Cisco AM a shout-out. I promise, they are probably
too young to remember your 6500/7600 tickets :-).

Mark.

On Thu, 11 Jun 2020 at 15:58, Mark Tinka <mark.tinka@seacom.mu> 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 others, but we didn't implement RPKI for shit and giggles,
we implemented it, because customers wanted us to do RPKI.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 to become part of an
RFP requirements document? Probably not.

Then again, the typical NTT customer probably has an engineering
department that understands and demands RPKI, because they are a
sizeable operator themselves. We only have a handful of customers that
technically appreciate that we've deployed RPKI. For the rest, it
doesn't register.

Not sure if beating up on Job for months qualifies as "a customer
wanting RPKI from NTT" :-).

Mark.


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> From: Mark Tinka <mark.tinka@seacom.mu>
> Sent: Thursday, June 11, 2020 1:56 PM
>
> On 11/Jun/20 14:17, adamv0025@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 :-).
>
Good PR might ;)

>
> >
> > But running MPLS over IPv6 in addition to already running it over IPv4,
> gaining new functionality or features in the process that could be ultimately
> monetized in providing better service to customers? -maybe even exposing
> the network to a new set of bugs? -I don't know, that doesn’t sound like a
> good use of company resources especially in these uncertain times . Maybe
> I'm being overly harsh here maybe if you could please explain the drivers or
> expected net value out of this exercise please?
>
> Oh dear, you sound like our Finance department now; "drivers" and "net
> value" :-).
>
I thought I sound like a network architect :(

> If I take your line of reasoning, deploying SRv6 likely requires new hardware,
> which means $$. How much money will I charge customers for my shiny new
> SRv6?
>
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.
Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS.

> LDPv6 builds on LDPv4. Just like IPv6 builds on IPv4. At best, you can remove
> BGPv6 from your core,
I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4...

> which lowers your administration costs in that part of
> the network even further, costing you less in human time running it,
> resources you can otherwise re-deploy to other time- and money-saving
> activities. At worst, you get IPv4/IPv6 feature parity, and who doesn't like
> that :-).
>
I knew there's a bit of OCD hidden in this at some level :)

> And how much money did LDPv6 cost you to deploy? $0.
>
Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network.


adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 11 Jun 2020 at 16:45, Mark Tinka <mark.tinka@seacom.mu> 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 accepting transit offers from providers who don't do RPKI.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> From: Saku Ytti <saku@ytti.fi>
> Sent: Thursday, June 11, 2020 3:29 PM
>
> On Thu, 11 Jun 2020 at 16:45, Mark Tinka <mark.tinka@seacom.mu> 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
> accepting transit offers from providers who don't do RPKI.
>
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.

adam


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 sound of this".

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 11/Jun/20 16:36, adamv0025@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 scale, taking the network down.

Not every bit of good network operation can be attributed to direct
revenue. BCP-38 is a great example, and that is still poorly deployed
despite being supported.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 11/Jun/20 16:25, adamv0025@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 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 IPv6 FEC's.

The idea is to create IPv6 FEC's so that IPv6 traffic can be
label-switched in the network natively, allowing you to remove BGPv6 in
a native dual-stack core.


> Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS.

No RSVP-TE here, thank the Lord :-).


> I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4...

Nothing like the real thing:

In IPv4-land, you get this:

24005  49017       105.16.Y.Z/32     Te0/0/0/2    105.16.A.B    8614773
            49017       105.16.Y.Z/32     Te0/1/0/0    105.16.C.D   8121753
            49017       105.16.Y.Z/32     Te0/7/0/5    105.16.E.F    9964543

In IPv6-land, you get this:

2c0f:feb0:X:Y::Z/128 25071   25458          BE1          Link-local
                                              25458         
BE2          Link-local


In Junos land, it looks like this:

7967               *[LDP/9] 1w5d 01:21:05, metric 1
                        >  to fe80::de38:e1ff:fe15:dc02 via ae2.0, Swap
145674

If I run an IPv6 traceroute toward a host that sits behind a router
doing LDPv6, this is what happens:

run traceroute 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
traceroute6 to 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
(2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ) from 2c0f:feb0:1:2::112, 64 hops
max, 12 byte packets
 1  ae-5-0.er6-01-fra.de.seacomnet.com (2c0f:feb0:1:2::111)  165.567 ms 
166.158 ms  166.924 ms
     MPLS Label=145786 CoS=0 TTL=1 S=1
 2  xe-0-0-0-0.cr6-02-mrs.fr.seacomnet.com (2c0f:feb0:1:2::f9)  165.682
ms 2c0f:feb0:1:2::279 (2c0f:feb0:1:2::279)  165.817 ms  168.123 ms
     MPLS Label=25494 CoS=0 TTL=1 S=1
<snip>

As you can see, just as with IPv4, IPv6 packets are now being
MPLS-switched in the core, allowing you to remove BGPv6 in the core and
simplify operations in that area of the network.

So this is native MPLSv6. It's not 6PE or 6VPE.

Your IPv4 domain could fall over and your MPLSv6 network will still be
alive, because it's neither 6PE nor 6VPE. And vice versa - your IPv6
network could die, and your MPLSv4 will be unaffected.


> I knew there's a bit of OCD hidden in this at some level :)

Safe to say the Internet is one big OCD project :-).

My OCD is sleeping at 3AM, in peace, lockdown or not, hehe.


> Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network.

Which you wouldn't have to do with SRv6, because you trust the vendors?

And no, LDPv6 does not call for one to migrate from LDPv4. They can live
together, side-by-side, just as native dual-stack IPv4/IPv6 does.

We are running LDPv4 and LDPv6 side-by-side, with no problems, between
IOS XR and Junos, as you can see above. This is a live network, carrying
revenue-generating, production traffic. It's not a fantasy.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

please remove me from this mailing list

On 11/06/2020 15:58, Mark Tinka wrote:
>
> On 11/Jun/20 16:25, adamv0025@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 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 IPv6 FEC's.
>
> The idea is to create IPv6 FEC's so that IPv6 traffic can be
> label-switched in the network natively, allowing you to remove BGPv6 in
> a native dual-stack core.
>
>
>> Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS.
> No RSVP-TE here, thank the Lord :-).
>
>
>> I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4...
> Nothing like the real thing:
>
> In IPv4-land, you get this:
>
> 24005  49017       105.16.Y.Z/32     Te0/0/0/2    105.16.A.B    8614773
>             49017       105.16.Y.Z/32     Te0/1/0/0    105.16.C.D   8121753
>             49017       105.16.Y.Z/32     Te0/7/0/5    105.16.E.F    9964543
>
> In IPv6-land, you get this:
>
> 2c0f:feb0:X:Y::Z/128 25071   25458          BE1          Link-local
>                                               25458
> BE2          Link-local
>
>
> In Junos land, it looks like this:
>
> 7967               *[LDP/9] 1w5d 01:21:05, metric 1
>                         >  to fe80::de38:e1ff:fe15:dc02 via ae2.0, Swap
> 145674
>
> If I run an IPv6 traceroute toward a host that sits behind a router
> doing LDPv6, this is what happens:
>
> run traceroute 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
> traceroute6 to 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
> (2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ) from 2c0f:feb0:1:2::112, 64 hops
> max, 12 byte packets
>  1  ae-5-0.er6-01-fra.de.seacomnet.com (2c0f:feb0:1:2::111)  165.567 ms
> 166.158 ms  166.924 ms
>      MPLS Label=145786 CoS=0 TTL=1 S=1
>  2  xe-0-0-0-0.cr6-02-mrs.fr.seacomnet.com (2c0f:feb0:1:2::f9)  165.682
> ms 2c0f:feb0:1:2::279 (2c0f:feb0:1:2::279)  165.817 ms  168.123 ms
>      MPLS Label=25494 CoS=0 TTL=1 S=1
> <snip>
>
> As you can see, just as with IPv4, IPv6 packets are now being
> MPLS-switched in the core, allowing you to remove BGPv6 in the core and
> simplify operations in that area of the network.
>
> So this is native MPLSv6. It's not 6PE or 6VPE.
>
> Your IPv4 domain could fall over and your MPLSv6 network will still be
> alive, because it's neither 6PE nor 6VPE. And vice versa - your IPv6
> network could die, and your MPLSv4 will be unaffected.
>
>
>> I knew there's a bit of OCD hidden in this at some level :)
> Safe to say the Internet is one big OCD project :-).
>
> My OCD is sleeping at 3AM, in peace, lockdown or not, hehe.
>
>
>> Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network.
> Which you wouldn't have to do with SRv6, because you trust the vendors?
>
> And no, LDPv6 does not call for one to migrate from LDPv4. They can live
> together, side-by-side, just as native dual-stack IPv4/IPv6 does.
>
> We are running LDPv4 and LDPv6 side-by-side, with no problems, between
> IOS XR and Junos, as you can see above. This is a live network, carrying
> revenue-generating, production traffic. It's not a fantasy.
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 easy. Given the lack of ECMP/WECMP, they remain fairly efficient within the hardware.

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 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 have a super-deep label stack removes all of the perceived benefits of cheap and simple. The arguments about IP lookups being slow is one best left to the 1990's when it was true. Fixed pipeline systems have proven this to be false.

And if the argument is coming down to the lookup delay between the two and your talking about the WAN, speed of light is dominate so the ns differences are in the noise, baring the monetary exchanges.

Your follow on statement about more ports and smaller silicon is in abstract somewhat correct but is practice not. Across the silicon manufactures no one in the open market is making a purely MPLS capable chip. With the cost of chips today, you must have multiple customers for the silicon, or, if you are using wholly internally, have enough volume to justify the $100M's that it costs to make. So everyone is optimizing around re-use and maximal customer overlap for execution. So they all do MPLS and IP and SR and IPIP and ... making the argument moot.

But please to not take this as saying SRv6 is great. The community got v6 wrong in a number of areas and SR is not helping that. v4 as a transport vs. MPLS is a useful conversation to be had, again depending on deployment and philosophy around large vs. small network nodes.

David

> On Jun 10, 2020, at 9:51 PM, Saku Ytti <saku@ytti.fi> wrote:
>
> On Thu, 11 Jun 2020 at 00:48, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
>> On 10/Jun/20 21:36, Phil Bedard wrote:
>>> In its simplest form without TE paths, there isn't much to SRv6. You use a v6 address as an endpoint and a portion of the address to specify a specific VPN service. You completely eliminate the label distribution protocol.
>>
>> A BGPv6-free core is a decent use-case for us.
>
> 100% Eliminating label forwarding in core is not an asset, it is a
> liability. Label forwarding is fast, cheap and simple[0]. You can do
> it with on-chip memory in constant time. IP lookups are slow,
> expensive and complex[0]. SRv6 marketing is false, bordering dishonest
> marketing of an unclean abomination of a protocol. 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.
>
> [0] None of this is hard to measure, it is a known fact. And all of it
> matters, you can measure lower jitter for MPLS than IP, you can better
> carry DDoS traffic when using MPLS compared to IP and you can have
> more ports in front-plate for the same money, by spending external
> memory SERDES for WAN ports.
>
>
>
> --
> ++ytti
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/