Lou Berger | 1 Dec 16:25 2008
Picon

Re: Path Key I-D : number of bits

that's what "SHOULD" is for...

At 04:47 AM 11/30/2008, JP Vasseur wrote:

>On Nov 29, 2008, at 3:58 PM, Lou Berger wrote:
>
>>Sure, but that's their *implementation* issue. Standards don't stop
>>you from doing something stupid,
>
>Well standard should at least "warn" you from doing something stupid ...
>
>>but they shouln't stop you from doing something intelligent/creative
>>either...
>
>Surely.
>
>Cheers,
>
>JP.
>
>>Lou
>>-----Original Message-----
>>From: JP Vasseur <jvasseur <at> cisco.com>
>>
>>Date: Sat, 29 Nov 2008 14:05:46
>>To: Lou Berger<lberger <at> labn.net>
>>Cc: Adrian Farrel<adrian <at> olddog.co.uk>; <pce <at> ietf.org>
>>Subject: Re: [Pce] Path Key I-D : number of bits
>>
>>
(Continue reading)

Adrian Farrel | 7 Dec 11:54 2008
Picon

Conclusion on Path Key I-D : number of bits

Hi,

I don't see a lot of support for Lou's suggestion of having more than 16 
bits for the path key.

Lou points out that standards...
>>>shouln't stop you from doing something intelligent/creative

While the idea would certainly leave future implementations plenty of room 
to do clever things, we haven't had any indication that there is a pressing 
requirement for this change.

Lou wrote...
>>>>a 32 bit key would allow for
>>>>potential future cases that we can already envision as well as
>>>>today's known cases.  (BTW I know of one experimental usage of PCE
>>>>that I suspect will want this immediately.)

But this leaves us guessing, and without some further hints I don't think we 
can make a change based on this level of evidence.

