[179306] in North American Network Operators' Group
Re: Cisco's IOS-XE and PCEP implementation
daemon@ATHENA.MIT.EDU (Mohamed Kamal)
Wed Apr 8 12:08:34 2015
X-Original-To: nanog@nanog.org
Date: Wed, 08 Apr 2015 19:06:30 +0300
From: Mohamed Kamal <mkamal@noor.net>
To: Phil Bedard <bedard.phil@gmail.com>, NANOG <nanog@nanog.org>
In-Reply-To: <55252903.71518c0a.03cc.55c8@mx.google.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Yes, indeed! Things like VPLS, full-features ESI and PCEP exist on
IOS-XR but not IOS and IOS-XE!
ISSU and HA operates differently between IOS-XE and NX-OS!
Their claim is not even logical, the ASR1k is supporting 600 TE tunnels
head-end, and up-to 10k midpoint! So, if I had an average of 30 ASR1k in
the edge, each with 500 TE, there will be over 15000 TE tunnels in the
core which will be creating a need for automatic tool such as NorthStar
of Juniper!
Mohamed Kamal
Core Network Sr. Engineer
On 4/8/2015 4:11 PM, Phil Bedard wrote:
> One of the downsides to having four (at least) different control plane
> operating systems across your product lines.
>
> Phil
> -----------------------------------------------------------------------=
-
> From: Mohamed Kamal <mailto:mkamal@noor.net>
> Sent: =E2=80=8E4/=E2=80=8E8/=E2=80=8E2015 5:13 AM
> To: NANOG <mailto:nanog@nanog.org>
> Subject: Re: Cisco's IOS-XE and PCEP implementation
>
> Here is Cisco's reply!
>
> =E2=80=9CGiven PCEP=E2=80=99s main use-case is inter-area TE tunnels (o=
r SDN controller in
> TE environment) and ASR1K is not marketed for TE, support is unlikely=E2=
=80=9D
>
> What is .. "not marketed for TE"?!
>
> All in all, I don't mind replacing them with some cheaper, powerful,
> flexible and SDN-ready juniper MX that are marketed for TE.
>
> Mohamed Kamal
> Core Network Sr. Engineer
>
> On 4/5/2015 10:42 PM, Mohamed Kamal wrote:
> >> and hence being implemented on IOS-XR within the Cisco environment
> today
> > I disagree! .. Engineering is all about optimization, and using an AS=
R1k
> > (which is being marketed as an "edge/PE router") in my edge doesn't m=
ean
> > that my network is not a "high-scale environment", it does mean that =
it
> > fits my needs in this location, where other IOS-XR (ASR9k) fits in
> others.
> >
> > Plus, PCEP is no magic, Juniper's MX series starting from the vMX is
> > supporting PCEP. They didn't claim that, a "higher-scale environment"=
is
> > being required for this.
> >
> >> the demand for online calculation has increased - either due to
> dependencies for new TE path-instantiating protocols (e.g., SR), or
> more complex constraints that cannot be well met by offline
> calculation or CSPF
> > That's why PCEP support should be added to the road-map in the near
> future.
> >
> > Mohamed Kamal
> > Core Network Sr. Engineer
> >
> > On 4/5/2015 8:33 PM, Rob Shakir wrote:
> >> On 30 March 2015 at 15:42:59, Mohamed Kamal (mkamal@noor.net) wrote:
> >>> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till
> now?!
> >>>=20
> >>> Should I be getting a 9k/CRS on the edge to implement an automatic
> tool
> >>> to build MPLS-TE tunnels!
> >> In general, PCE(P) implementations have been limited. IMHO the last
> 10 years of RSVP-TE management has generally been done with auto-mesh
> tools, or in-house driven offline path calculation tools (e.g., WANDL,
> Cariden, Aria=E2=80=A6).
> >>
> >> As such, the demand for online calculation has increased - either
> due to dependencies for new TE path-instantiating protocols (e.g.,
> SR), or more complex constraints that cannot be well met by offline
> calculation or CSPF (e.g., path-diversity with disjoint head-end PEs).
> This demand is mainly coming in higher-scale environments - and hence
> being implemented on IOS-XR within the Cisco environment today. I
> expect this is why IOS-XE is lagging. There are certainly requests for
> support - but as Mark says, you=E2=80=99ll need to interface with your =
account
> team to figure out when code will be available for your platform.
> >>
> >> As to whether you should buy an IOS XR device for your edge, I=E2=80=
=99m
> not sure what kind of logic would mean that device selection is solely
> based on PCEP support :-). I would certainly look more into the
> existing =E2=80=9Cautomatic=E2=80=9D tools, and possibilities for offli=
ne calculation
> in the interim period.
> >>
> >> r.
> >>
> >
>