Hi all,
I have a belated (but hopefully late is still better than never) comment on
path protection as defined in Section 2 of the
draft<https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/?include_text=1>.
This second para in this section says:
A first protection strategy consists in excluding any local repair
but instead use end-to-end path protection where each SPRING path is
protected by a second disjoint SPRING path. In this case local
protection MUST NOT be used.
First of all, I do not think that RFC 2119 language should be used in
Informational documents, especially in the documents that describe use cases.
In addition, I specifically disagree with the quoted statement above, because,
from my POV:
* Local repair and end-to-end path protection can be combined for the
same path
* Such a combination may be beneficial for the operators.
One possible way to combine the two is described below:
1. A pair of SR paths is set up between the given two nodes - later
referred to as source and destination - in the network. These paths are
"SR-disjoint" in the sense that their "explicit routes" do not have any common
elements, be they nodes or adjacencies, with exclusion of the final destination
2. Local repair for these paths is enabled in the network. It is
triggered by locally observed events (link failures etc.), applied by the nodes
adjacent to the failure and guarantees that, in the case of a link or node
failure that is not specified in the explicit route, traffic along the affected
path would be restored within <X> milliseconds
3. End-to-end liveness monitoring is enabled for the two SR paths, and
detects end-to-end failures of these paths within <Y> milliseconds where Y >>
X. In other words, end-to-end liveness monitoring for these paths will ignore
any failures that local repair can fix, but will detect failures that cannot be
locally repaired (e.g., failures of nodes or links that have been specified in
the explicit route of one of the paths
4. End-to-end liveness monitoring triggers end-to-end path protection to
be applied by the source node in the following way:
a. If it recognizes both paths as alive, one of them will carry the
customer traffic, while the other one will be idle. The rules for selecting the
active path in this scenario may vary
b. If end-to-end failure of one of these paths is detected while the other
one remains alive, traffic will be carried across the live path
c. If end-to-end failure of both paths is detected (e.g., if the final
destination node fails, or if the network is partitioned), this is recognized
as an unrecoverable failure.
>From my POV the combination of local repair and end-to-end protection for SR
>paths is one of a few possibilities to protect such paths against failures of
>nodes and/or links that have been specified in their explicit routes. (Another
>option has been described in Node Protection for SR-TE
>Paths<https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-00>,
> but this draft has expired).
Do I miss something substantial?
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
