Hi Dhruv,
Thank you for your comments. Please see inline. From: Dhruv Dhody <[email protected]> Subject: Query on draft-kumaki-murai-pce-pcep-extension-l3vpn-07 Date: Thu, 20 Oct 2011 08:05:10 +0000 : > Dear Authors, > > > > I understand that in this document you want to focus only on - "Dynamic > creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites" and not the complete > PCE-VPN-EXT. > > > > I agree completely with the need for address translation and use of > VPN-IPv4/v6 ENDPOINTS. > > > > Though you mention that the model will work when PCE function is not the PE > router, it's not immediately understood how. Especially when identification > of VPN is based on incoming interface? Yes, the identification of VPN at the edge PE is based on incoming interface. > If all PE routers must act as PCE, isn't it a drawback. Do you think this > rule is acceptable? It is assumed in the draft that the BGP/MPLS IP-VPN ingress and egress PE routers have PCE capabilities. However we think it's possible to adapt the external PCE architectures. It will require further study. > We need to figure out how PCE can learn the VPN information or do PCE and VPN > must always co-locate. Yes, we need to consider it. Regards, Tomoki > Also I find customer sites acting as a PCC, and connecting directly to > Service Provider PCE not compatible with the PCE architecture. > > PCE-VPN-REQ documents talk about customer PCE cooperating with Service > Provide PCE which fits better in the inter-domain path computation paradigm. > > > > Kindly provide your thoughts on this. > > > > Regards, > > Dhruv _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
