Cisco's IOS-XE and PCEP implementation
I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! Should I be getting a 9k/CRS on the edge to implement an automatic tool to build MPLS-TE tunnels! -- Mohamed Kamal Core Network Sr. Engineer
On 30/Mar/15 16:39, Mohamed Kamal wrote:
I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?!
Should I be getting a 9k/CRS on the edge to implement an automatic tool to build MPLS-TE tunnels!
My guess is if there is some code, you want to get it through your SE. Mark.
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?!
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…). 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’ll 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’m 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 “automatic” tools, and possibilities for offline calculation in the interim period. r.
and hence being implemented on IOS-XR within the Cisco environment today
I disagree! .. Engineering is all about optimization, and using an ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean 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?!
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…).
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’ll 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’m 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 “automatic” tools, and possibilities for offline calculation in the interim period.
r.
On 5 April 2015 at 20:43:24, Mohamed Kamal (mkamal@noor.net) wrote:
and hence being implemented on IOS-XR within the Cisco environment today
I disagree! .. Engineering is all about optimization, and using an ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean 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. I did not say that a high-scale environment is required. Just that as far as I have seen a number of deployments (e.g., Internet core/peering-edge) that are stating requirements for TE+PCEP are of the traffic scale that XR boxes are likely to be more widely deployed. IMHO, it’s this that means that XR is seeing the *first* implementations. Some very large networks (including some that I have responsibility for) make extensive use of IOS XE, and hence there are also requests for PCEP implementations there. I encourage you to request it of Cisco too! r.
Here is Cisco's reply! “Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in TE environment) and ASR1K is not marketed for TE, support is unlikely” 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 ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean 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?!
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…).
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’ll 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’m 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 “automatic” tools, and possibilities for offline calculation in the interim period.
r.
One of the downsides to having four (at least) different control plane operating systems across your product lines. Phil -----Original Message----- From: "Mohamed Kamal" <mkamal@noor.net> Sent: 4/8/2015 5:13 AM To: "NANOG" <nanog@nanog.org> Subject: Re: Cisco's IOS-XE and PCEP implementation Here is Cisco's reply! “Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in TE environment) and ASR1K is not marketed for TE, support is unlikely” 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 ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean 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?!
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…).
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’ll 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’m 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 “automatic” tools, and possibilities for offline calculation in the interim period.
r.
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: 4/8/2015 5:13 AM To: NANOG <mailto:nanog@nanog.org> Subject: Re: Cisco's IOS-XE and PCEP implementation
Here is Cisco's reply!
“Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in TE environment) and ASR1K is not marketed for TE, support is unlikely”
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
and hence being implemented on IOS-XR within the Cisco environment today I disagree! .. Engineering is all about optimization, and using an ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean 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?!
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…).
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’ll 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’m not sure what kind of logic would mean that device selection is solely
On 4/5/2015 10:42 PM, Mohamed Kamal wrote: based on PCEP support :-). I would certainly look more into the existing “automatic” tools, and possibilities for offline calculation in the interim period.
r.
Just to follow-up; Cisco has offered segment-routing and entropy label use starting from 3.16/3.17 respectively. Do Cisco see the 1k platform as an enterprise router?! Am I the only one here that assume that BGP-LS and PCEP support in the XE platforms is a must now after releasing the SR support? Mohamed Kamal Core Network Sr. Engineer On 4/8/2015 6:06 PM, Mohamed Kamal wrote:
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: 4/8/2015 5:13 AM To: NANOG <mailto:nanog@nanog.org> Subject: Re: Cisco's IOS-XE and PCEP implementation
Here is Cisco's reply!
“Given PCEP’s main use-case is inter-area TE tunnels (or SDN controller in TE environment) and ASR1K is not marketed for TE, support is unlikely”
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
and hence being implemented on IOS-XR within the Cisco environment today I disagree! .. Engineering is all about optimization, and using an ASR1k (which is being marketed as an "edge/PE router") in my edge doesn't mean 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?! 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…). 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’ll 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’m not sure what kind of logic would mean that device selection is solely
On 4/5/2015 10:42 PM, Mohamed Kamal wrote: based on PCEP support :-). I would certainly look more into the existing “automatic” tools, and possibilities for offline calculation in the interim period.
r.
participants (4)
-
Mark Tinka -
Mohamed Kamal -
Phil Bedard -
Rob Shakir