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

[Meral Shirazipour <meral.shirazipour at polymtl.ca>]

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.

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

sorry, my bad
:)


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

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

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

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.

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

ok

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

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



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

all good

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

I disagree ... bc...

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

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

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

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

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

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.


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

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

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

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

> Adrian


Regards,
Meral



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