Subject: Re: [mpls] maturity of the MRT technology

From: Stewart Bryant <[email-masked]>
Date: Wed, 03 Dec 2014 07:32:37 +0000

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-masked] 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-masked]]
> *Sent:* Friday, November 21, 2014 20:37
> *To:* LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> *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-masked]] *On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> *Sent:* Friday, November 21, 2014 1:23 AM
> *To:* Alia Atlas; Loa Andersson
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *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-masked]] *On Behalf Of *Alia Atlas
> *Sent:* Thursday, November 20, 2014 19:17
> *To:* Loa Andersson
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; VIGOUREUX, MARTIN 
> (MARTIN); [email-masked] <mailto:[email-masked]>
> *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-masked] 
> <mailto:[email-masked]>> 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-masked] 
> <mailto:[email-masked]>
> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
> Huawei Technologies (consultant)  phone: +46 739 81 21 64 
> <tel:%2B46%20739%2081%2021%2064>
>
> _______________________________________________
> rtgwg mailing list
> [email-masked] <mailto:[email-masked]>
> 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-masked]
> 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

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 3 Dec 2014 08:06:16 +0000

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!!

>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-masked]]
Sent: Tuesday, December 02, 2014 11:33 PM
To: [email-masked]; Uma Chunduri; Alia Atlas; Loa Andersson
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: maturity of the MRT technology

- Stewart

On 23/11/2014 08:47, [email-masked]<mailto:[email-masked]> 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-masked]]
Sent: Friday, November 21, 2014 20:37
To: LITKOWSKI Stephane SCE/IBNF; Alia Atlas; Loa Andersson
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, November 21, 2014 1:23 AM
To: Alia Atlas; Loa Andersson
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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-masked]] On Behalf Of Alia Atlas
Sent: Thursday, November 20, 2014 19:17
To: Loa Andersson
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; VIGOUREUX, MARTIN (MARTIN); [email-masked]<mailto:[email-masked]>
Subject: Re: maturity of the MRT technology

Loa,

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.

Regards,
Alia

On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Working Groups,

/Loa
mpls wg co-chair
--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

Thank you.

Thank you.

rtgwg mailing list

[email-masked]<mailto:[email-masked]>

--

---

From: Alia Atlas <[email-masked]>
Date: Wed, 3 Dec 2014 09:48:39 -0500

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-masked]> wrote:

> (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-masked]
> <[email-masked]>]
> >I’m not a great supporter of MRT implementation in my network, because it
> 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 …),
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> 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-masked] <[email-masked]>] *On
> Behalf Of *Alia Atlas
> [email-masked]; VIGOUREUX, MARTIN (MARTIN);
> [email-masked]
> On Tue, Nov 18, 2014 at 7:08 PM, Loa Andersson <[email-masked]> wrote:
>
> Working Groups,
>
> Senior MPLS Expert                          [email-masked]
> rtgwg mailing [email-masked]://www.ietf.org/mailman/listinfo/rtgwg
>
>
>
> --

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 03 Dec 2014 16:23:16 +0000

> It's always fun to speculate about what technology the future may hold.
Well SDN is more current design phase than future, although it could be
redesign of old technology since this is the way that transport networks
have always worked.

> include using a single device to compute and distribute the 
> alternates; partially
Of course this does not just apply to MRT, it applies to any/all of the
algorithms.
> ties back to how reasonable is the single failure assumption?
Are you talking about failure of the SDN controller or the need to deal 
with
multiple concurrent network failures? SDN controller reliability is a
subject in itself, which I assume to be getting focus by the SDN teams.
> I haven't seen
> be worth the added complexity if the protection can't be reapplied 
> within, say,
> 5 seconds.

How realistic is that requirement?

My understanding is that MRFB in the types of networks that need IPFRR 
is weeks
rather than seconds, and large parts of the network are disjoint WRT to 
repair
strategy, so the first priority is to remove any repairs that would loop 
as a result
of invocation of a repair in the presence of a missing link,  second is to
replace those repairs and third is to re-optimize the repairs, but I 
would be
surprised if that needed to be completed in seconds.

We have an existence proof for some of the above in transport networks which
can't react in that sort of time and rely use an SDN approach.

- Stewart

>
> Regards,
> Alia
>
> On Wed, Dec 3, 2014 at 2:32 AM, Stewart Bryant <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 23/11/2014 08:47, [email-masked]
>     <mailto:[email-masked]> 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,
>>
>>     *Cc:* [email-masked] <mailto:[email-masked]>;
>>     [email-masked] <mailto:[email-masked]>;
>>     >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 …),
>>
>>     I agree with above.  It depends on the particular deployment
>>     scenario and applicability for that network.
>>
>>     --
>>
>>     Uma C.
>>
>>     *Cc:* [email-masked] <mailto:[email-masked]>;
>>     [email-masked] <mailto:[email-masked]>;
>>     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
>>
>>     *Cc:* [email-masked] <mailto:[email-masked]>;
>>     [email-masked] <mailto:[email-masked]>;
>>     <mailto:[email-masked]>; VIGOUREUX,
>>     MARTIN (MARTIN); [email-masked] <mailto:[email-masked]>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 3 Dec 2014 19:59:22 +0000

Getting back on your original post, after a bit of more thinking:

Perhaps centralized or distributed computing of repair path approach pros/cons are interesting to discuss ;

>to control the IPFRR subsystem,

Sure.

>the method of calculating the

When we agree to standardize the IPFRR related parameters, IMO it’s important to standardize the relevant algorithm too regardless of where it’s used.

If it is used in a distributed manner this question is less relevant as it’s mostly  multi-vendor deployments.

Even when an orchestrator is computing using a particular algorithm IMO, it’s important Vendor X and Vendor Y of the controller do the same thing and
also this has to be *clearly* understood to validate (to see the corner cases are working correct)  and debug stuff, once deployed.

Proprietary stuff may come with their own cost/risk.

--
Uma C.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 04 Dec 2014 13:26:02 +0000

On 03/12/2014 19:59, Uma Chunduri wrote:
> When we agree to standardize the IPFRR related parameters, IMO it’s 
> important to standardize the relevant algorithm too regardless of 
> where it’s used.
>
> Even when an orchestrator is computing using a particular algorithm 
> IMO, it’s important Vendor X and Vendor Y of the controller do the 
> same thing and
>
> also this has to be **clearly** understood to validate (to see the 
> corner cases are working correct)  and debug stuff, once deployed.
>
I would appreciate hearing the operator's perspective(s) on this.

Will we see two vendor's controllers operate over the same set of nodes 
such that identical behaviour is required, or is this an area where we 
are likely to see customization to execute the repair in a way that best 
suits the specifics of the network and the applicable business model?

Stewart