Hi Ina,
%%% The PCC must at the minimum know what the destination is, and a loose hop
is a way to encode this. I cannot think of any situation in which the PCC does
not know the destination. I don't think the PCE should worry about whether the
PCC will request a path or not, since we are mandating a PCReq to request a
path, the PCE does not have to imply it from the ERO
[SLI] PCC knows the destination but when LSP is delegated, PCC does not own
path of the LSP anymore, so ERO should reflect what PCE sent to PCC. Again in
case of no path available from PCE, PCE will send empty ERO, PCE will not
really understand if PCC reports back an ERO with the destination in the ERO as
loose hop as this may imply that the PCC is trying to establish a path to the
destination using loose hop which is not compliant with what PCE tells. You may
fall into PCUpd/PCRpt loop in such scenario because PCE will try to update PCC
until PCC reports the same path as PCE sent in ERO.
Best Regards,
Stephane
From: Ina Minei [mailto:inami...@google.com]
Sent: Thursday, August 11, 2016 19:25
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA);
adr...@olddog.co.uk; Dhruv Dhody; pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?
Stephane,
Please see inline %%%
[snip]
Example :
Case#1 : PCC has no path, it reports empty ERO in PCRpt (case Olivier was
mentioning), PCE vendor does not compute path and does not send update
### In this case, the ERO must at least have one loose hop, the destination.
This will be clarified in the next version of the draft in (the new) section
6.1. See proposed text below:
The intended path, represented by the ERO object, is REQUIRED. If
the ERO ojbect is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error-value
to be assigned by IANA (ERO object missing). When present, the ERO
object SHOULD contain at least one subobject, representing the
destination of the LSP. "
This is a SHOULD and not a MUST because an empty ERO is allowed for
the end of synchronization marker.
[SLI] Having PCC sending an ERO with the destination as loose hop does not make
sense to me while PCC has no path. How do you differentiate with the case the
PCC reports a loose path to the destination from the case it has no path ?
%%% The PCC must at the minimum know what the destination is, and a loose hop
is a way to encode this. I cannot think of any situation in which the PCC does
not know the destination. I don't think the PCE should worry about whether the
PCC will request a path or not, since we are mandating a PCReq to request a
path, the PCE does not have to imply it from the ERO.
=> Using PCReq could make sense here as Mustapha proposed or clearly
mentioning that PCRpt with empty ERO needs to trigger path computation and
sending PCUpd.
### This will be clarified in the next version of the draft as well, the mode
of operation is to mandate a PCReq before the delegation.
[SLI] Ok thanks, that’s the good way to go.
Proposed text (new section 5.8.2)
5.8.2. Switching from Passive Stateful to Active Stateful
This section deals with the scenario of an LSP transitioning from a
passive stateful to an active stateful mode of operation. When the
LSP has no working path, prior to delegating the LSP, the PCC MUST
first use the procedure defined in Section 5.8.1 to request the
initial path from the PCE. This is required because the action of
delegating the LSP to a PCE using a PCRpt message is not an explicit
request to the 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.
The PCRpt message MUST NOT be used by the PCC to attempt to request a path from
the PCE.
When the LSP is delegated after its setup, it may be useful for the
PCC to communicate to the PCE the locally configured intended
configuration parameters, so that the PCE may reuse them in its
computations. Such parameters MAY be acquired through an out of band
channel, or MAY be communicated in the PCRpt message delegating the
LSPs, by including them as part of the intented-attribute-list as
explained in Section 6.1. An implementation MAY allow policies on
the PCC to determine the configuration parameters to be sent to the
PCE.
(the intended-attribute-list is new, see more below).
Case#2 : PCC has a path, it reports ERO, PCE has different constraints
configured, we expect PCE to update the path
Case#3 : PCC has a path, it reports ERO, PCE has a different optimization
algorithm leading to a different ERO with the same constraint, we expect PCE to
update the path
Case#2 and Case#3 requires the PCE to know the existing constraint configured
on PCC for the LSP , by using only PCRpt we cannot have such constraint
information, we need a PCReq also to describe the configuration (PCRpt only
describes operation state => Mustapha’s point again).
