Inline - Sri
Sent from my iPad On Nov 16, 2011, at 11:27 AM, "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 The IPFRR LFA RFC refers to protecting LDP LSP traffic. Maybe that is the source of the confusion ? > 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. Are you saying that RFC 5286 should have left out MPLS ? But that is not the point. LFA should not be interpreted as IP only protection mechanism. Rather it should be viewed as a technology that can protect traffic along shortest paths. This may be IP or LDP LSP traffic. > > 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. I agree. I was just responding to Stewart on where the work is. > > > > 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
