Subject: Re: [bmwg] OSPF convergence terminology

From: "Daniel Bui" <[email-masked]>
Date: Wed, 2 Jan 2002 04:08:24 -0800

Hi All,

    On internal measurements, Should the implementation be the
responsibility of the router or a third party (i.e. test equipment) to
measure and report the internals of the DUT?

Daniel

----- Original Message -----
From: "Howard C. Berkowitz" <[email-masked]>
To: "Manral, Vishwas" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 20, 2001 1:07 PM
Subject: RE: [bmwg] OSPF convergence terminology

> At 1:46 PM -0500 12/20/01, Manral, Vishwas wrote:
> >Howard,
> >
> >Comments inline prefixed with a VM>
> >
> >Thanks again for all the comments,
> >Vishwas
> >
> >>VM> Agreed. Most of the tests in the methodology draft for OSPF use
> >external
> >>measurements, with one exception. Although for measuring SPF time we
have a
> >>test using external measurements, we generally prefer internal
> >measurements.
> >
> >Thinking a little further, isn't the SPF time more of an
> >implementation specific issue anyway?  The RIB installation time
> >would seem more generally applicable.  A given implementation might
> >have a superfast SPF but a very slow RIB installer, so the
> >"convergence time" is a factor of the two.
> >
> >What is your reasoning for separating out the SPF time? Also, isn't
> >the SPF time highly reflective of the number and types of links,
> >where the total convergence time (sorry, Randy. It's a placeholder)
> >is more operationally useful?
> >
> >VM> I may not have I understood ur question properly, however I will try
to
> >answer my interpretation of the question. ;-)
>
> It sounds like what you are describing a two-step process: SPF to
> FIB. I see it as a three-step process: SPF to RIB to FIB.  Think of
> the basic route selection process in RFC 1812 (e.g., most specific
> prefix first), which is certainly post-SPF.
>
> Depending on the implementation, the RIB and FIB _MAY_ be the same
> data structure, but certainly don't have to be. It's quite common to
> have a single RIB but distributed FIBs.
>
> >
> >Firstly, we have measured times taken by OSPF specific tasks. The time we
> >call SPF time, the time to calculate the SPF for OSPF(from start to end).
> >How the routes are further get to FIB is very implementation specific,
and I
> >feel is not in the scope of OSPF.
> >
> >To explain the exact why we seperated out SPF time, let me try and
explain
> >tests in the methodology draft. Well we have tried to break up
convergence
> >to(simplified it for one LSA)
> >
> >convergence time for a lsa(got from an adjacent router) = time to get the
> >LSA + time to process the LSA + time  diff for scheduling the LSA + SPF
time
> >+ time to give the routes to FIB.
> >
> >We have tried to measure all individual pieces that are OSPF specific.
SPF
> >time happens to be one of them. (I know it is late here nearly 12:00AM,
so I
> >may not be making all sense, but we have thought the things out)
> >
> >
> >>As SPF times can be in units of microseconds, external measurements may
not
> >>be appropriate for the purpose(i think it is hard to get that level of
> >>accuracy). We have readily available outputs in the few routers I have
come
> >>across, which give the outputs(without distorting the readings, as they
are
> >>not "Log outputs" but show commands)
> >>
> >>
> >>VM> Well, although we could have done tests for all kinds of
> >links(including
> >>NBMA and P2MP), in all types of areas(NSSA, stub, normal), we have just
> >done
> >>it on two kinds of links.
> >
> >True.  But at least NBMA is a curse of the real world. I've probably
> >seen more people have problem with NBMA configuration than any other
> >operational part of OSPF. Last time I looked, there were around 5
> >different ways to configure NBMA on a Cisco router.
> >
> >VM> Ok.
> >
> >>tests using all kinds of interfaces?
> >
> >You made a very reasonable choice by differentiating between DR and
> >non-DR situations. Maybe I'm reading too much operational
> >cluelessness into it, but I would like to see some of the NBMA
> >aspects as a reality check for the testing. Consider the following
> >topology:  R1 and R2 are hub routers with connections to all the
> >spoke routers. The intention, of course, is to have no single point
> >of failure, so both R1 and R2 should be eligible to become DR.  If
> >there is no virtual circuit between R1 and R2, however, the NBMA can
> >get partitioned, have arguments over who is DR, and generally be
> >confused.
> >
> >VM> Well ok. I will rethink this up and see how and where it fits in the
> >draft.
> >
> >>
> >>>o    Measurement Units               The LSA time is generally
> >>>measured in milliseconds.
> >  >
> >>We should not preclude the experimental work going on that puts these
> >>times into the microsecond range.
> >>
> >>VM> For internal measurement it is possible, getting reading correct to
> >that
> >>accuracy when using external measurement in my view would not be
possible.
> >I
> >>have read thru Chengiz draft on IGP convergence, I think that too talks
> >>about millisecond convergence.
> >
> >That's what I was thinking of. Remember that both SPF and hello times
> >are involved here, potentially with very fast hellos. Alternatively,
> >you might want to consider the alternative to hellos of depending on
> >layer 1/2 information to detect link (but not dead router) failure.
> >
> >VM> We have a test case for that in the methodology draft, where the
> >detection of neighbor down is because of indication from a lower layer
and
> >not router dead interval expiry(just the case you have indicated). You
might
> >want to read the scalability draft in OSPF-wg, it is a work on OSPF in a
> >similar front, with a different conclusion though.
> >
> >>
> >>Any reason why you found the discussion more appropriate in the
methodology
> >>draft?
> >
> >We started out with things such as route mixes in terminology, but
> >quickly found they were intimately associated both with the load
> >generator requirements and the test report, neither of which "felt
> >right" in terminology.
> >
> >VM> This sounds reasonable, but do you intend to replicate all the stuff
all
> >over again in the iBGP draft if and when that is released.
>
> Probably, although we haven't gotten that far. It's possible there
> may be slight differences, and it's also possible we might split
> route mix into an entirely separate document.
>
>
>
> _______________________________________________
> bmwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/bmwg
>

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

---

From: "Daniel Bui" <[email-masked]>
Date: Wed, 2 Jan 2002 04:08:24 -0800

Hi All,

Daniel

----- Original Message -----
From: "Howard C. Berkowitz" <[email-masked]>
To: "Manral, Vishwas" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 20, 2001 1:07 PM
Subject: RE: [bmwg] OSPF convergence terminology

have a
to
and I
explain
convergence
time
SPF
so I
not
come
are
possible.
and
might
methodology
all