Subject: [Pce] VENDOR-CONSTRAINT

From: <[email-masked]>
Date: Mon, 9 May 2011 09:26:21 +0300

draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object.  I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to for example the END-POINTS object.

Christian

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 11 May 2011 11:14:13 +0800

Hi Christian,

Thanks for your comments.

Could you explain a little more about what are requirements for the VENOR-CONSTRAINT TLV? 
Why VENOR-CONSTRAINT object can not meet these requirements? 
How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV?

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Sent: Monday, May 09, 2011 2:26 PM
  Subject: [Pce] VENDOR-CONSTRAINT

  Christian

------------------------------------------------------------------------------

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

---

From: <[email-masked]>
Date: Wed, 11 May 2011 09:53:57 +0300

Certainly.

The VENDOR-CONSTRAINT TLV could be formatted this way (similar to
the VENDOR-CONSTRAINT object)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type                |          Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Enterprise Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                 Enterprise-Specific Information               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere
in the VENDOR-CONSTRAINT object to give additional information, so that
it is possible to correlate the contents of the VENDOR-CONSTRAINT object
with other objects in the message.  By having a VENDOR-CONSTRAINT TLV,
that TLV can be directly added to the object for which such additional
information is wanted.

Examples of use of VENDOR-CONSTRAINT TLV are as follows.
 * in PCNtf messages for vendor specific additions;
 * in END-POINTS object, specifically the Generalized Endpoints object type,
   with vendor specific additions
The addition of a VENDOR-CONSTRAINT TLV would free me from picking an
unused value for the Type.  The type I have picked is currently unused, 
but may be assigned in the near future, and then follows the general problem 
of updating not just future software (which is simple),
but also existing software already delivered to customers (which is not so
simple).

Christian

________________________________________
From: Fatai Zhang [[email-masked]]
Sent: Wednesday, May 11, 2011 05:14
To: Kaas-Petersen Christian; [email-masked]
Subject: Re: [Pce] VENDOR-CONSTRAINT

Hi Christian,

Thanks

Fatai

----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Sent: Monday, May 09, 2011 2:26 PM
Subject: [Pce] VENDOR-CONSTRAINT

Christian

________________________________

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

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 11 May 2011 15:44:38 +0800

Hi Christian,

You said "If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message."

I don't think that it needs any additional information if only the VENDOR-CONSTRAINT object is used. You can look at the description for "Enterprise-Specific Information":

=======================================================   
Enterprise-Specific Information

The detailed enterprise-specific constraint information carried by the object. The format and interpretation of this information is a matter for the enterprise identified by the Enterprise Number. Such formats and interpretation MAY be published by the enterprise (possibly through an informational RFC or through commercial documentation) so that PCCs or PCEs that are not part of the organization can use the information.
==============================================================

By using only the VENDOR-CONSTRAINT object, I think it can keep the PCEP protocol much simple without touching so many different existing objects.

Hope this can clarify your concern.

Thanks
 
Fatai

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 11, 2011 2:53 PM
Subject: RE: [Pce] VENDOR-CONSTRAINT

Certainly.

      0                   1                   2                   3

Christian

Hi Christian,

Thanks

Fatai

----- Original Message -----
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Sent: Monday, May 09, 2011 2:26 PM
Subject: [Pce] VENDOR-CONSTRAINT

Christian

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 11 May 2011 12:44:47 +0200

Hi Fatai, Christian, PCE-ers, 

I think that having one extra TLV is usefull  when you want to add
object-specific vendor constraints and not general one, the information
carried will remain the same but in another place and more accessible.

Having a generic vendor specific object seems a catch-all solution that
is likely to  include any vendor private information and might  leave
too much room for private information.

Another possible angle to carry vendor-specific constraint is not to
have a generic object but rather a set of very specifically scoped TLVs
or sub-objects.

This can be applied to the PCEP as follow :

-          Objective function : private OF code is already defined, an
private_of_parameter_tlv (only valid inside the OF object) would carry
possible operator-specific parameters

-          Metric : a private metric type can be defined, with vendors
specific body and metric value.

-          For GMPLS endpoint constraint a TLV for vendor-private label
constraint (valid for endpoints and label_set only for instance) can be
defined.

-          For WSON-specifics this is for example covered in
draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding
from draft-ietf-ccamp-wson-signaling-01

For sure it's possible to put all those in one object, but I am not sure
it's the best strategy in order to avoid all private extensions.

I think some feedback from the WG on this topic, especially from people
have implementation background, would be helpful.

Best Regards.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Fatai Zhang
Sent: Wednesday, May 11, 2011 9:45 AM
To: [email-masked]; [email-masked]
Subject: Re: [Pce] VENDOR-CONSTRAINT

Hi Christian,

