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

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 12 Jun 2002 00:59:51 -0400

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,
> >
> >         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: Kasi Viswanath <[email-masked]>
Date: Wed, 12 Jun 2002 17:14:49 +0530

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

---

From: Erblichs <[email-masked]>
Date: Wed, 12 Jun 2002 11:02:43 -0700

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
        -----------------------

---

From: Tom Thomas <[email-masked]>
Date: Sat, 15 Jun 2002 14:35:46 -0400

Depends in what way you are using "ospf implementation" if you are
considering doing it from a programming perspective then this si the right
forum. If you are doing it from 'how do I configure' routers X, Y, Z to use
OSPF this is not the right place. If you need some pointers to those places
contact me off line.

Tom

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Kasi
Viswanath
Sent: Wednesday, June 12, 2002 7:45 AM
To: [email-masked]
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time

Hi all

TIA

with regards
kasi viswanath.N.J