Pierre,
> Hello everyone,
>
> We seemed to have some form of consensus on the relevance of the draft,
> but we also received multiple comments
> on the list, mostly asking to remove references to solutions from the
> document.
>
> Here comes an update to the draft trying to satisfy these comments.
The update certainly addresses my comments wrt mixing use case
and solution. Thanks !
I have few more comments on the update.
> 3. Management-free local protection
>
> An alternative protection strategy consists in management-free local
> protection.
>
> For example, a PW from C to E, transported over the shortest path to
> E provided by the SPRING architecture, benefits from management-free
> local protection by having each node along the path (e.g. C and D)
> automatically pre-compute and pre-install a backup path for the
> destination E. Upon local detection of the failure, the traffic is
> repaired over the backup path in sub-50msec.
>
> The backup path computation should support the following
> requirements:
>
> o 100% link, node, and SRLG protection in any topology
> o Automated computation by the IGP
> o Selection of the backup path such as to minimize the chance for
> transient congestion and/or delay during the protection period, as
> reflected by the IGP metric configuration in the network.
>
>
> 4. Managed local protection
>
> There may be cases where a management free repair does not fit the
> policy of the operator. For example, the operator may want the
> backup path to end at the next-hop (or next-next-hop for node
> failure) hence excluding IPFRR/LFA types of backup path. Also, the
Such a backup path could be automatically pre-computed and pre-installed,
providing the management-free local protection.
> operator might want to tightly control the backup path to the next-
> hop: for the destination Z upon the failure of link CD, the backup
> path CGHD might be desired while the backup paths CGD and CHD are
> refused.
>
> The protection mechanism must support the explicit configuration of
> the backup path either under the form of high-level constraints (end
> at the next-hop, end at the next-next-hop, minimize this metric,
> avoid this SRLG...) or under the form of an explicit path.
It seems that the key distinction between 3 and 4 is that 3 relies
on LFA (and its variations), while 4 relies on building link/node
bypasses. Both LFA-based protection, and protection based on
link/node bypasses could be fully automated. It is true however,
that with link/node bypasses the operator, if desired, could have
a fairly detailed control over the bypass.
With this in mind I would suggest to change the title of Section 3
to something like "LFA-based local protection", Section 4
to something like "Local protection based on link/node bypasses",
and also change the first sentence in section 4 to something like
the following:
There may be cases where an LFA-based protection local protection
does not fit the policy of the operator.
Yakov.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
