Subject: Re: [Pce] Switching type Constraint in PCEP

From: "fabien.verhaeghe" <[email-masked]>
Date: Mon, 2 Apr 2007 15:45:42 +0200

Hi Adrian,

>> However, where we seem to have arrived is that the PCEP I-D contains the 
>> protocol definition and "core" functional units. Other units that were 
>> identified in 4657 (such as XRO, objective funcions, ...) are going into 
>> seperate I-Ds. Following that model, the GMPLS-specific work definitely 
>> goes into a separate draft. As above, I am comfortable for that to be in 
>> the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to 
>> help keep the number of I-Ds manageable

Having a unique "GMPLS and multi-layer requirement" document seems a good 
idea to me.
If we'd have 2 seperate drafts I'm afraid there would be some overlapping 
just like for the switching type.

>> So my view (other will surely correct me :-) is that encoding type is 
>> only needed where the signal is unpacked for some reason. Typically, this 
>> only happens at end points, so the PCE function is to ensure that the 
>> destination interface is capable of decoding the signal and delivering 
>> the data. In general, it has been considered that the destination 
>> capabilities are either known to the ingress (guaranteed LSP setup 
>> success - you wouldn't even bother trying to set up an LSP to someone you 
>> knew couldn't understand you) or are not known in which case the LSP will 
>> either succeed or fail (but no amount of re-routing will help). Now, it 
>> *is* possible that different interfaces on the egress have different 
>> levels of support for encoding types, but this has generally been 
>> considered as very advanced and not worth optimising for.
>>
>> However, recent discussion has suggested that in certain technologies, 
>> signal regeneration also requires knowledge of the encoding type. This 
>> would certainly expand the requirement for PCE to know about encoding 
>> type. I am not sure about the hardware specifics here and perhaps someone 
>> can enlighten us.

Thank you Adrian for the clarification. It helps a lot :-)...

Regards
Fabien

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "fabien.verhaeghe" <[email-masked]>; "LE ROUX 
Jean-Louis RD-CORE-LAN" <[email-masked]>; "Dan Li" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 29, 2007 5:18 PM
Subject: Re: [Pce] Switching type Constraint in PCEP

> Hi Fabien,
>
>> Reading the generic and inter layer requirement documents it is not clear 
>> to me if Switching Type is really specific to inter layer application.
>> As far as I understand inter-layer requirement refers to path computation 
>> which result path may comprise multiple layer technologies.
>> Though I understand Switching type is required in this context, it is 
>> also
>> required for mono layer path computation in a multi-layer environment
>> (e.g. to computate a Lambda path using a TE Database that contains also 
>> TDM TE Links).
>> So it is more a GMPLS specific requirement to me.
>
> I think you are correct. That is, the switching type constraint is 
> required in the multi-layer context, but it may have wider applicability.
>
> Provided that the multi-layer work progress quite quickly, I would suggest 
> that it is convenient to group all of the protocol extensions together. 
> You can then select from the set of optional objects as necessary for your 
> application. I would hope that you would provide your review input to the 
> multi-layer work to ensure that the protocol extensions give you what you 
> need.
>
> On the other hand, if the multi-layer work seems to get stuck or held up, 
> then I would understand you pushing to get the "GMPLS-specific" extensions 
> done separately.
>
>> Acually it is not clear to me what is the scope of generic and 
>> "application specific" requirements. Generic Requirement RFC4657 section 
>> 5.1.16
>> mention Switching and encoding type as "GMPLS specific requirements".
>> Does it mean "GMPLS specific" is "considered as generic?
>
> Hmmm.
> This is a line we have not succeeded in drawing very clearly.
>
> However, where we seem to have arrived is that the PCEP I-D contains the 
> protocol definition and "core" functional units. Other units that were 
> identified in 4657 (such as XRO, objective funcions, ...) are going into 
> seperate I-Ds. Following that model, the GMPLS-specific work definitely 
> goes into a separate draft. As above, I am comfortable for that to be in 
> the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to 
> help keep the number of I-Ds manageable.
>
>> Concerning the necessity of "encoding type" in PCEP I have to admit that 
>> I'm not sure to correctly understand the meaning of this parameter in the 
>> GMPLS
>> architecture :-).
>
> I think this puts you in the majority!
>
>> What I understand at least is that it is both an interface and
>> an LSP property, so from this it seems to be required in PCEP.
>> I would be interested to see discussion about encoding type
>> requirement in PCEP cause it may clarify the encoding type meaning to me 
>> ;-).
>
> So my view (other will surely correct me :-) is that encoding type is only 
> needed where the signal is unpacked for some reason. Typically, this only 
> happens at end points, so the PCE function is to ensure that the 
> destination interface is capable of decoding the signal and delivering the 
> data. In general, it has been considered that the destination capabilities 
> are either known to the ingress (guaranteed LSP setup success - you 
> wouldn't even bother trying to set up an LSP to someone you knew couldn't 
> understand you) or are not known in which case the LSP will either succeed 
> or fail (but no amount of re-routing will help). Now, it *is* possible 
> that different interfaces on the egress have different levels of support 
> for encoding types, but this has generally been considered as very 
> advanced and not worth optimising for.
>
> However, recent discussion has suggested that in certain technologies, 
> signal regeneration also requires knowledge of the encoding type. This 
> would certainly expand the requirement for PCE to know about encoding 
> type. I am not sure about the hardware specifics here and perhaps someone 
> can enlighten us.
>
> Cheers,
> Adrian
>
> 

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

