Re: [Pce] Pce Digest, Vol 141, Issue 28

[Joydeep Banerjee <[e-mail]>]

Hello
When PCUpd message does not have LSPA object (since this is optional), what
would be the interpretation on PCC?

In "PCEP Extensions for Stateful PCE" draft, it mentions that "

An LSP Update Request MUST contain all LSP parameters that a PCE wishes to
Crabbe, et al. Expires October 22, 2015 [Page 24] Internet-Draft PCEP
Extensions for Stateful PCE April 2015  be set for the LSP. A PCC MAY set
missing parameters from locally configured defaults."

So - If some objects like LSPA is missing according to the definition, PCE
does not intend to update it (thus PCC MAY apply operator defaults to the
missing parameters). However, it seems stateful PCE draft also says
<attribute-list> [ PCUpd definition in Sec 6.2] is taken from RFC 5440 and
"extended" by PCEP extensions. RFC 5440 says (Sec 7.11) -

When absent from the PCReq message, this means that the Setup and Holding
priorities are equal to 0,...

Should we extend the statement for PCReq to PCUpd? In that case it
contradicts Stateful PCE's way of handling missing objects.

Regards,

Joydeep





On Wed, Jun 29, 2016 at 12:30 AM, <[e-mail]> wrote:

> Send Pce mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/pce
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pce digest..."
>
>
> Today's Topics:
>
>    1. Re: Proposed text for handling stateless/router-computed to
>       active-stateful transitions in draft-ietf-pce-stateful-pce
>       (Olivier Dugeon)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Jun 2016 19:45:26 +0200
> From: Olivier Dugeon <[e-mail]>
> To: Robert Varga <[e-mail]>, "Aissaoui, Mustapha (Nokia - CA)"
>         <[e-mail]>, "[e-mail]" <[e-mail]>,
> "MEURIC
>         Julien IMT/OLN" <[e-mail]>
> Subject: Re: [Pce] Proposed text for handling
>         stateless/router-computed to active-stateful transitions in
>         draft-ietf-pce-stateful-pce
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Robert,
>
> General comment: The proposal modifications has been written following
> different interoperability tests done on different commercial solutions of
> both PCE and PCC. The issue raised following these tests show that the
> draft has been interpreted differently and thus, need to be consolidated
> i.e. precise text when ambiguity take place.
>
> More detail answers below.
>
> Regards
>
> Olivier
>
> Le 27/06/2016 15:58, Robert Varga a ?crit :
> >
> > On 06/14/2016 10:41 PM, Aissaoui, Mustapha (Nokia - CA) wrote:
> >> Dear all,
> >>
> >> As promised, Stephane, Olivier and I worked on a proposal for updating
> >> draft-ietf-pce-stateful-pce to handle the transition from stateless or
> >> router-computed to active-stateful operation for an LSP. More
> >> specifically, We are proposing the addition of a new section 5.8.3
> >> describing extensions for the following:
> >>
> >>
> >>
> >> a.     support of use of PCReq/PCRep for an LSP which does not have an
> >> initial path and which the PCC intends to delegate to the PCE. The
> >> proposal here is to first use the same procedure as in passive-stateful
> >> mode of operation with a PCReq/PCRep followed by sending the PCRpt
> message.
> >>
> >>
> >>
> >> b.    passing LSP constraints when delegating an LSP which already has a
> >> working path. While PCE does not need to compute a path immediately, it
> >> needs to save the constraints for the next opportunity to update the
> >> path. In this case, the PCRpt messages is enhanced to contains an
> >> additional set of the LSP parameters such as LSPA, Metric, Bandwidth,
> >> and IRO objects to report the original constraints of the LSP.
> >>
> >>
> >>
> >> We are also proposing modifications to a couple of paragraphs in
> >> sections 5.8.2 and 6.1 to clarify the use of the PCRpt message and of
> >> the ERO object in PCRpt respectively.
> >>
> >>
> >>
> >> We appreciate if the authors of the draft and members of this WG provide
> >> feedback.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Mustapha.
> >>
> >> ------------------------------
> >>
> >> I.              New Section 5.8.3 ? Reporting LSP Constraints on LSP
> >> transition from Stateless/Router-Computed to Active Stateful Modes of
> >> Operation
> >>
> >>
> >>
> >> When an LSP transitions from a stateless or router-computed mode to an
> >> active stateful mode of operation and the LSP has no working path, PCC
> >> MUST first reuse the same procedure defined in passive stateful mode to
> >> request the initial path from PCE.
> >>
> >>
> >>
> >> This additional step is required for two reasons. First, the action of
> >> delegating the LSP to a PCE using a PCRpt message is not an explicit
> >> request to PCE to compute a path for the LSP. The only explicit way for
> >> a PCC to request a path from PCE is to send a PCReq message as per RFC
> >> 5440.
> > This is an intentional side-effect of changing synchrony. Delegating an
> > LSP involves the PCC losing control over timing of route computation.
> Well, from an operational point of view, there is a need to take back the
> control of LSP on a PCC. This new text just proposes to precise these
> process.
> >
> >> Second, the PCRpt message does not contains the original
> >> constraints of the LSP path as configured by the user on the router. The
> >> PCRpt message may contain the operational or computed values of those
> >> same objects in the attribute-list. For example, the hop-count Metric
> >> object included in the PCRpt message will contain the computed value for
> >> the current path of the LSP but will not contain the hop-count bound the
> >> user may have configured on the router for this LSP. Note that since in
> >> this case the LSP has no working path, it may even not include any of
> >> the Metric objects in the attribute-list of the PCRpt message.
> >>
> >>
> >>
> >> To address the above situation, the PCReq message SHOULD include all the
> >> objects describing the current configuration of the LSP on the PCC :
> >> e.g. the relevant LSPA, Metric, Bandwidth, IRO, ? objects to convey the
> >> LSP path constraints to PCE. An implementation MAY allow policies on PCC
> >> to determine the configuration parameters to be sent to the PCE. The LSP
> >> object MAY also be included with the D-bit (Delegate bit) set to
> >> indicate to PCE that it intends to delegate this LSP. The PCE uses this
> >> indication to cache the constraint in these objects in anticipation of
> >> the subsequent PCRpt message which should confirm the delegation by
> >> setting the D-bit in the LSP object. The PCE may clear the cached
> >> information if no PCRpt message for that PLSP-ID is received within a
> >> finite amount of time.
> > I think this really is 'PCE policy', as this requires resources on the
> > PCE side, which are shared across multiple PCCs, hence a LRU or similar
> > should be allowed.
> >
> > I am not sure what caching the information will achieve: the PCC cannot
> > rely on this information to be present, hence a subsequent PCRpt needs
> > to repeat this information anyway...
> When a PCC loose its session with a PCE and try to setup a new PCEP
> session with a backup PCE, the later needs to know the details of the
> original request. Of course its a PCE problem, but if the PCC doesn't
> provide the information, how the PCE could collect them ?
> >
> >> When an LSP transitions from a stateless or router-computed to an active
> >> stateful mode of operation and  the LSP has a working path, there is no
> >> need to explicitly request a path from PCE at that point in time. While
> >> a PCC may decide to first use the passive stateful mode procedures as in
> >> the case above, there is no requirement for doing so. As such, this
> >> document defines an optional procedure by which the PCC can simply
> >> report the LSP constraints to the PCE in the PCRpt message. A PCC which
> >> supports this procedure MUST append an additional set of the relevant
> >> objects like LSPA, Metric, Bandwidth, and IRO objects, referred to as
> >> the request-list(1), in which it conveys the LSP path constraints to
> PCE.
> > I think we also need an indication that the PCC supports this procedure
> > -- otherwise the PCE cannot discern if the information is missing (which
> > would be a PCErr) or the PCC does not support it (which is okay).
> Yes. Good catch.
> >
> >> A PCE that receives a PCRpt with the request-list should assume the
> >> values contained in the request-list are the actual constraints. The
> >> values in the  request-list must update any corresponding value saved
> >> for that PLSP-ID in the LSP database. A PCE that receives a PCRpt
> >> without the request-list and that PLSP-ID has no saved constraints in
> >> the LSP database should assume the values contained in the
> >> attribute-list are the actual constraints. In either case, the
> >> constraint values can be overridden by PCE policy.
> > I am not sure I understand this part. Is this related to the PCE which
> > has current control of the LSP and is triggered for things like CLI
> > config changing, or is this for sake of backup PCEs?
> The first case apply as depending of the implementation, it is necessary
> to revoke the delegation before attempting to change CLI config on the PCC.
> Once the delegation is turn on, the PCC send a new PCRpt with the updated
> request-list.
> The second case apply when the PCC loose the PCEP session with the primary
> PCE and start establish a PCEP session with its backup PCE for which it
> send PCRpt message with the reques-list.
>
> >
> > Also, would an active PCE be able to update this information?
> PCE could override the information in its LSP database, but could not
> update the information on the router. PCEP is not NETCONF/YANG. I mean that
> PCEP statefull configuration are stored in the ephemeral configuration of
> the PCC while the config CLI  remains in the static configuration.
> >
> >> Note (1): RFC 5440 defines the request-list in the PCReq message as the
> >> above objects plus the RP and END-POINTS objects. As such we may need to
> >> refer to this differently. Maybe the constraint-list.
> >>
> >>
> >>
> >> II.             Modifications to last paragraph in Section 5.8.2 ?
> >> Active Stateful PCE LSP Update
> >>
> >>
> >>
> >> ?
> >>
> >>    The PCRpt message MUST NOT be used by PCC to request a path from PCE.
> >>
> >>    Standard PCReq as defined in RFC 5440 MUST be used instead.
> >>
> >>    A PCC MUST however NOT send to any PCE a Path Computation Request
> for a
> >>
> >>    once the LSP is delegated LSP.  Should the PCC decide it wants to
> issue a Path
> >>
> >>    Computation Request on a delegated LSP, it MUST perform Delegation
> >>
> >>    Revocation procedure first.
> >>
> >> ?
> > The intent here is that for any particular LSP exactly one mode of
> > operation (passive or active) is used and they are not intermixed --
> > exactly because of synchrony problems arising from such use.
> >
> > I agree with the updated text, but I also wonder if a paragraph in 5.8
> > would be more appropriate.
> Up to you to place the propose text at the most suitable place in the
> draft.
> >
> >> III.            Modifications to sixth paragraph in Section 6.1 ? The
> >> PCRpt Message
> >>
> >> ?
> >>
> >>    The intended path, represented by the ERO object, SHOULD be included
> in
> >>
> >>    PCRpt by the PCC whenever the PCC has a valid, non-empty, ERO for the
> >> LSP.
> >>
> >>    A valid ERO can be obtained by requesting a path from the local
> >> router CSPF or
> >>
> >>    from PCE using the PCReq message before delegation as explained in
> >> Section 5.8.3.
> >>
> >>    It can also be provided by local configuration on the router. A PCC
> >> MUST omit the
> >>
> >>    ERO object otherwise. In all cases, a PCC MUST NOT send an empty ERO
> >> in a PCRpt
> >>
> >>    message to PCE.
> > This would contradict the end-of-sync marker definition.
> >
> > This also means that every PCE implementation must support the
> > router-initiated computation synchrony -- which can problematic with
> > some implementation architectures.
> >
> > It also creates some friction with pce-initiated: the PCE is free to use
> > an empty ERO in PCEInitiate and the PCC is required to mirror it back in
> > PCRpt -- but this text forbids empty EROs in PCRpt...
> Well I understand the point. But, an empty ERO is something very strange
> for me ;-)
>
> Concerning the end-of-sync marker, perhaps another marker could be used
> instead of an empty ERO.
>
> For the PCEInitiate, again, it is strange for me to deploy a PCE on a
> network just to push on a PCC some tunnels without  ERO. This means that
> you let the PCC perform the CSPF while the PCE is build for that purpose. A
> simple NMS that push CLI or Netconf/Yang configuration is sufficient for
> this use case.
> >
> > Bye,
> > Robert
> >
> >
> >
> > _______________________________________________
> > Pce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pce
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>
> ------------------------------
>
> End of Pce Digest, Vol 141, Issue 28
> ************************************
>