You said "If only the VENDOR-CONSTRAINT object is possible, it is
necessary somewhere in the VENDOR-CONSTRAINT object to give additional
information, so that it is possible to correlate the contents of the
VENDOR-CONSTRAINT object with other objects in the message."

I don't think that it needs any additional information if only the
VENDOR-CONSTRAINT object is used. You can look at the description for
"Enterprise-Specific Information":

The detailed enterprise-specific constraint information carried by the
object. The format and interpretation of this information is a matter
for the enterprise identified by the Enterprise Number. Such formats and
interpretation MAY be published by the enterprise (possibly through an
informational RFC or through commercial documentation) so that PCCs or
PCEs that are not part of the organization can use the information.
==============================================================

By using only the VENDOR-CONSTRAINT object, I think it can keep the PCEP
protocol much simple without touching so many different existing
objects.

Thanks
 
Fatai

----- Original Message ----- 

From: <[email-masked]
<mailto:[email-masked]> >

To: <[email-masked] <mailto:[email-masked]> >;
<[email-masked] <mailto:[email-masked]> >

Certainly.

      0                   1                   2                   3

If only the VENDOR-CONSTRAINT object is possible, it is necessary
somewhere

Examples of use of VENDOR-CONSTRAINT TLV are as follows.
 * in PCNtf messages for vendor specific additions;
 * in END-POINTS object, specifically the Generalized Endpoints object
type,
   with vendor specific additions
The addition of a VENDOR-CONSTRAINT TLV would free me from picking an
unused value for the Type.  The type I have picked is currently unused, 
but may be assigned in the near future, and then follows the general
problem 
of updating not just future software (which is simple),
but also existing software already delivered to customers (which is not
so
simple).

Christian

To: Kaas-Petersen Christian; [email-masked] <mailto:[email-masked]> 

Hi Christian,

Could you explain a little more about what are requirements for the
VENOR-CONSTRAINT TLV?
Why VENOR-CONSTRAINT object can not meet these requirements?
How many (and which) objects should be extended to include
VENOR-CONSTRAINT TLV?

Thanks

Fatai

----- Original Message -----
From:
[email-masked]<mailto:[email-masked]
om
<mailto:[email-masked]%3cmailto:Christian.Kaas-Peters
[email-masked]> >
To: [email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3cmailto:[email-masked]> >
Sent: Monday, May 09, 2011 2:26 PM
Subject: [Pce] VENDOR-CONSTRAINT

draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT
object.  I should like the draft also to introduce a VENDOR-CONSTRAINT
TLV allowing vendor specific additions to for example the END-POINTS
object.

Christian

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3cmailto:[email-masked]> >
https://www.ietf.org/mailman/listinfo/pce
<https://www.ietf.org/mailman/listinfo/pce>

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 11 May 2011 13:53:31 +0200

Hi Fatai, 

One additional comment on that is when the constraint may apply to only
one occurrence of an object, for instance additional BANDWIDTH
constraint 
or in case of P2MP to ENDPOINT, it is additional work to define a vendor

format that take into account which occurrence of the object the
constraint
apply to.

In addition the grammar proposed in draft-ietf-pce-vendor-constraints-04

is not clear regarding to RFC6006 : should the <vendor-constraint-list>
also be present in the <end-point-rro-pair-list>?

The RFC6006 does also introduce a capability indication in the OPEN 
message, was this possibility considered the PCC/PCE to discover the 
supported vendor-constraints? Would it make sense or should the PCC 
try to use it on the requests?

Best regards.

> -----Original Message-----
> ext [email-masked]
> Sent: Wednesday, May 11, 2011 8:54 AM
> To: [email-masked]; [email-masked]
> The VENDOR-CONSTRAINT TLV could be formatted this way (similar to the
> VENDOR-CONSTRAINT object)
> 
>       0                   1                   2                   3
> somewhere in the VENDOR-CONSTRAINT object to give additional
> VENDOR-CONSTRAINT object with other objects in the message.  By having
> a VENDOR-CONSTRAINT TLV, that TLV can be directly added to the object
> for which such additional information is wanted.
> 
> problem of updating not just future software (which is simple), but
> also existing software already delivered to customers (which is not so
> simple).
> 
> Christian
> 
>

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 11 May 2011 14:32:57 +0200

Cyril, all,

First, speaking from a personal point of view, I would say that I am not 
a big fan of VENDOR_X extensions. I would rather like to see those 
constraints / TLVs etc. open for standardization.

Having vendor extensions will indeed limit interoperability, e.g. having 
a VENDOR_CONTRAINT object with the P-bit set basically means that only 
that vendor (and associated "partners") can do path computation for that 
request ?. This is analogue to having the whole PCEP interface as 
proprietary defeating the standardization purpose.

It may be argued that a TLV may provide finer granularity to qualify a 
given object, rather than some more generic, packed object, but as long 
as the contents are opaque I worry that the default "ignore TLV" action 
would not be respecting the PCC constraints.

<sarcastic> Finally, if there is an VENDOR_CONSTRAINT object, 
VENDOR_CONSTRAINT_TLV why not a VENDOR_ message? :) </sarcastic>

