Subject: RE: [Pce] PCEP ENCAP object

From: "Don Fedyk" <[email-masked]>
Date: Wed, 10 Aug 2005 14:54:52 -0400

Hi Adrian
 
I would vote for option 3. 
Reason decoupling and restarting is better.   While there may be short
term reuse I think PCEP should start from a clean slate and clean
documentation.  
 
Regards,
Don 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Wednesday, August 10, 2005 1:47 PM
To: [email-masked]
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.

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: "Igor Bryskin" <[email-masked]>
Date: Wed, 10 Aug 2005 16:53:59 -0400

Hi,

I agree with Don completely.

PCEP and RSVP never communicate directly, rather, through some application.
For instance, EROs received from a remote PCE are needed to go through some
processing before they will be inserted into the Path message. No one would
do the processing in the ERO wire format, there will be a need for some host
representation. Hence it is almost irrelevant whether PCEP and RSVP EROs are
encoded 100% identically or completely differently.
The benefits of sharing parsers and decoding tools are too minor to justify
the unnecessary IMO dependency between PCEP and RSVP object encoding.

Besides, one can argue that it is both unrealistic and unnecessary to
attempt to signal all possible PCE constraints, objection functions,
diversity types, etc. in the RSVP Path message (that's why the requirement
for PCEP flexibility is so much higher compared to one of the RSVP). Also
LSRs are not the only ultimate users of the PCEP. It is easy to imagine that
NMSs,  network builders, simulators, etc. (that is, not RSVP speakers) will
make use of remote PCE. Also, what if PWE3 folks would like to include the
remote PCE into their architecture but refuse using RSVP?

The bottom line: PCEP and RSVP should be completely decoupled in my opinion.

Cheers,
Igor