In conclusion, Lou also said...
>>>>On the other hand, if changing this now also impacts
>>>>implementations, I think we should only support longer keys once
>>>>there is real (not today's theoretical) demand for them.

Since I have been told of successful interop test of the current definition, 
I suggest we leave things as they are.
If 32 bits (or more!) become a requirement in the future, we can develop a 
new subobject.
(Continue reading)

Iksoon Hwang | 9 Dec 16:34 2008
Picon

A case that never happens in OpenWait state

Dear all,

 

I’m currently working on a research project, called CARRIOCAS, which aims at providing dynamically reconfigurable high speed network for high-performance applications where PCEP is used for path computation. My work in the project is to do modeling, validation, verification, and testing of PCEP. PCEP was described in a formal language IF and some properties were validated. I have some questions that were found during my work. The questions will be posted in four separate emails including this one.

 

I found that there is a case that never happens in OpenWait state. Is there anybody who can give me any advice if I’m missing something? The detailed case is as follows.

 

In Appendix A, when a system in OpenWait state receives an Open message from its peer where no errors are detected, OpenRetry is 0, the session characteristics are unacceptable but negotiable, and LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state.

 

According to our experiments, we found that the above case cannot happen. We analyzed the reason and the result is as follows: we can have LocalOK=1 only when the system in KeepWait state receives a Keepalive message from its peer. Since the system can move to KeepWait state only after receiving an Open message from its peer in OpenWait state, the OpenRetry value is always more than 0 if we have LocalOK=1.

 

Thanks in advance!

 

    Iksoon

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-US">Dear all, <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I&rsquo;m currently working on a research project,
called CARRIOCAS, which aims at providing dynamically reconfigurable high speed
network for high-performance applications where PCEP is used for path
computation. My work in the project is to do modeling, validation,
verification, and testing of PCEP. PCEP was described in a formal language IF
and some properties were validated. I have some questions that were found
during my work. The questions will be posted in four separate emails including
this one. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I found that there is a case that never happens in
OpenWait state. Is there anybody who can give me any advice if I&rsquo;m
missing something? The detailed case is as follows.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In Appendix A, when a system in OpenWait state
receives an Open message from its peer where no errors are detected, OpenRetry
is 0, the session characteristics are unacceptable but negotiable, and
LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait
state.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">According to our experiments, we found that the above
case cannot happen. We analyzed the reason and the result is as follows: we can
have LocalOK=1 only when the system in KeepWait state receives a Keepalive
message from its peer. Since the system can move to KeepWait state only after
receiving an Open message from its peer in OpenWait state, the OpenRetry value
is always more than 0 if we have LocalOK=1.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Thanks in advance!<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Iksoon</span><span lang="EN-US"><p></p></span></p>

</div>

</div>
Iksoon Hwang | 9 Dec 16:45 2008
Picon

When should we start the Keepalive timer?

Dear all,

 

It seems that there are some problems in the explanation of Appendix A concerning with the Keepalive timer.

 

In section 4.2.1, Keepalive messages are used to acknowledge Open messages, and once the PCEP session has been successfully established.

 

In section 6.2, the PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer.

 

In Appendix A, if a system in OpenWait state receives an Open message from the PCEP peer before the expiration of the OpenWait timer, it performs collision resolution procedure. If there is no collision, no errors are detected in Open message, and the session characteristics are acceptable to the local system, the system:

   o  Sends a Keepalive message to the PCEP peer,

   o  Starts the Keepalive timer,

   o  Sets the RemoteOK variable to 1.

If LocalOK=0 the system clears the OpenWait timer, starts the KeepWait timer and moves to the KeepWait state.

 

The statement in section 4.2.1 and starting the Keepalive timer in OpenWait state when LocalOK=0 are contradictory because the system starts keepalive mechanism although the session is not established yet.

 

Also, it seems that there is another problem. In section 7.3, it is explained that "A sends an Open message to B with Keepalive=10 seconds and Deadtimer=40 seconds.  This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40 second period". The Keepalive timer should follow the Keepalive value in the Open message that was sent to its peer (not the Keepalive value in the Open message received from its peer). Therefore, the Keepalive timer can be set only after the peer accepted the parameter values in the Open, i.e. only after the system receives a Keepalive message from its peer.

 

I think the Keepalive timer and the Deadtimer should be started when the system moves to SessionUP state. Is there anybody who can give me any advice?

 

Thanks in advance.

 

    Iksoon

 

 

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-US">Dear all,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">It seems that there are some
problems in the explanation of Appendix A concerning with the Keepalive timer.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In section 4.2.1, Keepalive messages
are used to acknowledge Open messages, and once the PCEP session has been
successfully established.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In section 6.2, the PCEP session is
considered as established once both PCEP peers have received a Keepalive
message from their peer.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In Appendix A, if a system in
OpenWait state receives an Open message from the PCEP peer before the
expiration of the OpenWait timer, it performs collision resolution procedure.
If there is no collision, no errors are detected in Open message, and the
session characteristics are acceptable to the local system, the system:<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp; o&nbsp; Sends a
Keepalive message to the PCEP peer,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp; o&nbsp; Starts the
Keepalive timer,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp; o&nbsp; Sets the
RemoteOK variable to 1.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US">If LocalOK=0 the system clears the
OpenWait timer, starts the KeepWait timer and moves to the KeepWait state.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">The statement in section 4.2.1 and
starting the Keepalive timer in OpenWait state when LocalOK=0 are contradictory
because the system starts keepalive mechanism although the session is not
established yet. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Also, it seems that there is another
problem. In section 7.3, it is explained that "A sends an Open message to
B with Keepalive=10 seconds and Deadtimer=40 seconds.&nbsp; This means that A
sends Keepalive messages (or any other PCEP message) to B every 10 seconds and
B can declare the PCEP session with A down if no PCEP message has been received
from A within any 40 second period". The Keepalive timer should follow the
Keepalive value in the Open message that was sent to its peer (not the
Keepalive value in the Open message received from its peer). Therefore, the
Keepalive timer can be set only after the peer accepted the parameter values in
the Open, i.e. only after the system receives a Keepalive message from its
peer. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I think the Keepalive timer and the
Deadtimer should be started when the system moves to SessionUP state. Is there
anybody who can give me any advice?<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Thanks in advance.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Iksoon<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

</div>

</div>
Iksoon Hwang | 9 Dec 16:54 2008
Picon

How to handle a second TCP connection establishment request from peer?

Dear all,

 

According to section 7.15, if a PCEP peer detects an attempt from another PCEP peer to establish a second PCEP session, it MUST send a PCErr message with Error-type=9, Error-value=1.

 

In section 6.2, it is mentioned that once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as specified in Appendix A. Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type 'PCEP session establishment failure' and Error-Value 'reception of an invalid Open message or a non Open message' and the PCEP session establishment attempt MUST be terminated by closing the TCP connection.

 

Then, in such a case, we have to exchange PCErr messages and Im wondering if it is necessary. I think it is better to mention that once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be either an Open message or an Error message. Any other message received .

 

Another question is that Id like to know if it is appropriate to ignore the second connection. In case of connection oriented protocols, we may have resource mismatch problems, i.e. one assumes that a connection is already released while the other is still holding it. If the second connection is always ignored, we cannot have any connection between two peers before resource mismatch problem is resolved.

 

Thanks in advance.

 

    Iksoon

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-US">Dear all,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">According to section 7.15, if a PCEP
peer detects an attempt from another PCEP peer to establish a second PCEP
session, it MUST send a PCErr message with Error-type=9, Error-value=1. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In section 6.2, it is mentioned that
once the TCP connection has been successfully established, the first message
sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as
specified in Appendix A. Any message received prior to an Open message MUST
trigger a protocol error condition causing a PCErr message to be sent with
Error-Type 'PCEP session establishment failure' and Error-Value 'reception of
an invalid Open message or a non Open message' and the PCEP session
establishment attempt MUST be terminated by closing the TCP connection.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Then, in such a case, we have to
exchange PCErr messages and I</span><span lang="EN-US">&rsquo;</span><span lang="EN-US">m wondering if it is necessary. I think it
is better to mention that </span><span lang="EN-US">&ldquo;</span><span lang="EN-US">once the TCP connection has been
successfully established, the first message sent by the PCC to the PCE or by
the PCE to the PCC MUST be either an Open message or an Error message. Any other
message received </span><span lang="EN-US">&hellip;</span><span lang="EN-US"> </span><span lang="EN-US">&ldquo;</span><span lang="EN-US">. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Another question is that I</span><span lang="EN-US">&rsquo;</span><span lang="EN-US">d like to know
if it is appropriate to ignore the second connection. In case of connection
oriented protocols, we may have resource mismatch problems, i.e. one assumes
that a connection is already released while the other is still holding it. If
the second connection is always ignored, we cannot have any connection between
two peers before resource mismatch problem is resolved.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Thanks in advance.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Iksoon<p></p></span></p>

</div>

</div>
Iksoon Hwang | 9 Dec 17:05 2008
Picon

Receiving an Open message from its peer in KeepWait state

Dear all,

 

According to the Appendix A, if an Open message is received from its peer when the system is in KeepWait state, the system should abort the establishment procedure. In order to have a successful session establishment, in such a case, reply messages must be sent in the order the requests are received.

 

Isnt it too strong condition? I think the order of reply messages may be changed in some cases so it might be better to allow the system to receive an Open message in KeepWait state.

 

Thanks in advance!

 

    Iksoon

<div>

<div class="Section1">

<p class="MsoNormal"><span lang="EN-US">Dear all, <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">According to the Appendix A, if an
Open message is received from its peer when the system is in KeepWait state,
the system should abort the establishment procedure. In order to have a
successful session establishment, in such a case, reply messages must be sent
in the order the requests are received. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Isn</span><span lang="EN-US">&rsquo;</span><span lang="EN-US">t it too strong condition? I think the
order of reply messages may be changed in some cases so it might be better to
allow the system to receive an Open message in KeepWait state. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Thanks in advance!<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Iksoon<p></p></span></p>

</div>

</div>
The IESG | 9 Dec 17:36 2008
Picon

Last Call: draft-ietf-pce-dste (Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol) to Proposed Standard

The IESG has received a request from the Path Computation Element WG 
(pce) to consider the following document:

- 'Diff-Serv Aware Class Type Object for Path Computation Element 
   Communication Protocol '
   <draft-ietf-pce-dste-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2008-12-23. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pce-dste-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16496&rfc_flag=0

The IESG | 9 Dec 17:37 2008
Picon

Last Call: draft-ietf-pce-of (Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)) to Proposed Standard

