Subject: RE: [Pce] PCEP Request ID

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 7 Sep 2007 19:07:08 +0200

Hi Fabien
 
Thanks for your comment.
 
Please see inline,

________________________________

	De : Fabien VERHAEGHE [mailto:[email-masked]] 
	Envoyé : vendredi 10 août 2007 14:26
	À : [email-masked]
	Objet : [Pce] PCEP Request ID

	Hello all,

	I have a little comment/suggestion on PCEP regarding the request Id.

	In section 7.3.1 states that

	"The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely 

	identify the path computation request context".

	I agree with that, however there may be 2 requests with same request Id exchanged on the same session in 

	the case of session between 2 PCEs. 

	One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to PCE#1.

	I don't think there is any problem with that but I am a little concerned about potential misinterpretation especially

	in PCErr and PCNotif message.

	If a PCNtf/PCErr message contains an RP object, nothing indicates if it is related to the Request from PCE#1 to PCE#2

	or the one from PCE#2 to PCE#1, except the notification/error type and value. 

	I guess this is why for instance for the "Pending Request cancelled" notification there are 2 values. One for PCC and

	one for the PCE. 

	Yes, this is exactly the reason why there are two values. 

	One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in order to retrieve

	the correct PathRequest. 

	Anyway, you have to parse the entire message. 

	There are other implementations that first parse the whole message and then start processing the objects.

	This is IMO and implementation issue.

	Another problem is if an implementation does not recognize a given Error type/value, then it can't tell for sure which PathRequest it

	is related to. 

	Anyway an Error related to a request is always sent in the PCE-PCC direction 

	So it seems to me it would be more consistent to add a bit in the RP object (in the flag field) to indicate the

	"direction" of the PathRequest.

	For instance if the bit is set the Message that carry the RP object is related to the request sent by the destination of the message. 

	Hence, an RP object would actually uniquely indentifies a PathRequest. 

	There maybe an ambiguity only in a few error/notif situations, and I don't think adding a generic bit would be really useful.

	 By the way this would be a significant change wilth potentially new error situations to handle (what do you do if the direction PCC to PCE is set in a reply message?) .

	Is that OK with you if we keep as is?

	Best Regards,

	JL

	Regards

	Fabien Verhaeghe

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

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Mon, 10 Sep 2007 10:07:33 +0200

Hi Jean-Louis,

Thanks for the reply.

See inline for mine…

Best regards

Fabien

  _____  

De : LE ROUX Jean-Louis RD-CORE-LAN
[mailto:[email-masked]] 
Envoyé : vendredi 7 septembre 2007 19:07
À : [email-masked]; [email-masked]
Objet : RE: [Pce] PCEP Request ID

Hi Fabien

Thanks for your comment.

Please see inline,

  _____  

Hello all,

“The Request-ID-number value combined with the source IP address of the PCC
and the PCE address uniquely 

identify the path computation request context”.

I agree with that, however there may be 2 requests with same request Id
exchanged on the same session in 

One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to
PCE#1.

I don’t think there is any problem with that but I am a little concerned
about potential misinterpretation especially

If a PCNtf/PCErr message contains an RP object, nothing indicates if it is
related to the Request from PCE#1 to PCE#2

or the one from PCE#2 to PCE#1, except the notification/error type and
value. 

I guess this is why for instance for the “Pending Request cancelled”
notification there are 2 values. One for PCC and

one for the PCE. 

So we would not need to define 2 values if the RP object fully identify the
PathRequest. 

>From a protocol specification point of view it seems more straightforward to
me.

One of the problem, from an implementation perspective, is that we must
first ready the Notification type/value in order to retrieve

the correct PathRequest. 

There are other implementations that first parse the whole message and then
start processing the objects.

I agree that it is partly an implementation issue. However, the
implementation can be optimised if the RP object fully identifies the
PathRequest.

For instance, you would not need to decode the Error object if the
PathRequest is unknown. 

