Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On 17/Nov/15 13:00, Tom Marcoen wrote:

> Mark
>
> That is a valid point but the company I work for already only uses Cisco for 
> its routing/switching devices. So it's also a non-issue.

Fair enough, then.

The other point, for me, is making sure easy ring topologies you would
build on the ME3600X/ASR920 using IP/MPLS can be replicated using
satellites. There will be a temptation not to build satellites as
point-to-point, but rather, as rings, and you don't want to find
yourself caught out.

Make sure you test and verify your ultimate Access topology before you
buy, as satellites do not typically run IP/MPLS.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Tom Marcoen]

We're currently also using ASR9010 as core routers with ME3600X as the access 
"switches" but are now looking at replacing the ME3600X with ASR9000v extension 
shelfs. Does anyone have any experience with this setup?

At first side it looks nice and (a bit) cheaper but I noticed the ASR9000v 
comes with 11-port increment licenses and does not have a redundant power 
supply. This last issue is show-stopper for us.

Anyway, I would like to hear your views on the matter.

Best regards
Tom

2013/7/25 Mattias Gyllenvarg 

> Good point, SDM is just another gotcha. Allocate according to use and
> complain in the log when your getting close to max.
>
> ME3600x + ASR9k FTW! Just make more physical variants of the ME and lower
> the price on ASR9k.
>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On 17/Nov/15 12:49, Tom Marcoen wrote:

> We're currently also using ASR9010 as core routers with ME3600X as the access 
> "switches" but are now looking at replacing the ME3600X with ASR9000v 
> extension shelfs. Does anyone have any experience with this setup?
>
> At first side it looks nice and (a bit) cheaper but I noticed the ASR9000v 
> comes with 11-port increment licenses and does not have a redundant power 
> supply. This last issue is show-stopper for us.
>
> Anyway, I would like to hear your views on the matter.

Satellites lock you into vendor gear.

Primary reason I stay away from satellites.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Tom Marcoen]

Mark

That is a valid point but the company I work for already only uses Cisco for 
its routing/switching devices. So it's also a non-issue.

Tom

-Original Message-
From: Mark Tinka [mailto:mark.ti...@seacom.mu] 
Sent: Tuesday, November 17, 2015 11:56
To: Tom Marcoen; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment 
Simplification Feedback



On 17/Nov/15 12:49, Tom Marcoen wrote:

> We're currently also using ASR9010 as core routers with ME3600X as the access 
> "switches" but are now looking at replacing the ME3600X with ASR9000v 
> extension shelfs. Does anyone have any experience with this setup?
>
> At first side it looks nice and (a bit) cheaper but I noticed the ASR9000v 
> comes with 11-port increment licenses and does not have a redundant power 
> supply. This last issue is show-stopper for us.
>
> Anyway, I would like to hear your views on the matter.

Satellites lock you into vendor gear.

Primary reason I stay away from satellites.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mattias Gyllenvarg]

Even not considering vendor-lock you will have less options from said
supplier if you expect to use this as a universal solution.

The ASR920 series has many variants, I am capitalizing on this for our
topology.

There will always, I find, be the Odd ball requirement that makes these
kind of things impossible. Staying flexible is always a good approach.

tis 17 nov. 2015 kl 12:06 skrev Mark Tinka :

>
>
> On 17/Nov/15 13:00, Tom Marcoen wrote:
>
> > Mark
> >
> > That is a valid point but the company I work for already only uses Cisco
> for its routing/switching devices. So it's also a non-issue.
>
> Fair enough, then.
>
> The other point, for me, is making sure easy ring topologies you would
> build on the ME3600X/ASR920 using IP/MPLS can be replicated using
> satellites. There will be a temptation not to build satellites as
> point-to-point, but rather, as rings, and you don't want to find
> yourself caught out.
>
> Make sure you test and verify your ultimate Access topology before you
> buy, as satellites do not typically run IP/MPLS.
>
> Mark.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Tom Hill]

On 17/11/15 11:05, Mark Tinka wrote:
> The other point, for me, is making sure easy ring topologies you would
> build on the ME3600X/ASR920 using IP/MPLS can be replicated using
> satellites. There will be a temptation not to build satellites as
> point-to-point, but rather, as rings, and you don't want to find
> yourself caught out.

This is where satellites fall down for me, also. You're dealing with a
remote line card, rather than an access "network".

Regardless of the cost implications of running your nV uplinks around in
a diverse metro ring (euw?) you're still only going to gain uplink
resilience via ASR9k clustering... And unless ASR9k clustering has some
magic that I'm missing, systemic failures (or configuration cock-ups) of
the entire cluster, are not something I want to have to worry about.

