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 backbone
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 networ
> 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 hav
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: VPN
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: VPN
> 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
> betwee
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 bette
> 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 PE2
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 DST-I
> 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 pac
> 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 to
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 re
On 13/Jun/20 01:32, Randy Bush wrote:
>
> we have rov in rfps received from paying customers
I hope this becomes the norm, globally.
Mark.
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, wh
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 have
< note that i am wearing arrcus hat >
> 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.
we have rov in rfps received from paying customers
randy
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 of
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 the
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 o
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 ci
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 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 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 sayin
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 IPv
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 eas
> 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 h
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
> data-center
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 the
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 all
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 of
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 SR-MP
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 sys
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: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 scale
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 sou
> 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
> l
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 ac
> 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 to
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 others
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 runnin
> 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, you'
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
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 de
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 th
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 s
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
netwo
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 har
> 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 disc
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 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 LDP
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 in
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 th
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 d
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.
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
(
62 matches
Mail list logo
