I know virtually nothing about RDs and RTs, but when I'm teaching
stuff that I am familiar with, I like to start out with the problem.
My mentor Howard Berkowitz is always fond of asking, "What problem are
you trying to solve?" Everything in networking is a solution to some
problem; understand the problem and you understand the solution.
If I'm understanding this correctly, RDs might be all that's necessary
for a basic VPN where customer A never needs to reach Customer B and
vice versa. RDs solve the problem of needing to create unique routes
in BGP for VPNs. But if your requirements change, you might run into
new problems. What if your basic VPNs are working but you suddenly
develop the need for some customers to see certain routes from other
customers? As I understand it, that's where Route Targets come in.
They solve a new and slightly different problem, right?
John
On Tue, Mar 27, 2012 at 10:03 AM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
> I simply cannot add anything to the fantastically simple explanation Carlos provided. If you haven't, read his response. Then go back and read the one I sent last night.
>
> Always question WHY and you will learn. I like your learning approach - it's the right way to do it.
>
> --
> Marko Milivojevic - CCIE #18427
>
> :: This message was sent from a mobile device. I apologize for errors and brevity. ::
>
> On Mar 27, 2012, at 5:40, Olayemi Salau <salauolayemi_at_googlemail.com> wrote:
>
>> Marc...thanks, this is the search page I was looking for.
>>
>> I wanted to search the archives to see if someone has asked why MP-BGP couldn't stick with RTs to "distinguish" customer routes, by extending normal 4 octect addresses with RT and not RDs, this will still achieve a 96 bit addr that can be used for MPBGP. I understand why RD cant do the job of RTs(flexibilty, complexities and load sharing traffic MPLS VPN traffic etc.), but I don't get why RTs can't do the job of RDs. I think the simple answer to this lies in the design/conceptual decisions. Perhaps RD was designed before RTs came into being. Nothing in the RFC 4364 to say this as I read.
>>
>> Like everyone said, we all know what they are n do. There are some design decisions fundamentals that cant be questioned I suppose, or maybe they can....like why Area 0 (not Area 1) for OSPF BB and Level2 (not Level0) "contiguousness" for ISIS, why does higher priorities in OSPF and lower BID in SPT win elections .....etc
>>
>> I thank everyone for their explanations of RT/RD. Very much appreciated.
>>
>> Yemi
>>
>> On Mar 27, 2012, at 6:19, marc edwards <renorider_at_gmail.com> wrote:
>>
>>> Answer to your original question:
>>>
>>> http://groupstudy.com/cgi-bin/search
>>>
>>> Now a great new thread in the archives from our experts as well :)
>>>
>>> HTH
>>>
>>> Marc
>>>
>>> On Mon, Mar 26, 2012 at 10:18 AM, Yemi Salau <salauolayemi_at_yahoo.co.uk>wrote:
>>>
>>>> Guys,
>>>>
>>>> I remember a time where I was able to search the GS archives for stuffs.
>>>> Is this still available today? I want to search out some stuffs on RD vs RT.
>>>>
>>>> Yemi
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Tue Mar 27 2012 - 11:04:21 ART
This archive was generated by hypermail 2.2.0 : Sun Apr 01 2012 - 07:56:52 ART