Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pce] Fw: I-D Action:draft-farrel-pce-vendor-constraints-00.txt
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
Selon Adrian Farrel <adrian at olddog.co.uk>:
> 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" <danli at huawei.com>
> To: "Meral Shirazipour" <meral.shirazipour at polymtl.ca>; "Adrian Farrel"
> <adrian at olddog.co.uk>
> Cc: <pce at ietf.org>
> 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
> >
> > ----- Original Message -----
> > From: "Meral Shirazipour" <meral.shirazipour at polymtl.ca>
> > To: "Adrian Farrel" <adrian at olddog.co.uk>
> > Cc: <pce at ietf.org>
> > 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...
>
>
>
_______________________________________________
Pce mailing list
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.