-- 
Tom
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Friday, July 26, 2013 04:08:15 PM sth...@nethelp.no 
wrote:

 Amen. Number of 1G ports, number of 10G ports,
 stackability: Cisco has a pretty significant hole in
 their metro portfolio there. Chassis based 6500/7600 is
 *not* the answer.

Cisco are certainly a step ahead of Juniper (Brocade are 
pretty okay), but there always is room for improvement.

The problem with scaling up within the PoP ultimately means 
a new chassis. Be it a non-modular chassis or stackability 
(where front 10Gbps ports aren't used). But, we need it 
nonetheless.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Adam Vitkovsky]

  However, in order to turn on 250 MDT routes, 
 we have to drop the IPv4 routes down to 12,000. 

 A reasonable use-case for a larger FIB in this platform family :-). 

We've gone through the same disappointment so I'm waiting for the
mLDP/NG-MVPN support. 
Yes however the bigger FIB would be much appreciated. 

Regarding the lack of 10GigE ports + 1GigE ports density, my first question
when I saw this platform was: Is it stackable? 
It would be great if the new version of X(CX) is stackable. 
Yes so far we use 2x CX to redundantly connect a 10GE ring to the city POP. 
However we don't really need CES everywhere so stacking two X-es together
would be a better solution with a lot more GigE ports. 


adam


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[sthaug]

 Regarding the lack of 10GigE ports + 1GigE ports density, my first question
 when I saw this platform was: Is it stackable? 
 It would be great if the new version of X(CX) is stackable. 
 Yes so far we use 2x CX to redundantly connect a 10GE ring to the city POP. 
 However we don't really need CES everywhere so stacking two X-es together
 would be a better solution with a lot more GigE ports. 

Amen. Number of 1G ports, number of 10G ports, stackability: Cisco has
a pretty significant hole in their metro portfolio there. Chassis
based 6500/7600 is *not* the answer.

Steinar Haug, AS 2116
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Leigh Harrison]

Hi there Waris,

We've got quite a few of the ME3600's deployed now, which we migrated to over 
and above a legacy 3750ME estate.  The big point for us was to migrate to MPLS 
access rather than have any spanning tree knocking about in the Core.

Favoured points from my team involves the ease of configuration and their raw 
speed.  Down sides are port capacity and buggy software.  

A denser system of 48 Gig ports and more 10Gb ports would assist greatly as we 
can fill up 24 1Gb ports quite quickly depending on which PoP the system has 
been built for.  We tend to ring the 3600's into ASR9K's and the more rings we 
buy, the more 9K 10Gb ports have to be taken up.  Additional 10Gb ports would 
be of great benefit to increase the capacity of each ring we build, rather than 
build new rings.  Our provider connections are also moving from 1Gb up to 10Gb 
and I need to be able to cater for this towards the Access, rather than the 
Core.

I would also like to see more horsepower in the systems.  We recently went to 
implement multicasting in VRF and ran into some odd challenges.   We have the 
3600's set up for routing and are about to push 24,000 IPv4 routes.   In our 
busier boxes we have around 9,000 routes, so I'm more than happy with the 
capacity there.  However, in order to turn on 250 MDT routes, we have to drop 
the IPv4 routes down to 12,000.  A sliding scale would be nice for memory 
allocation, but in the face of having 3600's move from 30% full to 60% full in 
the routing table to add in a new feature, we went for a redesign of how we 
delivered the multicasting.

Leigh


 Hi Everyone,
 I have seen lot of good inputs on this mailer. I am collecting 
 feedback for the existing deployment challenges on the following 
 platforms so that we can address them.
 
 -ME3800X
 -ME3600X
 -ME3600X-24CX
 -ASR903
 -ASR901
 -ME3400E

__
This email has been scanned by the Symantec Email Security Cloud System, 
Managed and Supported by TekNet Solutions (http://www.teknet.co.uk)
__

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mattias Gyllenvarg]

Good point, SDM is just another gotcha. Allocate according to use and
complain in the log when your getting close to max.

ME3600x + ASR9k FTW! Just make more physical variants of the ME and lower
the price on ASR9k.


