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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Apr 2008 17:56:19 +0100

Hi,

This I-D is intended to allow PCE implementations to support specific 
additional constraints information that is not intoned for standardisation 
but which might be published for wider use or that is kept private for 
PCC-PCE communications.

As usual, comments to the list, please.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 07, 2008 5:45 PM
Subject: I-D Action:draft-farrel-pce-vendor-constraints-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
> Title           : Conveying Vendor-Specific Constraints in the Path 
> Computation Element Protocol
> Author(s)       : A. Farrel, G. Bernstein
> Filename        : draft-farrel-pce-vendor-constraints-00.txt
> Pages           : 8
> Date            : 2008-04-07
>
> The Path Computation Element Protocol (PCEP) is used to convey path
> computation requests and responses between Path Computation Clients
> (PCCs) and Path Computation Elements (PCEs), and also between
> cooperating PCEs. In PCEP the path computation requests carry details
> of the constraints and objective functions that the PCC wishes the
> PCE to apply in its computation.
>
> The mechanisms defined for indicating objective functions include
> the capability to convey vendor-specific objective functions. This
> document defines a facility to carry vendor-specific constraints in
> PCEP.

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Meral Shirazipour <[email-masked]>
Date: Mon, 07 Apr 2008 18:02:19 -0400

Hi,
   In Section 5.6 raises an obvious issue :
   “the presence of additional vendor-specific
   information in PCEP messages may congest the operation of the
   protocol especially if the PCE does not support the constraints
   supplied by the PCC.”

Would it be safer to propose that the proposed feature should only be used for
inter-area and inter-layer path computations (and not for inter-domain)?! I
don’t really see the prospect of using vendor specific constraints in an
inter-domain environment...

Regards,
Meral

---

From: Dan Li <[email-masked]>
Date: Tue, 08 Apr 2008 10:57:30 +0800

Hi,

Since the constraints information is vendor specific, so the VENDOR-CONSTRAINT object can't be used in one domain which consists of different vendor's equipments. On the other side, if there are two domains, which consists of same vendor's equipments, the VENDOR-CONSTRAINT object should not be limited in only one domain. It can be exchanged between two PCEs where each PCE covers one domain.

Regards,

Dan

----- Original Message ----- 
From: "Meral Shirazipour" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 08, 2008 6:02 AM
Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt

Hi,
   In Section 5.6 raises an obvious issue :
   "the presence of additional vendor-specific
   information in PCEP messages may congest the operation of the
   protocol especially if the PCE does not support the constraints
   supplied by the PCC."

Would it be safer to propose that the proposed feature should only be used for
inter-area and inter-layer path computations (and not for inter-domain)?! I
don't really see the prospect of using vendor specific constraints in an
inter-domain environment...

Regards,
Meral

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Apr 2008 14:23:04 +0100

Hi,

Actually, the case I had in mind was where the constraints are 
vendor-specific but are publicly available. For example, if you buy a PCE 
from vendor X, it may offer standard features and vendor-specific features. 
If you want to operate a standard PCC then no problem, but if you want to 
use the vendor-specific features you use the published format for the 
object. The publication might be in a user manual or in an RFC 
(Informational/Experimental).

Of course, the cases you talk about where the object is only used between a 
PCC and PCE both from the same vendor also applies, and in that case no 
publication would be required.

I don't see why we would limit this to use within a single domain. It is 
possible for two PCEs in neighboring domains to communicate and pass 
vendor-specific constraints. It might be that significant policies are 
implemented at domain boundaries to restrict their use, but that is an 
operational feature not a protocol feature.

Adrian
----- Original Message ----- 
From: "Dan Li" <[email-masked]>
To: "Meral Shirazipour" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 08, 2008 3:57 AM
Subject: Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt

> Hi,
>
> Since the constraints information is vendor specific, so the 
> VENDOR-CONSTRAINT object can't be used in one domain which consists of 
> different vendor's equipments. On the other side, if there are two 
> domains, which consists of same vendor's equipments, the VENDOR-CONSTRAINT 
> object should not be limited in only one domain. It can be exchanged 
> between two PCEs where each PCE covers one domain.
>
> Regards,
>
> Dan
>
> Subject: Re: [Pce] Fw: I-D 
> Action:draft-farrel-pce-vendor-constraints-00.txt
>
>
> Hi,

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 08 Apr 2008 11:09:38 -0400

Hi,
 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.
 But then, another issue would be SPs who do not want to advertise the 'vendor'
information to other domains. What to do then?

 From a 'competition' point of view, I completely see why we would want to allow
vendor's to offer different 'capabilities' in terms of OF and constraints etc.
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]...

Regards,
Meral

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Apr 2008 18:03:17 +0100

Meral,

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

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.

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

> again, nothing prevents an admin to purchase PCEs from different 

I wonder if you mean intra-area, 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 :-)

Adrian

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 08 Apr 2008 13:58:19 -0400

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?

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

> to make discovery a SHOULD.

the other way would be how exactly?

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

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

> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Apr 2008 20:01:53 +0100

Meral,

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

> 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

>> these is discovery, but that is not the only way. So it would not be 
>> correct

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

s/PCE2/PCE3/

> 'path computaion failure' messages to solve the problem is necessarily a 

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.
>> >
> Ok for a PCC. But if I am a Service Provider and I have clients (PCCs)

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.

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

> various capabilities that are incompatible between vendors or between 

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

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 08 Apr 2008 19:06:12 -0400

Hi,
  I do not suggest at all to block the work, I am just raising the issues that I
think should be discussed or raised in the draft (I had the same concern for
draft:draft-ietf-pce-of-02.txt).
  I suggest strongly to state cases when this will/could be useful and draw
attention to possible problems, and future works that need to be done to make
it completely functional.

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

sorry, my bad
:)

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

I have no comments here, please see my other comments below

> - PCEP capabilities exchange

That is good, except for the "trial and error" which should not be a solution
but more an error recovery mechanism. You are a better judge of this though.

> considered to be a form of discovery.

ok

> constraints as it forwards the PCReq. Ditto PCE2 to PCE3.

Exactly what I wanted to make sure, that there should be a 'kind' of <<mapping>>
between PCEs supporting different OF/constraints.

> Or maybe other PCEs will support them.

all good

> Oh, I think you completely miss the point.

I disagree ... bc...

> particular PCE, then it will sell better.

... my concern is not the PCC or PCEi acting as PCC to PCEi+1
my concern is for PCEs having to answer to requests from PCCs. A PCC could
support all possible vendor specific functions, fine. But PCEs cannot: because
ow they would not be 'vendor specific' but rather 'standard' functions.

> Nothing prevents from standardising more OFs and constraints.

I agree, but if vendor% makes an OF vendor-specific, why would it allow it to
become a standard or why would other vendors accept it as a standard?!
And the question is why not standardize it before making it available (but that
is not our point here).

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

Again I fully supported and support the draft as long as it discusses all these
little issues and clarifies that a certain mapping is required at some point.

> to use the information conveyed.

I think it would be very beneficial to inter-area and inter-layer cases of path
computation. Different vendors could concentrate on different needs ...in that
sense.

My only concern is or was for the inter-domain case. But your answer above
assures that this will not be problem if the correct mapping mechanisms are
used...

> specific uses that strongly motivate this work.

Again, it would be great to add usage examples to the draft.

Regards,
Meral