Hi Anton,
Thanks very much for reviewing my draft.
I am not an expert in MTR . But from what I read about MTR, I understand this
an routing enhancement. Here all the routers in network should understand MTR(
Pls correct me if I am wrong). MTR type of implementation makes sense in large
campus environment where in all the network devices and links are under single
administrative control. However, I will not be able to extend my MTR topology
on to my WAN. For example consider the following scenario.
I am large enterprise customer . My network spread across 100+ location in 3
continents. I need to set up a global wan network.
Now I decide go for MPLS provider. In most cases I will not be able to get a
single MPLS provider to service all locations. I will be going for multiple
MPLS providers to optimize my cost. And where MPLS reach is not there, I would
also be forced to go for an internet circuit and built IPSEC VPN. Now I will
end up having to manage larger network which is a mix of MPLS and
Internet-IPSEC VPN. In the this scenario, I do not have option of doing MTR .
My MPLS network providers simply won't agree to run MTR .
Hence I do not think MTR is practical on large scale diverse wan environments.
Under DPS I am simply suggesting to build a DMVPN overlay. I will not have any
problem building such an overlay network on any type of WAN network.
Additionally DPS is not at all about routing across two topologies based on IP
precedence or DSCP. It attempts to achieve following objectives .
1) When two sites communicates, DPS provides a mechanism for participating
sites exchange signaling information regarding the application that they wanted
to send over DPS routing domain
2) Once information is exchanged , it separates the traffic meant to be routed
over DPS domain ( only non-critical application going to DPS capable sites
pushed to DPS domain )
Once it is pushed on to DPS domain, routing happens over the pre-built overlay
network.
It should be noted that , in DPS , traffic does not comes marked. Instead
traffic is marked once it hits the router( based on DPS profile of site to
which destination IP belongs to ). Again the marking that is done by the router
is locally significant . Once the decision is taken and traffic pushed in to
DPS routing domain( or normal routing domain), the marking are never looked at.
In fact We can remark the traffic once the decision is taken without any issues.
To summarize, objective of Multi-topology Routing and DPS are different and it
resolves different problems.
Pls. mail me back in case you have any clarification.
Thanks and Regards
Arun
Arun Arumuganainar
CCIE#16918 ( R&S and SP )
Technical Design Authority
Advanced Solution Delivery
Tata Communications Limited
Direct +44 207 029 9513 | Fax +44 207 519 4609 | Mobile +44 7771 831 052
| IP 709513
[email protected]
-----Original Message-----
From: Anton Smirnov [mailto:[email protected]]
Sent: 18 October 2013 17:29
To: Arun Arumuganainar
Subject: Re: Requesting Comments about the Draft :
draft-aumuganainar-rtgwg-dps-00
Hi Arun,
how is this different from MTR (multitopology routing)? I mean I see the
difference in how it is implemented but it looks like if MTR was properly and
widely supported then one could do all that DPS does.
Anton
On 10/15/2013 08:45 PM, Arun Arumuganainar wrote:
> Hello all,
> I have posted a following draft - Dynamic Path selection ( Based on
> Application
> )._http://www.ietf.org/internet-drafts/draft-aumuganainar-rtgwg-dps-00
> .txt_ In the draft I have proposed a network design architecture for
> routing packets via different paths available in the network based on
> application port number. Primarily, this is targeted for Enterprise
> customers who have built up redundancy at their WAN edge but are
> suffering from a congested primary link whilst the secondary is idle.
> The objective of this architecture is as follows
> 1) Offload bulky application on to the secondary link
> 2) Achieve the above without introducing asymmetric routing in the
> network It would be great if you can review this draft and respond
> back with any comments.
> Thanks very much.
> Thanks and Regards
> Arun
> *Arun Arumuganainar*
> *CCIE#16918 ( R&S and SP )*
> Technical Design Authority
> Advanced Solution Delivery
>
> *Tata Communications Limited
> *Direct +44 207 029 9513 | Fax +44 207 519 4609 | Mobile +44 7771
> 831 052 | IP 709513
> [email protected]_
> <mailto:[email protected]>
>
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
