[j-nsp] Separate internet transit network versus converged

Mark Tees marktees at gmail.com
Tue Mar 29 07:58:05 EDT 2016


I watched a video the other day describing the manufacturing process Cisco
used for the UADP ASIC does that count? ;)

I think it's actually a missing part of the puzzle in most training
material but possibly because previously it has been something vendors
don't talk about much?

On Tuesday, 29 March 2016, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
wrote:

> > Saku Ytti [mailto:saku at ytti.fi <javascript:;>]
> > Sent: Monday, March 28, 2016 12:24 PM
> >
> > On 28 March 2016 at 13:32, Adam Vitkovsky
> > <Adam.Vitkovsky at gamma.co.uk <javascript:;>> wrote:
> >
> > > Public means exposed to whims of the wild Internet, that is in both
> data
> > rates (DDoS) and updates (Malformed BGP updates) something you can't
> > control.
> > > Private means very good control over traffic rates and control plane
> > > (number of updates,...)
> >
> > QoS should guarantee that Internet DDoS does not hurt L3 MPLS VPN. And
> > BGP free core should guarantee that core does not core(SIC) on random BGP
> > UPDATE.
> >
> Hey Saku,
>
> Yes please, with BGP free core one usually relies on RRs and my point is
> that it's a good practice to run separate BGP process/RR (or at least
> sessions) for public control plane so malformed update that would god
> forbid cause iBGP session reset won't affect private control-plane sessions.
>
> With regards to QOS,
> In my opinion QOS is just a small piece in the puzzle (as a meter of fact
> it's not even the first thing that matters when a packet hits the box) and
> I think that one has to be well versed with how an ideal data-plane
> architecture looks like in order to be able to assess the HW capabilities
> and all the chokepoints across the chassis at hand correctly. Only then one
> can tell whether a particular HW fits the design requirements. There are
> cases were one doesn't need to bother but designing a converged network is
> not one of them.
>
> That said, I'd like to encourage all folks on the list to get educated in
> how routers work, it's fun trust me. I find it striking how much we know
> about how control-plane works (SR, BGP, ISIS ...) but so little about a
> life of a packet through the data-plane, even though a great deal of info
> is available online (though don't expect any fancy certificates for knowing
> this stuff). Every time I ask a data-plane question on the list I get
> little relevant info and Saku is basically the only one whom I may discuss
> these topics with except the vendor folks.
>
> adam
>
>
>
>
>
>
>
>
>
>
>
>         Adam Vitkovsky
>         IP Engineer
>
> T:      0333 006 5936
> E:      Adam.Vitkovsky at gamma.co.uk <javascript:;>
> W:      www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmaster at gamma.co.uk <javascript:;>
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net <javascript:;>
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
Regards,

Mark L. Tees


More information about the juniper-nsp mailing list