Subject: RE: [bmwg] OSPF convergence terminology

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 5 Jan 2002 03:39:46 -0500

Daniel,

The internal measurements are a responsibility of the router equipment
manufacturers. However these measurements require test conditions, which
need to be available and hence require test equipment for that purpose.

The internal measurements as in our draft for "spf time" can be done thru
show commands, and are available in both CISCO and Juniper equipment(I am
unaware of other router vendor equipment). We have given an alternative
measurement method using "external measurement", which can be used even if
such mechanism is not available in the router. However it is prefereable to
have measurements using both methods specified in the test report.

Thanks,
Vishwas

-----Original Message-----
From: Daniel Bui [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 5:38 PM
To: Manral, Vishwas; [email-masked]; Howard C. Berkowitz
Subject: Re: [bmwg] OSPF convergence terminology

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

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 5 Jan 2002 03:39:46 -0500

Daniel,

Thanks,
Vishwas

-----Original Message-----
From: Daniel Bui [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 5:38 PM
To: Manral, Vishwas; [email-masked]; Howard C. Berkowitz
Subject: Re: [bmwg] OSPF convergence terminology

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

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 5 Jan 2002 03:52:24 -0500

Howard,

Sorry for the extremely delayed reply. Comments inline prefixed by a VM>

-Vishwas

VM>Yes, I understand that and I havent exactly forgotten about it, however
it probably needs another thought.

VM> Yes, that could be another approach. Did you get a chance to check the
methodology draft?

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 5 Jan 2002 03:52:24 -0500

Howard,

-Vishwas