Hi, Lets say we have: PCC1<--->PCE1(vendor C, domain1)<--->PCE2(Vendor H, domain2)
...and say that PCC1 sends a PCReq to PCE1 who will have to send a request to PCE2 for the end-to-end path computation... If the initial request is with a vendorC specific OF/constraint, then how will this work out? > > Does that mean that to avoid these serious issues (Section 5.6), > > PCE discovery 'Should' also retrieve the 'Vendor' information > > of other PCEs? > If so, Section 5.5 and 5.6 could maybe be > > merged and slightly modified to further discuss/emphasize this. > > The issue here is for a PCC to not send vendor constraints that are not a > valuable part of the request, or that will not be used by the PCE. for this the PCC/PCE needs to know the 'vendor' type of the PCE it is sending the request to. right? > 5.6 recommends two ways to collect the capabilities information. One of > these is discovery, btu that is not the only way. So it would not be correct > to make discovery a SHOULD. the other way would be how exactly? > > But then, another issue would be SPs who do not want to advertise the > > 'vendor' > > information to other domains. What to do then? > > There is no process for advertising capabilities between domains. In PCEP > exchanges between cooperating PCEs, there is the possibility to exchange PCE > capabilities, but these would typically be subject to significant policy. > OTOH, PCE partnering between administrations s likely to include the maual > distribution of PCE capabilities. That is exactly what is bothering me...if we extend the question/example I wrote at the beginning of this reply to: PCC1<--->PCE1(ven C, dom1)<--->PCE2(Ven H, dom2))<--->PCE2(Ven E, dom3) How will PCC1 know when to send ven C specific requests to PCE1 and when not to (because PCE2 and PCE3 will not support it). And I don't believe relying on 'path computaion failure' messages to solve the problem is necessarily a good idea. > > However I do not see at all how this will not become an obstacle to the > > initial > > goal of the PCE architecture: that of having a "standard" way for PCEs > > from > > different vendors AND from different domains, to cooperate and compute > > Inter-Domain paths. > > > > That is why I was insinuating to 'maybe' make any extra, vendor specific, > > functionality only available for inter-area and inter-layer cases... [but > > again, nothing prevents an admin to purchase PCEs from different > > vendors]... > > I wonder if you mean intra-area, etc. I mean anything under the same administration-where all the info on all coorperation PCEs could be available without any policy constraints etc.... > There is no reason that I see to prevent the use of this object in a wider > context. If you find that you can't use it, then don't use it :-) Ok for a PCC. But if I am a Service Provider and I have clients(PCCs) wanting/needing to send me PCReqs with certain vendor specific constraints that are crucial for them, then as their SP I will have to purchase PCEs from all major vendors? I am sure they wouldn't mind ;) I would just hate to see that the basic standard PCE box will come with some small and insignificant set of OF/constraints, and that if anyone needs certain specific more interesting set of OF/constraints, they will have to specifically purchase PCEs from vendor c, vendor e or vendor h or even more than one brand to be able to satisfy different customers needs..or their own internal(inter-layer/inter-area) needs. ...and I think it is obvious that for a sooner and larger-scale real world PCE deployment, vendors should follow more strictly standardized set of capabilities (OF/constraints), and concentrate competition on *bug free*, reliable and cost efficient implementation of PCE boxes. (Rather than PCEs with various capabilities that are incompatible between vendors or between versions or...). Thanks, Meral > Adrian > > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