On Thu, Jul 25, 2013 at 12:56 PM, Leigh Harrison 
lharri...@convergencegroup.co.uk wrote:

 Hi there Waris,

 We've got quite a few of the ME3600's deployed now, which we migrated to
 over and above a legacy 3750ME estate.  The big point for us was to migrate
 to MPLS access rather than have any spanning tree knocking about in the
 Core.

 Favoured points from my team involves the ease of configuration and their
 raw speed.  Down sides are port capacity and buggy software.

 A denser system of 48 Gig ports and more 10Gb ports would assist greatly
 as we can fill up 24 1Gb ports quite quickly depending on which PoP the
 system has been built for.  We tend to ring the 3600's into ASR9K's and the
 more rings we buy, the more 9K 10Gb ports have to be taken up.  Additional
 10Gb ports would be of great benefit to increase the capacity of each ring
 we build, rather than build new rings.  Our provider connections are also
 moving from 1Gb up to 10Gb and I need to be able to cater for this towards
 the Access, rather than the Core.

 I would also like to see more horsepower in the systems.  We recently went
 to implement multicasting in VRF and ran into some odd challenges.   We
 have the 3600's set up for routing and are about to push 24,000 IPv4
 routes.   In our busier boxes we have around 9,000 routes, so I'm more than
 happy with the capacity there.  However, in order to turn on 250 MDT
 routes, we have to drop the IPv4 routes down to 12,000.  A sliding scale
 would be nice for memory allocation, but in the face of having 3600's move
 from 30% full to 60% full in the routing table to add in a new feature, we
 went for a redesign of how we delivered the multicasting.

 Leigh


  Hi Everyone,
  I have seen lot of good inputs on this mailer. I am collecting
  feedback for the existing deployment challenges on the following
  platforms so that we can address them.
 
  -ME3800X
  -ME3600X
  -ME3600X-24CX
  -ASR903
  -ASR901
  -ME3400E

 __
 This email has been scanned by the Symantec Email Security Cloud System,
 Managed and Supported by TekNet Solutions (http://www.teknet.co.uk)
 __

 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/




-- 
*Med Vänliga Hälsningar*
*Mattias Gyllenvarg*
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[natacha lebaron]

+1 on last comment


2013/7/25 Mattias Gyllenvarg matt...@gyllenvarg.se

 Good point, SDM is just another gotcha. Allocate according to use and
 complain in the log when your getting close to max.

 ME3600x + ASR9k FTW! Just make more physical variants of the ME and lower
 the price on ASR9k.


 On Thu, Jul 25, 2013 at 12:56 PM, Leigh Harrison 
 lharri...@convergencegroup.co.uk wrote:

  Hi there Waris,
 
  We've got quite a few of the ME3600's deployed now, which we migrated to
  over and above a legacy 3750ME estate.  The big point for us was to
 migrate
  to MPLS access rather than have any spanning tree knocking about in the
  Core.
 
  Favoured points from my team involves the ease of configuration and their
  raw speed.  Down sides are port capacity and buggy software.
 
  A denser system of 48 Gig ports and more 10Gb ports would assist greatly
  as we can fill up 24 1Gb ports quite quickly depending on which PoP the
  system has been built for.  We tend to ring the 3600's into ASR9K's and
 the
  more rings we buy, the more 9K 10Gb ports have to be taken up.
  Additional
  10Gb ports would be of great benefit to increase the capacity of each
 ring
  we build, rather than build new rings.  Our provider connections are also
  moving from 1Gb up to 10Gb and I need to be able to cater for this
 towards
  the Access, rather than the Core.
 
  I would also like to see more horsepower in the systems.  We recently
 went
  to implement multicasting in VRF and ran into some odd challenges.   We
  have the 3600's set up for routing and are about to push 24,000 IPv4
  routes.   In our busier boxes we have around 9,000 routes, so I'm more
 than
  happy with the capacity there.  However, in order to turn on 250 MDT
  routes, we have to drop the IPv4 routes down to 12,000.  A sliding scale
  would be nice for memory allocation, but in the face of having 3600's
 move
  from 30% full to 60% full in the routing table to add in a new feature,
 we
  went for a redesign of how we delivered the multicasting.
 
  Leigh
 
 
   Hi Everyone,
   I have seen lot of good inputs on this mailer. I am collecting
   feedback for the existing deployment challenges on the following
   platforms so that we can address them.
  
   -ME3800X
   -ME3600X
   -ME3600X-24CX
   -ASR903
   -ASR901
   -ME3400E
 
  __
  This email has been scanned by the Symantec Email Security Cloud System,
  Managed and Supported by TekNet Solutions (http://www.teknet.co.uk)
  __
 
  ___
  cisco-nsp mailing list  cisco-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-nsp
  archive at http://puck.nether.net/pipermail/cisco-nsp/
 



 --
 *Med Vänliga Hälsningar*
 *Mattias Gyllenvarg*
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Thursday, July 25, 2013 12:56:52 PM Leigh Harrison wrote:

 I would also like to see more horsepower in the systems. 
 We recently went to implement multicasting in VRF and
 ran into some odd challenges.   We have the 3600's set
 up for routing and are about to push 24,000 IPv4 routes.
   In our busier boxes we have around 9,000 routes, so
 I'm more than happy with the capacity there.  However,
 in order to turn on 250 MDT routes, we have to drop the
 IPv4 routes down to 12,000.  A sliding scale would be
 nice for memory allocation, but in the face of having
 3600's move from 30% full to 60% full in the routing
 table to add in a new feature, we went for a redesign of
 how we delivered the multicasting.

A reasonable use-case for a larger FIB in this platform 
family :-).

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Stephen Fulton]

