[j-nsp] Separate internet transit network versus converged

[Jesper Skriver]

On Tue, Mar 29, 2016 at 03:46:07PM +0300, Saku Ytti wrote:
> On 29 March 2016 at 15:05, chip <chip.gwyn at gmail.com> wrote:
> > Juniper has a "This Week" book freely available that discussess, in detail,
> > the path of a packet through an MX.  It's quite an informative read.
> >
> > http://www.juniper.net/us/en/training/jnbooks/day-one/networking-technologies-series/packet-walkthrough-mx-series/
> 
> I love that 'few milliseconds', only 3 orders of magnitude off.
> 
> > This Week: An Expert Packet Walkthrough on the MX Series 3D provides the
> > curious engineer with a global view of the short life (a few milliseconds)
> > of packets inside the Juniper Networks MX Series of 3D routers.
> 
> Technically not JNPR book, but reverse engineered by JNPR customer,
> which is bit of ironic that we have to do that. There is great
> internal Trio document (now dated) by Steven Wong. But it is really
> really good for external customers too. Who knows what gems they have
> I don't have any idea, which would have helped me avoid downtime or
> bad design choices.
> I would put in all future RFQ/RFP requirement for internal-level
> architecture documentation, since getting these otherwise is super
> hard. I don't understand why vendors don't publish these.

Almost certainly such documents would contain 'secret sauce' that
the vendor does not want to disclose to competitors.

> Mentioned
> document has helped me countless time, to choose design which least
> exposes platforms compromises, to troubleshoot issue without bothering
> JTAC or helped me give JTAC precise troubleshooting information
> potentially cutting weeks of solution time and downtime of repeated
> problems.

As alluded to in this thread, the number of customers who invest
such effort can be counted on a very small number of hands, and I
doubt vendors will see sufficient business benefit in disclosing
the information you describe.

> Lot of the good instrumentation is not exposed to end-users at all,
> like packet-via-dmem or capturing exception packets (you're getting
> CRC errors from IXP, which neighbour is to blame?, you're getting IP
> checksum errors from MPLS core, who is mangling them?). Traditionally
> very hard to answer questions become trivial with supplied
> instrumentation.

Debugging tools, sure disclose all those - but that is very
different than what you are asking for.

/Jesper