Re: [Pce] Multipath / replication segment comment

[Cyril Margaria <[e-mail]>]

continued inline

<cut> ,

>
> [Cyril] There is a related work that ties one tunnel to multiple path,
> list of hops :  RFC8697, and draft-ietf-pce-stateful-path-protection-11.
> Given the mechanism used (and flexibility in term of the individual legs),
> would it make sense to reuse the path protection mechanisms to tie those
> multiple EROs together? In addition it addresses the backup path already.
>
> [TS]: Consider the case of a PCE delegated SR Policy Candidate Path. The
> PCC desires an SR path computation from a PCE that is subject to
> constraints – The PCC has no a-priori idea **how many** Segment-Lists (SLs)
> the PCE path computation will result in-- so it does not know how many (or
> whether it should at all) create multiple PLSPs with NO-ERO and report them
> so PCE can respond to each.
>

The PCC can use a PCReq, PCRep, that allows multiple ERO. What is the
drawback of delegating the maximum set of Supported Segment List with no
ERO, the association may carry an attribute to indicate to the PCE
"Minimize the number of LSP with route" (or it can be a METRIC). The PCC
knows how many segment-list per candidate path are supported though
(whereas the PCE does not a priori)


> The PCC creates **one** PLSP and reports to the PCE the LSP down (with
> NO-ERO) along with the specified user constraints. The PCE computes and
> determines the feasible number of SLs. Now, it would be awkward for the PCE
> to instantiate PLSPs – different from the one originally delegated by the
> PCC—so to encode each SL in its own PLSP and make use the “association
> object” method.. I can also imagine complexities in what each PLSP LSP
> would carry in terms of constraints – especially after some configuration
> change on the PCC…
>

s/one/all/ and that works with:
  - limited extensions
  - reuse the path protection for protection
  - Any OAM extension and procedure works (as its per path)
  - The PCC has the freedom to have policies for per (set of) segment-list
constraints
  -

The function desired is more the shared control of the number of path
between the PCC and the PCE. Stateless PCE uses the LOAD-BALANCING for
that, but stateful has a more restrictive definition.
A possibility is to reuse the original multiple ERO defined, What is
currently a TE-Path, but adapt it to stateful:
   - allow LOAD-BALANCING (please refer to RFC5440) in PCRpt
   - the PCE May use multiple ERO and LOAD-BALANCING to *suggest* some
alternative paths to the PCC, in case of a candidate path the PCC should
create the other PLSPs
   - The PCE can update the LOAD-BALANCING and suggested ERO, the PCC
should update its set of LSPs

It keeps the PCE-Controlled number of paths, it can work for other kind of
associations that groups traffic together (RSVP, GMPLS) , you can keep OAM
and constraints freedom, scenarios like per-destination or region-chain PCE
delegation is still allowed
The PCC can have more control and options, or keep one LSP with
LOAD-BALANCING + candidate path


>
> The proposal in draft-koldychev-pce-multipath indeed proposes elegant way
> to encode all computed SLs (as multiple SERO lists) into a single PLSP –
> the one originally reported by the delegated PLSP. In fact, this method
> allows at anytime the PCE to send PCUpd to add/remove/update SL(s) within a
> single PLSP freely – which IMO is powerful.
>

I understand that people like to map their management objects directly,
but Its awkward to say that one path is not one path, Anyhow in term of TE
and OAM, each segment-list is kind of independent.
PCCreate works equally well for a PCE to create/delete paths, the
LOAD-BALANCING and suggested EROs offer more flexibility from PCE and PCC.



>
>
> I think the same argument applies to backup paths/SLs too.. The PCC would
> not know how many SL(s) can protect a single path, so it would not be able
> to a-priori create PLSPs and use association object.
>
>
> Where is the requirement of updating all the segment-list of an
> SR-Candidate together coming from?
>
>
>
> On an unrelated note, why is it called Candidate-path and not
> candidate-multipath, if there are multiple path?
>
>
>
> [TS]: please refer to draft-ietf-spring-segment-routing-policy which
> defines such terms…
>
>
>
The draft does not say why its considered a single path when it has
multiple physical paths,  nor the use of association with multiple PLSP
contradict contradict the unit of signaling (the unit of signaling being
the association parameters) .