I'll add my +1 to Mark's suggestions, and request more 10GE ports. 
We're receiving more requests for 10GE (mostly sub-rate, some line-rate) 
from our customers and offers from our carrier suppliers for the same. 
The 3600X-24CX fits part of that bill, but I'd really prefer something 
with more than 8GE ports when the four 10GE ports are activated.


-- Stephen


On 21/07/2013 5:29 PM, Waris Sagheer (waris) wrote:

Hi Mark,
Thanks for all the feedback.
Couple of questions and clarification,
- 48 gig port switch requirement, I suppose you also need 4x10Gig uplink along 
with 48 Gig port, correct?
- Per pop growth, I'll get get back to you with a solution to seek your feedback
- Can you give me an idea in terms of number of FIB entries requirement?
- Can you elaborate your comment (particularly coming as close to the flexibility 
of what software routers like the 7200 can do)? Any 7200 example functionality.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group
wa...@cisco.commailto:wa...@cisco.com
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901


http://www.cisco.com/



[Think before you print.] Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: mark.ti...@seacom.mumailto:mark.ti...@seacom.mu 
mark.ti...@seacom.mumailto:mark.ti...@seacom.mu
Organization: SEACOM
Reply-To: mark.ti...@seacom.mumailto:mark.ti...@seacom.mu 
mark.ti...@seacom.mumailto:mark.ti...@seacom.mu
Date: Saturday, July 20, 2013 10:34 PM
To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net 
cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
Cc: Waris Sagheer wa...@cisco.commailto:wa...@cisco.com
Subject: Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment 
Simplification Feedback

On Tuesday, March 19, 2013 09:27:45 AM Waris Sagheer (waris)
wrote:

Hi Everyone,
I have seen lot of good inputs on this mailer. I am
collecting feedback for the existing deployment
challenges on the following platforms so that we can
address them.
-ME3800X
-ME3600X
-ME3600X-24CX
-ASR903
-ASR901
-ME3400E

- I would like to see a variant of the ME3600X/3800X
   that provides for at least 4x 10Gbps SFP+ uplink
   ports.

- I would like to see a variant of the ME3600X/3800X
   that provided for 48x Gig-E copper or fibre ports
   in a 1U chassis (I'll also take a 1.5U chassis if
   times are really hard). Yes, all at line rate :-).

- I would like to see a solution that allows for PoP
   growth. We've had scenarios where the number of
   ME3600X/3800X chassis has grown to a level to
   justify looking at a chassis (ASR9000 or
   MX480/960), but the line card costs alone still
   make stacking yet another ME3600X/3800X a
   commercially better idea, but lousy for
   operations. What can the team do to allow
   operators to grow ports and scale on a per-PoP
   basis while simplifying operations and keeping
   port costs down? I've never been drawn to
   virtual/multi-chassis systems, but... :-).

- I'm not very heavy on growing the FIB on the
   ME3600X/3800X systems, but any thought Cisco can
   put into this that doesn't make the cost of
   building the units outrageous would be much
   appreciated. This isn't critical for me; just a
   very nice-to-have.

In addition to what Nick and the others have already
mentioned, those are the things I'd like to see addressed,
Waris.

For me, one of the things that pleases me most about the
ME3600X/3800X (apart from the fact that we can drop STP and
extend IP/MPLS into the Access) is that QoS is normal,
simple and behaves like a regular Cisco router. Additional
work and simplification in this area (particularly coming as
close to the flexibility of what software routers like the
7200 can do) would be much appreciated. You have no idea how
much it sucked running the 3750ME as a Metro-E IP/MPLS
Access platform and trying to do simple or complex QoS
strategies for customers and the core :-).

Many thanks for reaching out to the community about this,
Waris. It makes all the difference for us operators, and is
more of what we would like to see from our preferred
vendors.

Cheers,

Mark.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Sunday, July 21, 2013 11:29:01 PM Waris Sagheer (waris) 
wrote:

 Hi Mark,

Hello Waris.

 - 48 gig port switch requirement, I suppose you also need
 4x10Gig uplink along with 48 Gig port, correct?

Yes, we'd need at least 4x 10Gbps uplink SPF+ ports for a 
switch that came with 48x Gig-E ports. Of course, the 
assumption is that you could only uplink 40Gbps, but 
assuming all ports can run at line rate, that should not 
limit local switching between Gig-E ports if customers are 
communicating with one another via the same switch.

 - Per
 pop growth, I'll get get back to you with a solution to
 seek your feedback

