On Sat, 7 Jul 2018 at 18:45, Alexandre Guimaraes
<alexandre.guimar...@ascenty.com> 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 the best route, put in place a second 
> best route(standby), how many routes you want...

You can (and should) run your iBGP inside LSP too, so there is no
difference, except iBGP can be redundant.

Consider this

Edge1----Core1----Edge2
|          |       |
+--------Core2-----+

Now imagine you have L2 transport between Edge1 and Edge2. With iBGP
Edge[12] would receive information redundantly from both core
interfaces, to lose signalling information either end needs to lose
state to both BGP sessions.
With LDP it's single session, if that becomes sufficiently lossy that
it flaps, it's done, you lose state.

So BGP just provides more signalling redundancy.

> If we experience some degraded fiber/service, checking the LSP, we know where 
> to look. And after disabling that segment of network, all problem solved.
> Tshoot time decreased to few minutes only, and this makes everyone happy.

What I was trying to tell, your example is implementation detail, not
fundamental problem of BGP signalled pseudowire.

> VPLS is very good when you use one port per customer, 1/10Gb, when you have 
> to set trunk ports of 10Gb and put lots of vlan in a VC of 5to10 QFX 
> switches,  things gone wild...  one error, a l2 loop will shut every customer 
> inside that distribution POD.

Here we are not comparing same things, of course if you have L2
redundancy it's vulnerable to loops. The debate isn't should you do
ELAN or EPIPE, the debate it should you signal EPIPE on LDP or BGP,
and the examples you detail making the BGP case poorer are
implementation detail, not fundamental problem in BGP signalled
pseudowires.

-- 
  ++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to