Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt

[Cyril Margaria <[e-mail]>]

Hi,

For the LSP object I fail to see a conceptual difference between a packet
and non-packet LSP in that regards, so I think the presence of the LSP
object in PCReq/PCRep must be generic.


On 23 October 2013 03:22, Zhangxian (Xian) <[e-mail]> wrote:

>  Hi, All,
>
>
>
> Just to amend the first comment below. In Section 2. 5 of
> http://tools.ietf.org/html/draft-zhang-pce-pcep-stateful-pce-gmpls-03, we
> discuss the use cases of why the LSP identifier is useful in existing
> messages (PCReq and PCRep) and provide encoding.  Although we currently put
> in this draft, but IMHO, it should be generic. What is the WG opinion on
> this?
>
>
>
> Regards,
>
> Xian
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Dhruv
> Dhody
> *Sent:* 2013年10月22日 21:58
> *To:* [e-mail]; [e-mail]
> *Subject:* Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.txt
>
>
>
> Hi Authors/WG,
>
>
>
> Some comments on draft-ietf-pce-stateful-pce-07.
>
> Apologies for a long mail.
>
>
>
>    Major
>
>       - I noticed that the PCReq/PCRep encoding are removed from this
>
>       version, how should the passive stateful PCE behave now (with no
>
>       LSP object). In section 5.6.1 when a passive stateful PCE sends
>
>       PCRep message, PCC send PCRpt message to indicate is the path can
>
>       be setup or not. There is a need to link the PCRep with PCRpt in
>
>       case of passive stateful PCE. The LSP object added in PCReq/PCRep
>
>       in the previous version could do this.  I wish there is some
>
>       discussion on the mailing list, so that the WG is aware of why the
>
>       changes were made.
>
>
>
>       - PCRpt/PCUpd Message: What is the way to know the source and
>
>       destination of the LSP in the current encoding esp when the LSP is
>
>       down or not yet setup?  Also note that the ERO is a mandatory
>
>       object in PCRpt. Should it be existing when the path calculation
>
>       has not been initiated so far? ERO object is also mandatory in
>
>       PCUpd. IMO PCE may choose to tear down an LSP (say during handling
>
>       of a higher priority LSP), what should be in the ERO object then?
>
>       IMHO ENDPOINT object in PCRpt/PCUpd will make for much cleaner
>
>       design but "...an ERO with just the 'endpoints'" is also an
>
>       option. Either way some text in the document should explain that.
>
>
>
>       - PLSP-ID: it is constant for the life time of a PCEP session. IMO
>
>       its a better idea to make PLSP-ID unique NOT per PCEP session but
>
>       across PCEP session, i.e. if there are multiple stateful PCE and
>
>       re-delegation happens (after the earlier delegated PCE is down),
>
>       PLSP-ID will not change. IMO in case of PCE-Initiated LSP, it
>
>       would allow a new stateful PCE to take control over the orphan LSP
>
>       using the same PLSP-ID in a much simpler way.
>
>
>
>    Minor
>
>       - Abstract
>
>
>
>           Although PCEP explicitly makes no assumptions regarding the
>
>           information available to the PCE, it also makes no provisions
>
>           for synchronization or ...
>
>
>
>         Prefer if *synchronization* can be clarified, i.e. we explicitly
>
>         say LSP state synchronization, so as not to be confused with TED
>
>         sync.
>
>
>
>       - Terminology
>
>
>
>           State Timeout Interval: when a PCEP session is terminated, a
>
>           PCC waits for this time period before flushing LSP state
>
>           associated with that PCEP session and reverting to operator-
>
>           defined default parameters.
>
>
>
>         Can we change this to operator-defined default parameters or
>
>         procedures? By procedure I meant that on state timeout interval
>
>         expiry, PCC may rely on local CSPF computed path or ask a
>
>         passive/stateless PCE to re-compute based on the operator-
>
>         defined procedure.
>
>
>
>       - Sec 3.1.3. Protocol vs. Configuration
>
>
>
>           Security: opening up a configuration channel to a PCE would
>
>           allow a malicious PCE to take over a PCC.
>
>
>
>         Rest of the section compares the shortcoming of existing
>
>         configuration tools/protocols with stateful PCE; But this point
>
>         suggest opening up configurations of state directly at PCE. Am
>
>         not so sure about it.
>
>
>
>       - Sec 5.3. Capability Advertisement
>
>
>
>         If PCE advertise its stateful capability during IGP discovery,
>
>         do the PCC/PCE still need to follow the procedure laid out in
>
>         this section. This should be clarified in the draft.
>
>
>
>           If the PCEP Speakers support the extensions of this draft but
>
>           did not advertise this capability, then a PCErr with error-
>
>           type 19 (Invalid Operation), error-value 2 (Attempted LSP
>
>           Update Request if active stateful PCE capability was not
>
>           advertised)(see Section 8.4) will be generated and the PCEP
>
>           session will be terminated.
>
>
>
>         Also needed an error-value for attempting to send LSP State
>
>         report if stateful PCE capability was not advertised. Basically
>
>         a PCEP speaker which supports this extension but did not
>
>         advertise it, PCC anyhow chooses to send PCRpt message then the
>
>         another error value is needed.
>
>
>
>       - Sec 5.4. State Synchronization
>
>
>
>           The set of LSPs for which state is synchronized with a PCE is
>
>           determined by advertised stateful PCEP capabilities and PCC's
>
>           local configuration (see more details in Section 9.1).
>
>
>
>         How is the capability advertisement related to decision which
>
>         set of LSP are synchronized? IMO Capability advertisement
>
>         determines if the state synchronization as a whole is performed
>
>         or not, it doesn't determine a set (subset) of LSPs which are
>
>         synchronized.
>
>
>
>           A PCE SHOULD NOT send PCUpd messages to a PCC before State
>
>           Synchronization is complete.  A PCC SHOULD NOT send PCReq
>
>           messages to a PCE before State Synchronization is complete.
>
>
>
>         Some text can be added to suggest how should the PCC/PCE react
>
>         if above happens? Error Message? Termination of PCEP session?
>
>
>
>           A PCE implementing a limit on the resources a single PCC can
>
>           occupy, MUST send a PCErr message with error-type 19 (invalid
>
>           operation) and error-value 4 (indicating resource limit
>
>           exceeded) in response to the PCRpt message triggering this
>
>           condition in the synchronization phase and MUST terminate the
>
>           session.
>
>
>
>         By resource do you mean a limit on number of LSPs that a given
>
>         PCC can synchronize?
>
>
>
>
>
>       - Sec 6.1. The PCRpt Message
>
>
>
>           <path>::= <ERO><attribute-list>[<RRO>]
>
>
>
>         Please add some description on when RRO should be used. How it
>
>         works along ERO etc?
>
>
>
>       - Sec 7.2. SRP Object
>
>
>
>           The SRP (Stateful PCE Request Parameters) object MUST be
>
>           carried within PCUpd messages and MAY be carried within PCRpt,
>
>           PCNtf and PCErr messages.
>
>
>
>         PCNtf? Well then the extension of PCNtf is needed to support
>
>         carrying of SRP object.
>
>
>
>       - Sec 7.3.2. Symbolic Path Name TLV
>
>
>
>           The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP
>
>           Object and the LSPA Object.
>
>
>
>         What is the purpose of this TLV inside the LSPA object? (Also
>
>         mentioned in section 7.4)
>
>
>
>    Editorial
>
>       - Terminology
>
>
>
>           This document uses the following terms defined in [RFC4090]:
>
>           MPLS TE Fast Reroute (FRR), FRR One-to-One Backup, FRR
>
>           Facility Backup.
>
>
>
>         Should be removed as they are not used in the document anymore.
>
>
>
>         Delegation
>
>           OLD
>
>             For intra-domain LSPs, this PCC SHOULD be the PCC of the LSP
>
>             head end.
>
>           NEW
>
>             For intra-domain LSPs, this PCC SHOULD be the LSP head end.
>
>
>
>         LSP State Report
>
>           OLD
>
>             an operation to send LSP state (Operational / Admin Status,
>
>             LSP attributes configured and set by a PCE, etc.) from a PCC
>
>             to a PCE.
>
>           NEW
>
>             an operation to send LSP state (Operational / Admin Status,
>
>             LSP attributes configured at PCC and updated by a PCE, etc.)
>
>             from a PCC to a PCE.
>
>
>
>       - Sec 3.1.3. Protocol vs. Configuration
>
>           OLD
>
>             Efficient State Synchronization: configuration channels may
>
>             be heavyweight and unidirectional, therefore efficient state
>
>             synchronization between a PCE and a PCE may be a problem.
>
>           NEW
>
>             Efficient State Synchronization: configuration channels may
>
>             be heavyweight and unidirectional, therefore efficient state
>
>             synchronization between a PCC and a PCE may be a problem.
>
>
>
>       - Sec 5.1. LSP State Ownership
>
>           OLD
>
>             An active stateful PCE may have control of a PCC's LSPs be
>
>             delegated to it, but the LSP state ownership is retained by
>
>             the PCC.
>
>           NEW
>
>             An active stateful PCE may have control of a PCC's LSPs that
>
>             are delegated to it, but the LSP state ownership is retained
>
>             by the PCC.
>
>
>
>       - Sec 7.3. LSP Object
>
>
>
>           The figure shows operational bits of 2 bit length, it should
>
>           be three!
>
>
>
> Dhruv
>
>
>
> On Wed, Oct 9, 2013 at 12:12 PM, <[e-mail]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Path Computation Element Working Group
> of the IETF.
>
>         Title           : PCEP Extensions for Stateful PCE
>         Author(s)       : Edward Crabbe
>                           Jan Medved
>                           Ina Minei
>                           Robert Varga
>         Filename        : draft-ietf-pce-stateful-pce-07.txt
>         Pages           : 47
>         Date            : 2013-10-08
>
> Abstract:
>    The Path Computation Element Communication Protocol (PCEP) provides
>    mechanisms for Path Computation Elements (PCEs) to perform path
>    computations in response to Path Computation Clients (PCCs) requests.
>
>    Although PCEP explicitly makes no assumptions regarding the
>    information available to the PCE, it also makes no provisions for
>    synchronization or PCE control of timing and sequence of path
>    computations within and across PCEP sessions.  This document
>    describes a set of extensions to PCEP to enable stateful control of
>    MPLS-TE and GMPLS LSPs via PCEP.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>


-- 
-- 
Cyril Margaria