Ben:
<snip>
> I would broaden the definition as selection suggests to me explicit
> routing, whereas increasing the reliabilty of implicit path construction
> would imply intelligent pruning of options. To a certain extent,
> conservative label retention in an implicit case implies some knowledge of
> which LSPs would be more optimal than others, and sufficient information
> should be available at the overall L3 layer (not just MPLS topolocy) to make
> that determination.
Selection, in this case, was meant generically (not intended to imply explicit
routing); however, the path protection mechanism draft does not address
reroute recovery (this is covered in other IDs) and so the broadening
you suggest may be out of scope for that ID. Is there a need to address this
in the framework (I don' think the framework says anything in particular about
recovery path selection options)?
I'll admit, I've lumped the recovery mechanisms together where protection switching with resource reservation (and the corollary effect, pre-emption) is a superset of reroute recovery. To my mind, where reroute recovery and protection switching collide head on is in every way but the timely allocation of resources on the backup path (where specific resource allocation is required and we're out to be frugal). The livliness mechanisms, path routing, revertive protection etc. have common requirements. Such as timliness, path diversity, minimal disruption of ordering etc.
<snip>
I was concerned that the broader defintion of protection domain being proposed
implied that ONE recovery action (e.g., PSL switch) would be able
to recover from any fault in the protection domain. I had trouble seeing
how a fault on an L3 link could be correlated with the working LSP, and the
PSL informed. The concept of concatenated protection domains is much
simpler, and I think this allows a narrower definition of protection
domain (uniform mechanism). Redundancy/diversity/coordination at protection
domain boundaries is then the interesting problem.
Agreed, some of this is addressed by redundant egress LERs, as a failure of the egress LER can be addressed in the MPLS domain, a failure downstream of the egress LER is handed by the egress LER or a downstream node in the network. (it wears two hats). If I'm into another MPLS domain, I may have redundant trees, one anchored on the working egress LER and one on the protection egress LER, (I'd probably have that anyway), and if it is some other technology, it presumably would be non-MPLS re-route and may not be as fast, but then thats what you get.
<snip>
Well... I wasn't trying to say anything about non-MPLS mechanisms.
We are trying to further clarify the framework terminology (a summary
has been posted to the mail list by Vas Makam) and "protection
switching" implies resource reservation. This is not to say that
there are not recovery mechanisms that work otherwise (e.g., reroute
recovery). The path protection mechanism ID is aimed at protection
switching, so resource reservation is assumed there, and this leads
to some desire to have a mechanism that operates simply at the MPLS
layer.
I'm not out to re-invent the rest of the network either...
<snip>
It makes sense to have a bigger toolbox, as long as we have a reasonable
understanding of the tools and their appropriate use. You have pointed out
a useful alternative to be added, and we should try to develop a clear
description for the affected IDs.
Agreed.
>
> 2) I don't think we need to overload the recovery space by expanding
> the protected domain beyond MPLS, only acknowledge that we may concatenate
> protection mechanisms, they function autonomously, and may have multiple
> points of attachment. Coordination of protection across multiple transport
> technologies is out of scope if we are to make progress.
This seems reasonable.
Good,
regards
Dave