On 16/Jun/20 14:24, adamv0...@netconsultings.com wrote:
> Actually I was exactly I that situation and v4 RFC 1918 space worked out just
> fine.
In that way, you are braver than me. But hey, if you need IPv4 and can't
get the public stuff, I won't fault you for going with the private stuff
> From: Mark Tinka
> Sent: Tuesday, June 16, 2020 12:09 PM
>
> On 16/Jun/20 12:00, adamv0...@netconsultings.com wrote:
>
> > Hence my earlier comment on why I think it's not commercially feasible
> > to switch to v6 control plane,
>
> Personally, I've never been a fan of a single-stack
On 16/Jun/20 12:00, adamv0...@netconsultings.com wrote:
> Hence my earlier comment on why I think it's not commercially feasible to
> switch to v6 control plane,
Personally, I've never been a fan of a single-stack backbone. I can,
however, understand the use-case where a new or growing
> From: Mark Tinka
> Sent: Monday, June 15, 2020 4:07 PM
>
> On 15/Jun/20 12:13, adamv0...@netconsultings.com wrote:
>
> > Not to mention this whole thread is focused solely on next-hop
> identification -which is just the lowest of the layers of abstraction in the
> vertical stack.
> > We
On 15/Jun/20 12:13, adamv0...@netconsultings.com wrote:
> Not to mention this whole thread is focused solely on next-hop
> identification -which is just the lowest of the layers of abstraction
> in the vertical stack. We haven’t talked about other "entities" that
> need identification like:
On 15/Jun/20 12:13, adamv0...@netconsultings.com wrote:
> Not to mention this whole thread is focused solely on next-hop identification
> -which is just the lowest of the layers of abstraction in the vertical stack.
> We haven’t talked about other "entities" that need identification like:
> ECMP appears to be your main pain point, the rich features are not
> relevant, and you mentioned commodity hardware being able to hash on
> IPIP. I feel this may be a very special case where HW can do IPIP hash
> but not MPLSIP hash. Out of curiosity, what is this hardware? Jericho
> can do
> What I'm getting at is that IP allows re-write sharing in that what needs to
> change on two IP frames taking the same paths but ultimately reaching
> different destinations are re-written (e.g. DMAC, egress-port) identically.
> And, at least with IPIP, you are able to look at the
> From: Saku Ytti
> Sent: Monday, June 15, 2020 11:02 AM
>
> On Mon, 15 Jun 2020 at 12:46, wrote:
>
> > Yes it can indeed, and that's moving towards the centre between the
> extreme cases that David laid out.
> > It's about how granular one wants to be in identifying an end-to-end path
>
On Mon, 15 Jun 2020 at 12:46, wrote:
> Yes it can indeed, and that's moving towards the centre between the extreme
> cases that David laid out.
> It's about how granular one wants to be in identifying an end-to-end path
> between a pair of edge nodes.
> I agree with you that MPLS is still
> From: Saku Ytti
> Sent: Monday, June 15, 2020 10:31 AM
>
> On Mon, 15 Jun 2020 at 12:24, wrote:
>
>
> > Yes this is where each node needs to have a label uniquely identifying
> > every LSP passing through it.
> > Saku,
> > With IP header you don't need this,
> > Consider this:
> > PE1 to
On Mon, 15 Jun 2020 at 12:24, wrote:
> Yes this is where each node needs to have a label uniquely identifying every
> LSP passing through it.
> Saku,
> With IP header you don't need this,
> Consider this:
> PE1 to PE2 via 3 P-core nodes
> With ECMP in IP, then PE1 just needs single FEC the
> David Sinn
> Sent: Friday, June 12, 2020 4:42 PM
>
> > On Jun 12, 2020, at 8:26 AM, Saku Ytti wrote:
> >
> > On Fri, 12 Jun 2020 at 18:16, David Sinn wrote:
> >
> The label stack question is about the comparisons between the two
> extremes of SR that you can be in. You either label your
> From: David Sinn
> Sent: Friday, June 12, 2020 4:19 PM
>
> > On Jun 11, 2020, at 2:02 PM, Mark Tinka wrote:
> >
> > 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
On Fri, Jun 12, 2020 at 10:22 PM David Sinn wrote:
> Except that is actually the problem if you look at it in hardware. And to
> be very specific, I'm talking about commodity hardware, not flexible
> pipelines like you find in the MX and a number of the ASR's. I'm also
> talking about the more
On 13/Jun/20 08:00, Saku Ytti wrote:
>
> ECMP appears to be your main pain point, the rich features are not
> relevant, and you mentioned commodity hardware being able to hash on
> IPIP. I feel this may be a very special case where HW can do IPIP hash
> but not MPLSIP hash. Out of curiosity,
On Fri, 12 Jun 2020 at 23:25, David Sinn wrote:
> > Should we design a rational cost-efficient solution, we should choose
> > the lowest overhead and narrowest working keys.
>
> In the abstract, sure. But if you want a practical, deployable, production
> network, it's multi-dimensioned.
We
On 12/Jun/20 17:19, David Sinn wrote:
> Yes. Path enumeration when you use mult-tier Clos topologies within a PoP
> causes you many, many problem.
Okay, got you. I thought you were running into these problems on the
"usual suspect" platforms.
Yes, commodity hardware certainly has a number
> On Jun 12, 2020, at 11:41 AM, Robert Raszuk wrote:
>
> I'm not sure why this deep label stack keeps popping, if we need
> multiple levels of tunneling, we need it in IP too, and it's almost
> more expensive in IP.
>
> Well imagine you need only one level of tunneling but rich ECMP.
>
>
>
>> Unless you want ECMP then it VERY much matters. But I guess since we are
>> only talking about theoretical instead of building an actual practical
>> network, it doesn't matter.
>
> Well blatantly we are, because in the real world most of the value of
> MPLS tunnels is not available as IP
> Rewrites on MPLS is horrible from a memory perspective as maintaining the
> state and label transition to explore all possible discrete paths across the
> overall end-to-end path you are trying to take is hugely in-efficient.
> Applying circuit switching to a packet network was bad from the
On Fri, 12 Jun 2020 at 21:41, Robert Raszuk wrote:
> Well imagine you need only one level of tunneling but rich ECMP.
>
> Then with IP encap (even MPLS app demux carried in UDP) you just make sure
> src UDP port is random and voila works very nicely.
>
> In contrast to achieve the same with
>
> I'm not sure why this deep label stack keeps popping, if we need
> multiple levels of tunneling, we need it in IP too, and it's almost
> more expensive in IP.
>
Well imagine you need only one level of tunneling but rich ECMP.
Then with IP encap (even MPLS app demux carried in UDP) you just
On Fri, 12 Jun 2020 at 20:12, Andrey Kostin wrote:
> Sorry for jumping in in the mddle of discussion, as a side note, in case
> of IPIP tunneling, shouldn't another protocol type be utilized in MAC
> header? As I understand, in VXLAN VTEP ip is dedicated for this purpose,
> so receiving a packet
Saku Ytti писал 2020-06-12 12:10:
On Fri, 12 Jun 2020 at 18:52, David Sinn wrote:
Unless you want ECMP then it VERY much matters. But I guess since we
are only talking about theoretical instead of building an actual
practical network, it doesn't matter.
Well blatantly we are, because in
On Fri, 12 Jun 2020 at 18:52, David Sinn wrote:
> Unless you want ECMP then it VERY much matters. But I guess since we are only
> talking about theoretical instead of building an actual practical network, it
> doesn't matter.
Well blatantly we are, because in the real world most of the value
Salve,
On Thu, Jun 11, 2020 at 8:08 PM David Sinn wrote:
Rewrites on MPLS is horrible from a memory perspective as maintaining the
> state and label transition to explore all possible discrete paths across
> the overall end-to-end path you are trying to take is hugely in-efficient.
> Applying
>> The label stack question is about the comparisons between the two extremes
>> of SR that you can be in. You either label your packet just for it's
>> ultimate destination or you apply the stack of the points you want to pass
>> through.
>
> Quite, but transit won't inspect the stack, it
On Fri, 12 Jun 2020 at 18:16, David Sinn wrote:
> I'm not sure what implementation you are saying doesn't exist. The Broadcom
> XGS line is all on-die. The two largest cloud providers are using them in
> their transport network (to the best of my understanding). So I'm not sure if
> your
On Fri, 12 Jun 2020 at 18:42, David Sinn wrote:
> But why do you need full table lookup in the middle of the network? Why place
> that class of gear where it's not needed?
Some people do collapsed core. But this is getting bit theoretical,
because we definitely could do this on IP, we could do
> On Jun 12, 2020, at 8:26 AM, Saku Ytti wrote:
>
> On Fri, 12 Jun 2020 at 18:16, David Sinn wrote:
>
>> I'm not sure what implementation you are saying doesn't exist. The Broadcom
>> XGS line is all on-die. The two largest cloud providers are using them in
>> their transport network (to
> On Jun 11, 2020, at 2:02 PM, Mark Tinka wrote:
>
>
>
> 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
On 11/Jun/20 19:19, Saku Ytti wrote:
> The demand is, we need tunneling, then the question is what are the
> metrics of a good tunneling solution. By answering this honestly, MPLS
> is better. We could do better surely, but IP is not that.
One unexpected benefit, I will say, with going native
> On Jun 11, 2020, at 12:39 PM, Saku Ytti wrote:
>
> 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
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
> 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
>
> On Jun 11, 2020, at 8:41 AM, Saku Ytti wrote:
>
> 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
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
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 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
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
please remove me from this mailing list
On 11/06/2020 15:58, Mark Tinka wrote:
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.
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 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
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
> 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 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
Hi,
On Thu, Jun 11, 2020 at 01:17:55PM +0100, adamv0...@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
> 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 Thu, 11 Jun 2020 at 13:33, Robert Raszuk 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
>
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 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.
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.
> 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
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
> 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
/* 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
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.
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
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
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
>
> 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'.
>
Nope that was not the main reason.
Main reason was the belief that labels
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
On Wed, 10 Jun 2020 at 22: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.
Then do
On Thu, 11 Jun 2020 at 00:48, Mark Tinka 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
On 10/Jun/20 21:20, Gert Doering wrote:
> Oh. Indeed, sorry for being unclear here.
>
> SR/MPLS sounds like a good idea (reducing label state).
>
> SR/IPv6 does not sound convincing.
+1.
2010 - 2019 has been a decade of "pushing stuff".
2020 is the year of deciding what snake oil no longer
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
On 10/Jun/20 20:45, Saku Ytti wrote:
> I'm pretty sure that one or more of Mark, Gert or Tim are thinking
> SR/MPLS IPv6 when they say SRv6?
Oh, not at all, Saku.
> No one in their right minds thinks SRv6 is a good idea, terrible snake
> oil and waste of NRE. SR/MPLS IPv6 of course is
On 10/Jun/20 21:17, Gert Doering wrote:
>
> We do have IOS XEs today (ASR920), and based on that, we're not going
> to buy new IOS XE devices any time soon.
>
> The amount of... strangeness... that this BU considers acceptable
> is... not.
It's been a week of trying to get them to see reason.
Ah yes, I would say LDPv6 and/or SR/MPLS IPv6. SRv6 reads like a science
project.
Either way, I would like to achieve a full IPv6 control plane.
On Wed, Jun 10, 2020 at 2:46 PM Saku Ytti wrote:
> I'm pretty sure that one or more of Mark, Gert or Tim are thinking
> SR/MPLS IPv6 when they say
Hi,
On Wed, Jun 10, 2020 at 09:45:55PM +0300, Saku Ytti wrote:
> I'm pretty sure that one or more of Mark, Gert or Tim are thinking
> SR/MPLS IPv6 when they say SRv6?
>
> No one in their right minds thinks SRv6 is a good idea, terrible snake
> oil and waste of NRE. SR/MPLS IPv6 of course is
Hi,
On Wed, Jun 10, 2020 at 08:45:31PM +0200, Mark Tinka wrote:
> On 10/Jun/20 20:10, Gert Doering wrote:
>
> > To be honest, I do not think we're going to buy any IOS XE gear in the
> > foreseeable future. But if we did, LDPv6 would be nice to have - to get
> > rid of IPv4 in the backbone
On 10/Jun/20 20:29, Tim Durack wrote:
> I would take either LDPv6 or SRv6 - but also need L3VPN (and now EVPN)
> re-wired to use IPv6 NH.
At the moment, LDPv6 doesn't have what I call "service" support, i.e.,
l3vpn's, l2vpn's, MPLSv6-TE, mLDP, CsC, e.t.c. To be honest, I don't
mind those so
I'm pretty sure that one or more of Mark, Gert or Tim are thinking
SR/MPLS IPv6 when they say SRv6?
No one in their right minds thinks SRv6 is a good idea, terrible snake
oil and waste of NRE. SR/MPLS IPv6 of course is terrific.
LDPv6 and SRv6 seem like an odd couple, LDPv6 SR/MPLS IPv6 seem far
On 10/Jun/20 20:10, Gert Doering wrote:
> To be honest, I do not think we're going to buy any IOS XE gear in the
> foreseeable future. But if we did, LDPv6 would be nice to have - to get
> rid of IPv4 in the backbone network.
We have LDPv6 working beautifully between IOS XR (6.4.2) and Junos
I would take either LDPv6 or SRv6 - but also need L3VPN (and now EVPN)
re-wired to use IPv6 NH.
I have requested LDPv6 and SRv6 many times from Cisco to migrate the
routing control plane from IPv4 to IPv6
I have lots of IPv6 address space. I don't have a lot of IPv4
address space. RFC1918 is not
Hi,
On Wed, Jun 10, 2020 at 07:19:18PM +0200, Mark Tinka wrote:
> 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
92 matches
Mail list logo
