Pierre, > 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 :)
Correct :-) > 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? Yes, it does make sense. The ToC you proposed above is fine. Yakov. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
