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