x
<<   <   Page 19 / 26   >   >>
jerry33 12/4/2012 | 8:17:20 PM
re: Charlotte's Networks, Take 2 Did someone heard lately from dnewman?
Why didn't he answered the questions last day?
Perhaps those were tough one's
skeptic 12/4/2012 | 8:17:20 PM
re: Charlotte's Networks, Take 2 The quote below is from Light Reading's article, back in March, reporting the results of the test. Let's forget about comparisons to the Juniper and Cisco results and zero in on Dave Newman's comment that the market belongs to two vendors for the foreseeable future. Unless Mr. Newman believes that the results of the test are all just "bought" lies from Tolly and Spirent then he has to conclude that there is another core router out there now.
-----------------

There is lots more to being a core router vendor
than just these sorts of tests. Few people have
even seen Charlotte's product, let alone tested
it in a real network. And the beta test sites
I have heard so far are not all that impressive.

Charlotte's has to prove that they can work in a
real network and that they can support the product. Until then, they are still just a startup with a prototype in beta trials.

And beyond that, a startup that failed in the
only public test done where it didn't pay for
the result.

-----------------



As for his recent comment about how every vendor can make significant progress in three months then what happens if you extrapolate Charlotte's rate of improvement from February to May into June through September!!! Seems to me that Charlotte has the momentum in development!
-------------------

No. Its more like they are digging themselves out of the mud and cleaning off. Their first
round of testing was a humiliation. They looked
bad.

As far as your message goes, certain people are
really obsessed with getting an endorsement
of Charlottes by David Newman whatever way they
can. Anyone else notice a pattern of messages
demanding that David Newman make particular
comments in favor of Charlottes.




jerry33 12/4/2012 | 8:17:19 PM
re: Charlotte's Networks, Take 2 ". And the beta test sites
I have heard so far are not all that impressive."
-----------------------------------------------
From whom have you heard that?
Maybe those beta were before fixxing there bugs?

"Charlotte's has to prove that they can work in a
real network and that they can support the product. Until then, they are still just a startup with a prototype in beta trials.

----------------------------------------------
Didn't Juniper started like that? Sure they started like that and may I add that they did a hell of a good job

regards

bluey 12/4/2012 | 8:17:19 PM
re: Charlotte's Networks, Take 2 Either that, or he got sick of responding to a bunch of out-and-out manaical nutjobs who kept harping on the same old points, and who suggested that he enjoyed pulling the wings out of flies. Frankly, I don't blame him.

jerry33 12/4/2012 | 8:17:18 PM
re: Charlotte's Networks, Take 2 If I may add, I wish him health.
And a free little tip: If responding makes him sick just don't do that.

regards
jerry33 12/4/2012 | 8:17:18 PM
re: Charlotte's Networks, Take 2 Thank you for en-lighten me and all thouse respected bunch of out-and-out manaical nutjobs for the exact reasone.thank you,thank you and god bless you brother.But I have a feeling that this isn't the real reason.

regards
silver740i 12/4/2012 | 8:17:12 PM
re: Charlotte's Networks, Take 2 Dear Mr. Skeptic:
>
> Thank you very much for your earlier replies. I read your last comment,
> but I have to admit that you made me completely confused.
>
> First, you said that MPLS and LSP numbers are not important and that its
> software issue.
> Then, you said its the memory space per label on control panel and it has
> nothing to do with CPU or ASICS
> Now, you say that its RSVP that has to do with CPU or ASICS. It looks to
> me now that this is hardware not software problems.
> Lastly, and most important, you doubt David Newman, an expert in this
> field, and you doubt his credibility
>
> Anyway, I realy appreciate all of your replies and comments. I would realy
> like David Newman's opinions on these .
>
> Sincerely,
>
> silver740i
dnewman 12/4/2012 | 8:17:11 PM
re: Charlotte's Networks, Take 2 "> Now, you say that its RSVP that has to do with CPU or ASICS. It looks to
> me now that this is hardware not software problems.
> Lastly, and most important, you doubt David Newman, an expert in this
> field, and you doubt his credibility"

Actually, I think skeptic and I are in lock step on this one. I've been very interested in his/her comments on device internals and their effect on LSP numbers. And thus far I don't disagree with anything he or she has said.

As a rule, we generally don't get into "inside the box" issues, preferring instead to focus on what's externally observable. But from my (admittedly limited) knowledge of MPLS device design issues I'm in agreement with skeptic here.

Regards,
David Newman
brichter 12/4/2012 | 8:17:10 PM
re: Charlotte's Networks, Take 2 what you say , really. is that any tests except for the LR test you made
worth nothing.
I assume everybody in this forum can agree with that.

You need to learn to read. His statement was that he can't verify the results, he can't quantify the results, and he will not endorse the results.
skeptic 12/4/2012 | 8:17:08 PM
re: Charlotte's Networks, Take 2 >
> Thank you very much for your earlier replies. I read your last comment,
> but I have to admit that you made me completely confused.
>
> First, you said that MPLS and LSP numbers are not important and that its
> software issue.

1. The LSP capacity numbers measured by the
light reading test for all vendors are low.
All the vendors are capable of higher numbers
in that area.

2. Ultimatly, the LSP capacity number will be
proportional to the memory in the system for
holding the RSVP state.

3. Compared IP routing, the space used for packet
forwarding LSP tables (in the ASICS) is small.
A vendor might design an ASIC that only allowed
small tables, but it doesn't seem likely to me
that they would.

4. In the early days of MPLS, there was a problem
with the per-LSP overhead of RSVP. That problem has been fixed for a while by a change to the
RSVP standard. Its difficult to tell if the
software for any particular vendor supports that
change or not. But without that change, the CPU
overhead of a large number of LSPs will be quite
high. I would expect that most vendors now
operate with that change and once that change
is made, CPU overhead of a large number of LSPs
is a far smaller problem.

5. I have disagreements outstanding with David
Newman about his methodlogy, how certain results
were presented and a whole set of other issues.

6. Testing or evaluating MPLS software is very
difficult at present. Its also difficult to
know how to compare implementations or to know
which one is best. LSP capacity is not what
people should be using to choose the best MPLS
implementation (in my opinion). There are no
easy answers or quick tests to say which MPLS
is best.





<<   <   Page 19 / 26   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE