[c-nsp] MPLS-TE on ME3600

[Aaron]

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
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> 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
> 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> 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 
>> 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 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>