Many thanks, Waris.

 - Can you give me an idea in terms of
 number of FIB entries requirement?

I think a compromise between cost of the switch vs. where 
the world is going re: IPv4 and IPv6 table growth, I'd be 
happy if Cisco can support 1,000,000 FIB entries (whether 
IPv4, IPv6 or MPLS) in newer hardware provided it doesn't 
break the bank. I think anything more than that and this 
product line quickly begins to lose its appeal as an Access 
IP/MPLS router with high port density, since it will start 
to cost more and we're back to square one.

But like I said, this is not such a real issues for me, 
personally, as this switch line has more important things to 
do like remove STP from the Access rings :-). So even if you 
were to bump current FIB slots by just even double, I'm sure 
someone out there would be happy.

 - Can you elaborate
 your comment (particularly coming as close to the
 flexibility of what software routers like the 7200 can
 do)? Any 7200 example functionality.

I was referring to MQC, and how on software routers, it can 
really do anything you want.

On hardware-based platforms, you find certain QoS features 
aren't supported, e.g., when the ME3600X/3800X first 
shipped, there were restrictions on QoS match conditions 
(match-any vs. match-all), queue depth limitations, how 
interface bandwidth %'s were allocated in QoS policy maps, 
e.t.c. Of course, since these QoS configurations get 
programmed into hardware, there is little margin for 
flexibility than when compared to a software-based router; 
so what I mean is, wherever possible, making QoS on the 
ME3600X/3800X as flexible as we have it on the software-
based routers, assuming the hardware can do it without 
adverse side effects on another functionality of the switch.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Monday, July 22, 2013 04:23:31 AM Stephen Fulton wrote:

 I'll add my +1 to Mark's suggestions, and request more
 10GE ports. We're receiving more requests for 10GE
 (mostly sub-rate, some line-rate) from our customers and
 offers from our carrier suppliers for the same. The
 3600X-24CX fits part of that bill, but I'd really prefer
 something with more than 8GE ports when the four 10GE
 ports are activated.

Stephen, as we wait to hear from Waris on this, I have 
considered having a version of my proposed fixed 
ME3600X/3800X chassis that provides for several SFP+-based 
10Gbps ports for such customers.

However, I'm not sure how cheaply Cisco would be able to 
make this while still keeping the spirit of the product line 
re: making the Access simpler with IP/MPLS rather than STP.

Given that it is actually more expensive for MPLS networks, 
today, to transport 10Gbps-based EoMPLS pw's across the 
core, until 100Gbps is more mainstream, I think customers 
will continue to just bypass the MPLS network and plug 
straight into the DWDM backbone and/or purchase dark fibre 
if they need 10Gbps point-to-point links.

Like we're seeing for Gig-E, we shall see customers move 
their 10Gbps links off DWDM/dark fibre and into the MPLS 
network when the core is running at much higher rates than 
the Access network, i.e., 100Gbps or more.

As such, the majority of 10Gbps links we may keep seeing for 
a while are IP Transit ones, in which case boxes like the 
ASR9000 and MX480/960 will continue to make better sense 
here than a fixed ME3600X/3800X chassis.

Just my thoughts, I could be way off :-)...

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mattias Gyllenvarg]

+1 and I add a me3600x chassie to the mix of wet dreams.
On 21 Jul 2013 08:01, Mark Tinka mark.ti...@seacom.mu wrote:

 On Tuesday, March 19, 2013 09:27:45 AM Waris Sagheer (waris)
 wrote:

  Hi Everyone,
  I have seen lot of good inputs on this mailer. I am
  collecting feedback for the existing deployment
  challenges on the following platforms so that we can
  address them.
 
  -ME3800X
  -ME3600X
  -ME3600X-24CX
  -ASR903
  -ASR901
  -ME3400E

 - I would like to see a variant of the ME3600X/3800X
   that provides for at least 4x 10Gbps SFP+ uplink
   ports.

 - I would like to see a variant of the ME3600X/3800X
   that provided for 48x Gig-E copper or fibre ports
   in a 1U chassis (I'll also take a 1.5U chassis if
   times are really hard). Yes, all at line rate :-).

 - I would like to see a solution that allows for PoP
   growth. We've had scenarios where the number of
   ME3600X/3800X chassis has grown to a level to
   justify looking at a chassis (ASR9000 or
   MX480/960), but the line card costs alone still
   make stacking yet another ME3600X/3800X a
   commercially better idea, but lousy for
   operations. What can the team do to allow
   operators to grow ports and scale on a per-PoP
   basis while simplifying operations and keeping
   port costs down? I've never been drawn to
   virtual/multi-chassis systems, but... :-).

 - I'm not very heavy on growing the FIB on the
   ME3600X/3800X systems, but any thought Cisco can
   put into this that doesn't make the cost of
   building the units outrageous would be much
   appreciated. This isn't critical for me; just a
   very nice-to-have.

 In addition to what Nick and the others have already
 mentioned, those are the things I'd like to see addressed,
 Waris.

 For me, one of the things that pleases me most about the
 ME3600X/3800X (apart from the fact that we can drop STP and
 extend IP/MPLS into the Access) is that QoS is normal,
 simple and behaves like a regular Cisco router. Additional
 work and simplification in this area (particularly coming as
 close to the flexibility of what software routers like the
 7200 can do) would be much appreciated. You have no idea how
 much it sucked running the 3750ME as a Metro-E IP/MPLS
 Access platform and trying to do simple or complex QoS
 strategies for customers and the core :-).

 Many thanks for reaching out to the community about this,
 Waris. It makes all the difference for us operators, and is
 more of what we would like to see from our preferred
 vendors.

 Cheers,

 Mark.

 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Sunday, July 21, 2013 09:14:18 AM Mattias Gyllenvarg 
