I have to agree with Brian Dennis on the age issue. For generations age
has been referenced as a classification of intelligence. This
classification is clearly going out the window with the emerging
generation. Technology has changed the way children have been raised and
their brains have been scientifically proven by professors at MIT to be
"wired" differently than the older generations. For christ sake I saw a
6 year old at wal-mart a few days ago walking around with a friggin
iphone.
Throughout the years I've have worked with several engineers in a wide
range of ages groups and I can say without a doubt that there are some
extremely intelligent young individuals in the industry just as there
are extremely intelligent older individuals whom have been in the
industry for 10+ years. However I have worked with several people whom
have been in the network field for 15+ years and cannot tell me what TCP
port BGP operates on.
Just because someone is younger than you does not mean that you cannot
learn something from them and the notion that because someone is younger
than you that they cannot teach you something you dont already know is
ill-conceived. Times change and speaking from personal experience; my
neice is doing computer science classes in 7th grade that I used to do
in college.
None the less, age is irrelevant and should be not be part of a group
study discussion at all. One can argue that with experiance comes age,
of course someone else could also argue it's not the quanity of
experience that matters, its the quality. The same goes for
training/education.
Matthew George
On 27.03.2012 14:37, Brian Dennis wrote:
> Narbik,
> I think you're reading too much into this. I've known Brian McGahan
> for over 9 years and he's one of the most laid back individuals you
> will ever come across. I've literally seen him upset once in those 9
> years. He doesn't walk around with a big ego on this shoulder and
> always has a smile on his face. He wasn't trying to upset you in any
> way.
>
> In regards to him being young (late-twenties), in this field as fast
> as things change, age really doesn't have a lot to do with anyone's
> knowledge. One of the smartest students I ever had in one of my
> bootcamps was only 23. He of course easily passed the lab on his
> first attempt. Just the other day I was reading an article in
> regards
> to the latest changes in the linux kernel only to get to the bottom
> and see that the author was still in high school. Now that I had to
> laugh about ;-)
>
> --
> Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/Voice)
> bdennis_at_ine.com
>
> Internetwork Expert, Inc.
> http://www.INE.com
>
>
> On 03/27/2012 10:32 AM, Narbik Kocharians wrote:
>> Brian,
>>
>> Lets respect each other and have some professionalism and
>> professional
>> courtesy, we are both instructors and we have taught this subject
>> many many
>> times, to constantly pick on words and get into semantics does NOT
>> make you
>> a better instructor, as a matter of fact it works against you, and
>> it does
>> not go well with me and/or other students or participants of this
>> forum.
>> People are sick and tired of this kind of childish games and
>> behavior. To
>> constantly do that, does not automatically put people in your class,
>> or
>> sign people to your forum. This is a total waste of my time.
>>
>> So from now on, I will NOT participate in any childish
>> discussions/arguments of this kind, and as a mater of fact I wont
>> even
>> reply to you unless its unicast.
>>
>> To teach me anything, you must know it better than me, I do not want
>> to be
>> rude, but you are too young to do that.
>>
>> On Tue, Mar 27, 2012 at 8:52 AM, Brian McGahan<bmcgahan_at_ine.com>
>> wrote:
>>
>>> Don't worry m8, you learn something new every day.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Narbik Kocharians [mailto:narbikk_at_gmail.com]
>>> *Sent:* Tuesday, March 27, 2012 10:43 AM
>>>
>>> *To:* Brian McGahan
>>> *Cc:* Marko Milivojevic; Yemi Salau; ccielab_at_groupstudy.com
>>> *Subject:* Re: OT: GS Archives Search****
>>>
>>> ** **
>>>
>>> hahahahahaha****
>>>
>>> ** **
>>>
>>> I thought it all happens automagically.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> On Tue, Mar 27, 2012 at 8:34 AM, Brian McGahan<bmcgahan_at_ine.com>
>>> wrote:**
>>> **
>>>
>>>> The "Route-target" is a BGP extended community that indicates
>>>> which
>>> routes should be exported from a given VRF or imported into a given
>>> VRF.**
>>> **
>>>
>>> The Route Target doesn't control which routes leave the VRF to go
>>> into
>>> VPNv4 BGP, redistribution controls this. If you don't set a Route
>>> Target
>>> the VPNv4 routes will still originated, but no one will be able to
>>> import
>>> them on the other side. This is actually a common misconfiguration
>>> for
>>> MPLS L3VPN.****
>>>
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>>> bmcgahan_at_INE.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.INE.com
>>>
>>> ****
>>>
>>> From: Narbik Kocharians [mailto:narbikk_at_gmail.com]
>>> Sent: Monday, March 26, 2012 9:18 PM
>>> To: Brian McGahan
>>> Cc: Marko Milivojevic; Yemi Salau; ccielab_at_groupstudy.com****
>>>
>>> Subject: Re: OT: GS Archives Search****
>>>
>>> Since we all know what VRFs are. Remember that the VRF is NOT
>>> operational
>>> without an RD.
>>> What is an RD? An RD is a 64 bit value that is attached to the
>>> customer's
>>> IPv4 address, to make it a Unique 96 bit address called VPNv4.
>>> These
>>> addresses are ONLY exchanged between the PE routers. In Brian's
>>> example,
>>> RDs distinguish one route from another, in his example 10.0.0.0:A
>>> from
>>> 10.0.0.0:B.
>>>
>>> I think that the name "VPNv4" is the worst name they could assign
>>> to these
>>> addresses, because many people think that RDs define the VPN, and
>>> they DO
>>> NOT define the VPN.
>>>
>>> Once the PE router attaches the RD to the CE routes, it then sends
>>> the
>>> VPNv4 address/es to the other PE router/s. The receiving PE router
>>> strips
>>> the RD from the VPNv4 prefix, and it's left with an IPv4 address.
>>> ****
>>>
>>> NOW..How does the receiving PE know which VRF does the IP address
>>> belong
>>> to? The answer is "Route-Target".****
>>>
>>>
>>> The "Route-target" is a BGP extended community that indicates which
>>> routes
>>> should be exported from a given VRF or imported into a given VRF.
>>> I hope this helped.
>>> On Mon, Mar 26, 2012 at 6:27 PM, Brian McGahan<bmcgahan_at_ine.com>
>>> wrote:
>>> Personally that seems overly confusing to me. Yes Route Targets
>>> are an
>>> attribute of the route, but that attribute is not part of the BGP
>>> Bestpath
>>> Selection. I'm not sure how it ties together. It's simpler to
>>> think of it
>>> this way:
>>>
>>> It's given that customers of a Service Provider will have
>>> overlapping IP
>>> addressing in their VPNs, e.g. you will have more than two
>>> customers who
>>> use the 10.0.0.0/8 network. The RD is how you tell them apart. If
>>> you
>>> have customer "A" with RD "A" and customer "B" with RD "B" the
>>> routes "A:
>>> 10.0.0.0/8" and "B:10.0.0.0/8" become unique. This is all the RD
>>> does.
>>>
>>> The Route Target tells you which VRF table the route belongs to.
>>> You have
>>> to separate the two attributes because sometimes you want the same
>>> route to
>>> belong to multiple VRF tables. This is common in what's known as
>>> "Central
>>> Services VPNs". For example if the Service Provider hosts email
>>> for
>>> customers, that route to the mail server would have to be in the
>>> routing
>>> table of multiple customers. This doesn't break the rule of the
>>> route
>>> having to be unique though, which is what the RD does.
>>>
>>> Like I said you may be able to find more clarification in this
>>> video:
>>> http://goo.gl/Y0imB.
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>>> bmcgahan_at_INE.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.INE.com
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On
>>> Behalf Of
>>> Marko Milivojevic
>>> Sent: Monday, March 26, 2012 6:00 PM
>>> To: Yemi Salau
>>> Cc: ccielab_at_groupstudy.com
>>> Subject: Re: OT: GS Archives Search
>>>
>>> Simple reason - prefixes are passed on through the bestpath
>>> selection
>>> process where the best one is chosen based on attributes. RT is a
>>> community, which is an attribute. This means that given two
>>> prefixes with
>>> different RTs would be treated as equals when it comes to bestpath
>>> selection. With RD we extend the prefix space to 86 bits and then
>>> use those
>>> for comparison instead of 32bit ones.
>>>
>>> [ iPhone, brevity, etc disclaimer :-) ]
>>>
>>> --
>>> Marko Milivojevic - CCIE #18427
>>>
>>> :: This message was sent from a mobile device. I apologize for
>>> errors and
>>> brevity. ::
>>>
>>> On Mar 26, 2012, at 14:44, Yemi Salau<salauolayemi_at_yahoo.co.uk>
>>> wrote:
>>>
>>>> Thanks Marko, reading RFC 4364, I was trying to figure out why RT
>>>> couldn't
>>> do the same job of RD for uniquely separating VPN-IPv4 routes
>>> within the
>>> provider MPLS cloud. I'll watch your video when I get home. Many
>>> Thanks.
>>>>
>>>> From: Marko Milivojevic<markom_at_ipexpert.com>
>>>> To: Yemi Salau<salauolayemi_at_yahoo.co.uk>
>>>> Cc: ccielab_at_groupstudy.com
>>>> Sent: Monday, 26 March 2012, 16:25
>>>> Subject: Re: OT: GS Archives Search
>>>>
>>>>
>>>> Yemi,
>>>>
>>>> I'm not sure about the Archive search, but I can certainly help
>>>> you
>>>> with RD
>>> and RT. Almost two years ago I hosted a free online training
>>> session
>>> called "MPLS 101". You can find it, together with all other
>>> recorded
>>> vLectures on many other subjects here:
>>>>
>>>> http://bit.ly/vLecture
>>>>
>>>> Please go ahead and watch it and if you have any questions feel
>>>> free
>>>> to ask
>>> them here.
>>>>
>>>> --
>>>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor -
>>>> IPexpert
>>>>
>>>> On Mon, Mar 26, 2012 at 10:18, 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Narbik Kocharians
>>> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>>> www.MicronicsTraining.com
>>> Sr. Technical Instructor
>>> YES! We take Cisco Learning Credits!
>>> A Cisco Learning Partner****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> *Narbik Kocharians**
>>> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>>> *www.MicronicsTraining.com*<http://www.micronicstraining.com/>
>>> Sr. Technical Instructor ****
>>>
>>> YES! We take Cisco Learning Credits!
>>> A Cisco Learning Partner****
>>>
>>> ** **
>>>
>>
>>
>>
>> --
>> *Narbik Kocharians
>> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>> *www.MicronicsTraining.com*<http://www.micronicstraining.com/>
>> Sr. Technical Instructor
>> YES! We take Cisco Learning Credits!
>> A Cisco Learning Partner
>>
>>
>> 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 - 15:54:28 ART
This archive was generated by hypermail 2.2.0 : Sun Apr 01 2012 - 07:56:52 ART