Re: maturity of the MRT technology

Wed, 03 Dec 2014 08:26:52 -0800 

On 03/12/2014 14:48, Alia Atlas wrote:

Stewart,

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.


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.

Of course this does not just apply to MRT, it applies to any/all of the
algorithms.
The question of needing to distribute alternates from a centralized location 
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
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.


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 protected] <mailto:[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]
    <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





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

Reply via email to