Subject: [Pce] Compliance with the PCECP Requirement Document

From: JP Vasseur <[email-masked]>
Date: Wed, 24 Jan 2007 11:38:04 -0500

Dear WG,

As discussed in San Diego, there are still a few requirements stated  
in RFC 4657 that PCEP does not satisfy (see Appendix A of the PCEP  
ID) for which we'd like your feed-back:

Appendix A

    The aim of this section is to list the set of requirements set forth
    in [RFC4657] that are not satisfied by the current revision of this
    document.  This only concerns the requirements listed as MUST
    according to [RFC2119].

    Here is the list of currently unsatisfied requirements:

    o  Allow to select/prefer from advertised list of standard objective
       functions/options

    o  Allow to customize objective function/options

    o  Support "unsynchronized" & "synchronized" objective functions

Comment> The Proposal is to work on this item in the context of a  
separate ID that will cover the set of requirements, IGP PCED  
extensions and PCEP extensions since these functions are not required  
for the base protocol specification.

    o  Protocol recovery support resynchronization of information &
       requests between sender & receiver.

Comment> We can see two potential avenues here:
1) Upon loosing the PCEP session, pending requests are considered as  
lost, and the PCC has the initiative to resend the set of pending  
requests. The main benefit of such approach is to be extremely simple  
and IMO well suited to most of the cases since path computation  
requests are not likely to be pending for a long period of time.
2) Specify a set of re-synchronization procedures. We came up with  
similar solutions for many other protocols (in very different  
contexts and set of requirements) and our experience clearly tells us  
that this will likely to be a fairly complex issue. We could see some  
benefit in statefull contexts though; thus if such functions is  
required for particular context, we would propose not to include in  
the base protocol specification and leave it for further should the  
WG think that such function will be required.

Thanks for your feed-back.

JP, Jean-Louis et al.

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 26 Jan 2007 11:09:44 -0500

Dear WG,

In absence of negative reply we'll go ahead with the proposed plan  
below. Let us know within 1-2 weeks max if you have comments.

Thanks,

JP.

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: January 24, 2007 11:38:04 AM EST
> To: [email-masked]
> Subject: [Pce] Compliance with the PCECP Requirement Document
>
> Dear WG,
>
> As discussed in San Diego, there are still a few requirements  
> stated in RFC 4657 that PCEP does not satisfy (see Appendix A of  
> the PCEP ID) for which we'd like your feed-back:
>
>
> Appendix A
>
> extensions and PCEP extensions since these functions are not  
> required for the base protocol specification.
>
> 1) Upon loosing the PCEP session, pending requests are considered  
> as lost, and the PCC has the initiative to resend the set of  
> pending requests. The main benefit of such approach is to be  
> extremely simple and IMO well suited to most of the cases since  
> path computation requests are not likely to be pending for a long  
> period of time.
> contexts and set of requirements) and our experience clearly tells  
> us that this will likely to be a fairly complex issue. We could see  
> some benefit in statefull contexts though; thus if such functions  
> is required for particular context, we would propose not to include  
> in the base protocol specification and leave it for further should  
> the WG think that such function will be required.
>

---

From: [email-masked]
Date: Sat, 27 Jan 2007 00:12:45 +0100

hi j-p

one point on the last issue, assuming wg goes as planned:

there is a need to distinguish re-sync and de-sync (or out-of-sync), you 
may certainly want to prevent complex re-sync, but de-sync must lead to 
the possibility to drop replies from previous requests, assume that a PCC 
initiates a req. to a PCE, the TCP connection breaks, PCC re-initiates the 
same request, and receives an answer does it come from the former or the 
latter req. (this may lead to false positive or true negative) ?

thanks,
- d.

JP Vasseur <[email-masked]>
26/01/2007 17:09
 
        To:     [email-masked]
        cc: 
        Subject:        Fwd: [Pce] Compliance with the PCECP Requirement 
Document

Dear WG,

In absence of negative reply we'll go ahead with the proposed plan below. 
Let us know within 1-2 weeks max if you have comments.

Thanks,

JP.

Begin forwarded message:

Dear WG,

As discussed in San Diego, there are still a few requirements stated in 
RFC 4657 that PCEP does not satisfy (see Appendix A of the PCEP ID) for 
which we'd like your feed-back:

Appendix A

Comment> The Proposal is to work on this item in the context of a separate 
ID that will cover the set of requirements, IGP PCED extensions and PCEP 
extensions since these functions are not required for the base protocol 
specification.

Comment> We can see two potential avenues here:
1) Upon loosing the PCEP session, pending requests are considered as lost, 
and the PCC has the initiative to resend the set of pending requests. The 
main benefit of such approach is to be extremely simple and IMO well 
suited to most of the cases since path computation requests are not likely 
to be pending for a long period of time.
2) Specify a set of re-synchronization procedures. We came up with similar 
solutions for many other protocols (in very different contexts and set of 
requirements) and our experience clearly tells us that this will likely to 
be a fairly complex issue. We could see some benefit in statefull contexts 
though; thus if such functions is required for particular context, we 
would propose not to include in the base protocol specification and leave 
it for further should the WG think that such function will be required.

JP, Jean-Louis et al.

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sat, 27 Jan 2007 00:45:17 +0100

Hi Dimitri,

As stated in the spec, if the TCP connection fails the PCE releases all ressources for the session, including pending requests. Hence a PCC will never receive a reply for a request sent during a previous session.

Regards,

JL

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] 
> Envoyé : samedi 27 janvier 2007 00:13
> À : JP Vasseur
> Cc : [email-masked]
> Objet : Re: Fwd: [Pce] Compliance with the PCECP Requirement Document
> 
> Attention, votre correspondant continue de vous écrire à 
> votre ancienne adresse en @orange-ft.com, qui va être 
> désactivée début avril. Veuillez lui demander de mettre à 
> jour son carnet d'adresses avec votre nouvelle adresse en 
> @orange-ftgroup.com.
> 
> Caution : your correspondent is still writing to your 
> orange-ft.com address, which will be disabled beginning of 
> April. Please ask him/her to update his/her address book to 
> orange-ftgroup.com ..................................................
> 
> hi j-p
> 
> stated in
> Comment> separate

---

From: [email-masked]
Date: Sat, 27 Jan 2007 08:24:23 +0100

hi jean-louis

is my reading correct:

"   In case of TCP connection failure, the PCEP session SHOULD be
   maintained for a period of time equal to the DeadTimer."

DeadTimer = recommended 4 x KeepAlive (min 1s and recommended 30 s) 

during that interval (recommended = 120s) which is not negligible
how pending requests are processed ? or did i miss something ?

thanks,
- d.

"LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
27/01/2007 00:45
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: Fwd: [Pce] Compliance with the PCECP 
Requirement Document

Hi Dimitri,

As stated in the spec, if the TCP connection fails the PCE releases all 
ressources for the session, including pending requests. Hence a PCC will 
never receive a reply for a request sent during a previous session.

Regards,

JL