Hello Yakov, On Apr 2, 2014, at 4:24 PM, Yakov Rekhter <[email protected]> wrote:
> 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. Indeed. I'm getting the feeling that the next-hop/next-next-hop example of section 4 is not well chosen for what we were trying to achieve :) The use case of section 4 is basically: Give freedom to the operator on the definition of the repair path. We say that SPRING should allow the operator to define the protection he wants with the precision that he needs. More on this below, as it's related with your other comments. > > >> 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. Mmm, it was more: section 3 relies on automated protection established by the router, as experience showed that it most often does the job, while section 4 relies on operator input to the router, in order to achieve a protection path that better fits his policy. > 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. Similarly to the link/node bypass approach, there are ways to provide more detailed control in some IP-FRR variants. > > 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. Based on your comments and mine, I would suggest the following ToC, as I think it unifies our views on the topic: 1. Path protection 2. Unmanaged local protection 2.1 Shortest path based / IP-FRR variants 2.2 Automated link/node bypass (as per your comment that link/node bypasses provide an unmanaged solutions) 3. Managed local protection 3.1 managed shortest path based protection (allowing for constraints on the repair brought by the IP-FRR machinery, with the level of granularity as currently described in the doc. ) 3.2 managed link/node bypass based protection (allowing for the detailed control over the bypass, as you mentioned) Does that make sense to you? Thanks a lot for your feedback, Pierre. > > Yakov. > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
