Subject: [Pce] Switching type Constraint in PCEP

From: "fabien.verhaeghe" <[email-masked]>
Date: Wed, 28 Mar 2007 10:56:05 +0200

Hi,

In RFC4657 one of the generic requirement concerns the support of switching/encoding type constraint
for GMPLS.

Is there any ongoing work about this item?

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

---

From: Dan Li <[email-masked]>
Date: Wed, 28 Mar 2007 17:36:18 +0800

Hi Fabien,

There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which may relate to this issue. But the switching/encoding type may be considered as an attribute of a TE-link, so I doubt it has something to do with the PCEP.

Regards,

Dan

  ----- Original Message ----- 
  From: fabien.verhaeghe 
  To: [email-masked] 
  Sent: Wednesday, March 28, 2007 4:56 PM
  Subject: [Pce] Switching type Constraint in PCEP

  Hi,

  Thanks
  Fabien

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 28 Mar 2007 12:18:33 +0200

Hi Fabien,
 
The switching type/encoding type used to be carried in earlier versions of PCEP
( GENERALIZED LABEL OBJECT in http://www.watersprings.org/pub/id/draft-vasseur-pce-pcep-00.txt).
We decided to remove it from the base spec as this is application specific.
This will be covered in a separate document (for instance switching/encoding type could be encoded in a optional TLV of the LSPA object).
 
Best Regards,
 
JL

________________________________

	De : Dan Li [mailto:[email-masked]] 
	Envoyé : mercredi 28 mars 2007 11:36
	À : fabien.verhaeghe; [email-masked]
	Objet : Re: [Pce] Switching type Constraint in PCEP

	Hi Fabien,

	Regards,
	 
	Dan

		----- Original Message ----- 
		From: fabien.verhaeghe <mailto:[email-masked]>  
		To: [email-masked] 
		Sent: Wednesday, March 28, 2007 4:56 PM
		Subject: [Pce] Switching type Constraint in PCEP

		Hi,

		 
		Thanks
		Fabien

________________________________

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Mar 2007 12:46:33 +0100

Just to complete the sequence of referenced I-Ds...

http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-04.txt 
discusses the requirements for multi-layer path computation (while 
http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-03.txt 
gives a framework for the use of PCE in a multi-layer network).

Section 5.1.3 of draft-ietf-pce-inter-layer-req-04.txt describes the 
specific requirements that you mention for switching type. And section 5.1.4 
discusses adaptation capabilities.

We have not, so far, added a requirement for encoding type and are not clear 
whether this is a constraint that is necessary. We'd be interested to have 
this discussion.

Before the Prague meeting, Eiji Oki started to put together the necessary 
protocol extensions in support of this work, but we held off publication 
because the base PCEP needed to advance a bit more. I guess this sounds like 
the community is ready for this draft now.

Cheers,
Adrian

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Dan Li" <[email-masked]>; "fabien.verhaeghe" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, March 28, 2007 11:18 AM
Subject: RE: [Pce] Switching type Constraint in PCEP

Hi Fabien,

The switching type/encoding type used to be carried in earlier versions of 
PCEP
( GENERALIZED LABEL OBJECT in 
http://www.watersprings.org/pub/id/draft-vasseur-pce-pcep-00.txt).
We decided to remove it from the base spec as this is application specific.
This will be covered in a separate document (for instance switching/encoding 
type could be encoded in a optional TLV of the LSPA object).

Best Regards,

JL

Hi Fabien,

There is a draft "draft-otani-ccamp-gmpls-cspf-constraints-05.txt" which may 
relate to this issue. But the switching/encoding type may be considered as 
an attribute of a TE-link, so I doubt it has something to do with the PCEP.

Regards,

Dan

----- Original Message ----- 
From: fabien.verhaeghe <mailto:[email-masked]>
To: [email-masked]
Sent: Wednesday, March 28, 2007 4:56 PM
Subject: [Pce] Switching type Constraint in PCEP

Hi,

In RFC4657 one of the generic requirement concerns the support of 
switching/encoding type constraint
for GMPLS.

Thanks
Fabien

---

From: "fabien.verhaeghe" <[email-masked]>
Date: Wed, 28 Mar 2007 16:05:42 +0200

Hi Dan, JL, Adrian,

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.

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?

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 :-). 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 ;-).

Regards
Fabien

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

Cheers,
Adrian

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Dan Li" <[email-masked]>; "fabien.verhaeghe"

Hi Fabien,

Best Regards,

JL

Hi Fabien,

Regards,

Dan

----- Original Message ----- 
From: fabien.verhaeghe <mailto:[email-masked]>
To: [email-masked]
Sent: Wednesday, March 28, 2007 4:56 PM
Subject: [Pce] Switching type Constraint in PCEP

Hi,

Thanks
Fabien

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Mar 2007 16:18:53 +0100

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.
> (e.g. to computate a Lambda path using a TE Database that contains also 
> TDM TE Links).

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".

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
> 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

---

From: Tomohiro Otani <[email-masked]>
Date: Fri, 30 Mar 2007 08:44:55 +0900

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).
> 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.
> 
>> "application specific" requirements. Generic Requirement RFC4657 
>> section 5.1.16
> 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 :-).
> 
>> 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.
> 
> 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
> 
>