The IESG has received a request from the Path Computation Element WG 
(pce) to consider the following document:

- 'Encoding of Objective Functions in the Path Computation Element 
   Communication Protocol (PCEP) '
   <draft-ietf-pce-of-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2008-12-23. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pce-of-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16437&rfc_flag=0

Fabien Verhaeghe | 10 Dec 10:17 2008

Re: A case that never happens in OpenWait state

Hello Iksoon,

 

> we can have LocalOK=1 only when the system in KeepWait state receives a Keepalive message from its peer

 

I guess your statement comes from the fact that the only place where it is said to set the LocalOK variable to 1 is in keepwait state:

 

If a Keepalive message is received before the expiration of the

   KeepWait timer, then the system sets LocalOK=1 and:”

 

However if you apply the definition of the LocalOk variable you must set the LocalOk variable to 1 each time you receive a positive acknowledgement

of the Open message, whatever is the current state (OpenWait or KeepWair).

 

“LocalOK: the LocalOK variable is a Boolean set to 1 if the system has

received a Keepalive message acknowledging that the Open message sent

to the peer was valid.”

 

More generally the state diagram described in PCEP draft must be carefully interpreted because of the independent Open/Keepalive message flow in opposite

direction which is managed with a single state.

But I agree that strictly speaking in the OpenWait state case there should be statement about the receipt of a KeepAlive message when LocalOk is 0.

 

