Stewart, It's always fun to speculate about what technology the future may hold. Certainly a way to ease deployment of a new technology like MRT could include using a single device to compute and distribute the alternates; partially deployment is also quite reasonable to handle parts of the network topology that don't have full LFA protection.
The question of needing to distribute alternates from a centralized location ties back to how reasonable is the single failure assumption? I haven't seen any recent studies indicating that the mean time between failures has increased. So - there's the question of whether fast-reroute provides enough protection to be worth the added complexity if the protection can't be reapplied within, say, 5 seconds. Regards, Alia On Wed, Dec 3, 2014 at 2:32 AM, Stewart Bryant <[email protected]> wrote: > I have been mulling this over for a while and I am wondering > how the current industry debate on SDN vs traditional distributed > routing plays into this. > > You could build a case that whilst there always needs to be a base > topology that needs to be calculated using a traditional distributed > routing protocol (for absolute resilience and bootstrapping) any > domain wide repair topology could be better implemented through > SDN since it benefits from a global perspective. > > That would suggest that whilst we might benefit from standardizing > the advertisement of some IPFRR related parameters, and would > certainly benefit from standardization of the YANG models needed > to control the IPFRR subsystem, the method of calculating the > repair topology itself ought to be private to the orchestrator. > > The classical argument against this is concern with the time to > reinstate the repair topology after a failure, but I am not sure > how significant this is since (a) normally this would be an incremental > change, and (b) given that we would normally be computing this > on some high end platform it could have the results of any single > failure (or restore) pre-computed. > > - Stewart > > > On 23/11/2014 08:47, [email protected] wrote: > > HI Uma, > > > > > Is this because of domain wide deployment requirements MRT brings-in > (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the > network? > > > > No, domain-wide deployment is not an issue. The issue I see in MRT (for my > use case) is unoptimality of the FRR path (at least using lowpoint > algorithm). But anyway, as I mentioned, I’m not opposed to make MRT > progressing at all. It’s good to have multiple tools. > > > > Best Regards, > > > > > > *From:* Uma Chunduri [mailto:[email protected] > <[email protected]>] > *Sent:* Friday, November 21, 2014 20:37 > *To:* LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* RE: maturity of the MRT technology > > > > >I’m not a great supporter of MRT implementation in my network, because it > does not address correctly my use cases but despite of this, > > > > Is this because of domain wide deployment requirements MRT brings-in (as > elaborated by Stewart?) or you are ok with LFA/rLFA coverage in the network? > > > > > I deeply think that it’s another item in the FRR toolchest (like LFA, > remote LFA …), > > >it will be up to each Service Provider to choose the appropriate > technology based on its own use case/constraints. > > > > I agree with above. It depends on the particular deployment scenario and > applicability for that network. > > > > -- > > Uma C. > > > > *From:* mpls [mailto:[email protected] <[email protected]>] *On > Behalf Of *[email protected] > *Sent:* Friday, November 21, 2014 1:23 AM > *To:* Alia Atlas; Loa Andersson > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* Re: [mpls] maturity of the MRT technology > > > > +1 > > > > As for all FRR technologies, MRT has pros and cons, and this does not > influence the maturity of the technical solutions. We already had multiple > discussions online and offline on technical details leading now to > documents that are quite detailed and well understood technology (with pros > and cons as I mentioned). I’m not a great supporter of MRT implementation > in my network, because it does not address correctly my use cases but > despite of this, I deeply think that it’s another item in the FRR toolchest > (like LFA, remote LFA …), it will be up to each Service Provider to choose > the appropriate technology based on its own use case/constraints. > Processing of MRT , IMHO, should be done as LFA and other similar > technologies so standard track sounds good to me. > > > > We already seen much less mature technologies going to standard track and > being RFC without any running code after … > > > > Best Regards, > > > > Stephane > > > > > > *From:* rtgwg [mailto:[email protected] <[email protected]>] *On > Behalf Of *Alia Atlas > *Sent:* Thursday, November 20, 2014 19:17 > *To:* Loa Andersson > *Cc:* [email protected]; [email protected]; > [email protected]; VIGOUREUX, MARTIN (MARTIN); > [email protected] > *Subject:* Re: maturity of the MRT technology > > > > Loa, > > > > Without any hats on, I would note: > > > > a) As far as I'm aware, this has seen two independent prototypes > implemented. > > b) I have not heard any concrete technical concerns. Stewart and I did > specificallly > > discuss MRT this past IETF. I am, of course, quite interested in hearing > any > > concrete technical concerns. > > > > c) I'd be happy seeing this question asked of more drafts :-) > > > > Regards, > > Alia > > > > > > On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <[email protected]> wrote: > > Working Groups, > > We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been > posted to the mpls wg mailing list. > > In his MPLS-RT review Stewart Bryant says: > > "I have concerns about whether or not MRT technology has the maturity > expected in the standards track. However that decision needs to be > taken in RTGWG and MPLS needs to follow their and lead in determining > the fate and track of this draft. This draft should not be published > ahead of the drafts that define the technology that it is supporting." > > He also says that he see no reason not to go ahead and start the poll to > see if we have consensus to adopt the document as an mpls wg document. > > The question Stewart ask is valid, and we'd like input from the rtgwg > and rtgwg chairs (copied on this mail). We will also copy both the > poll for adoption and the wglc to the rtgwg mailing list. > > /Loa > mpls wg co-chair > -- > > > Loa Andersson email: [email protected] > Senior MPLS Expert [email protected] > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > > _______________________________________________ > rtgwg mailing [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
