MPLS Traffic Engineering PCE (Path Computation Element)

Have any of you tried PCE on IOS-XR? I just did a small lab using this for the first time. What a great feature! It makes Inter-AS or Inter-Area TE so much better. 

The config is quite simple too!

Just wanted to share here and ask if anyone else has tried this out of has used it in production.

 

Pablo

Comments

  • I have tried it in a lab on IOS-XR.  I wonder though that in Inter-area implementations, why would you use PCE because it finds you shortest-path which you can do with loose hops too? Okay it makes sense if you want to setup tunnels with certain link-attributes like affinity-bits or SRLG (if supported)?

    I would like to see PCE in SDN implementations, that would be nice.

    Cheers,

    AB.

  • The beauty of it is that it's dynamic. You set up your PCE devices and they dynamically advertise themselves via the IGP. The head-end router doesn't have to specify an explicit path with loose hops, it just specifies a dynamic path with the "pce" option set at the end. 

    "path-option 10 dynamic pce"

    The head end node establishes a TCP session with the PCE device over which they exchange info regarding parts of the topology that are unknown to the head. 

     

  • How did you propagate PCE information from one AS to another AS when you setup Inter-AS MPLS-TE?

    Cheers,

    AB.

  • I have not tried inter-as, I just tried inter-area, but the concept is the same. I am sure that you would have to run the inter-as link as passive, and set up a PCE at each ASBR.

    I set this up using a 3 OSPF area design

     

    R1---area1----ABR(PCE)---area0----ABR(PCE)----area2----R2

     

    I would assume that the setup would be the same for inter-as, only the ASBR to ASBR link would run as passive (each one is a PCE). In this case there is no IGP in between them, so you would just configure the address of each PCE statically (on ASBR1 configure it as a PCE but also specify ASBR2's address, on ASBR2 configure as PCE but also configure ASBR1's address).

     

    I don't have access to the XR rack today, as soon as I do I will test this out and let you know. 

     

  • Yeah, you will need to configure it statically under "mpls traffic-eng" using "pce peer ipv4 <IP_Address>" command. However, there is no equivalent of "passive-interface" in XR that I could find in 4.3.0.

    With Inter-Area, did PEs in Area1/2 discover PCE information dynamically? The reason I am asking is because the PCE information is carried in Opaque LSA Type-10 (more specifically, Router Information LSA) in OSPF which has area-scope only. So I am interested in knowing how Area1 and Area2 discovered PCE dynamically. I imagine you must have used Loopback interface as PCE address. On the ABR, it can be in either Area0 or Area1/2, not both.

    Cheers,

    AB.

  • Has anyone been able to get PCE working in an Inter-AS scenario? I have a topology like this:

    R1 - R2 - XR1 - XR2

    XR1 and XR2 are ASBRs and XR2 (20.20.20.20) initiates a tunnel to R1 (1.1.1.1). XR1, R1 and R2 run OSPF with TE extensions. I keep getting an error during the path lookup on XR1. I definitely have a path from XR1 and I tried setting up a tunnel from it to R1 to ensure there are no issues and it was established successfully. I think for some reason XR1 tries to do a path lookup from the source to the destination of the tunnel rather than from itself to the destination, which causes that error. The same setup in an inter-area scenario works, where XR1 and XR2 are in area 1 and XR1, R1 and R2 are in area 0.

    =====

    te_control[1046]: DBG-PCE-PATH[14]: pce_process_path_request_msg:5220:     Request has a LSPA_LONG object: setup 7 hold 7 prot 0 affinity 0
    te_control[1046]: DBG-PCE-PATH[14]: pce_process_path_request_msg:5164:     Request has req BW object, bw = 0
    te_control[1046]: DBG-PCE-PATH[14]: pce_process_path_request_msg:5299:     Request has a METRIC object, metric val = 0 metric type = 2
    te_control[1046]: DBG-PCE-PATH[14]: pce_process_path_request_msg:5461: Path req from 20.20.20.20 to 1.1.1.1, id = 16, curr_bw 0 req_bw 0
    te_control[1046]: DBG-PCE-PATH[14]: te_pce_get_in_req_entry:507: te_pce_get_in_req_entry: src_addr = 20.20.20.20 in_req_id = 16 sender_addr 10.19.20.20
    te_control[1046]: DBG-PCE-PATH[14]: pce_process_path_request_msg:5476: Creating incoming entry: src = 20.20.20.20 id = 16 bw = 0 from PCE 10.19.20.20
    te_control[1046]: DBG-PCE-PATH[14]: te_pce_create_in_req_entry:413: te_pce_create_in_req_entry: src_addr = 20.20.20.20 dst_addr = 1.1.1.1 in_req_id = 16
    te_control[1046]: DBG-PCE-PATH[14]: te_pce_update_dst_thread:566:     Updating dst thread, dst = 1.1.1.1
    te_control[1046]: DBG-PCE-PATH[1]: te_pce_process_main_thread_event:3178: Run start VSPT: src 20.20.20.20 dst 1.1.1.1  req bw = 0 current bw = 0  affinity = 0  setup priority = 7 hold priority 7 prot = N
    te_control[1046]: DBG-PCE-PATH[1]: te_pce_process_main_thread_event:3193:  metric type = TE
    te_control[1046]: DBG-PCE-PATH[1]: te_pce_start_vspt:2037:     Work has 0 paths
    te_control[1046]: DBG-PCE-PATH[14]: te_pce_get_in_req_entry:507: te_pce_get_in_req_entry: src_addr = 20.20.20.20 in_req_id = 16 sender_addr 10.19.20.20
    te_control[1046]: DBG-PCE-PATH[14]: te_pce_process_pce_thread_event:4030: Sending -ve reply for (20.20.20.20 16): sender 10.19.20.20
    te_control[1046]: DBG-PCE-PATH[14]: pce_enqueue_path_reply_msg:8066: Sending reply to 10.19.20.20, num_ero = 0
    te_control[1046]: DBG-PCE-PATH[14]: pce_enqueue_path_reply_msg:8141: Sending NO-PATH to 10.19.20.20, NOI = 0

    =====

Sign In or Register to comment.