PCEP extensions for a BGPMPLS IPVPN draftkumakimuraipcepextensionl 3

PCEP extensions for a BGP/MPLS IP-VPN draft-kumaki-murai-pcep-extension-l 3 vpn-00. txt Kenji Kumaki ke-kumaki@kddilabs. jp (KDDI R&D Labs) Tomoki Murai murai@fnsc. co. jp (FURUKAWA NETWORK SOLUTION CORP. ) 72 nd IETF, PCE WG, July 2008

Motivation • Some service providers want to build new service which guarantees Qo. S or bandwidth from a local CE to a remote CE through the network. – draft-ietf-l 3 vpn-e 2 e-rsvp-te-reqts • A VPN customer desires their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. • The PCE architecture is the most suitable to calculate customer MPLS TE LSPs. 72 nd IETF, PCE WG, July 2008

Problem Statement • There is a problem with the current specifications of PCEP. • An Extension of PCEP is necessary. VPN 1: MPLS TE LSPs CE 0 BGP/MPLS IP-VPN CE 1 PCE 1 VPN 1 PE 1 CE 4 CE 5 CE 2 P P VPN 1 PE 2 CE 6 VPN 2: MPLS TE LSPs • The VPN 1 and the VPN 2 establish a customer MPLS TE LSP between their sites. 72 nd IETF, PCE WG, July 2008 CE 3 192. 168. 2. 1 CE 7 192. 168. 2. 1 VPN 2

Problem Statement(cont. ) VPN 1: MPLS TE LSPs CE 0 BGP/MPLS IP-VPN CE 1 PCE 1 VPN 1 PE 1 CE 4 CE 5 VPN 2 CE 2 P PCReq message P CE 3 192. 168. 2. 1 VPN 1 ? PE 2 CE 6 CE 7 192. 168. 2. 1 VPN 2: MPLS TE LSPs • The PCE 1 can identify each PCReq message from each incoming interface. • The PCE 1 forward the PCReq messages to PCE 2. • The PCE 2 can’t distinguish between the VPN 1 PCReq messages and the VPN 2 PCReq messages due to the same destination. • The PCE 2 can’t calculate an appropriate TE LSP between CEs per VPN. 72 nd IETF, PCE WG, July 2008

PCEP Extensions • The new Object-Types for VPN-IPv 4 address and VPN-IPv 6 address in END-POINTS object. • END-POINTS Object-Types 1 : IPv 4, 2 : IPv 6, 3 : VPN-IPv 4, 4 : VPN-IPv 6 • A new END-POINTS object consists of the original source/destination IPv 4/IPv 6 address and the Route Distinguisher(RD). 72 nd IETF, PCE WG, July 2008

PCEP Extensions(cont. ) The format of the END-POINTS object body 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source VPN-IPv 4 address (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination VPN-IPv 4 address (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source VPN-IPv 6 address (24 bytes) | // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination VPN-IPv 6 address (24 bytes) | // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 nd IETF, PCE WG, July 2008

PCReq message Handling END-POINTS object IPv 4/IPv 6 address PCReq message N VP y f i t den END-POINTS object CE (PCC) VPN 1 BGP/MPLS IP-VPN VPN-IPv 4/IPv 6 address PCE 1 Ingress PE I PCE 2 P P VPN 1 Egress PE CE (PCC) VPN 2 • Ingress PE (PCE 1) – Deals with an original address in the END-POINTS object as a VPN -IPv 4/IPv 6 address. – Puts VPN-IPv 4/IPv 6 address in the END-POINTS object and send the message to an Egress PE. • Egress PE (PCE 2) – Identifies a VPN from the VPN-IPv 4/IPv 6 address in the ENDPOINTS object. 72 nd IETF, PCE WG, July 2008 CE CE VPN 2

Open Issues • There is a case where an ingress PE can’t distinguish a path computation reply message. – When an Ingress PE received a PCRep message for a PCReq message from an Egress PE, it can’t identify a VPN only by a Request-ID in the RP object. – In the current specification of PCEP, a PCRep message does not include the END-POINTS object • option 1: We need to expand an object to identify a VPN at an Ingress PE. • option 2: A PCRep message includes the END-POINTS object. 72 nd IETF, PCE WG, July 2008

Next Steps • Feedback from WG – Please comment ! • Will work with yasukawa’s vpn-req draft. • Will expand an object to identify a vpn at an Ingress PE. Thank you 72 nd IETF, PCE WG, July 2008