Re: more comments on draft-ietf-bmwg-benchres-term

Feher Gabor wrote:
> 
> Dear All,
> 
> Thanks for the comments!
> 
> >Apart from Bob's comment, I am bit concerned that the authors are
> >slightly confused about diffserv. The text under "Issues" in 6.1.3
> >really misses the point - the way you look at resource management
> >in a diffserv domain is simply different from how you look at it
> >in a reserved-flow model. A BMWG draft for diffserv domains might
> >be a good idea, but that is a separate discussion.

> I agree that benchmarking DiffServ domains is a completely different
> discussion, and we do not intend to investigate it together with IntServ.
> However, it is an interesting question, wether a DiffServ router is a
> router that supports resource reservation or not. Actually, I would say,
> that in itself it is not a resource reservation capable router, 

I agree. It's a router with configured resource management (specifically,
configured queue management) as described in RFC 3290, with measureable
quantities defined in the MIB (RFC 3289). The question for BMWG would
be whether other quantities beyond those defined in the MIB are
valid metrics.

> however if
> a DiffServ router is extended with a signaling protocol, like RODA
> (formally Load Control) then it already supports resource reservations.
> (Resources are allocated (namely) to certain traffic flows) And this is why
> DiffServ is mentioned in the draft.

draft-ietf-bmwg-ospfconv-term-01.txt

I believe that the terminology used in this document does not reflect
current OSPF practice.

A Broadcast Link is defined as

              Networks supporting many (more than two) attached
routers,
              together with the capability to address a single
physical
              message to all of the attached routers (broadcast). In
the
              context of [2] and [3], broadcast links are taken as
those
              on which a designated router is elected.

In practice, put together any pair of routers on a LAN (with broadcast
capability) and I expect to see a DR elected with its concomitant
Network LSA.  I appreciate that the wording comes from RFC2328 but
that document does later contradict itself with a reference to a DR
being elected on any broadcast or NBMA network with at least two
routers (ie two does quallify).

And for Hello Interval

              ... The
              typical hello interval is 10 seconds on broadcast net-
              works, and 30 seconds for point-to-multipoint and point-
              to-point networks.

RFC2328 suggests 10 second for LANs (broadcast or not) with 30 second

more on draft-feher-bmwg-benchres-term

Date: Tue, 03 Dec 2002 14:56:03 -0800
From: Kathleen Nichols <nichols <at> packetdesign.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020930
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Bradner <sob <at> harvard.edu>
CC: braden <at> isi.edu, brian <at> hursley.ibm.com
Subject: Re: draft-feher-bmwg-benchres-term-01.txt
References: <200211270148.gAR1mP59010878 <at> newdev.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Actually draft-ietf-bmwg-benchres-term-02.txt.