Another problem is if an implementation does not recognize a given Error
type/value, then it can’t tell for sure which PathRequest it

is related to. 

 

I agree this is true today but will it still be true with future PCEP
extensions.

If it is this a strict rules I think it should be mentioned in the draft.

However can’t we imagine that a PCC sends an Error message to a PCE because
it does not like the Reply sent by the PCE?

e.g. the Path does not respect the requested constraints.

Besides we still that have a problem in case of unrecognised Notification
type/value.

So it seems to me it would be more consistent to add a bit in the RP object
(in the flag field) to indicate the

“direction” of the PathRequest.

For instance if the bit is set the Message that carry the RP object is
related to the request sent by the destination of the message. 

There maybe an ambiguity only in a few error/notif situations, and I don't
think adding a generic bit would be really useful.

By the way this would be a significant change wilth potentially new error
situations to handle (what do you do if the direction PCC to PCE is set in a
reply message?) .

I don’t really see it as a significant change.

For the Error case I think it would be ok to say that the bit must be set in
PCReq and Clear in PCRep  message and must be ignored upon reception.

Besides if we keep the RP object as is what do you do if you receive a PCNtf
message with formatted as follows:

<RP><Notif1><Notif2> with Notif 1 and Notif2 being “pending request
cancelled” but one with Notification value 1 and the other with notification
value 2.

It seems this is anyway an error case that must be specified with current
PCEP specification.

So basically I agree that it is partly an implementation problem and that it
is possible to do with current specification

But it seems to me, from a protocol design point of view it would be more
consistent if the RP object fully identify the PathRequest.

Best Regards,

JL

Regards

Fabien Verhaeghe

---

From: JP Vasseur <[email-masked]>
Date: Thu, 13 Sep 2007 18:38:00 -0400

Hi Fabien,

Jumping at the end .... You wrote:

> So basically I agree that it is partly an implementation problem  
> and that it is possible to do with current specification
>
> But it seems to me, from a protocol design point of view it would  
> be more consistent if the RP object fully identify the PathRequest.
>

As you know the only potential issue is in the case of two pending
requests with the same ID between two PCEs and the related potential
Notification messages. In that case, we do have the Notification  
Value to
make sure that there is no ambiguity, as we did for the request  
cancellation
Notification message. And if one of the PCEs does not "understand" the
Notification itself, then trying to determine the request it relates  
to is
not relevant.

Agree ?

Thanks.

JP.

On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote:

> Hi Jean-Louis,
>
>
>
> Thanks for the reply.
>
> See inline for mine…
>
>
>
> Best regards
>
> Fabien
>
>
>
> De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:jeanlouis.leroux@orange- 
> ftgroup.com]
> “The Request-ID-number value combined with the source IP address of  
> the PCC and the PCE address uniquely
>
> I agree with that, however there may be 2 requests with same  
> request Id exchanged on the same session in
>
> I don’t think there is any problem with that but I am a little  
> concerned about potential misinterpretation especially
>
> If a PCNtf/PCErr message contains an RP object, nothing indicates  
> if it is related to the Request from PCE#1 to PCE#2
>
> I guess this is why for instance for the “Pending Request  
> cancelled” notification there are 2 values. One for PCC and
>
> one for the PCE.
>
>
>
> So we would not need to define 2 values if the RP object fully  
> identify the PathRequest.
>
> From a protocol specification point of view it seems more  
> straightforward to me.
>
>
>
> One of the problem, from an implementation perspective, is that we  
> must first ready the Notification type/value in order to retrieve
>
> the correct PathRequest.
>
>
>
> implementation can be optimised if the RP object fully identifies  
> the PathRequest.
>
> Another problem is if an implementation does not recognize a given  
> Error type/value, then it can’t tell for sure which PathRequest it
>
> is related to.
>
>
>
> I agree this is true today but will it still be true with future  
> PCEP extensions.
>
> However can’t we imagine that a PCC sends an Error message to a PCE  
> because it does not like the Reply sent by the PCE?
>
> Besides we still that have a problem in case of unrecognised  
> Notification type/value.
>
>
>
>
>
> So it seems to me it would be more consistent to add a bit in the  
> RP object (in the flag field) to indicate the
>
> For instance if the bit is set the Message that carry the RP object  
> is related to the request sent by the destination of the message.
>
> There maybe an ambiguity only in a few error/notif situations, and  
> I don't think adding a generic bit would be really useful.
>
> By the way this would be a significant change wilth potentially new  
> error situations to handle (what do you do if the direction PCC to  
> PCE is set in a reply message?) .
>
>
>
> For the Error case I think it would be ok to say that the bit must  
> be set in PCReq and Clear in PCRep  message and must be ignored  
> upon reception.
>
> Besides if we keep the RP object as is what do you do if you  
> receive a PCNtf message with formatted as follows:
>
>
>
> cancelled” but one with Notification value 1 and the other with  
> notification value 2.
>
>
>
> It seems this is anyway an error case that must be specified with  
> current PCEP specification.
>
>
>
> So basically I agree that it is partly an implementation problem  
> and that it is possible to do with current specification
>
> But it seems to me, from a protocol design point of view it would  
> be more consistent if the RP object fully identify the PathRequest.
>
>
>
> Best Regards,
>
>
>
> JL
>
>
>
> Regards
>
> Fabien Verhaeghe
>
>
>

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Fri, 14 Sep 2007 09:44:50 +0200

