Subject: [Pce] PCEP ENCAP object

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Aug 2005 18:47:18 +0100

Hi,

I have a question remaining about the PCEP spec, and I would appreciate input from the WG and from the DT.

There is clearly considerable overlap between the information that needs to be carried by PCEP and that which is signaled by RSVP-TE. This is not a surprise because many of the constraints are identical. As a result, when deriving ways to encode this information it makes sense (to me and apparently to the DT) to re-use encodings that already exist.

This takes care of many of the details, but it leaves a high-level question. We should choose between the three options listed below.

1. Re-use RSVP-TE objects entirely unchanged
   In this option, PCEP messages can carry objects encoded as
   RSVP-TE objects using the same C-Num and C-Type as defined
   for RSVP-TE.
   The disadvantages of this mechanism are:
   a. RSVP and PCEP share the same code-point space with the
      possible result that the space will become depleted.
   b. Changes to the RSVP-TE object will result in the receipt 
      of unexpected variants to the PCEP object. I don't know 
      whether this will matter since the RSVP processing rules
      will require backward compatibility.
   c. Fields that are not required in PCE will be transported 
      but not used.
   d. Subobjects that are not required in PCE are ambiguous.
      This option would be documented as follows:
        My_Object
        C-Num and C-Type as for RSVP-TE [RFCwxyz]
        The content of this object is defined in [RFCwxyz]
        In the context of PCE the fields of this object are 
        interpreted as follows:

          Field 1:
             Blah, blah, blah

          Field 2:
             etc.

2. Encapsulate RSVP-TE objects entirely unchanged
   As currently documented, the ENCAP object solves problem 1a.
   Encapsulation keeps the code points separate.
   There is the further (significant) advantage that objects 
   from other protocols can also be encapsulated which provides
   great future extensibility.
   We should note, however, that there is no impact on issues
   1b, 1c, or 1d.
   There is also no change to the mechanism for documentation.
   In particular, it is still necessary to document the meaning
   of the fields in the context of PCE, and this would mean that
   as new objects (from any protocol) are made available for 
   encapsulation new I-Ds would be needed to  describe how
   they identify constraints or response information. Further,
   if an existing object is modified in an I-D for some other 
   protocol, a new I-D would be needed for PCEP to explain how
   the new fields are used (if they are used). 
   There might be limited exceptions to this when interpretation
   is obvious and unambiguous.
 
 3. Define new objects within PCEP
   In this option new objects are defined specifically for PCEP.
   Where the contents of the object are identical to those in 
   some other protocol, this can be documented by reference, but
   the PCEP I-D has to describe how they are used in the PCE 
   context.
   Where only some of the fields are identical to those in an 
   object (or several objects) in another protocol they need to
   be documented, but unused protocol fields do not need to be 
   reproduced in PCEP.
   This option solves all of the issues 1a, 1b, 1c and 1d, but
   introduces the need for new source code that cannot be common
   with the protocol code used in some other component.
   There are no documentation requirements for changes to other  
   protocols, but there may be more to do when new information 
   is added to PCEP.
   [Note that this option says much less about how the 
    information is actually encoded.]

Discuss.

Thanks,
Adrian

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 10 Aug 2005 23:40:10 +0200

adrian

even if the syntax of some of the objects can be maintained their 
processing is going to be different anyway so independently of their 
encoding the PCEP I-D has to describe how these objects are going to be 
used in the PCE context - the reason for this is pretty clear having a 
protocol for signaling end-to-end traffic parameters and perform 
resource reservation is radically different from having a client-server 
protocol for requesting path computation based on a set of specific 
constraints (by the way reducing the set of constraints and focus on a 
restricted set of strictly required constraints and not a desirable set 
of constraint would also help in assessing the problem)

the re-use of parsers is in any case going to imply introduction of 
masks for subobjects or fields that do not have a specific semantic (i 
should also point out that these objects will be processed in the 
context of the message into which they are received and afaik PCEP 
defines a new set of messages) but in addition one will require to carry 
them over since the protocol is also meant for the PCE-PCE communication 
or even worst have another semantic in the context of PCEP (rather than 
the current RSVP-TE implementation) therefore the re-usability argument 
is going to fall short after a small couple of cycles

on the other way, if option 1 is selected what is going to happen when 
the PCEP protocol will need additional specific subobject(s) or value(s) 
? are we going to also have to update the corresponding RSVP-TE object ? 
forget about you are simply going to put in place "yet another" flavor 
for the interpretation of the RSVP-TE objects and the last thing that is 
desirable is to reduce the genericity of their applicability

option 2 is also not going to provide any specific help from this 
perspective simply because instead of having to deal with one set of 
objects (i.e. those defined in the RSVP context) one is potentially 
going to face a set of set of such objects and related issues

therefore, only option 3 remains, it is imho the only viable solution

thanks,
- dimitri.

Adrian Farrel wrote:

> Hi,
> 
> I have a question remaining about the PCEP spec, and I would
> appreciate input from the WG and from the DT.
> 
> There is clearly considerable overlap between the information that
> needs to be carried by PCEP and that which is signaled by RSVP-TE.
> This is not a surprise because many of the constraints are identical.
> As a result, when deriving ways to encode this information it makes
> sense (to me and apparently to the DT) to re-use encodings that
> already exist.
> 
> This takes care of many of the details, but it leaves a high-level
> question. We should choose between the three options listed below.
> 
> 1. Re-use RSVP-TE objects entirely unchanged In this option, PCEP
> messages can carry objects encoded as RSVP-TE objects using the same
> C-Num and C-Type as defined for RSVP-TE. The disadvantages of this
> mechanism are: a. RSVP and PCEP share the same code-point space with
> the possible result that the space will become depleted. b. Changes
> to the RSVP-TE object will result in the receipt of unexpected
> variants to the PCEP object. I don't know whether this will matter
> since the RSVP processing rules will require backward compatibility. 
> c. Fields that are not required in PCE will be transported but not
> used. d. Subobjects that are not required in PCE are ambiguous. This
> option would be documented as follows: My_Object C-Num and C-Type as
> for RSVP-TE [RFCwxyz] The content of this object is defined in
> [RFCwxyz] In the context of PCE the fields of this object are 
> interpreted as follows:
> 
> Field 1: Blah, blah, blah
> 
> Field 2: etc.
> 
> 2. Encapsulate RSVP-TE objects entirely unchanged As currently
> documented, the ENCAP object solves problem 1a. Encapsulation keeps
> the code points separate. There is the further (significant)
> advantage that objects from other protocols can also be encapsulated
> which provides great future extensibility. We should note, however,
> that there is no impact on issues 1b, 1c, or 1d. There is also no
> change to the mechanism for documentation. In particular, it is still
> necessary to document the meaning of the fields in the context of
> PCE, and this would mean that as new objects (from any protocol) are
> made available for encapsulation new I-Ds would be needed to
> describe how they identify constraints or response information.
> Further, if an existing object is modified in an I-D for some other 
> protocol, a new I-D would be needed for PCEP to explain how the new
> fields are used (if they are used). There might be limited exceptions
> to this when interpretation is obvious and unambiguous.
> 
> 3. Define new objects within PCEP In this option new objects are
> defined specifically for PCEP. Where the contents of the object are
> identical to those in some other protocol, this can be documented by
> reference, but the PCEP I-D has to describe how they are used in the
> PCE context. Where only some of the fields are identical to those in
> an object (or several objects) in another protocol they need to be
> documented, but unused protocol fields do not need to be reproduced
> in PCEP. This option solves all of the issues 1a, 1b, 1c and 1d, but 
> introduces the need for new source code that cannot be common with
> the protocol code used in some other component. There are no
> documentation requirements for changes to other protocols, but there
> may be more to do when new information is added to PCEP. [Note that
> this option says much less about how the information is actually
> encoded.]
> 
> 
> Discuss.
> 
> Thanks, Adrian
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Pce mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Aug 2005 23:37:45 +0100

Well, we weren't exactly flooded with responses on this issue, but there
seemed to be a slight preference for option 3 with no-one speaking up for
options 1 and 2.

Since the current PCEP I-D uses option 2 and only introduces option 3 for
entirely new or very significantly different objects, it would be
interesting to hear the views of the authors on this issue.

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 10, 2005 6:47 PM
Subject: [Pce] PCEP ENCAP object

Hi,

I have a question remaining about the PCEP spec, and I would appreciate
input from the WG and from the DT.

There is clearly considerable overlap between the information that needs
to be carried by PCEP and that which is signaled by RSVP-TE. This is not a
surprise because many of the constraints are identical. As a result, when
deriving ways to encode this information it makes sense (to me and
apparently to the DT) to re-use encodings that already exist.

          Field 1:
             Blah, blah, blah

          Field 2:
             etc.

Discuss.

Thanks,
Adrian

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

---

From: Stephen Morris <[email-masked]>
Date: Wed, 24 Aug 2005 00:44:45 +0100 (BST)

Hi All
I have a few comments/suggestions about the
architecture document sections 8.1, 8.3, & 10:

(1) Section 8.1
I suggest we allow path computations to be initiated
using SNMP (e.g., set a variable). This potentially
opens up PCE technology to existing NMS/OSS products.
Just a new (PCE) MIB module and some backend code is
needed to integrate PCE technology in this case.

Path computation completion might be indicated by an
informational notification or an SNMP response.
Another approach might be the use of polling to allow
a PCC to query PCE completion of a path request.

(2) Section 8.3
Correctness - maybe provide ping access through SNMP?

(3) Section 10
IANA might be needed for the MIB module?

(4) A further manageability item is deployment or
software distribution. Let's say I have LSR X from
vendor Y and I want to upgrade LSR X to include PCE
capability. Or let's say I want to upgrade a number of
LSRs to support PCE. While this is mostly an NMS/OSS
issue (ftp, tftp etc.), the PCE element can help by
supporting software version data (i.e., deployment
data).

Best wishes
Stephen Morris

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com