Wow,

        Hope this helps:

        First try to identify what you are trying to do and
        limit your scope to the amount of time and effort
        available...

        1) Are you concerned with byte order?
        2) Are you concerned with stack overflow?
        3) Are you concerned with redistribution?
        4) Do you need to support area border routers (ABR)?
        5) Do you need to do packet/field validation?
        6) Do you need to write your own spf algorithm?
        7) Do you need to support opaque LSAs?
        8) Are you concerned with only intra-area routes?
        9) Are you concerned with BMA, P2P, etc support?
        10) Do you need to support Ethernet, ATM, FDDI, etc?
        11) Are you concerned with authentication support?
        12) Do you need to write your own Command Line Interface (CLI)?
        ... :-)
        100) What is your testing configuration, environment,criteria?

        And verify that the scope is acceptable for your project.

        Mitchell Erblich
        -----------------------

Kasi Viswanath wrote:
>
> Hi all
>
> I'm new to this mailing list,
> and I'm doing ospf implementation as my academic project
> and I have lots of doubts to clarify.
> Is there any format or rules to ask question?
>
> TIA
>
> with regards
> kasi viswanath.N.J
>
> ----- Original Message -----
> From: "Manral, Vishwas" <VishwasMNETPLANE.COM>
> To: <OSPFDISCUSS.MICROSOFT.COM>
> Sent: Wednesday, June 12, 2002 10:29 AM
> Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
> > Hi Mitchell,
> >
> > Thanks for ur response.
> >
> > If you read the methodology draft, you will observe that most of the tests
> > are like, how long it takes for a change to be propagated to other routers
> > and the SPF being calculated. The definition of convergence is given in
> the
> > context of this, as are all other definitions, where the LSA change does
> > cause a route change in the neighbor. I do understand ur point however.
> >
> > I guess I agree we can change the definiton of convergence to better
> reflect
> > the what you say. We could have loop free paths even with different
> > databases and this may not be what we want to convey.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Erblichs [mailto:erblichsEARTHLINK.NET]
> > Sent: Wednesday, June 12, 2002 12:32 AM
> > To: OSPFDISCUSS.MICROSOFT.COM
> > Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> >
> >
> > Vishwas,
> >
> > Most of the points here are what I call nits..
> >
> > However, the convergence item "C" is the most
> > interesting one. You state that "the same LSDB may be on
> > all the routers and they still may have LSA's on the
> > retransmit list), Maxage etc."
> >
> > I consider convergence is when a level of stasis
> > (a non-changing time is present). When LSA are on
> > re-xmit lists, it needs to be assumed that one or
> > more routers (IS's) may not have the LSA. They may
> > have had it and it may have been aged out.
> >
> > As a implicit item in my statement, the item may
> > be on the re-xmit list because the one or more
> > other link-partners may have lost its link and
> > the adjacency timer has not yet fired.
> >
> > Thus, I was striving for a known state that we
> > are in a state of stable non-changing conditions
> > for at least a moment in time..
> >
> > I have seen non-loop free paths and all of the
> > link state databases have identical LSAs. It was
> > due to configuration errors and redistribution
> > differences in a multi-protocol environment.
> >
> > Yes, it is a level of more complexity than as
> > the wg's definition.. I have run into a number of
> > people who disagree on really what is meant by
> > convergence. I don't think it really has been
> > stated with a precise definition. So, I was
> > trying to nail it down here...
> >
> > Mitchell Erblich
> > =================
> >
> >
> >
> >
> >
> >
> > "Manral, Vishwas" wrote:
> > >
> > > Hi Mitchell,
> > >
> > > Thanks for the comments. My comments are inline prefixed by a VM>.
> > >
> > > -Vishwas
> > >
> > > -----------------------------------------------------------
> > > A)
> > >
> > > 5. Definitions
> > >
> > > Hello Interval
> > >
> > > "and point-to-point networks" -> and non-Demand Circuit point-to-point
> > > networks.
> > >
> > > OR
> > >
> > > "and point-to-point networks". + Exceptions of some point-to-point
> > > circuits are demand point to point circuits, which would be the
> > > successful of hello supression negotiation..
> > >
> > > On the assumption that RFC 1793 Hello suppression is employed.
> > > VM> I agree to your point. However I think its an overkill to put all
> the
> > > special cases in a definition.
> > >
> > > B) 5. Definitions
> > >
> > > Shortest Path First Time
> > >
> > > ADD... Some implimentations may force a interval between
> > > successive SPF calculations. If it exists, then this additional time
> > > value should be subtracted from the total time.
> > > VM> If you check the methodology draft, we have taken care of this.
> > >
> > > C) Meaning of Convergence
> > >
> > > I would suggest..
> > >
> > > A network is termed converged at one point in time when all of the
> > > following has occured.
> > >
> > > * all adjacencies that are to be formed have proceeded to full
> > > state.
> > > * all retransmission lists are empty
> > > * all recieved update, req LSAs have been processed
> > > * All MAXAGE LSAs within the link state databases have been removed
> > > * the link state databases are synchronized, exceptions are opaque LSAs
> > > * all routers within an area have completed their SPF calculations
> > > and have inserted the results into their respective routing tables
> > >
> > > VM> The definition of convergence that has been derived has come out
> after
> > > atleast 40 mail exchanges on the bmwg list. I however do not agree to
> > many
> > > of the points you state above, like the one on retransmission lists(the
> > same
> > > LSDB may be on all the routers and they still may have LSA's on the
> > > retransmit list), Maxage etc.
> > >
> > > D) New item....
> > >
> > > 6.3 Types of Network Events
> > >
> > > * SPF events / triggers
> > >
> > > Time the various types of events/triggers that would cause a
> > > SPF calculation to occur.
> > > VM> I guess that is something we do not require in the draft at all.
> > Network
> > > events have been listed, as we have given the methodology to find time
> to
> > > converge when the events occur.
> > >
> > > Thanks again.
> > >
> > > "Manral, Vishwas" wrote:
> > > >
> > > > Hi Mitchell,
> > > >
> > > > Apologies for the delayed reply(I have been away from my mail for some
> > > time
> > > > now) and thanks for the comment.
> > > >
> > > > I guess the point you are trying to make is that although the DR
> > election
> > > > itself could cause a delay in the broadcast case, there are certain
> > other
> > > > factors involved.
> > > >
> > > > However in the context of the discussion, what we have tried to say is
> > > that
> > > > all other things being the same(as we have put it as "of the same
> > speed"),
> > > > because on a broadcast network if routers were comming up
> symultaneously
> > > > they would have to wait for the Waiting interval before electing a DR,
> > it
> > > > would take a longer time. Also the flooding takes place via the DR/BDR
> > and
> > > > that causes additional delay. Maybe we will try and modify the text to
> > > make
> > > > the fact clearer.
> > > >
> > > > Besides I would like to know of any other point you you would like to
> > > > comment on(not agree on) within the draft.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Erblichs [mailto:erblichsEARTHLINK.NET]
> > > > Sent: Friday, June 07, 2002 12:07 AM
> > > > To: OSPFDISCUSS.MICROSOFT.COM
> > > > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> > > >
> > > > Group,
> > > >
> > > > I have a few items that I don't necessarily agree
> > > > with here, but the one item that I feel most
> > > > strongly with is..
> > > >
> > > > 5. Definition
> > > > Point-to-Point links
> > > > Discussion "will take lesser time to converge than
> > > > a broadcast link"
> > > >
> > > > Yes, I do agree that a DR election, mainly due to the
> > > > initial wait time, can become a large part in the time
> > > > to converge.
> > > >
> > > > Given that if point-to-point links are substituted for
> > > > broadcast links, I feel that the above statement becomes
> > > > false..
> > > >
> > > > Note: adjacencies = adjs
> > > >
> > > > Why,,
> > > >
> > > > The fewer number of adjs
> > > > allows a fewer number of database description packets to
> > > > be exchanged, a fewer number of master/slave negotiations,
> > > > etc. As each additional adj is formed, there is a higher
> > > > probability that additional SPF calculations will need
> > > > to be performed.
> > > >
> > > > In addition, additional flooding due to additional adjs
> > > > will slow the converge process. Also with the additional
> > > > load, the router may identify a overload condition, and
> > > > even temporally reject some of these point-to-point adj
> > > > formations..
> > > >
> > > > I am unsure whether a single slow router to inform the
> > > > DR or BDR of its links vs informing all of the adjs of
> > > > its links, will adversely effect the MA vs the P2P link
> > > > topology more. In my mind there are just too many variables.
> > > >
> > > > In addition, the statement does not implicitly or explicitly
> > > > imply whether the routing topology has changed and thus
> > > > the BDR is being elected as the DR.
> > > >
> > > > THUS, I would consider a different wording to be on the
> > > > order of ... (Please note that I have not mentioned
> > > > Ethernet (shared-meda) type links where collisions with
> > > > exponential backoff may play a role OR....) To keep it
> > > > simple.
> > > >
> > > > A point-to-point link network topology makes the tradeoff
> > > > of additional adjacencies formations vs the overhead of
> > > > the required multi-access DR/ BDR election. Given a small
> > > > number of adjacencies in a point-to-point environment, it
> > > > can be more efficent than a multi-access topology if the
> > > > links between the DR and DRothers are constantly changing
> > > > OR that the election wait-time requirement is a large
> > > > part of the convergence time.
> > > >
> > > > Thanks,
> > > > Mitchell Erblich
> >

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]