Hi,

I think there is a little problem with PCEP object TLV format.

The main problem being that the general format of the TLVs is not described
(Type, length value length, 4 bytes alignment.).

Besides for existing TLVs we have:

"The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request. 

The REQ-MISSING TLV is padded to eight-byte alignment.

TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request"

I think the LENGTH field should be set to 6, the unused field 2 bytes being
part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said that
all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused
field (2bytes) - Value field

Otherwise, there may be some problem when decoding a message with unknown
TLV.

Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte
alignment." statement.

Is it really needed?

For the NO-PATH-VECTFrom [email-masked] Fri Sep 14 05:51:23 2007
From: "Fabien VERHAEGHE" <[email-masked]>
To: <[email-masked]>
Date: Fri, 14 Sep 2007 09:44:50 +0200
Cc: 
Subject: [Pce] TLV Format
Reply-To: [email-masked]

This is a multi-part message in MIME format.
Hi,

I think there is a little problem with PCEP object TLV format.

The main problem being that the general format of the TLVs is not described
(Type, length value length, 4 bytes alignment.).

Besides for existing TLVs we have:

"The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request. 

The REQ-MISSING TLV is padded to eight-byte alignment.

TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request"

I think the LENGTH field should be set to 6, the unused field 2 bytes being
part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said that
all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused
field (2bytes) - Value field

Otherwise, there may be some problem when decoding a message with unknown
TLV.

Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte
alignment." statement.

Is it really needed?

For the NO-PATH-VECTOR TLV we have

"The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

   specifying the number of bytes in the value field, followed by a fix

   length value field of 32-bits flags field used to report the

   reason(s) that led to unsuccessful path computation.

   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.

TYPE: To be assigned by IANA

   LENGTH: 4

   VALUE: 32-bits flags field"

In this case there is no Unused field 2 bytes. 

I think it would be better to have the same format for all TLVs of all
object.

And again I'm wondering if the LENGTH field should be set to 4 or 6?

Can you please clarify this to me? Am I missing something?

Thanks

Fabien

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Fri, 14 Sep 2007 11:04:59 +0200

clarify
this to me? Am I missing something?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Thanks<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Fabien<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_003C_01C7F6B3.E5AA9890--

--===============0459779908==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0459779908==--

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Fri, 14 Sep 2007 11:04:59 +0200

Hi JP,

About the unknown notification I was thinking about cases where an
implementation may pass

the notification with the associated pathRequest to another module that may
be able to understand 