For the rest of the mail, please see inline

On 11/05/2011 12:44, Margaria, Cyril (NSN - DE/Munich) wrote:
> object-specific vendor constraints and not general one, the 
> information carried will remain the same but in another place and more 
> accessible.
>

In this sense, it is unfortunate that not all objects are potentially 
TLV containers, (e.g. we had to define GENERALIZED_BANDWIDTH due to 
this) so only objects that are actually defined by RFC5440 as 
"containers" could have "vendor extensions" as TLVs. There is no way to 
add a VENDOR TLV to the bandwidth object, for example

> Having a generic vendor specific object seems a catch-all solution 
> that is likely to  include any vendor private information and might 
>  leave too much room for private information.
>
Agreed.

> have a generic object but rather a set of very specifically scoped 
> TLVs or sub-objects.
>
To some extent, yes, but then we shift the problem elsewhere. First, I 
am not sure if the standard way to proceed when a proprietary (unknown) 
TLV is found in an object (RFC 5440 $7.1,  "Unrecognized TLVs MUST be 
ignored") would be the best thing to do.
Without that vendor-specific information I am not sure if the resulting 
path is ignoring some MUST-USE TLV. However, at least, I know what 
object is "extended with vendor information" by virtue of being a TLV of 
that object.

> specific body and metric value.
Being nitpicking here .-) , but contrary to OF, metric types are 
assigned by IETF review process. Nothing precludes defining a private 
range but afaik it is not the case now.
>
> -          For GMPLS endpoint constraint a TLV for vendor-private 
> label constraint (valid for endpoints and label_set only for instance) 
> can be defined.
>
I would be less against the proliferation of vendor TLVs if there is a 
clear "consensus"  that those TLVs are only meaningful in the context of 
"private" ranges as Cyril examples. In other words, if the OF object 
with a code in the range 32768- has vendor TLVs I am fine. If I can't 
apply that OF code I don't care about the TLVs, and the processing rules 
for OF objects are standard and clear.

> For sure it's possible to put all those in one object, but I am not 
> sure it's the best strategy in order to avoid all private extensions.
>
Honestly, thinking that discussing whether private extensions either in 
objects or in TLVs would lead us to a best strategy in order to avoid 
private extensions seems weird :-)

That said, "less of two evils"?  the TLVs seem more granular, provide 
some information of what object they qualify, the processing rules are 
clear leading to "ignore the TLV", (it is important to note that I 
understand that an object that a PCE can "process" with P-bit set but 
with unknown TLVs does not imply the request being rejected) but not all 
object support TLVs.

Best regards
Ramon

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 25 May 2011 10:22:32 +0800

Hi Ramon,

If I understand you correctly, do you meant that you prefer "only the VENDOR-CONSTRAINT object" to "one extra TLV"?

Thanks
 
