Subject: [Pce] Interested in working on a new ID ?

From: JP Vasseur <[email-masked]>
Date: Fri, 17 Feb 2006 12:45:23 -0500

Dear WG,

We discussed some time ago about the use of existing objects (e.g.  
RSVP) in PCEP messages so as to specify constraints, return computed  
paths and so on. There were two possible approaches:

(1) Define a PCEP object that would carry non PCEP object.
(2) Specify an identical object with a PCEP codepoint.

(1) was rejected because of potential ambiguity in the interpretation  
of the non PCEP object in a PCEP context, thus we elected to adopt  
the (2) approach. For example, in the current PCEP ID:

  7.8. ERO Object

        The ERO object is used to encode a TE LSP path. If can either be
        carried within a PCReq message to specify the existing path  
of a TE
        LSP to be reoptimize or within a PCRep message to provide a  
computed
        TE LSP.

        The contents of this object are identical in encoding to the  
contents
        of the Explicit Route Object defined in [RSPV-TE], [GRSVP]  
and [RSVP-
        UNNUM]. That is, the object is constructed from a series of sub-
        objects. Any RSVP ERO sub-object already defined or that  
could be
        defined in the future for use in the ERO is acceptable in this
        object.

        PCEP ERO sub-object types correspond to RSVP ERO sub-object  
types.

        Since the explicit path is available for immediate signaling  
by the
        MPLS or GMPLS control plane, the meanings of all of the sub- 
objects
        and fields in this object are identical to those defined for  
the ERO.

        ERO Object-Class is to be assigned by IANA (recommended value=7)
        ERO Object-Type is to be assigned by IANA (recommended value=1)

        7.9. RRO Object

        The RRO object is used to record the route followed by a TE  
LSP. The
        PCEP RRO object is exclusively carried within a PCReq message  
so as
        to specify the route followed by a TE LSP for which a  
reoptimization
        is desired.

        The contents of this object are identical in encoding to the  
contents
        of the Route Record Object defined in [RSPV-TE], [G-RSVP] and  
[RSVP-
        UNNUM]. That is, the object is constructed from a series of sub-
        objects. Any RSVP RRO sub-object already defined or that  
could be
        defined in the future for use in the RRO is acceptable in this
        object.

        The meanings of all of the sub-objects and fields in this  
object are
        identical to those defined for the RRO.

        PCEP RRO sub-object types correspond to RSVP RRO sub-object  
types.

        RRO Object-Class is to be assigned by IANA (recommended value=8)
        RRO Object-Type is to be assigned by IANA (recommended value=1)

There are other examples such as the PROTECTION object (draft-ietf- 
ccamp-gmpls-recovery-e2e-signaling-03.txt ), <CLASSTYPE> (RFC4124), ...

It would be a good idea to have a separate ID to get PCEP codepoint  
for these objects (for which the format is likely to remain  
unchanged) and potentially (if needed) clarify the interpretation of  
these objects in a PCEP context.

Any volunteer to drive this ?

Thanks,

JP and Adrian.

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