wrote:

 +1 and I add a me3600x chassie to the mix of wet dreams.

To be honest, I'm not sure an ME3600X/3800X chassis (a la 
6500/7600/ASR9000) would be possible for a couple of 
reasons:

- Internal conflicts within Cisco, where such a
  chassis could cause issues with the ASR1013 team,
  the ASR9006/9010 team, 6500/7600 teams, e.t.c.

- If they make it a typical chassis with line cards
  and or SIP carrier cards, it may work out to be as
  pricey as the mainstream chassis' anyway.

Possible compromise, I wouldn't mind a big ME3600X/3800X 
chassis with fixed ports/slots. So instead of having 
removable line cards or carrier cards, it comes in various 
rack units (6U, 12U, 21U, e.t.c.), filled full of ports. 

Cisco could consider having a fibre-only and copper-only 
variant, but my guess is any operator would likely take the 
fibre-only chassis since they can deploy SFP-T copper-based 
optics to support copper links.

I'm hoping making it a fixed (non-modular) chassis full of 
Gig-E (and a few 10-Gig-E) ports should make it cheaper than 
having a modularized chassis, and also keep other BU's 
within Cisco at bay.

They could even keep things simple by having centralized 
forwarding and integrated control planes (although if the 
RAM on the control planes can be upgraded with regular RAM, 
that would be a huge plus).

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Aled Morris]

On 21 July 2013 15:47, Mark Tinka mark.ti...@seacom.mu wrote:


 I'm hoping making it a fixed (non-modular) chassis full of
 Gig-E (and a few 10-Gig-E) ports should make it cheaper than
 having a modularized chassis, and also keep other BU's
 within Cisco at bay.


Maybe an ME version of the 4500-X would be cool.

Aled
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Sunday, July 21, 2013 04:55:16 PM Aled Morris wrote:

 Maybe an ME version of the 4500-X would be cool.

The multi-rate nature of the 4500-X Ethernet ports would 
make a corresponding chassis-based ME3600X/3800X pricey, I 
presume.

I'd be happy with a Gig-E-only ME3600X/3800X chassis 
(provided we have enough 10Gbps SPF+ uplinks to handle 
them), but of course, if Cisco can make a multi-rate system 
that is cheaper than stacking 1U systems or the ASR9000, I'm 
game :-).

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Waris Sagheer (waris)]

Hi Mark,
Thanks for all the feedback.
Couple of questions and clarification,
- 48 gig port switch requirement, I suppose you also need 4x10Gig uplink along 
with 48 Gig port, correct?
- Per pop growth, I'll get get back to you with a solution to seek your feedback
- Can you give me an idea in terms of number of FIB entries requirement?
- Can you elaborate your comment (particularly coming as close to the 
flexibility of what software routers like the 7200 can do)? Any 7200 example 
functionality.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group
wa...@cisco.commailto:wa...@cisco.com
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901


http://www.cisco.com/



[Think before you print.] Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: mark.ti...@seacom.mumailto:mark.ti...@seacom.mu 
mark.ti...@seacom.mumailto:mark.ti...@seacom.mu
Organization: SEACOM
Reply-To: mark.ti...@seacom.mumailto:mark.ti...@seacom.mu 
mark.ti...@seacom.mumailto:mark.ti...@seacom.mu
Date: Saturday, July 20, 2013 10:34 PM
To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net 
cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
Cc: Waris Sagheer wa...@cisco.commailto:wa...@cisco.com
Subject: Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment 
Simplification Feedback

On Tuesday, March 19, 2013 09:27:45 AM Waris Sagheer (waris)
wrote:

