> -----Original Message----- > From: Alia Atlas [mailto:[email protected]] > Sent: Wednesday, November 16, 2011 1:33 PM > To: Eric Osborne (eosborne) > Cc: Sriganesh Kini; Stewart Bryant (stbryant); [email protected] > Subject: Re: Charter Update (Discussion) > > 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.
OK, so solutions which use TE LSPs as FAs for FRR are OK but computing the paths and destinations for those LSPs is not? eric > > 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
