>From design perspective, you can can have end to end TE tunnels for example >for an ELINE service by using LDP over TE tunnel. It would be similar to >Unified MPLS solution without simple protection solution. Remote LFA is much >simpler. ODL supports PCEP and it is pretty interesting to use BGP LS for topology discovery and PCEP for tunnel provisioning. We are hoping to replace RSVP TE with Segment Routing TE . SR TE would eliminate the states and complexity of traditional RSVP TE.
Best Regards, [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg] Waris Sagheer Technical Marketing Manager Service Provider Access Group (SPAG) [email protected]<mailto:[email protected]> Phone: +1 408 853 6682 Mobile: +1 408 835 1389 CCIE - 19901 <http://www.cisco.com/> 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: Aaron <[email protected]<mailto:[email protected]>> Date: Friday, November 14, 2014 at 5:37 AM To: Pshem Kowalczyk <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [c-nsp] MPLS-TE on ME3600 This is incredible. I'm always amazed at developments in the network realm. What will they think of next...? I read here that PCE is the solution to Inter-AS and Inter-Area MPLS-TE.... http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r3-9/mpls/configuration/guide/gc39crs1book_chapter4.html#con_1279822 "Path Computation Element (PCE) solves the specific issue of inter-domain path computation for MPLS-TE label switched path (LSPs), when the head-end router does not possess full network topology information (for example, when the head-end and tail-end routers of an LSP reside in different IGP areas). PCE uses area border routers (ABRs) to compute a TE LSP spanning multiple IGP areas as well as computation of Inter-AS TE LSP." But wait, there's more...there's actually an IETF working group for this exact thing... IETF PCE WG for standardizing a TCP based protocol called, PCEP... http://datatracker.ietf.org/wg/pce/charter/ cisco pce info.... http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/mpls/configuration/guide/b_mpls_cg42crs/b_mpls_cg42crs_chapter_0100.html#con_1256727 juniper pce info... https://www.juniper.net/documentation/en_US/junos12.3/topics/concept/pcep-for-mpls-rsvp-te.html .... when reading this I start thinking about sdn, nfv, openflow, things like that, like protocols that allow for decisions to be made elsewhere, seem to usher in the whole idea of virtualizing and cloud'ing the control plane with mere control plane clients that reside on routers/swiches/lsr's with tcp sessions to all-knowing controllers elsewhere. Crazy huh Aaron -----Original Message----- From: Pshem Kowalczyk [mailto:[email protected]] Sent: Wednesday, September 11, 2013 3:18 PM To: Aaron Cc: Eric Van Tol; [email protected]<mailto:[email protected]> Subject: Re: [c-nsp] MPLS-TE on ME3600 Hi, If you want a simple setup I suggest you go with a single OSPF/ISIS area. A multi-area setup can be build, but I'd question the reasons behind doing that. You're right about the attributes - TE requires additional LSAs (for OSPF), that are confined to a single area. The main disadvantage of using TE across multiple areas is the fact that any path that crosses the border has to be manually defined to at least some extend. If you have to split your IGP because of the scale I suggest you look at things like IP FRR/ (r)LFA and BGP PIC with additional paths. That can provide protection across multiple areas and it's much easier to scale. kind regards Pshem On 12 September 2013 08:05, Aaron <[email protected]<mailto:[email protected]>> wrote: Is it true that mpls traffic engineering requires single area ospf ? (something about mple te attributes within ospf getting lost between areas, or unable to be passed into other areas) Aaron -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Pshem Kowalczyk Sent: Wednesday, September 11, 2013 2:36 PM To: Eric Van Tol Cc: [email protected]<mailto:[email protected]> Subject: Re: [c-nsp] MPLS-TE on ME3600 Hi, We use ME3600x with MPLS TE. I can't comment on the first point (we don't have multiple areas), but on the second one - path protection is protection end-to-end, whilst FRR uses a local repair mechanism, so these two are quite different in the way they work. FRR on that device works fine and provides protection for both originated and transit LSPs. On the third point - yes, that's a limitation. I'm not sure if it's a hardware or a software one. kind regards Pshem On 12 September 2013 04:15, Eric Van Tol <[email protected]<mailto:[email protected]>> wrote: Hi all, I'm a bit confused about the documentation for the ME3600 with regard to its MPLS-TE support. Specifically, the 'MPLS TE' section (http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software /relea se/15.3_3_S/configuration/guide/swmpls.html#wp1183331) states: The switch does not support these MPLS TE features: *Interarea TE support for OSPF and IS-IS *TE path protection On the first bulletpoint, does this simply mean that it cannot pass through areas without an explicit path set up? On the second bulletpoint, I'm confused about this because the next section in the documentation deals with Fast Reroute. Does this bulletpoint mean that the ME3600 cannot provide protection for transit LSPs? And finally, within the Fast Reroute section, I see this little nugget: "The switch supports MPLS TE fast reroute over only routed ports and not over SVIs or EtherChannels." Huh? Really? -evt _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
