Al Morton | 5 Dec 2011 05:46
Picon
Favicon

Draft Minutes from IETF-82

BMWG,

Draft minutes are available for comment or questions:
http://www.ietf.org/proceedings/82/minutes/bmwg.html

regards,
Al
bmwg chair
Al Morton | 5 Dec 2011 15:48
Picon
Favicon

WGLC: draft-ietf-bmwg-protection-meth-09

BMWG,

This message begins a Last call on the MPLS Protection methods:

http://tools.ietf.org/html/draft-ietf-bmwg-protection-meth-09

The Last Call will end on January 1, 2012.

We've been discussing this topic in BMWG almost as long as I have
been chairman.  The previous WGLCs were on terms-06 and meth-05
in July 2009, and term-09 and meth-07 in January, 2010.
The authors believe that the current drafts
address all previous comments.  The terminology has been approved
and published as http://tools.ietf.org/html/rfc6414

Please weigh-in on whether or not this Internet-Draft
should be given to the Area Directors and IESG for consideration and
publication as an Informational RFCs.  Send your comments
to this list and/or acmorton <at> att.com.

Al
bmwg chair
Jan Novak (janovak | 6 Dec 2011 22:12
Picon
Favicon

FW: New Version Notification for draft-ietf-bmwg-ipflow-meth-05.txt

Al,

The .05 contains the suggested modification of
text in sections 4.1, 4.2, 4.3, 4.3.2 with just
minor terminology modifications.

Tx, Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: 06 December 2011 21:09
To: Jan Novak (janovak)
Cc: Jan Novak (janovak)
Subject: New Version Notification for draft-ietf-bmwg-ipflow-meth-05.txt

A new version of I-D, draft-ietf-bmwg-ipflow-meth-05.txt has been successfully submitted by Jan Novak
and posted to the IETF repository.

Filename:	 draft-ietf-bmwg-ipflow-meth
Revision:	 05
Title:		 IP Flow Information Accounting and Export Benchmarking Methodology
Creation date:	 2011-12-06
WG ID:		 bmwg
Number of pages: 31

Abstract:
(Continue reading)

Jan Novak (janovak | 13 Dec 2011 16:22
Picon
Favicon

Re: draft-varlashkin-router-conv-bench-00

Hi,

>This are two main categories who will execute tests. So it looks like
it's >reasonable to assume that testers will have means to execute the
tests >according to relevant scope. Would you agree?

Yes, it was just the wording in the text with just the physical
devices, otherwise yes, it gives the freedom to do what everybody
needs to do.

> What do you (and others in BMWG) think about described approach, would
that address your concerns?

5.4 Explicitly requires a BGP exchange - the non-DUT has to initiate 
a BGP exchange and that may depend on the non-DUT - maybe easiest this
could be circumvented by requiring the other BGP peer is from the same
vendor/same implementation or tested always with the same one
when comparing two DUT implementation ?? Although maybe it is covered
already by the requirement the update is immediate - so as long as this
is considered it is ok.

Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

-----Original Message-----
From: Ilya Varlashkin [mailto:ilya <at> nobulus.com] 
Sent: 31 October 2011 23:10
(Continue reading)

iLya | 13 Dec 2011 17:04

Re: draft-varlashkin-router-conv-bench-00

Hi Jan,

--------------------------------------------------
> Hi,
>
>>This are two main categories who will execute tests. So it looks like
> it's >reasonable to assume that testers will have means to execute the
> tests >according to relevant scope. Would you agree?
>
> Yes, it was just the wording in the text with just the physical
> devices, otherwise yes, it gives the freedom to do what everybody
> needs to do.
>

If you or someone else have an alternative wording, I'll be happy to 
consider it. Original text was not meant to confuse anyone but it is 
probably result of me not being native english speaker.

>> What do you (and others in BMWG) think about described approach, would
> that address your concerns?
>
> 5.4 Explicitly requires a BGP exchange - the non-DUT has to initiate
> a BGP exchange and that may depend on the non-DUT - maybe easiest this
> could be circumvented by requiring the other BGP peer is from the same
> vendor/same implementation or tested always with the same one
> when comparing two DUT implementation ?? Although maybe it is covered
> already by the requirement the update is immediate - so as long as this
> is considered it is ok.
>

(Continue reading)


Gmane