draft-litkowski-idr-flowspec-interfaceset-02

draft-litkowski-pce-state-sync-00
S. Litkowski, Orange
S. Sivabalan, Cisco
IETF 97 Seoul
1
Goal
• PCE Redundancy specification for stateful PCE
is really basic today and causes some trouble
• Association based constraint (like diversity)
does not work properly in a redundancy
scenario
• We want to enhance computation and
resiliency for association based constraint
2
Problem to be solved: case 1
• Sequence of Events:
– Configure PCC1->PCC2
• ERO used: R1->R3->R4->R2>PCC2
– Configure PCC3->PCC4
• Need to move the other LSP
to find a room
• PCE2 cannot move the
existing LSP
• No disjointness can be
found
3
Problem to be solved: case 2
• Sequence of Events:
– Configure both LSPs in the same
time window
– A computation loop will occur
4
Problem to be solved: case 2
PCC1->PCC2 path:
R1->PCC2
Received PCC3->PCC4 path:
none
PCC3->PCC4 path:
R3->R1->PCC2->PCC4
Received PCC1->PCC2 path:
none
5
Problem to be solved: case 2
PCC1->PCC2 path:
R1->PCC2
Received PCC3->PCC4 path:
R3->R1->PCC2->PCC4
PCC3->PCC4 path:
R3->R1->PCC2->PCC4
Received PCC1->PCC2 path:
R1->PCC2
Non disjoint
path
Non disjoint
path
Newly computed paths are reported =>
disjointness must be computed !
6
Problem to be solved: case 2
PCC1->PCC2 path:
->PCC2
Received PCC3->PCC4 path:
R3->R1->PCC2->PCC4
PCC3->PCC4 path:
R3->PCC4
Received PCC1->PCC2 path:
R1->PCC2
Disjoint path
Disjoint
path
New paths have been computed, report will
be done
7
Problem to be solved: case 2
PCC1->PCC2 path:
->PCC2
Received PCC3->PCC4 path:
R3->PCC4
PCC3->PCC4 path:
R3->PCC4
Received PCC1->PCC2 path:
->PCC2
Non disjoint
path
Non optimal
disjoint path
Newly computed paths are reported => CSPF
will run again to provide a more optimal LSP
placement
8
Problem to be solved: case 2
PCC1->PCC2 path:
R1->PCC2
Received PCC3->PCC4 path:
R3->PCC4
PCC3->PCC4 path:
R3->R1->PCC2->PCC4
Received PCC1->PCC2 path:
->PCC2
We are back to the initial state, as PCE
computations are not synchronized , there is a
chance that they do not use the right state
9
Problem to be solved: case 3
• Having a single PCE in a network may be
dangerous:
– We never put all eggs in one basket
• But how to handle disjointness-like computation
in this scenario:
10
Our proposal
• InterPCE communication is required !
– Let’s create a stateful PCEP session between PCEs
• It is not specified by any document yet
• Using multiple computing PCEs for association
based constraint is not a good idea:
– Let’s introduce a master/slave mechanism
– Using subdelegation
11
State-sync session
• We use a new bit flag in the
STATEFUL-CAPABILITY-TLV:
STATE-SYNC-CAPABILITY
PCE1
• At session opening stage,
both PCEs behaves both as
PCC and PCE: bidirectional
initial synchronization is used
• Each PCE will report its
delegated LSPs on the statesync session and may decide
to subdelegate to a master
PCE
PCRpt S=1
PCE2
PCC
PCRpt EOS
PCRpt S=1
PCRpt EOS
PCRpt D=1
PCupdate
PCRpt D=1
PCupdate
PCRpt D=1
12
Master/slave PCE
• Master/slave PCE is based on a priority mechanim
• How to exchange priority is out of scope of the document
• It may be an IGP/BGP extension, local configuration, …
• A PCE may be master for some LSPs or associations and
slave for others (loadsharing)
• If a PCE does not have delegation for all LSPs in the
association, it should not take into account the
association constraint or provide no-path.
13
Back to problem case 2
PCE1 is master for the association
PCC1->PCC2 path:
R1->PCC2
PCC3->PCC4 path:
none
PCRpt D=1
PCC3->PCC4
Received PCC3->PCC4 path:
none
Received PCC1->PCC2 path:
none
PCE1 computes path for PCC1->PCC2 (delegated
by PCE)
PCE2 subdelegates PCC3->PCC4 to PCE1
14
Back to problem case 2
PCRpt D=0
PCC1->PCC2
PCC1->PCC2 path:
R1->PCC2
PCC3->PCC4 path:
R3->R1->PCC2->PCC4
PCUpd D=1
PCC3->PCC4
Received PCC3->PCC4 path:
R3->R1->PCC2->PCC4
Received PCC1->PCC2 path:
R1->PCC2
Disjoint path
PCE1 computes path for PCC3->PCC4 and
updates PCE2
It reports also PCC1->PCC2 path to PCE2
15
Conclusion and next steps
• State-sync provides an efficient way to design a network
using PCEP
– It offers possibility to loadshare computation while keeping
optimal computation without risk of loops
– It increases the resiliency of the design
– It provides a good scaling solution for PCE
– It does not touch the PCC side (easier and faster to deploy)
• We have some running code… (to be deployed soon)
• We welcome feedback from the WG
16