Eric, What I meant with "virtually" is that there must be a backup in order to use one, there is no uncovered 2%.
Regards, Jeff -----Original Message----- From: Eric Osborne (eosborne) [mailto:[email protected]] Sent: Wednesday, November 16, 2011 17:45 To: Jeff Tantsura Cc: Stewart Bryant (stbryant); Sriganesh Kini; [email protected] Subject: RE: Charter Update (Discussion) > -----Original Message----- > From: Jeff Tantsura [mailto:[email protected]] > Sent: Thursday, November 17, 2011 9:34 AM > To: Eric Osborne (eosborne) > Cc: Stewart Bryant (stbryant); Sriganesh Kini; [email protected] > Subject: Re: Charter Update (Discussion) > > 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. No, and I don't think we need to be in the business of standardizing topologies. But look at it the other way. If a technology provides 100% coverage in some real-world technologies that people are using today but provides 98% in other topologies that are also in use, that technology seems appropriate for the first case. Whether it's appropriate for the second is up to the operator of the second. Right? > 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) > I admit I have not read them. But I think the nuance here hinges on '*virtually* any topology'. If a technology provides 100% in many cases and 98% in many others, is that not 'virtually' all? eric > 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