Best regards

Fabien

 

 

De : pce-bounces <at> ietf.org [mailto:pce-bounces <at> ietf.org] De la part de Iksoon Hwang
Envoyé : mardi 9 décembre 2008 16:35
À : pce <at> ietf.org
Objet : [Pce] A case that never happens in OpenWait state

 

Dear all,

 

I’m currently working on a research project, called CARRIOCAS, which aims at providing dynamically reconfigurable high speed network for high-performance applications where PCEP is used for path computation. My work in the project is to do modeling, validation, verification, and testing of PCEP. PCEP was described in a formal language IF and some properties were validated. I have some questions that were found during my work. The questions will be posted in four separate emails including this one.

 

I found that there is a case that never happens in OpenWait state. Is there anybody who can give me any advice if I’m missing something? The detailed case is as follows.

 

In Appendix A, when a system in OpenWait state receives an Open message from its peer where no errors are detected, OpenRetry is 0, the session characteristics are unacceptable but negotiable, and LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state.

 

According to our experiments, we found that the above case cannot happen. We analyzed the reason and the result is as follows: we can have LocalOK=1 only when the system in KeepWait state receives a Keepalive message from its peer. Since the system can move to KeepWait state only after receiving an Open message from its peer in OpenWait state, the OpenRetry value is always more than 0 if we have LocalOK=1.

 

Thanks in advance!

 

    Iksoon

<div>

<div class="Section1">

<p class="MsoNormal"><span>Hello </span><span lang="EN-US">Iksoon,<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">&gt; we can have LocalOK=1 only when the system in
KeepWait state receives a Keepalive message from its peer<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I guess your statement
comes from the fact that the only place where it is said to set the LocalOK
variable to 1 is in keepwait state:<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<span lang="EN-US">&ldquo;</span><span lang="EN-GB">If a Keepalive message is received before the expiration of the<p></p></span><span lang="EN-GB">&nbsp;&nbsp; KeepWait timer, then the system sets LocalOK=1 and:&rdquo;<p></p></span>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">However if you apply the
definition of the LocalOk variable you must set the LocalOk variable to 1 each
time you receive a positive acknowledgement<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">of the Open message,
whatever is the current state (OpenWait or KeepWair).<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<span lang="EN-GB">&ldquo;LocalOK: the LocalOK variable is a Boolean set to 1 if the system has <p></p></span><span lang="EN-GB">received a Keepalive message acknowledging that the Open message sent<p></p></span><span lang="EN-GB">to the peer was valid.&rdquo;<p></p></span>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">More generally the state
diagram described in PCEP draft must be carefully interpreted because of the
independent Open/Keepalive message flow in opposite<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">direction which is
managed with a single state.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">But I agree that strictly
speaking in the OpenWait state case there should be statement about the receipt
of a KeepAlive message when LocalOk is 0.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Best regards<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Fabien<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>

