[c-nsp] MPLS-TE on ME3600

Fri Nov 14 14:33:56 EST 2014

>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)
waris at cisco.com<mailto:waris at cisco.com>
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 <aaron1 at gvtc.com<mailto:aaron1 at gvtc.com>>
Date: Friday, November 14, 2014 at 5:37 AM
To: Pshem Kowalczyk <pshem.k at gmail.com<mailto:pshem.k at gmail.com>>
Cc: "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
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:pshem.k at gmail.com]
Sent: Wednesday, September 11, 2013 3:18 PM
To: Aaron
Cc: Eric Van Tol; cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
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 <aaron1 at gvtc.com<mailto:aaron1 at gvtc.com>> 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:cisco-nsp-bounces at puck.nether.net] On Behalf
Of Pshem Kowalczyk
Sent: Wednesday, September 11, 2013 2:36 PM
To: Eric Van Tol
Cc: cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
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 <eric at atlantech.net<mailto:eric at atlantech.net>> 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  cisco-nsp at puck.nether.net<mailto:cisco-nsp at 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 at puck.nether.net<mailto:cisco-nsp at 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 at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/