Hi Everyone,
I have seen lot of good inputs on this mailer. I am
collecting feedback for the existing deployment
challenges on the following platforms so that we can
address them.
-ME3800X
-ME3600X
-ME3600X-24CX
-ASR903
-ASR901
-ME3400E

- I would like to see a variant of the ME3600X/3800X
  that provides for at least 4x 10Gbps SFP+ uplink
  ports.

- I would like to see a variant of the ME3600X/3800X
  that provided for 48x Gig-E copper or fibre ports
  in a 1U chassis (I'll also take a 1.5U chassis if
  times are really hard). Yes, all at line rate :-).

- I would like to see a solution that allows for PoP
  growth. We've had scenarios where the number of
  ME3600X/3800X chassis has grown to a level to
  justify looking at a chassis (ASR9000 or
  MX480/960), but the line card costs alone still
  make stacking yet another ME3600X/3800X a
  commercially better idea, but lousy for
  operations. What can the team do to allow
  operators to grow ports and scale on a per-PoP
  basis while simplifying operations and keeping
  port costs down? I've never been drawn to
  virtual/multi-chassis systems, but... :-).

- I'm not very heavy on growing the FIB on the
  ME3600X/3800X systems, but any thought Cisco can
  put into this that doesn't make the cost of
  building the units outrageous would be much
  appreciated. This isn't critical for me; just a
  very nice-to-have.

In addition to what Nick and the others have already
mentioned, those are the things I'd like to see addressed,
Waris.

For me, one of the things that pleases me most about the
ME3600X/3800X (apart from the fact that we can drop STP and
extend IP/MPLS into the Access) is that QoS is normal,
simple and behaves like a regular Cisco router. Additional
work and simplification in this area (particularly coming as
close to the flexibility of what software routers like the
7200 can do) would be much appreciated. You have no idea how
much it sucked running the 3750ME as a Metro-E IP/MPLS
Access platform and trying to do simple or complex QoS
strategies for customers and the core :-).

Many thanks for reaching out to the community about this,
Waris. It makes all the difference for us operators, and is
more of what we would like to see from our preferred
vendors.

Cheers,

Mark.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Mark Tinka]

On Tuesday, March 19, 2013 09:27:45 AM Waris Sagheer (waris) 
wrote:

 Hi Everyone,
 I have seen lot of good inputs on this mailer. I am
 collecting feedback for the existing deployment
 challenges on the following platforms so that we can
 address them.
 
 -ME3800X
 -ME3600X
 -ME3600X-24CX
 -ASR903
 -ASR901
 -ME3400E

- I would like to see a variant of the ME3600X/3800X
  that provides for at least 4x 10Gbps SFP+ uplink
  ports.

- I would like to see a variant of the ME3600X/3800X
  that provided for 48x Gig-E copper or fibre ports
  in a 1U chassis (I'll also take a 1.5U chassis if
  times are really hard). Yes, all at line rate :-).

- I would like to see a solution that allows for PoP
  growth. We've had scenarios where the number of
  ME3600X/3800X chassis has grown to a level to
  justify looking at a chassis (ASR9000 or
  MX480/960), but the line card costs alone still
  make stacking yet another ME3600X/3800X a
  commercially better idea, but lousy for
  operations. What can the team do to allow
  operators to grow ports and scale on a per-PoP
  basis while simplifying operations and keeping
  port costs down? I've never been drawn to
  virtual/multi-chassis systems, but... :-).

- I'm not very heavy on growing the FIB on the
  ME3600X/3800X systems, but any thought Cisco can
  put into this that doesn't make the cost of
  building the units outrageous would be much
  appreciated. This isn't critical for me; just a
  very nice-to-have.

In addition to what Nick and the others have already 
mentioned, those are the things I'd like to see addressed, 
Waris.

For me, one of the things that pleases me most about the 
ME3600X/3800X (apart from the fact that we can drop STP and 
extend IP/MPLS into the Access) is that QoS is normal, 
simple and behaves like a regular Cisco router. Additional 
work and simplification in this area (particularly coming as 
close to the flexibility of what software routers like the 
7200 can do) would be much appreciated. You have no idea how 
much it sucked running the 3750ME as a Metro-E IP/MPLS 
Access platform and trying to do simple or complex QoS 
strategies for customers and the core :-).

Many thanks for reaching out to the community about this, 
Waris. It makes all the difference for us operators, and is 
more of what we would like to see from our preferred 
vendors.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Waris Sagheer (waris)]

Hi Everyone,
I have seen lot of good inputs on this mailer. I am collecting feedback for the 
existing deployment challenges on the following platforms so that we can 
address them.

-ME3800X
-ME3600X
-ME3600X-24CX
-ASR903
-ASR901
-ME3400E


  *   What can Cisco do to simplify the deployment of the above products? Any 