<div>

<div>

<div class="MsoNormal" align="center"><span>

</span></div>

<p class="MsoNormal" align="left"><span>De&nbsp;:</span><span> pce-bounces <at> ietf.org
[mailto:pce-bounces <at> ietf.org] <span>De la part de</span>
Iksoon Hwang<br><span>Envoy&eacute;&nbsp;:</span> mardi 9 d&eacute;cembre
2008 16:35<br><span>&Agrave;&nbsp;:</span> pce <at> ietf.org<br><span>Objet&nbsp;:</span> [Pce] A case that
never happens in OpenWait state</span><span><p></p></span></p>

</div>

<p class="MsoNormal" align="left"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Dear all, <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I&rsquo;m currently working on a research project,
called CARRIOCAS, which aims at providing dynamically reconfigurable high speed
network for high-performance applications where PCEP is used for path
computation. My work in the project is to do modeling, validation,
verification, and testing of PCEP. PCEP was described in a formal language IF
and some properties were validated. I have some questions that were found
during my work. The questions will be posted in four separate emails including
this one. <p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">I found that there is a case that never happens in
OpenWait state. Is there anybody who can give me any advice if I&rsquo;m
missing something? The detailed case is as follows.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">In Appendix A, when a system in OpenWait state
receives an Open message from its peer where no errors are detected, OpenRetry
is 0, the session characteristics are unacceptable but negotiable, and
LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait
state.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">According to our experiments, we found that the above
case cannot happen. We analyzed the reason and the result is as follows: we can
have LocalOK=1 only when the system in KeepWait state receives a Keepalive
message from its peer. Since the system can move to KeepWait state only after
receiving an Open message from its peer in OpenWait state, the OpenRetry value
is always more than 0 if we have LocalOK=1.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">Thanks in advance!<p></p></span></p>

<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp; Iksoon</span><span lang="EN-US"><p></p></span></p>

</div>

</div>

</div>
Adrian Farrel | 10 Dec 15:22 2008
Picon

Fw: Letters of Invitation to IETF 74 now available to past attendees


----- Original Message ----- 
From: "Alexa Morris" <amorris <at> amsl.com>
To: <ietf <at> ietf.org>; <wgchairs <at> ietf.org>
Sent: Tuesday, December 09, 2008 6:31 PM
Subject: Letters of Invitation to IETF 74 now available to past attendees

> If you need a letter of invitation (LOI) in order to obtain a visa to  
> come to IETF 74 in San Francisco  -- and if you have attended at least  
> one IETF meeting in the past -- you can now request a LOI via this  
> webform: https://www.amsl.com/ietf/ietf74-loi.html. The LOI will be  
> sent to you via email unless you specifically request a hard copy. You  
> can also access the webform from the Meetings page of the IETF website.
> 
> As soon as we officially open registration for the meeting, anyone who  
> registers for IETF 74 (regardless of whether or not they've attended a  
> past meeting) will be able to request and receive a letter of  
> invitation to attend.
> 
> Regards,
> Alexa
> 
> -----------
> Alexa Morris / Executive Director / IETF
> 48377 Fremont Blvd., Suite 117, Fremont, CA  94538
> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
> Email: amorris <at> amsl.com
> 
> Managed by Association Management Solutions (AMS)
> Forum Management, Meeting and Event Planning
> www.amsl.com <http://www.amsl.com/>
> 
>


Gmane