---

From: "fabien.verhaeghe" <[email-masked]>
Date: Tue, 3 Apr 2007 13:07:35 +0200

Hi Tomo,

I read your draft pointed by Dan that indeed contains some valuable 
information.
Especially in section 2.2:

"For the simplicity of the analysis in path consideration, the below
   basic assumptions are made when the LSP is created.

       (1) Switching capabilities (SC) of outgoing links from the
           ingress and egress nodes (link1-2 and link4-3 in Figure 1)
           must be consistent with each other.
       (2) SC of all transit links including incoming links to the
           ingress and egress nodes (link2-1 and link3-4) should be
           consistent with switching type of a LSP to be created.
       (3) Encoding-types of all transit links should be consistent
           with encoding type of a LSP to be created."

Point 2 and 3 seems to imply that a PCE needs to know both the switching and 
encoding type
of the LSP.
To me the information would typically be provided by the PCC (which knows 
what kind of LSP is being established)
using PCEP.
Am I misunderstanding something or do you agree?

Regards
Fabien

----- Original Message ----- 
From: "Tomohiro Otani" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "fabien.verhaeghe" <[email-masked]>; "LE ROUX 
Jean-Louis RD-CORE-LAN" <[email-masked]>; "Dan Li" 
<[email-masked]>; <[email-masked]>
Sent: Friday, March 30, 2007 1:44 AM
Subject: Re: [Pce] Switching type Constraint in PCEP

> Hi Fabien and Adrian,
>
> Looking at the discussion, path computation itself and a protocol
> staff such as PCEP are a different thing.  I believe, touch upon
> by Dan, that our cspf draft is a kind of guideline how to consider
> GMPLS-specific constrains including encoding type for path computation.
> I hope that the cspf draft help Fabien to understand parameters.
>
> If you need any help for GMPLS specific extensions, please let me know.
>
> With best regards,
>
> Tomo
>
>
>
> Adrian Farrel wrote:
>> Hi Fabien,
>>
>>> Reading the generic and inter layer requirement documents it is not
>>> clear to me if Switching Type is really specific to inter layer
>>> application.
>>> As far as I understand inter-layer requirement refers to path
>>> computation which result path may comprise multiple layer technologies.
>>> (e.g. to computate a Lambda path using a TE Database that contains
>>> also TDM TE Links).
>> Provided that the multi-layer work progress quite quickly, I would
>> suggest that it is convenient to group all of the protocol extensions
>> together. You can then select from the set of optional objects as
>> necessary for your application. I would hope that you would provide your
>> review input to the multi-layer work to ensure that the protocol
>> extensions give you what you need.
>>
>> On the other hand, if the multi-layer work seems to get stuck or held
>> up, then I would understand you pushing to get the "GMPLS-specific"
>> extensions done separately.
>>
>>> "application specific" requirements. Generic Requirement RFC4657
>>> section 5.1.16
>>> Concerning the necessity of "encoding type" in PCEP I have to admit
>>> that I'm not sure to correctly understand the meaning of this
>>> parameter in the GMPLS
>>> architecture :-).
>>
>>> requirement in PCEP cause it may clarify the encoding type meaning to
>>> me ;-).
>>
>> only needed where the signal is unpacked for some reason. Typically,
>> this only happens at end points, so the PCE function is to ensure that
>> the destination interface is capable of decoding the signal and
>> delivering the data. In general, it has been considered that the
>> destination capabilities are either known to the ingress (guaranteed LSP
>> setup success - you wouldn't even bother trying to set up an LSP to
>> someone you knew couldn't understand you) or are not known in which case
>> the LSP will either succeed or fail (but no amount of re-routing will
>> help). Now, it *is* possible that different interfaces on the egress
>> have different levels of support for encoding types, but this has
>> generally been considered as very advanced and not worth optimising for.
>>
>> type. I am not sure about the hardware specifics here and perhaps
>> someone can enlighten us.
>>
>> Cheers,
>> Adrian
>>
>>