inputs?
  *   Does configuration guide cover all the features?
  *   What additional information should be added to the CCO product documents? 
Do you want to see more whitepapers? If yes, topics?
  *   Do you want to see Product Design Guide covering Platform best practices? 
Solution based example configuration?
  *   Do you think Video documentation would help?
  *   Do you think Video feature demos would be  helpful?
  *   What are the operational challenges faced by the customer when deploying  
these platforms?
  *   Do you want to see End to End Carrier Ethernet and Mobile Backhaul 
solution documents?
  *   How are you using ME3800X/ME3600X/ME3600-24CX in your network?
  *   How are you using ASR903 in your network?
  *   How are you using ASR901  in your deployment?
  *   Any critical feature gaps? Please indicate the deployment scenario along 
with the feature ask.

I would appreciate if you can unicast me the feedback. Thanks in advance.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Senior Technical Marketing Manager
Service Provider Access Group
wa...@cisco.commailto:wa...@cisco.com
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901


http://www.cisco.com/



[Think before you print.] Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Nick Hilliard]

On 19/03/2013 07:27, Waris Sagheer (waris) wrote:
   *   What can Cisco do to simplify the deployment of the above products? Any 
 inputs?

the CLI that was designed for interface label (e.g. mpls and .1q)
management is hard.  In particular, it takes some effort to work out what
labels are pushed and popped in what order.

Sensible deployment templates for service providers would be good.  E.g.
disabling proxy arp, setting up good bgp/ospf/isis defaults,

   *   Does configuration guide cover all the features?
   *   What additional information should be added to the CCO product 
 documents? Do you want to see more whitepapers? If yes, topics?
   *   Do you want to see Product Design Guide covering Platform best 
 practices? Solution based example configuration?

yes, very much so, e.g.:

- integration with other platforms (XR in particular) would be very helpful
and there is currently not much of this.  Many of us operate networks with
both xr and ios, and the semantics are often different.

- internal architecture design like Cisco publishes for e.g. the ASR9000
product line.

- VRF solutions guides

- worked-through qos examples

- worked-through copp examples

   *   Do you think Video documentation would help?
   *   Do you think Video feature demos would be  helpful?

no.  you can't grep mpegs.

   *   What are the operational challenges faced by the customer when 
 deploying  these platforms?

integration with other types of kit, both from cisco and other vendors.

   *   Do you want to see End to End Carrier Ethernet and Mobile Backhaul 
 solution documents?
   *   How are you using ME3800X/ME3600X/ME3600-24CX in your network?

collapsed p/pe.

   *   How are you using ASR903 in your network?
   *   How are you using ASR901  in your deployment?
   *   Any critical feature gaps? Please indicate the deployment scenario 
 along with the feature ask.

urpf.  this is really hurting for PE stuff.

Nick


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[David Farrell]

On 19/03/13 12:16, Nick Hilliard wrote:

Waris,


I would 2nd Nick on these points;


*   Do you want to see Product Design Guide covering Platform best practices? 
Solution based example configuration?
yes, very much so, e.g.:

- internal architecture design like Cisco publishes for e.g. the ASR9000
product line.

- VRF solutions guides

- worked-through qos examples

- worked-through copp examples

   *   Do you think Video documentation would help?
   *   Do you think Video feature demos would be  helpful?

no.  you can't grep mpegs.


   *   How are you using ME3800X/ME3600X/ME3600-24CX in your network?

collapsed p/pe.


   *   Any critical feature gaps? Please indicate the deployment scenario along 
with the feature ask.

urpf.  this is really hurting for PE stuff.


David.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback

[Matthias Kluth]

Hi Waris,

On 19.03.13 08:27 Waris Sagheer (waris) wrote:

Hi Everyone,
I have seen lot of good inputs on this mailer. I am collecting feedback for the 
existing deployment challenges on the following platforms so that we can 
address them.

[...]

   *   How are you using ME3800X/ME3600X/ME3600-24CX in your network?


At the time of writing this we are using them mostly for backhauling our 
DSL/FTTH access nodes.
But also using them for directly connecting bandwith hungry business 
customers with fibre access to the Internet in combination with 
ME3400-2CS as CPE.


Therefor i'm specially interested in deployment and QoS scenarios where 
to shrink down bandwith on ingress to somewhat below 1 Gbps (200 Mbps 
up to 500 Mpbs) with class best effort without dropping to much packets.





   *   Any critical feature gaps? Please indicate the deployment scenario along 
with the feature ask.


Yes, please.

Regarding with old IPv4 deployment using DHCP locally served on the 
ME3800/ME3600, the feature authorized DHCP (MAC authorized inside a 
VRF) isn't VRF aware. At least for business customers i would like to 
see this thing working.



Best Regards.
  Matthias Kluth
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/