Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time

From: Erblichs <[email-masked]>
Date: Thu, 6 Jun 2002 11:36:44 -0700

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

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 12 Jun 2002 08:01:44 -0400

Hi Kasi,

I guess there are no rules I know of, however you could always check the
archives located at
http://discuss.microsoft.com/archives/ospf.html for basic question/doubts as
most of them have been asked earlier.

Thanks,
Vishwas

-----Original Message-----
From: Kasi Viswanath [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 5:15 PM
To: [email-masked]
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time

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" <[email-masked]>
To: <[email-masked]>
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:[email-masked]]
> Sent: Wednesday, June 12, 2002 12:32 AM
> To: [email-masked]
> 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:[email-masked]]
> > > Sent: Friday, June 07, 2002 12:07 AM
> > > To: [email-masked]
> > > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> > >
> > > Group,
> > >