Yakov, Okay I'll stick to the proposed ToC for rev -02. ( and put a better example in former section 4 ;) )
Cheers, Pierre. On Apr 2, 2014, at 6:44 PM, Yakov Rekhter <[email protected]> wrote: > 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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
