Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt

["Adrian Farrel" <adrian at olddog.co.uk>]

Meral,

>  Lets say we have:
> PCC1<--->PCE1(vendor C, domain1)<--->PCE2(Vendor H, domain2)

Let's not make hidden references to company names even in jest.

> ...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?

If the vendor constraints are published and if the PCE in the second domain 
supports them, why would this not work?

Further, does PCE2 know that PCE2 does not support the vendor constraints of 
the original request? And might there be a PCE in domain2 to which PCE2 can 
forward the request and that supports the constraints?

Why would you want to legislate against these posibilities by banning the 
use of vendor constraints between domains?

Maybe the enterprise is not an individual company, but a consortium of 
vendors.

>> > 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?

Nope.

It has to know whether the vendor constraints object is supported or not. 
One PCE vendor may support constraints for multiple PCC vendors. One PCC may 
communicate with PCEs from different vendors. Different releases of software 
may support different constraints.

It may find this out:
- by discovery (RFC5088/9)
- PCEP capabilities exchange
- configuration
- trial and error

>> 5.6 recommends two ways to collect the capabilities information. One of
>> these is discovery, but that is not the only way. So it would not be 
>> correct
>> to make discovery a SHOULD.
>
> the other way would be how exactly?

As the draft says...

   Thus, a PCC SHOULD monitor the capabilities of a
   PCE either by discovery mechanisms as described in Section 5.5, or
   through the receipt of negative responses.

Note well that "discovery mechanisms as described in Section 5.5" covers the 
first two bullet in the list above, while the third bullet is often 
considered to be a form of discovery.

>> > 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)

s/PCE2/PCE3/

> 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.

How does the PCC know that the sequence of domains is dom1, dom2, dom3?

Frankly, it doesn't matter.

If this type of network exists, a likely solution is that PCE1 understands 
vendor constraints for itself (obviously) and for PCE2. So PCE1 will map 
constraints as it forwards the PCReq. Ditto PCE2 to PCE3.

Or maybe the vendor constraints will be optional and ignored by PCEs that 
don't support them.

Or maybe other PCEs will support them.

>> > 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 ;)

Oh, I think you completely miss the point.
If a PCC will only operate in the presence of a particular PCE, then it will 
not sell very well.
If a PCC is able to engage additional function if it is available in a 
particular PCE, then it will sell better.

> 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.

Nothing prevents from standardising more OFs and constraints.

> ...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...).

Then don't implement any vendor-specific constraints in your 
implementations!

The main thrust of your email seems to be that you do not see any specific 
benefit from adding transport of non-standard within a standardised 
protocol, that you believe that it may impede implementation of the 
standardised protocol, and that there may be cases where it is not possible 
to use the information conveyed.

To the second and thrid of these, I agree completely, but don't see them as 
reasons to block the work. To the first point, (obviously?) I can see some 
specific uses that strongly motivate this work.

Adrian


_______________________________________________
Pce mailing list
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce