Re: OSPF LSA type 3 filtering

Correct. Summarization of the tree in (2) is the generation of the Type 3 LSA.

What I meant by "no control" is the presence of other protocols that can
populate the RIB. Type 3 will be generated even for those prefixes that are
not in the RIB due to better sources being available. Hence my comment on what
the "routing table structure" refers to.

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
:: This message was sent from a mobile device. I apologize for errors and
brevity. ::
On Jan 4, 2013, at 2:01, shiran guez <shiranp3_at_gmail.com> wrote:
> 1) The RFC have no control, however it is used a guideline for the
programmer implementation, we see many RFC's and some times implementations
are different  however not in this case
> 2) The SPF is done in few stages (sorry for that lack of details as I am
short on time) in each area there is a full detailed tree (that result the RIB
for that area) of that area and then the ABR is summarizing the tree to the
backbone.
>
>
>
> On Fri, Jan 4, 2013 at 11:44 AM, Marko Milivojevic <markom_at_ipexpert.com>
wrote:
>> LSA summarization is not done in/from the RIB. Original Type-3 is created
from the computed SPF tree, which in turn is  based on the information from
Type 1 and Type 2 LSAs. "The routing table structure" in the context quoted is
what I called the "computed SPF tree", not the RIB, as the RFC has no control
over how RIB is constructed.
>>
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior CCIE Instructor - IPexpert
>>
>> :: This message was sent from a mobile device. I apologize for errors and
brevity. ::
>>
>> On Jan 4, 2013, at 1:20, shiran guez <shiranp3_at_gmail.com> wrote:
>>
>> > Hi All
>> >
>> > I have to agree with Brian and add some to back it up:
>> >
>> > 1) LSA type 1 or LSA type 2 does not need to be filtered or summarized
>> > simply because that are locally significant to the area that they where
>> > generated
>> > RFC2328
>> > "
>> >
>> > 12.4.1.  Router-LSAs
>> >
>> > ...
>> >
>> > The LSA is flooded throughout the particular area, and no further.
>> >
>> > ...
>> >
>> > 12.4.2.  Network-LSAs
>> >
>> > ...
>> >
>> > The network-LSA is flooded throughout the area that contains the
>> >            transit network, and no further.
>> >
>> > "
>> >
>> > 2) LSA type 3 is generated from the RIB using the SPF algorithm
>> >
>> > "12.4.3.  Summary-LSAs
>> >
>> > ...
>> >
>> > The precise summary routes to advertise into an area are
>> >            determined by examining the routing table structure (see
>> >            Section 11) in accordance with the algorithm described
>> >            below.
>> >
>> > "
>> >
>> >
>> >   - Any filtering and / or summary is done on the RIB not on the
database
>> >   it self!
>> >
>> > Personal Note: I much prefer the semantics story being told. if you wish
to
>> > follow someone all your professorial life you can take the easy way and
>> > learn configurations and some of the basic or even advanced designs and
you
>> > will do fine in your work, however if you wish to be followed upon and
be
>> > that one that people turn to for answers, you MUST know and understand
the
>> > semantics even if it mean that you need to waist more time and effort.
>> >
>> >
>> >
>> >
>> > On Thu, Jan 3, 2013 at 11:46 AM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>> >
>> >> If you want to continue this as a technical discussion that's fine,
just
>> >> don't freak out again after reading my response ;)
>> >>
>> >> You said:
>> >>
>> >>> What if in area 1 there are some LSA type-1 and type-2? Can you not
>> >> filter them or summarize them with the "area range" command?
>> >>
>> >> No, you can not. This is a fundamentally incorrect notion about OSPF.
>> >> First, both LSA 1 and 2 are area local scope. The ABR cannot pass them
>> >> between areas hence there is no filtering or summarization that can
affect
>> >> them. Secondly, the *topology* information described by these LSAs is
>> >> automatically summarized by the ABR into LSA 3.  The *reachability*
>> >> information is not.
>> >>
>> >> The reachability information described in multiple LSA 3s can
summarized
>> >> together with the "area range" command. Additionally the reachability
>> >> information described in LSA 3 can be filtered with either "area range"
or
>> >> "area filter-list".
>> >>
>> >> "area range" and "area filter-list" do not affect LSAs 1 or 2, they
affect
>> >> LSA 3. You can argue this is semantics if you want, but in binary there
are
>> >> only two values, TRUE and FALSE.
>> >>
>> >>
>> >>
>> >> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>> >> bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>
>> >>
>> >> Internetwork Expert, Inc.
>> >> http://www.INE.com
>> >>
>> >> On Jan 3, 2013, at 3:25 AM, "Narbik Kocharians"
<narbikk_at_gmail.com<mailto:
>> >> narbikk_at_gmail.com>> wrote:
>> >>
>> >> Unbelievable,
>> >>
>> >> You are saying that LSA Type-2s don't provide reachability information,
I
>> >> am saying and showing you that they do provide the subnet mask, you
then
>> >> say that you should NOT say LSA filtering because we can not
theoretically
>> >> filter LSAs, especially when you are going to take the CCIE lab, let me
>> >> tell you something, they will probably say "LSA Type 3 Filtering" as
the
>> >> header, they mention that in every Doc CD i have read, now whose
student/s
>> >> will miss out on the terminology? You guys use it because it is
"commonly
>> >> used" (Based on Petr) or Cisco says it that way in their DOC-CD, but if
I
>> >> say it, you claim that I do not understand basics of OSPF or routing and
I
>> >> should be teaching CCNA.
>> >>
>> >> Then, you agree with Paul about my explanation, and then you ask him
what
>> >> does that have to do with "Area range" or the other commands, so why is
it
>> >> OK with you to use the term "LSA Filtering" and Not anyone else? Check
how
>> >> quick you agreed with Paul, and he was basically repeating what I
>> >> mentioned, that tells me that you are agreeing with me but you like to
>> >> argue. I even said at the end of my post "I am not disagreeing with
you",
>> >> but I guess it did not click.
>> >>
>> >> Once again, stop doing that. Do you know how to unsubscribe a person
from
>> >> a thread? You are very good with google, try it one more time.
>> >>
>> >> On Thu, Jan 3, 2013 at 1:04 AM, Brian McGahan <bmcgahan_at_ine.com<mailto:
>> >> bmcgahan_at_ine.com>> wrote:
>> >> You need to relax Narbik.  I'm not sure how you made this leap in the
>> >> discussion, but thanks for once again ruining a potentially helpful and
>> >> intellectual thread on the list.  My apologies if I somehow offended
you.
>> >>
>> >>
>> >>
>> >> On Jan 3, 2013, at 2:34 AM, "Narbik Kocharians"
<narbikk_at_gmail.com<mailto:
>> >> narbikk_at_gmail.com>> wrote:
>> >>
>> >> You are VERY WRONG. Picking words and acting as though you are an
attorney
>> >> did not convince me a bit, but your immaturity is what you definitely
>> >> proved here today. You are in a routing loop my friend, we made a full
>> >> circle.
>> >>
>> >> Unsubscribe me from further responses. Paul B the owner of this forum
>> >> forgot to put a disclaimer about people under legal age.
>> >>
>> >> If this continues, I will ignore your replies or comments all together,
or
>> >> i will be very rude.
>> >>
>> >> How do you connect this discussion about my students failing because in
>> >> many words they attended my class? What does that have to do with this
>> >> discussion? A student of mine told me that you guys in your volumes say
>> >> "filtering LSA Type 3", so what gives you the right to use the terms
that
>> >> you disagree with?
>> >>
>> >> I even commented in your blog, when Petr wrote an article "ospf route
>> >> filtering demystified" right after I released a 10 minute VoD on OSPF
>> >> Filtering, and he admitted in the blog that he uses that same term
because
>> >> Cisco uses it in their documentation, but if I use it, I don't know what
I
>> >> am talking about? Here incase you forgot:
>> >> http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/
>> >>
>> >> As I said before unsubscribe me from this thread.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>> >
>> >
>> > --
>> > Shiran Guez
>> > MCSE CCNP NCE1 JNCIA-ENT JNCIS-ENT CCIE #20572
>> > http://cciep3.blogspot.com
>> > http://www.linkedin.com/in/cciep3
>> > http://twitter.com/cciep3
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ENT JNCIS-ENT CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
Blogs and organic groups at http://www.ccie.net