Eric, Self-rephrasing - if a solution to provide 100% coverage is topology dependent then it simply doesn't provide 100%, there's no "right topology" to apply to every network. However - if you look at rtgwg agenda - there are at least 2 proposals to provide 100% coverage in virtually any topology (given there's a backup)
Regards, Jeff On Nov 17, 2011, at 9:08 AM, "Eric Osborne (eosborne)" <[email protected]> wrote: > Self-replying....what if the charter said something like "RTGWG focuses > on IGP-based protection mechanisms which require no multihop explicit > routing and which attempt to provide 100% failure coverage" or something > along those lines? > > 'no multihop explicit routing' is deliberately intended to exclude not > just TE LSPs but also static TP LSPs and whatever other explicit path > steering mechanisms we come up with (IP Options? A zombie outbreak of > CR-LDP?). It allows for the small bit of explicit routing that LFA > does, picking an OIF not in the RIB. > > "attempts to provide 100% coverage" is to recognize that there are > multiple solutions to the problem (LFA, MRT, whatever we come up with > next). All can provide 100% coverage in the right topology, but some > can't cover all scenarios; it may be that the scenarios which can't be > 100% covered are not of interest to those who wish to deploy a > particular technology. > > > Language lawyering aside, does this seem like a reasonable approach? > > > eric > > >> -----Original Message----- >> From: Eric Osborne (eosborne) >> Sent: Wednesday, November 16, 2011 8:20 AM >> To: Stewart Bryant (stbryant); Sriganesh Kini >> Cc: [email protected] >> Subject: RE: Charter Update (Discussion) >> >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On > Behalf >>> Of Stewart Bryant (stbryant) >>> Sent: Wednesday, November 16, 2011 7:09 AM >>> To: Sriganesh Kini >>> Cc: [email protected] >>> Subject: Re: Charter Update (Discussion) >>> >>> >>> Unfortunately whether MPLS is used in a particular network segment > or >>> not is a complex and sometimes emotive issue. >>> >>> If we decide that the best solution is to use MPLS we then face the >>> issue of what to do about networks that decline to support MPLS. Do > we >>> declare non-MPLS networks out of scope for IPFRR, or do we work on >>> another non- MPLS solution? >> >> I think you also have to wrestle with the opposite problem. If you > declare >> that convergence schemes which require MPLS to provide 100% coverage >> are within scope, what exactly is out of scope? >> >> >> >> eric >> >>> >>> - Stewart >>> >>> >>> On 15/11/2011 22:29, Sriganesh Kini wrote: >>>> IP is addressed via MPLS. If IP forwarding were to be used >>>> exclusively, then it becomes complicated. With MPLS being extended >>>> to more parts of the network than just the core, it seems that is >>>> not as much of a concern. >>>> >>>> On Tue, Nov 15, 2011 at 2:14 PM, Stewart > Bryant<[email protected]> >>> wrote: >>>>> On 15/11/2011 21:36, Sriganesh Kini wrote: >>>>>> Hi, >>>>>> >>>>>> I agree that having a solution with full coverage is very useful >>>>>> because it removes the need for complicated analysis to > determine >>>>>> what is protected versus what is not (and worse, how that > changes >>>>>> as the topology change). But the solution has to be simple for > it >>>>>> to get deployed. >>>>>> >>>>>> One approach using MPLS that solves this using extensions to a >>>>>> single protocol (LDP) is given in draft-kini-mpls-frr-ldp. >>>>> It the approach extensible to an IP context? >>>>> >>>>> Stewart >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtgwg mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/rtgwg >>>>> >>>> >>>> >>> >>> >>> -- >>> For corporate legal information go to: >>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> >>> _______________________________________________ >>> rtgwg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