it. Or for instance if you just want to display the Notification with
information about the related PathRequest.

But my main point is rather that IMHO it would be more consistent if the RP
object unambiguously identifies the PathRequest rather

than defining 2 Error/Notification values.

However I agree that there is no actual issue with current specification and
if you think that work is maybe too advanced to change this

now that would be fine to me to let it as is.

Just another point regarding the discussion with Jean-Louis, About the fact
that Error message related to a PathRequest are always in

PCE to PCC direction, I just realized that this may not be totally true.

Error-Type 8 “Unknown request reference” is in the PCC to PCE direction.
Unless an implementation is not supposed to put the RP object in

the error message in this case (It is not explicitly said in section 7.3.2).

Best regards

Fabien

  _____  

De : JP Vasseur [mailto:[email-masked]] 
Envoyé : vendredi 14 septembre 2007 00:38
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Pce] PCEP Request ID

Hi Fabien,

Notification messages. In that case, we do have the Notification Value to 

make sure that there is no ambiguity, as we did for the request cancellation

Notification itself, then trying to determine the request it relates to is

not relevant.

Agree ?

Thanks.

JP.

Hi Jean-Louis,

Thanks for the reply.

See inline for mine…

Best regards

Fabien

  _____  

Hi Fabien

Thanks for your comment.

Please see inline,

  _____  

Hello all,

 

one for the PCE. 

>From a protocol specification ple

Hi JP,

About the unknown notification I was thinking about cases where an
implementation may pass

the notification with the associated pathRequest to another module that may
be able to understand 

it. Or for instance if you just want to display the Notification with
information about the related PathRequest.

But my main point is rather that IMHO it would be more consistent if the RP
object unambiguously identifies the PathRequest rather

than defining 2 Error/Notification values.

However I agree that there is no actual issue with current specification and
if you think that work is maybe too advanced to change this

now that would be fine to me to let it as is.

Just another point regarding the discussion with Jean-Louis, About the fact
that Error message related to a PathRequest are always in

PCE to PCC direction, I just realized that this may not be totally true.

Error-Type 8 “Unknown request reference” is in the PCC to PCE direction.
Unless an implementation is not supposed to put the RP object in

the error message in this case (It is not explicitly said in section 7.3.2).

Best regards

Fabien

  _____  

De : JP Vasseur [mailto:[email-masked]] 
Envoyé : vendredi 14 septembre 2007 00:38
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Pce] PCEP Request ID

Hi Fabien,

Notification messages. In that case, we do have the Notification Value to 

make sure that there is no ambiguity, as we did for the request cancellation

Notification itself, then trying to determine the request it relates to is

not relevant.

Agree ?

Thanks.

JP.

Hi Jean-Louis,

Thanks for the reply.

See inline for mine…

Best regards

Fabien

  _____  

Hi Fabien

Thanks for your comment.

Please see inline,

  _____  

Hello all,

 

one for the PCE. 

me.

the correct PathRequest. 

 

is related to. 

 

 

Best Regards,

JL

Regards

Fabien Verhaeghe

Pce mailing list

[email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Mon, 17 Sep 2007 17:09:26 -0400

Hi Fabien,

On Sep 14, 2007, at 5:04 AM, Fabien VERHAEGHE wrote:

> the notification with the associated pathRequest to another module  
> that may be able to understand
> it.

Then the info should be passed via the API.

> Or for instance if you just want to display the Notification with  
> But my main point is rather that IMHO it would be more consistent  
> if the RP object unambiguously identifies the PathRequest rather
> However I agree that there is no actual issue with current  
> specification and if you think that work is maybe too advanced to  
> change this

OK.

>
> Just another point regarding the discussion with Jean-Louis, About  
> the fact that Error message related to a PathRequest are always in
> Error-Type 8 “Unknown request reference” is in the PCC to PCE  
> direction. Unless an implementation is not supposed to put the RP  
> object in

But in this case there is no ambiguity that this is coming from the PCC.

Thanks.

JP.