+1 Adrian.
complexity associated with GR (additional state/signaling/etc) wouldn’t be
justified, given existing means to provide synchronization.
Cheers,
Jeff
On 6/19/17, 08:21, "Pce on behalf of Adrian Farrel" <pce-boun...@ietf.org on
behalf of adr...@olddog.co.uk> wrote:
Hi Sasha,
> However, our primary interest is the control plane (including PCC)
restart in
a
> network element with separated control and forwarding planes.
Yup. I assumed control plane restart was the issue.
> Specifically, my colleagues and I try to understand, how to make such a
restart
> non-traffic affecting while:
> - The network uses Segment Routing for setting up paths computed by the
PCE.
> This means that these paths are only known to their respective head-end
nodes.
> This situation is different from the scenario where RSVP-TE is used to
signal these
> paths, since they cannot be re-learned from the neighbors as part of
the
RSVP-TE
> graceful restart procedures
OK, so you are less worried about PCE restart than about restart of control
plane elements in the network.
But you are using SR so there is no state (or rather only routing state) in
the
network. The state for the path is at the PCE and at the headend, and
nowhere
else.
So, if a network node restarts, it doesn't matter.
If the headend loses state it must relearn it from the PCE. If the PCE loses
state it must relearn it from the headend.
> - The protocols used for distributing SR-related information (i.e., IGP
and
BGP SR
> extensions) are GR-capable, and GR for them is enabled in the network
Right. So that is additional reason to not worry about restart elsewhere in
the
network
> - The PCE is an active stateful PCE, i.e., it instructs the head-end
node,
> which paths should be set up without any requests coming from the
> nodes.
This makes life easier because we know that the PCE has pushed all of the
paths.
So restart is just matter of pushing all of those paths again.
It is an implementation question whether the restart has preserved
forwarding
plane state. In this case, forwarding plane state is "classification"
information, that is "packets of this type get this SID stack".
If the forwarding state is saved, data can continue to flow. Restart is
about
making sure that the PCE and headend are in synch.
If forwarding state is not saved, the PCE must resynch the state before the
headend can use it.
It is certainly the case that the failure of a PCEP session does not result
in
discard of headend state. That is, the headend can continue to operate
using any
state that was pushed by a PCE even after that PCE has failed. This might be
termed "non-stop forwarding" in some protocols in the middle of the
network, but
is just normal business for a stateful active PCE.
> Hopefully this clarifies the context for our question.
It does.
> It may well be that the requirement for non-traffic affecting control
plane
> restart can be addressed without any changed to the existing protocols.
> Alternatively, it is possible that some minor changes (like making the
PCE
> aware of separation between the control and forwarding planes, negotiation
> of GR capabilities and grace periods etc.) are required.
>
> Any inputs would be highly appreciated.
My take-away from the swamp of text above is that:
- Network nodes don't need to do anything special except in their
relationship with the PCE
- A stateful PCE needs to resynch pushed paths for all paths that it has
responsibility for upon reconnection with a network node
Now we can go and look at the stateful I-D and the PCE-initiated I-D to see
whether we already have enough stuff in the protocol. My belief is that we
do.
Cheers,
Adrian
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