Fatai

  ----- Original Message ----- 
  From: Ramon Casellas 
  To: [email-masked] 
  Sent: Wednesday, May 11, 2011 8:32 PM
  Subject: Re: [Pce] VENDOR-CONSTRAINT

  Cyril, all, 

  First, speaking from a personal point of view, I would say that I am not a big fan of VENDOR_X extensions. I would rather like to see those constraints / TLVs etc. open for standardization. 

  Having vendor extensions will indeed limit interoperability, e.g. having a VENDOR_CONTRAINT object with the P-bit set basically means that only that vendor (and associated "partners") can do path computation for that request ?. This is analogue to having the whole PCEP interface as proprietary defeating the standardization purpose.

  It may be argued that a TLV may provide finer granularity to qualify a given object, rather than some more generic, packed object, but as long as the contents are opaque I worry that the default "ignore TLV" action would not be respecting the PCC constraints.

  <sarcastic> Finally, if there is an VENDOR_CONSTRAINT object, VENDOR_CONSTRAINT_TLV why not a VENDOR_ message? :) </sarcastic>

    I think that having one extra TLV is usefull  when you want to add object-specific vendor constraints and not general one, the information carried will remain the same but in another place and more accessible.

  In this sense, it is unfortunate that not all objects are potentially TLV containers, (e.g. we had to define GENERALIZED_BANDWIDTH due to this) so only objects that are actually defined by RFC5440 as "containers" could have "vendor extensions" as TLVs. There is no way to add a VENDOR TLV to the bandwidth object, for example

    Having a generic vendor specific object seems a catch-all solution that is likely to  include any vendor private information and might  leave too much room for private information.

  Agreed.

    Another possible angle to carry vendor-specific constraint is not to have a generic object but rather a set of very specifically scoped TLVs or sub-objects.

  To some extent, yes, but then we shift the problem elsewhere. First, I am not sure if the standard way to proceed when a proprietary (unknown) TLV is found in an object (RFC 5440 $7.1,  "Unrecognized TLVs MUST be ignored") would be the best thing to do. 
  Without that vendor-specific information I am not sure if the resulting path is ignoring some MUST-USE TLV. However, at least, I know what object is "extended with vendor information" by virtue of being a TLV of that object.

    -          Objective function : private OF code is already defined, an private_of_parameter_tlv (only valid inside the OF object) would carry possible operator-specific parameters

    -          Metric : a private metric type can be defined, with vendors specific body and metric value.

  Being nitpicking here .-) , but contrary to OF, metric types are assigned by IETF review process. Nothing precludes defining a private range but afaik it is not the case now.

    -          For GMPLS endpoint constraint a TLV for vendor-private label constraint (valid for endpoints and label_set only for instance) can be defined.

    -          For WSON-specifics this is for example covered in draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding from draft-ietf-ccamp-wson-signaling-01

  I would be less against the proliferation of vendor TLVs if there is a clear "consensus"  that those TLVs are only meaningful in the context of "private" ranges as Cyril examples. In other words, if the OF object with a code in the range 32768- has vendor TLVs I am fine. If I can't apply that OF code I don't care about the TLVs, and the processing rules for OF objects are standard and clear. 

    For sure it's possible to put all those in one object, but I am not sure it's the best strategy in order to avoid all private extensions.

  Honestly, thinking that discussing whether private extensions either in objects or in TLVs would lead us to a best strategy in order to avoid private extensions seems weird :-) 

  That said, "less of two evils"?  the TLVs seem more granular, provide some information of what object they qualify, the processing rules are clear leading to "ignore the TLV", (it is important to note that I understand that an object that a PCE can "process" with P-bit set but with unknown TLVs does not imply the request being rejected) but not all object support TLVs.

  Best regards
  Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 25 May 2011 07:15:39 +0200

El 25/05/2011 4:22, Fatai Zhang escribió:
> Hi Ramon,
> If I understand you correctly, do you meant that you prefer "only 
> the VENDOR-CONSTRAINT object" to "one extra TLV"?
>
Hello Fatai, all,

I'm afraid not (sorry for not having expressed myself  clearly). In the 
case of vendor constraints, I think, without a strong opinion, that I 
would rather have vendor-specific TLVs that apply to a given object, 
rather than a top-level object. The reasons for this are:

* It seems more granular and clearly identifies which object is 
constrained. Seems less opaque :)

* The default behavior as current RFC is to ignore the TLV if not 
known/supported. This may require a flags field within the TLV to 
specify that the constrain was indeed processed.

A good question is whether a single TLV "vendor_tlv" would do, or there 
is a reason to have more grained tlvs

There are some drawbacks of course:
* There are objects that were defined without TLVs. With a strict 
interpretation of rfc 5440, it would not be possible to constrain such 
objects.

* The constraint (semantics) involved in the TLV has to somehow relate 
to the object it is attached to. If there is no such object, the use of 
TLVs seems less flexible and an object would be needed.

In short, there seem to be use cases for both. Preferably, use vendor tlvs.

Thank you and best regards
R.

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 25 May 2011 13:53:43 +0800

Hi Ramon,

OK, thanks a lot.

Any more opinions from the WG?

Thanks
 
Fatai

  ----- Original Message ----- 
  From: Ramon Casellas 
  To: Fatai Zhang ; [email-masked] 
  Sent: Wednesday, May 25, 2011 1:15 PM
  Subject: Re: [Pce] VENDOR-CONSTRAINT

  Hello Fatai, all,

  I'm afraid not (sorry for not having expressed myself  clearly). In the case of vendor constraints, I think, without a strong opinion, that I would rather have vendor-specific TLVs that apply to a given object, rather than a top-level object. The reasons for this are:

  * It seems more granular and clearly identifies which object is constrained. Seems less opaque :)

  * The default behavior as current RFC is to ignore the TLV if not known/supported. This may require a flags field within the TLV to specify that the constrain was indeed processed.

  A good question is whether a single TLV "vendor_tlv" would do, or there is a reason to have more grained tlvs 

  There are some drawbacks of course:
  * There are objects that were defined without TLVs. With a strict interpretation of rfc 5440, it would not be possible to constrain such objects.

  * The constraint (semantics) involved in the TLV has to somehow relate to the object it is attached to. If there is no such object, the use of TLVs seems less flexible and an object would be needed.