Hi Stewart, Great thoughts..
Essentially you are saying use X algorithm (LFA/rLFA/MRT/combination-o- these/some-great-alternate-path-hunting-algorithm) to compute alternate paths by a controller for each node and program these for link/node failures as per operator choice. Perhaps it's futuristic but that future may not be that far!! >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. Given a typical 1000 node network with bunch of links at each node every topology change has to be factored to compute and distribute alternates to all the nodes. If we really put the alternate computation off from each node and centralized at a controller (which is really powerful) we still need to factor the distribution (and delays surrounding it) part of computed results for all the nodes This is an interesting thing to model. Else the concern will continue to linger given the local computation/protection experience in a non-SDN routing model. Again, in any case some delay MAY be tolerable as these are alternatives computed for getting ready for next failure any ways. -- Uma C. From: Stewart Bryant [mailto:[email protected]] Sent: Tuesday, December 02, 2014 11:33 PM To: [email protected]; Uma Chunduri; Alia Atlas; Loa Andersson Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: maturity of the MRT technology 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]<mailto:[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]] Sent: Friday, November 21, 2014 20:37 To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Friday, November 21, 2014 1:23 AM To: Alia Atlas; Loa Andersson Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]] On Behalf Of Alia Atlas Sent: Thursday, November 20, 2014 19:17 To: Loa Andersson Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; VIGOUREUX, MARTIN (MARTIN); [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> Senior MPLS Expert [email protected]<mailto:[email protected]> Huawei Technologies (consultant) phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064> _______________________________________________ rtgwg mailing list [email protected]<mailto:[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 list [email protected]<mailto:[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
