Dear Editors, chairs, WG community,
please find my comments to the current version of your work below:
* Introduction
o The first paragraph may leave an impression that local protection of
transit LSRs is not being already addressed, neither by RFC 4090, nor RFC 4875;
o I think that "global protection" is not commonly used term, "end-to-end
protection" seems to be commonly used instead.
* Section 3.1
o Third paragraph contains the following requirement:
"For a P2P LSP, after the primary ingress fails, the backup ingress must use a
method to reliably detect the failure of the primary ingress before the PATH
message for the LSP expires at the next hop of the primary ingress."
But that is not obvious that such requirement is really needed. Since this is
RSVP-TE LSP, why not to use MP2MP construct and let the Source node to control
switchover. Especially since, as noted in the last paragraph of Section 2.1,
primary and backup ingress nodes must be connected by a logical link, which in
general case will be a tunnel. Thus this solution puts a requirement,
implicitly though, to instantiate a tunnel per protection group, tunnel that
would not be used to carry traffic.
o In addition, what is importance of requirement quoted above:
"... before the PATH message for the LSP expires at the next hop of the primary
ingress"
o Fourth paragraph makes very questionable assumption in:
"After the primary ingress fails, it will not be reachable after routing
convergence."
I believe that if OAM session is between two nodes there's no reliable way to
differentiate between node and link failure. Thus, to declare a node
unreachable there must be N tunnels for N OAM sessions that monitor all
possible paths between two nodes. (Note, that if there was no requirement to
use a tunnel between primary and backup ingress, multi-hop BFD could be used
though its detection time being limited by IGP convergence, which may be too
slow comparing with your requirement of tens milliseconds).
* Section 5.1
o Regarding "Ingress local protection in use" flag
As demonstrated earlier, backup ingress node has no reliable way to detect that
primary ingress node is not reachable to the Source and thus protection must be
activated.
Considering that backup ingress may initiate described in the document actions
not when primary ingress became unavailable to Source, I believe that cases
that may produce false positives must be removed along with extensions that
intended to support these cases. In my opinion, the only viable case of ingress
protection is Source-centric where Source monitors availability of both primary
and backup ingress nodes and controls traffic switchover. I'd ask WG to discuss
these comments and, if agreed, ask Editors to make appropriate changes to the
document.
Regards,
Greg
