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

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 11 Jun 2002 02:18:17 -0400

Forwarding a thread of comments received on the OSPF list on the OSPF BMWG
drafts.

Thanks,
Vishwas

-----Original Message-----
From: Manral, Vishwas [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 10:49 AM
To: [email-masked]
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time

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

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 11 Jun 2002 02:18:17 -0400

Thanks,
Vishwas

-----Original Message-----
From: Manral, Vishwas [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 10:49 AM
To: [email-masked]
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time

Hi Mitchell,

-Vishwas

5. Definitions

 Hello Interval

OR

B) 5. Definitions

Shortest Path First Time

I would suggest..

D) New item....

* SPF events / triggers

Thanks again.

time
that
make