On 12/Jul/18 18:46, Phil Bedard wrote:
> This is from an industry perspective and not specific to Juniper. BIER won't
> really happen without hardware support which is coming but will not be
> compatible with a lot of already deployed hardware.
Yes, this is what I have found so far, maki
On 12/Jul/18 13:04, Saku Ytti wrote:
> I believe you're right, that there isn't really anything there. But
> I'd love to be wrong.
Yes, BIER is not yet available, so you'd still need to maintain IP in
the core for Multicast.
> I see no reason why NG-MVPN couldn't have SR tunnel / forwarding-
This is from an industry perspective and not specific to Juniper. BIER won't
really happen without hardware support which is coming but will not be
compatible with a lot of already deployed hardware.
There was some IETF work going on to figure out how to map multicast to SR-MPLS
but it kind
I believe you're right, that there isn't really anything there. But
I'd love to be wrong.
I see no reason why NG-MVPN couldn't have SR tunnel / forwarding-plane.
On Thu, 12 Jul 2018 at 13:43, Jackson, William
wrote:
>
> So just to throw a question out there:
>
> When I last looked at SR this was
So just to throw a question out there:
When I last looked at SR this was a big empty hole when it came to multicast.
As we are possibly removing mLDP and RSVP from the network in favour of SR(-TE)
what are people doing to fill this void.
There were some drafts being worked on last year and if I
On 10/Jul/18 23:33, adamv0...@netconsultings.com wrote:
> Now a robust transport network with appropriate redundancy and failover
> mechanisms is responsibility of each operator.
> One can use IGP tuning or take the new path computation out of the equation
> completely with FRR options: LDP +
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Tuesday, July 10, 2018 11:33 AM
>
>
> On 9/Jul/18 17:25, adamv0...@netconsultings.com wrote:
>
>
>
> Well that really depends on the type of fault, let me explain:
>
> All agreed.
>
> My point was that if there is enough redundancy ins
> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Tuesday, July 10, 2018 12:23 PM
> To: Mark Tinka
> Cc: adamv0...@netconsultings.com; alexandre.guimar...@ascenty.com;
> Juniper List
> Subject: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-
> lag)
>
> O
On 10/Jul/18 21:33, adamv0...@netconsultings.com wrote:
> Speaking for the Carrier Ethernet market here,
>
> There was a huge market potential several years ago for p2p PWs (I don't
> really know what the situation is nowadays).
> It all started the same way as the shift from leased lines to F
On 10/Jul/18 21:43, adamv0...@netconsultings.com wrote:
> So is the market still blooming the same way or has it saturated over time
> please?
Connectivity (you know, the "dumb-pipe" talk) is very big business in
Africa right now; and growing massively YoY.
In the more matured markets like So
> Of Mark Tinka
> Sent: Tuesday, July 10, 2018 8:35 AM
> To: Pavel Lunin
> Cc: juniper-nsp
> Subject: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-
> lag)
>
>
> In our market (primarily Africa, and parts of Europe as end points),
customers
&g
> Of Pavel Lunin
> Sent: Monday, July 09, 2018 11:46 PM
>
> However my original point was rather about pseudo-wires than VPLS. I
> mean, I don't see a lot of pseudo-wires in the wild. Mostly because PW is
a
> kind of hard to sell. Customers can be of two types: those who love Metro
> Ethernet and
On 10/Jul/18 13:22, Saku Ytti wrote:
> I don't think so. This is to establish loop-to-loop LDP in addition to
> link LDP, meaning it'll help with core LDP, but not pseudowire LDP.
Never used it, so can't say for sure.
Seems like the Cisco implementation supports protection of VRF's:
https
On Tue, Jul 10, 2018 at 2:32 AM, Aaron Gould wrote:
> My entire Ethernet cellular backhaul architecture is based an a pair of
> pseudowires per cell tower. We are making money off of pw's.
>
>
Yep, mobile backhaul is a classic example. But it's also a case when
business model permits the network
On Tue, 10 Jul 2018 at 14:14, Mark Tinka wrote:
> Perhaps an option for the LDP heads is LDP Session Protection, which is
> supported by the major vendors. I don't use it in my network, though.
I don't think so. This is to establish loop-to-loop LDP in addition to
link LDP, meaning it'll help w
On 10/Jul/18 12:39, Saku Ytti wrote:
> I'd say this is true if you compare full-mesh iBGP and LDP, if you
> compare RR iBGP and LDP, it's not true, RR iBGP has signalling
> redundancy LDP does not have.
Agreed on that point.
Perhaps an option for the LDP heads is LDP Session Protection, which
On Tue, 10 Jul 2018 at 13:33, Mark Tinka wrote:
> My point was that if there is enough redundancy inside the core network
> to deal with fibre failures that can keep iBGP sessions up, it will also
> keep LDP sessions up, but most importantly, traffic will continue to flow.
I'd say this is true i
On 9/Jul/18 17:25, adamv0...@netconsultings.com wrote:
> Well that really depends on the type of fault, let me explain:
All agreed.
My point was that if there is enough redundancy inside the core network
to deal with fibre failures that can keep iBGP sessions up, it will also
keep LDP session
On 10/Jul/18 02:32, Aaron Gould wrote:
> My entire Ethernet cellular backhaul architecture is based an a pair of
> pseudowires per cell tower. We are making money off of pw's.
That I get.
What I was keen on understanding are those MNO's that use VPLS as the
backbone, i.e., as in a network
On 10/Jul/18 00:46, Pavel Lunin wrote:
>
>
> I have no doubt that you know how to run MPLS in the access smoothly.
> However, choosing the right gear for this role has always been a hard
> job. Those folks who chose Brocade CES some 5-7 years ago, where are
> they now?
>
> The problem is that
My entire Ethernet cellular backhaul architecture is based an a pair of
pseudowires per cell tower. We are making money off of pw's.
Aaron
> On Jul 9, 2018, at 5:46 PM, Pavel Lunin wrote:
>
> We run MPLS all the way into the access, on ASR920's. So pw's are
>> end-to-end, and the Provisioni
We run MPLS all the way into the access, on ASR920's. So pw's are
> end-to-end, and the Provisioning/NOC teams only need to look at the end
> boxes. I found the whole idea of centralized "gateways" in the core to be a
> bit clunky.
>
I have no doubt that you know how to run MPLS in the access smo
On 9/Jul/18 23:52, Andy Koch wrote:
>
>
> You mentioned a couple times in the thread that the EX4550 is EoS. I
> am not finding any reference to that on the Juniper site. In fact,
> they still tout the switch. Do you have a link to the EoS/EoL notices?
It was during a discussion with our J
On 7/7/18 7:37 AM, Mark Tinka wrote:
Slightly off-topic, we tried the EX4600 as a way to move away from the
now-EoS EX4550,
Hi Mark,
You mentioned a couple times in the thread that the EX4550 is EoS. I am not
finding any reference to that on the Juniper site. In fact, they still tout
the s
Hey Michael,
On Mon, 9 Jul 2018 at 17:09, Michael Hare wrote:
> When I was a bit greener with our MPLS network I would experience the same
> concern as Alexandre when a dual connected customer lost a PE, in that I
> would experience loss of service waiting for BGP to timeout. I briefly went
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Monday, July 09, 2018 11:54 AM
>
>> On 9/Jul/18 11:58, adamv0...@netconsultings.com wrote:
>> That is faulty fibre causes BGP session problems but not targeted-LDP
>> session problems?
>
> Faulty fibre will affect any control plane session
ing
instances.
-Michael
>>-Original Message-
>>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
>>Of Saku Ytti
>>Sent: Saturday, July 07, 2018 4:24 PM
>>To: alexandre.guimar...@ascenty.com
>>Cc: Juniper List
>>Subject: Re: [j-nsp] S
That’s correct Mark!
I don’t need run BGP in every router or switch that I have, and I don’t have
VPLS capable equipments in every location, but i have l2circuits equipments in
every location because our business is provide l2 services for Carriers and
Corporations.
When VPLS p2mp or mp2mp is
On 9/Jul/18 11:58, adamv0...@netconsultings.com wrote:
> That is faulty fibre causes BGP session problems but not targeted-LDP
> session problems?
Faulty fibre will affect any control plane sessions.
I think what Alexandre was trying to say is that troubleshooting the
network where issues co
On 9/Jul/18 10:55, James Bensley wrote:
> I was having the exact same thoughts. LDP or BGP signaled - it should
> be independent of IGP link flaps. Saku raises a good point that with
> BGP signaled we can have multiple RR's meaning that loosing one
> doesn't mean that the server state is lost f
On 9/Jul/18 07:52, joel jaeggli wrote:
> As they are a matrix of cell forwarders either attached to each other or
> to a fabric it's probably more proper to think of that as 4GB of packet
> buffer per asic. There is in fact a small amount onboard the asic and
> then the large dollop of offboard
On 9/Jul/18 01:13, Pavel Lunin wrote:
> And yes, as pseudo-wire data plane is way simpler than VPLS, depending on
> your access network design, you can [try to] extend it end-to-end, all the
> way to the access switch and [maybe, if you are lucky] dramatically
> simplify your NOC's life.
We ru
On 8/Jul/18 22:35, adamv0...@netconsultings.com wrote:
> Hold on gents,
> You are still talking about multi-hop TCP sessions, right? Sessions that
> carry information that is ephemeral to the underlying transport network -why
> would you want those session ever go down as a result of anything
On 8/Jul/18 22:22, adamv0...@netconsultings.com wrote:
> The only way how you can be 100% sure about the service availability is
> inserting test traffic onto the PW, that's why in Carrier Ethernet a good
> practice is to use CFM so you can not only turn the L2ckt down if corrupted
> but also b
> From: Alexandre Guimaraes [mailto:alexandre.guimar...@ascenty.com]
> Sent: Sunday, July 08, 2018 11:16 PM
>
> Adam,
>
> Important observation, I prefer keep my pw working even a lot of segments
> of the network are affected by fiber cut and so on...
>
> When I migrate my BGP VPLS services to l
On 8 July 2018 21:35:36 BST, adamv0...@netconsultings.com wrote:
>Hold on gents,
>You are still talking about multi-hop TCP sessions, right? Sessions
>that
>carry information that is ephemeral to the underlying transport network
>-why
>would you want those session ever go down as a result of anythi
On 7/8/18 01:34, Mark Tinka wrote:
>
>
> On 7/Jul/18 23:54, Aaron Gould wrote:
>
>> Thanks Mark, I haven't been aware of any buffer deficiency in my
>> 4550's. If something adverse is occurring, I'm not aware.
>
> The EX4550 has only 4MB of shared buffer memory. The EX4600 has only 12MB.
>
>
Hi experts,
I had a pleasure time reading the whole thread. Thanks, folks !
Honestly, I also (a bit like Saku) feel that Alexandre's case is more about
throwing the *unneeded* complexity away than about BGP vs. LDP.
The whole story of Kompella-style signaling for L2VPN and VPLS is
auto-discovery
Adam,
Important observation, I prefer keep my pw working even a lot of segments of
the network are affected by fiber cut and so on...
When I migrate my BGP VPLS services to l2circuits, my problems today is almost
Zero.
No matter what happens, business order for everyone is to keep everything
> From: James Bensley [mailto:jwbens...@gmail.com]
> Sent: Friday, July 06, 2018 2:04 PM
>
>
>
> On 5 July 2018 09:56:40 BST, adamv0...@netconsultings.com wrote:
> >> Of James Bensley
> >> Sent: Thursday, July 05, 2018 9:15 AM
> >>
> >> - 100% rFLA coverage: TI-LA covers the "black spots" we cur
> Of Mark Tinka
> Sent: Sunday, July 08, 2018 9:24 AM
>
>
>
> On 7/Jul/18 23:24, Saku Ytti wrote:
>
> > All these protocols have hello timers, LDP, ISIS, RSVP, BGP. And each
> > of them you'd like to configure to trigger from events without delay
> > when possible, instead of relying on timers.
> Of Mark Tinka
> Sent: Sunday, July 08, 2018 9:20 AM
>
Hi Mark,
two points
>
>
> On 7/Jul/18 23:10, Saku Ytti wrote:
>
> > Alexandre's point, to which I agree, is that when you run them over
> > LSP, you get all the convergency benefits of TE.
>
> Unless you've got LFA (or BFD, for the poor
> Of Alexandre Guimaraes
> Sent: Saturday, July 07, 2018 1:01 PM
>
Hi Alexandre,
With the level of detail you provided I'm afraid that it seems like some of
your troubles are rooted in somewhat suboptimal design choices.
> My Usage Cent
>
> My core Network, P and PE, are 100% Juniper
>
> We st
On 7/Jul/18 23:54, Aaron Gould wrote:
> Thanks Mark, I haven't been aware of any buffer deficiency in my
> 4550's. If something adverse is occurring, I'm not aware.
The EX4550 has only 4MB of shared buffer memory. The EX4600 has only 12MB.
You need the "set class-of-service shared-buffer perc
On 7/Jul/18 23:24, Saku Ytti wrote:
> All these protocols have hello timers, LDP, ISIS, RSVP, BGP. And each
> of them you'd like to configure to trigger from events without delay
> when possible, instead of relying on timers. Indeed you can have BGP
> next-hop invalidated the moment IGP informs
On 7/Jul/18 23:18, Alexandre Guimaraes wrote:
> When we use l2circuits, you remove some layer of routing protocol
> troubleshooting. In just few command you know what’s going on.
>
> In a flap, BGP session will be dropped after timers reached.
>
> RSVP/ISIS/LDP will be affect immediately. Also
On 7/Jul/18 23:10, Saku Ytti wrote:
> Alexandre's point, to which I agree, is that when you run them over
> LSP, you get all the convergency benefits of TE.
Unless you've got LFA (or BFD, for the poor man), in which case there is
no real incremental benefit.
We run BFD + LFA for IS-IS. We've
Sweet dreams Alexandre I can see you counting l2circuits now... I mean
sheep... I mean l2circuits...
Aaron
> On Jul 7, 2018, at 4:10 PM, Alexandre Guimaraes
> wrote:
>
> Saku,
>
> Indeed. iBGP will be redundant and resilient, yes... with a cost, 90 seconds
> (timers) of unavailability a
Thanks Mark, I haven't been aware of any buffer deficiency in my 4550's. If
something adverse is occurring, I'm not aware.
Thanks for the warning about large VC... I don't really intend on going past
the (2) stacked. After we outgrow it, I'll move on.
Aaron
> On Jul 7, 2018, at 3:02 PM, Mar
Hey Alexandre,
> When we use l2circuits, you remove some layer of routing protocol
> troubleshooting. In just few command you know what’s going on.
> In a flap, BGP session will be dropped after timers reached.
>
> RSVP/ISIS/LDP will be affect immediately. Also ISIS is the fundamental key
> of
Hey,
> Not everyone have MX960, MX480 handling BGP in every part of the network, I
> don’t have... I have QFX, hundreds of them. Now imagine in some MX, you have
> 5/6 full routing table coming from upstream or peerings partners. Now
> experience a flap between two of those MX exchanging full
Saku, just forgot
When we use l2circuits, you remove some layer of routing protocol
troubleshooting. In just few command you know what’s going on.
In a flap, BGP session will be dropped after timers reached.
RSVP/ISIS/LDP will be affect immediately. Also ISIS is the fundamental key of
everyth
On Sat, 7 Jul 2018 at 22:58, Mark Tinka wrote:
Hey Mark,
> I just let iBGP sessions form normally over IGP-mapped paths. Or am I missing
> something.
Alexandre's point, to which I agree, is that when you run them over
LSP, you get all the convergency benefits of TE. But I can understand
why so
Saku,
Indeed. iBGP will be redundant and resilient, yes... with a cost, 90 seconds
(timers) of unavailability and more 1-3 minutes to get back online. I know, we
can change timers, bfd and so on...
I used that before... but
Not everyone have MX960, MX480 handling BGP in every part of th
On 7/Jul/18 18:03, Alexandre Guimaraes wrote:
> Yes! But... Ex4550 we have 32 ports 1/10Gb, using expansion slots, more
> 1/10Gb or 40Gb ports. L2circuits, QinQ L2TP, vlan translation, rtg
> local-interface switching and so on...
>
> We eat 1/10Gb ports, ASR920 didn’t help us with that.
Agre
On 7/Jul/18 17:45, Alexandre Guimaraes wrote:
>
> ELS cli bring me some problem with QinQ L2TP services since it doesn’t
> works, also with the RTG, doesn’t work to, cause that I still using
> ex2200, ex3300.
Why Juniper broke this, is simply beyond me. It was working just fine...
I'm switchin
On 7/Jul/18 20:01, Aaron Gould wrote:
>
> I love my dual-ex4550 data center virtual chassis's However, I enabled mpls
> vrf on one recently and didn't feel very good about proceeding... So I will
> revert to pure ethernet switching, I put 40 gig into it and AE for fat 80 gig
> pipe to PE...
On 7/Jul/18 19:37, Aaron Gould wrote:
> BGP based VPLS isn't that much to deploy... It's actually easier then manual
> VPLS ... It's similar to saying , RR-based ibgp is easier than manually full
> meshing an ibgp environment Like ATM LANE was easier then full meshing
> SPVC's , lol , Go
On 7/Jul/18 18:26, Saku Ytti wrote:
> You can (and should) run your iBGP inside LSP too, so there is no
> difference, except iBGP can be redundant.
I just let iBGP sessions form normally over IGP-mapped paths. Or am I
missing something.
While I know an IGP path can follow an LSP, short of IGP
I have ACX5448 powered on in my lab ready to play with... We can share test
stories as we proceed... I think mine has Junos 18.x and I haven't done
anything with it yet
I love my dual-ex4550 data center virtual chassis's However, I enabled mpls
vrf on one recently and didn't feel very good abo
BGP based VPLS isn't that much to deploy... It's actually easier then manual
VPLS ... It's similar to saying , RR-based ibgp is easier than manually full
meshing an ibgp environment Like ATM LANE was easier then full meshing
SPVC's , lol , God rest your soul ATM
Aaron
> On Jul 7, 2018, at
On Sat, 7 Jul 2018 at 18:45, Alexandre Guimaraes
wrote:
Hey Alexandre,
> Mark is correct, l2circuits are end-to-end services where uptime is based at
> the termination points,
> Inside the backbone, every l2circuits works under LSP with FRR, so... from
> on point to another, LSP can search th
> Have you considered the Cisco ASR920 if you are running MPLS pw's on your
> EX4550's?
Yes! But... Ex4550 we have 32 ports 1/10Gb, using expansion slots, more 1/10Gb
or 40Gb ports. L2circuits, QinQ L2TP, vlan translation, rtg local-interface
switching and so on...
We eat 1/10Gb ports, ASR9
Saku,
Mark is correct, l2circuits are end-to-end services where uptime is based at
the termination points,
Inside the backbone, every l2circuits works under LSP with FRR, so... from on
point to another, LSP can search the best route, put in place a second best
route(standby), how many routes y
On 7/Jul/18 14:16, Saku Ytti wrote:
> I feel your frustration, but to me it feels like there is very little
> sharable knowledge in your experience.
Hmmh, I thought there was a fair bit, explicit and inferred. I feel
Alexandre could have gone on more than his TL;DR post allowed for :-).
> Yo
On 7/Jul/18 14:00, Alexandre Guimaraes wrote:
> My Usage Cent
Oh wow! Thanks for that, Alexandre. I love to hear such stories, as
that's what network operations is really all about - despite all the
fluff we get fed everyday.
> Ex4550 will be EOS soon... with no replacement of features... m
Hey Alexandre,
I feel your frustration, but to me it feels like there is very little
sharable knowledge in your experience. You seem to compare full-blown
VPLS, with virtual switch and MAC learning to single LDD martini. You
also seem to blame BGP pseudowires for BGP transport flapping, clearly
yo
My Usage Cent
My core Network, P and PE, are 100% Juniper
We start using VPLS, based in BGP sessions, at that time we was working at
maximum of 2 or 3 new provisions per day.
We won a big project contract, we reach 90/100 per month.
VPLS become a issue in all fronts...
Planning/ low ports - pri
On 7/Jul/18 13:03, James Bensley wrote:
> Ah, I remember that thread. It became quite long and I was very busy
> so I lost track of it. Just read through it. I also looked at LDPv6 a
> while back and saw it was not well supported so passed. For us 6PE
> (and eventually 6vPE as we move to Intern
On 5 July 2018 at 09:40, Mark Tinka wrote:
>
> In our case, we have different boxes from Cisco, each with varying support
> for SR. This makes things very tricky, and then we need to also throw in our
> Juniper gear. For me, the potential pain isn't worth the hassle, as we are
> not suffering in a
On 6/Jul/18 18:49, Aaron Gould wrote:
> Thanks Mark,
>
> To be clear I'm not arguing the difference and preference of RFC 4761 and RFC
> 4762 BGP or LDP signaled multi point VPLS...
>
> ...i'm strictly speaking about eline point to point
BGP can also be used for p2p services. In our case,
On 6/Jul/18 18:49, Aaron Gould wrote:
> Thanks Mark,
>
> To be clear I'm not arguing the difference and preference of RFC 4761 and RFC
> 4762 BGP or LDP signaled multi point VPLS...
>
> ...i'm strictly speaking about eline point to point
BGP can also be used for p2p services. In our case,
Thanks Mark,
To be clear I'm not arguing the difference and preference of RFC 4761 and RFC
4762 BGP or LDP signaled multi point VPLS...
...i'm strictly speaking about eline point to point
Aaron
> On Jul 6, 2018, at 11:26 AM, Mark Tinka wrote:
>
>
>
> On 6/Jul/18 17:03, Aaron Gould wrot
On 6/Jul/18 17:03, Aaron Gould wrote:
> Thanks, appreciate the thoughts/insights
>
> BGP-based ELINE ... Is this Kompella you speak of ? If so, seems like a lot
> for a simply/quick p2p pw
There have been plenty of threads arguing for/against BGP-based vs.
LDP-based pw signaling.
Technical
Thanks, appreciate the thoughts/insights
BGP-based ELINE ... Is this Kompella you speak of ? If so, seems like a lot
for a simply/quick p2p pw
Aaron
> On Jul 6, 2018, at 8:28 AM, James Bensley wrote:
>
>
>
>> On 5 July 2018 14:08:02 BST, Aaron Gould wrote:
>> I really like the simplicity
On 5 July 2018 09:56:40 BST, adamv0...@netconsultings.com wrote:
>> Of James Bensley
>> Sent: Thursday, July 05, 2018 9:15 AM
>>
>> - 100% rFLA coverage: TI-LA covers the "black spots" we currently
>have.
>>
>Yeah that's an interesting use case you mentioned, that I haven't
>considered, that i
On 5 July 2018 14:08:02 BST, Aaron Gould wrote:
>I really like the simplicity of my ldp-based l2vpn's... eline and elan
>
>You just made me realize how that would change if I turned off ldp.
>
>So, SR isn't able to signal those l2circuits, and manual vpls instances
>?
>... I would have to do a
Hey Aaron,
> So, SR isn't able to signal those l2circuits, and manual vpls instances ?
Correct.
> ... I would have to do all that with bgp ? I use bgp in some cases for
> rfc4762, but not for simple martini l2circuits.
Correct.
Why do you prefer to dynamically start PtP LDP for pseudowires,
i
Hello James.
Interesting feedback, thank you.
//Gustav
-Ursprungligt meddelande-
Från: juniper-nsp För James Bensley
Skickat: den 5 juli 2018 10:15
Till: juniper-nsp@puck.nether.net
Ämne: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
On 4 July 2018 at 18:13, Mark
I really like the simplicity of my ldp-based l2vpn's... eline and elan
You just made me realize how that would change if I turned off ldp.
So, SR isn't able to signal those l2circuits, and manual vpls instances ?
... I would have to do all that with bgp ? I use bgp in some cases for
rfc4762, bu
Thanks a lot James, that's very nice of you to explain all that to me and the
community.
I have Cisco and Juniper network.
MX960 - (5 nodes) supercore
ACX5048 - (~40 nodes) distribution
ASR9k - (15 nodes) core
ME3600 - (~50 nodes) distribution
Aaron
> On Jul 5, 2018, at 2:46 AM, James Bensle
> Of James Bensley
> Sent: Thursday, July 05, 2018 9:15 AM
>
> - 100% rFLA coverage: TI-LA covers the "black spots" we currently have.
>
Yeah that's an interesting use case you mentioned, that I haven't
considered, that is no TE need but FRR need.
But I guess if it was business critical to get th
On 5/Jul/18 10:15, James Bensley wrote:
>
> If you get any feedback you can publicly share I'm all ears!
Will do.
I'm currently working on getting those that have deployed it in the wild
to do a preso at an upcoming conference.
> As far as a greenfield deployment goes I'm fairly convinced th
> Of Gustav Ulander
> Sent: Wednesday, July 04, 2018 10:46 PM
>
> Has anyone actually managed to verify a business case with SR? Im guessing
> those mentioned bellow did?
>
How I see it, currently the only feasible business case to go with SR is if you
outgrew your scaling limits with regards to
On 4 July 2018 at 18:13, Mark Tinka wrote:
>
>
> On 4/Jul/18 18:28, James Bensley wrote:
>
> Also
>
> Clarence Filsfils from Cisco lists some of their customers who are
> happy to be publicly named as running SR:
>
> https://www.youtube.com/watch?v=NJxtvNssgA8&feature=youtu.be&t=11m50s
>
>
> We've
On 4 July 2018 at 22:25, Aaron Gould wrote:
> I'm concerned how to go from my LDP environment to SR/SPRING and what if some
> of my gear doesn't support SR/SPRING ? Is this LDP/SR mapping thing easy ?
>
>
> Aaron
Hi Aaron,
I think you're running Cisco gear too right so hopefully it's OK if I
s
: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
I'm concerned how to go from my LDP environment to SR/SPRING and what if some
of my gear doesn't support SR/SPRING ? Is this LDP/SR mapping thing easy ?
Aaron
> On Jul 4, 2018, at 6:05 AM, Niall Donaghy wrote:
18 10:10
> To: Niall Donaghy ; Gert Doering
>
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
>
>
>
>
>
> On 4/Jul/18 10:58, Niall Donaghy wrote:
>
> Hi Mark,
>
> As for segment routi
On 4/Jul/18 18:28, James Bensley wrote:
> Also
>
> Clarence Filsfils from Cisco lists some of their customers who are
> happy to be publicly named as running SR:
>
> https://www.youtube.com/watch?v=NJxtvNssgA8&feature=youtu.be&t=11m50s
We've been struggling to get vendors to present deployment
On 4/Jul/18 18:09, James Bensley wrote:
> Hi Mark,
>
> Walmart, Microsoft and Comcast all claim to have been running SR since 2016:
>
> http://www.segment-routing.net/conferences/2016-sr-strategy-and-deployment-experiences/
Thanks, James. This is helpful.
I don't know anyone at Walmart, but I
On 4 July 2018 at 17:09, James Bensley wrote:
> On 4 July 2018 at 10:09, Mark Tinka wrote:
>>
>>
>> On 4/Jul/18 10:58, Niall Donaghy wrote:
>>> Hi Mark,
>>>
>>> As for segment routing, several of our NREN partners have SR up and running
>>> in their backbones.
>>> We in GÉANT (the backbone that
On 4 July 2018 at 10:09, Mark Tinka wrote:
>
>
> On 4/Jul/18 10:58, Niall Donaghy wrote:
>> Hi Mark,
>>
>> As for segment routing, several of our NREN partners have SR up and running
>> in their backbones.
>> We in GÉANT (the backbone that connects these NRENs) are looking toward
>> deploying SR
;
>
>
> Br,
>
> Niall
>
>
>
>
>
> *From:*Mark Tinka [mailto:mark.ti...@seacom.mu]
> *Sent:* 04 July 2018 10:10
> *To:* Niall Donaghy ; Gert Doering
>
> *Cc:* juniper-nsp@puck.nether.net
> *Subject:* Re: [j-nsp] Segment Routing Real World Deployment (was: VP
Subject: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
On 4/Jul/18 10:58, Niall Donaghy wrote:
Hi Mark,
As for segment routing, several of our NREN partners have SR up and running in
their backbones.
We in GÉANT (the backbone that connects these NRENs) are looking toward
On 4/Jul/18 10:58, Niall Donaghy wrote:
> Hi Mark,
>
> As for segment routing, several of our NREN partners have SR up and running
> in their backbones.
> We in GÉANT (the backbone that connects these NRENs) are looking toward
> deploying SR across our entire backbone in the medium term.
Thank
95 matches
Mail list logo