Okay, I agree with Bob about it seeming to wander into NSIS
territory (but then NSIS seems to be wandering into all
kinds of territory, so maybe there's some method here).
I also agree with Brian that they seem to see diffserv as
some kind of subset of rsvp-intserv.

It seems odd to me that there is a concern with "different
resource reservation protocols" that includes some stuff
that is in research papers, not IETF RFCs, standards or
informational. Interestingly enough, one of these, Boomerang
shares a first author with this document. I think mentioning
it on a par with RSVP in a WG document is a blantant ploy to
try to create some kind of standards visibility for someone's
research project. And a rather back-handed one. Who is shipping
Boomerang? What IETF WG owns it?

RE: draft-ietf-bmwg-ospfconv-term-01.txt

Hi Tom,

Thanks for the comment and sorry for the delayed reply.

Well regarding the first comment I guess we have tried not to repeat
definitions in the OSPF RFC itself. The definitions we have given are more
in context of the methodology draft which I guess has been stated. However
if there are any contradictions we will  remove them.

Regarding the second comment, those values were put in more in response to a
comment that typical values used in production networks may be put in, into
the draft. Looking at that in perspective I feel that as such values change,
we could do without such things in the terminology draft itself.

Thanks,
Vishwas

-----Original Message-----
From: Tom Petch [mailto:nwnetworks <at> dial.pipex.com]
Sent: Monday, December 02, 2002 9:52 PM
To: bmwg <at> ietf.org
Cc: OSPF
Subject: [bmwg] draft-ietf-bmwg-ospfconv-term-01.txt

I believe that the terminology used in this document does not reflect
current OSPF practice.

A Broadcast Link is defined as

              Networks supporting many (more than two) attached

draft-ietf-bmwg-benchres-term-02.txt

given the review comments on this one, should i consider this draft
back in the wg's court and waiting for a new version?

randy

Re: several comments on draft-feher-bmwg-benchres-term

Randy and all,

On Tue, 3 Dec 2002, Randy Bush wrote:

 > I also agree with Brian that they seem to see diffserv as
 > some kind of subset of rsvp-intserv.

Well, we're certainly aware of the difference between intserv and
diffserv, and we do not intend to deal with diffserv here in general. We
mentioned a protocol proposal (RODA, http://standards.ericsson.net/rmd/),
which is built on top of diffserv, but as this text seems to be misleading
we'll clarify this. To sum up, we are interesting only in routers that use
signaling protocols to perform resource reservations.

 > It seems odd to me that there is a concern with "different
 > resource reservation protocols" that includes some stuff
 > that is in research papers, not IETF RFCs, standards or
 > informational. Interestingly enough, one of these, Boomerang
 > shares a first author with this document. I think mentioning
 > it on a par with RSVP in a WG document is a blantant ploy to
 > try to create some kind of standards visibility for someone's
 > research project. And a rather back-handed one. Who is shipping
 > Boomerang? What IETF WG owns it?

Randy, we found your words unfair.

Our intention with the resource reservation benchmarking terminology &
methodology drafts was to create a general framework, which can be used
for both existing (standard) and future reservation protocols. We hope
this is ok so far.

Re: several comments on draft-feher-bmwg-benchres-term

>> It seems odd to me that there is a concern with "different
>> resource reservation protocols" that includes some stuff
>> that is in research papers, not IETF RFCs, standards or
>> informational. Interestingly enough, one of these, Boomerang
>> shares a first author with this document. I think mentioning
>> it on a par with RSVP in a WG document is a blantant ploy to
>> try to create some kind of standards visibility for someone's
>> research project. And a rather back-handed one. Who is shipping
>> Boomerang? What IETF WG owns it?
> Randy, we found your words unfair.

not my words, but the words from over in *serve land.

there seems to be a widespread feeling that this effort needs a
tighter focus.  we can keep arguing about it or we can tighten the
focus.

randy

Re: several comments on draft-feher-bmwg-benchres-term

At 11:13 AM 12/13/2002 -0800, Randy wrote:
 > not my words, but the words from over in *serve land.

Sorry, perhaps it's because of our poor English, but we just don't
understand this sentence.

 > there seems to be a widespread feeling that this effort needs a
 > tighter focus.  we can keep arguing about it or we can tighten the
 > focus.

Again, it's not clear for us, what do you mean by tightening the focus.

Regards,
Gabor, Krisztian

Questions on the draft - "Benchmarking Terminology for Protection Performance"

Re: Questions on the draft - "Benchmarking Terminology for Protection Performance"

Arun,

Thank you for your comments.

> o Why there are no units defined for "Recovery time"? [Section 3.4.9]

I am sorry, it is a bug.
Its measurement unit is Seconds.
We will fix the bug in the next version of draft.

> o The concept of "Induced latency" is pretty intuitive but its definition
> seems somewhat unclear (or is this just me?). [Section 3.4.7]

You are quite right in saying so.
If a sequence of latency is measured as shown below,
the induced latency is (0.071 - 0.054) or (0.068 - 0.054)
in the present definition.
I intend to define "Induced latency" as the maximum one among those.
We will change the definition in order to fit to our intention.

 seq.  latency
   1    0.023
   2    0.023
   3    0.023
   6    0.071
   7    0.068
  10    0.054
  11    0.054
  12    0.054

Thanks,

Takumi