PCE communication Protocol (PCEP) draft-ietf-pce-pcep-09.txt J.P. Vasseur (Cisco System Inc.) J.L. Le Roux (France Telecom) A. Ayyangar (Nuova Systems) E. Oki (NTT) A. Atlas (Google) A. Dolganow (Alcatel) Y. Ikejiri (NTT Communications Corporation) K. Kumaki (KDDI Corporation)

IETF 70, PCE WG, Vancouver 12/04/2007

Changes since last version 1/2

P flag of the END-POINT object MUST be set in PCReq messagesP flag of the RP object MUST be set in PCReq/PCRep and MUST

be cleared in PCErr/PCNtfClarification on receiving two optimization metric objects (B=0)

the receiving peer MUST send a PCErr message with Error-type=10 and Error-value=2

New Error Type/Values:Type 10: reception of a malformed object

–Value 1: reception of an object with P flag not set although it must be set

–Value 2: reception of a PCReq message with two METRIC object with B-flag clear

Changes since last version 2/2

PCEP TLVsWe used to have different TLV formats We have now defined a single TLV format for all PCEP objects

–Type: 2 bytes, Length: 2 bytes

We redefined the NO-PATH-VECTOR, OVERLOAD-DURATION and REQ-MISSING TLVs accordingly

Single IANA code point registry

Clarification regarding non understood objectIf a PCReq includes multiple unsynchronized requests, only requests for which an object with the

P flag set is unknown/unsupported MUST be rejectedIf a PCReq includes multiple synchronized requests, with one request for which an object with the

P flag set is unknown/unsupported => All requests MUST be rejected

Change in the FSM with regards to the collision resolution procedure IANA Section updated Rewordings for the sake of clarity

Collision Resolution

Collision when two PCEP peers try simultaneously to setup a PCEP session

May lead to two TCP connections and two PCEP sessionsCollision resolution used to be performed in the TCPPending state,

that is at the TCP levelIf the system detects that a PCE Peer with an higher IP @ tries to simultaneously

establish a TCP connection, it stops the current TCP connection establishment and goes back to the idle state

Difficult to implement due to atomicity of TCP socket methodsNow performed in the OpenWait sate, at the "application" level

If Open received, check other sessions with same peerIf one other session => Collision resolution

–If the system initiated the current session and has lower IP @, it closes the TCP connection and goes back to the idle state

Thanks to Fabien Verhaeghe that raised this point

Next Steps

Again thanks a lot for the very useful comments provided by implementers

At least 9 known implementations on the table which is quite good for a two years old protocol !

Adrian agreed to make a detailed reviewFor sure a few comments

Rev 10 to be submitted before end December => WG last CallTarget: Document sent to the IESG before end JanuaryExtensive testing, successful interop testing

France Telecom / MARBEN Products PCEP Interoperability session Fabien Verhaeghe (MARBEN Products) Mohamad Chaitou (France Telecom)

IETF 70, PCE WG, Vancouver 12/04/2007

FT PCC / MARBEN PCE

FT PCE / MARBEN PCC

PCEP session opening/closing

PCEP session parameters negotiation

PCEP KeepAlive Mechanism

PCEP session FSM (OpenWait, KeepWait…)

Simple requests with no constraint

Multi constraint requests

Unsuccessful Path Computation

Path Reply with optional object

Path requests with unsupported object

ProfileProfile

Session managementSession management

Computation Computation RequestRequest

PCEP Interoperability session scope

PCEP interoperability session results

No interoperability problem encountered

No interoperability problem encountered

Common understanding of the PCEP draft

PCEP protocol quite straight forward

risk of interoperability problem seems very low

Path Computation Request

PCEP Session management

Conclusion

Thanks

Questions?