IPFRR has always included LDP-FRR as well. Both are clearly hop-by-hop distributed routing - hence the wording in the charter.
There's RSVP-TE FRR and that is clearly for explicitly routed paths - which is clearly not hop-by-hop distributed routing. Since an RSVP-TE LSP can be a forwarding adjacency that appears as a link in the IGP, of course there is the potential for an IP/LDP FRR solution to use a TE LSP as a link. Solutions that require explicitly routed paths to be computed in a non-distributed fashion seem out of the problem scope to me. Alia On Tue, Nov 15, 2011 at 10:27 PM, Eric Osborne (eosborne) <[email protected]> wrote: > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Sriganesh Kini >> Sent: Wednesday, November 16, 2011 11:11 AM >> To: Stewart Bryant (stbryant) >> Cc: [email protected] >> Subject: Re: Charter Update (Discussion) >> >> Solutions that use exclusively IP have been seen to run the risk of > issues such >> as incomplete coverage or complexity (or both), ...etc. >> Networks that decline to support MPLS would be similarly affected. >> Solutions that use MPLS and have full coverage and are deployable seem >> possible. If we declare non-MPLS(read as IP) networks out of scope of > IPFRR >> that would be quite confusing :-). > > Perhaps...but so would declaring that 'IPFRR' contained MPLS. I always > looked looked at it as: > > - first we had MPLS FRR, which we just called FRR. > - then, for those that were not interested in MPLS FRR, IPFRR was > introduced. Implicitly the name 'IPFRR' excludes MPLS. > > To now redefine IPFRR to say that the 'IP' part refers to client traffic > rather than the forwarding technology which builds your protection is > revisionist and probably contentious. > >> IMO there is value in an IP only solution >> that is simple and has full coverage. If there isn't one then MPLS > based >> solutions seem a better option. >> > > But we're not debating value of various solutions, we're debating > charter and thus where those solutions come from. > > > > eric > > >> On Tue, Nov 15, 2011 at 3:08 PM, Stewart Bryant <[email protected]> >> wrote: >> > >> > 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? >> > >> > - 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 >> > >> >> >> >> -- >> - Sri >> _______________________________________________ >> 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
