Subject: RE: Fwd: [Pce] Compliance with the PCECP Requirement Document

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 2 Feb 2007 21:06:34 +0100

Hi Dimitri,

Yes your reading is correct, and you actually pointed out a mistake in the draft.

The exact processing is the one actually defined in section 10:

"If a malformed PCEP message is received or the TCP connection fails,
   the systems sends a PCEP CLOSE message, the system releases the PCEP
   resources for that PCEP peer, closes the TCP connection and moves to
   the Idle State."

So upon TCP connection failure, the PCE releases pending requests. Thus a PCC never receives responses for requests sent during a previous session.

We are going to align section 5.2.5 with section 10.

Regards,

JL

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] 
> Envoyé : samedi 27 janvier 2007 08:24
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : JP Vasseur; [email-masked]
> Objet : RE: Fwd: [Pce] Compliance with the PCECP Requirement Document
> 
> 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
> 
> > -----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
> > 
> > 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:
> > 
> > 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
> > 
> >    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 
> > Comment> 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
> > _______________________________________________
> > Pce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pce
> > 
> > 
> > 
> > _______________________________________________
> > Pce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pce
> > 
> > 
> > 
> 
> 
> 

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