[j-nsp] QFX3500 optics lock?
Tim Jackson
jackson.tim at gmail.com
Sat Jan 7 22:53:01 EST 2012
+1
Nobody wants "support" just don't cripple the platform. "Reasons to use
Juniper over Cisco" - 1 if this stays this way, or becomes the norm.
On Jan 7, 2012 9:28 PM, "Julien Goodwin" <jgoodwin at studio442.com.au> wrote:
> On 07/01/12 15:50, Salman Zahid wrote:
> > 2. In terms of 3rd party optics support , we are evaluating the
> support for 3rd party optics . Please continue to check the Juniper
> documentation and talk to your account team for roadmap information .
>
> My ire has cooled considerably since reading this statement yesterday,
> so here's an attempt at a sane response.
>
> Nobody is asking Juniper to *support* third party optics, they never
> have before. All we want is, that like all other Juniper products to
> date (that I'm aware of) that third party optics work, and have feature
> parity.
>
> If you're so worried about latency within a Qfabic making Juniper
> branded (because I'll bet they're not even a special run, let alone
> special model) optics required on the internal side of a fabric is
> annoying, but not all that objectionable. There's also nothing wrong
> with WONTFIXing latency tickets if the path is not 100% Juniper optics,
> much as other issues with third party optics are handled today.
>
> To lock third party optics out you had to *add* code to JunOS, remember
> that.
>
> Even ignoring common optic types (SR, LR, etc) there's still plenty of
> reasons to want third party optics, passive C/DWDM is just the start,
> RAD's [TE][13] SFP modules are another type that Juniper just don't offer.
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list