Subject: RE: [Pce] PCEP ENCAP object

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 23 Aug 2005 18:10:13 +0200

Hi Adrian,
 
Please see inline

________________________________

	De : Adrian Farrel [mailto:[email-masked]] 
	Envoyé : mardi 23 août 2005 13:14
	À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
	Objet : Re: [Pce] PCEP ENCAP object

	Hi JL,
	 
	Thanks for responding.
	 
	I think I need to draw your attention to the precise wording that I put in option 3. 
	
	>>    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.
	 
	That is, to use your example of the ERO, the PCEP text would define a new object and would state something like...
	   The contents of this object are identical in encoding to the
	   contents of the RSVP-TE Explicit Route Object. That is, the
	   object is constructed from a series of sub-objects. Any 
	   sub-object defined for use in the ERO is acceptable in this
	   object.
	[JLLR] You would end up with PCEP objects made of RSVP sub-objects, and from a pure protocol design point of view this sounds quite ugly :-(

	   This object is used to report an explicit path that has been
	   computed by a PCE. 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.
	
	This is not particularly heavy IMHO, and does not represent a significant gain from the ENCAPs object.
	
	[JLLR] 
	With option 3 you solve option 1 issues by having separate name spaces and actually by introducing a mapping between RSVP name space and PCEP name space (i.e. PCEP object x content = RSVP object y content).
	 
	The rationale for option 2 is to avoid such mapping. 
	By the way the ENCAP object saves PCEP name space and maybe in 10 years we may face PCEP name space saturation :-) (see what happens with RSVP name space...)
	 
	Regards,
	 
	JL

	Thanks,
	Adrian
	 
	----- Original Message ----- 
	From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked] <mailto:[email-masked]> >
	To: <[email-masked] <mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]> >
	Sent: Tuesday, August 23, 2005 10:43 AM
	Subject: RE: [Pce] PCEP ENCAP object

	Hi Adrian, all
	
	Option 2+3 sounds the best way to progress, as it provides a good flexibility.
	Option 3 only could, for some objects, be really heavy... take ERO for instance and think about redocumenting all ERO subobjects types from 3902, 3473, 3477...
	
	Note that in current PCEP version we carefully use option 2 only when useful (4 of 13 objects), 
	and this is not the default option.
	
	Note that option 2 must be used only when there is a significant gain (e.g. ERO).
	
	Regards,
	
	JL

	> -----Message d'origine-----
	> De : [email-masked] <mailto:[email-masked]>  
	
	> [mailto:[email-masked]] De la part de Adrian Farrel
	> Envoyé : mardi 23 août 2005 00:38
	> À : [email-masked] <mailto:[email-masked]> 
	> Objet : Re: [Pce] PCEP ENCAP object
	> 
	> 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] <mailto:[email-masked]> >
	> To: <[email-masked] <mailto:[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.
	> 
	> 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] <mailto:[email-masked]> 
	> > https://www1.ietf.org/mailman/listinfo/pce <https://www1.ietf.org/mailman/listinfo/pce> 
	> >
	> 
	> 
	> _______________________________________________
	> Pce mailing list
	> [email-masked] <mailto:[email-masked]> 
	> https://www1.ietf.org/mailman/listinfo/pce <https://www1.ietf.org/mailman/listinfo/pce> 
	> 

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