headers
Silvija Andrijic Dry (sdry | 1 Mar 2007 12:36
Picon
Favicon

RE: comments on draft-sdry-bmwg-mvpnscale-00


Hi Thomas and all,

Thomas, thank you for thorough review of the "00" version of this draft
and valuable feedback !
Btw, we just posted "01" version that addresses some of your feedback:
http://www.ietf.org/internet-drafts/draft-sdry-bmwg-mvpnscale-01.txt

Let me start this email by addressing couple of key points from the
summary of your email, and other details I will put inline (labeled with
[SD] and [SD-end]) In this email I'll refer to draft-l3vpn-2547bis-mcast
as [l3vpn-mcast], draft-rosen-vpn-mcast-08  as [rosen-8] and
draft-sdry-bmwg-mvpnscale as [mvpn-bm] (or this draft).
Also to avoid confusion I will use term "MVPN architectures" to refer to
various different sets of technologies/protocols that can be used to
implement MVPN service as described in [l3vpn-mcast] and term "MVPN
implementations" to refer to practical implementations of any given
specific "MVPN architecture".
I will refer to portion of [l3vpn-mcast] that addresses architecture
from [rosen-8] as "rosen-8 architecture".

1) Changing scope of the [mvpn-bm] to be agnostic of "architecture"
used:
------------------------------------------------------------------------
---
- We have considered your suggestion of making [mvpn-bm] agnostic of
MVPN "architecture" used, specifically agnostic of PE-PE C-Multicast
routing transmission protocol and core transport/signaling mechanism
used.
- We decided NOT to change the scope of [mvpn-bm], i.e. scope remains to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Silvija Andrijic Dry (sdry | 1 Mar 2007 12:51
Picon
Favicon

RE: comments on draft-sdry-bmwg-mvpnscale-00


Hi Thomas and all,

Thomas, thank you for thorough review of the "00" version of this draft
and valuable feedback !
Btw, we just posted "01" version that addresses some of your feedback:
http://www.ietf.org/internet-drafts/draft-sdry-bmwg-mvpnscale-01.txt

Let me start this email by addressing couple of key points from the
summary of your email, and other details I will put inline (labeled with
[SD] and [SD-end]) In this email I'll refer to draft-l3vpn-2547bis-mcast
as [l3vpn-mcast], draft-rosen-vpn-mcast-08  as [rosen-8] and
draft-sdry-bmwg-mvpnscale as [mvpn-bm] (or this draft).
Also to avoid confusion I will use term "MVPN architectures" to refer to
various different sets of technologies/protocols that can be used to
implement MVPN service as described in [l3vpn-mcast] and term "MVPN
implementations" to refer to practical implementations of any given
specific "MVPN architecture".
I will refer to portion of [l3vpn-mcast] that addresses architecture
from [rosen-8] as "rosen-8 architecture".

1) Changing scope of the [mvpn-bm] to be agnostic of "architecture"
used:
------------------------------------------------------------------------
---
- We have considered your suggestion of making [mvpn-bm] agnostic of
MVPN "architecture" used, specifically agnostic of PE-PE C-Multicast
routing transmission protocol and core transport/signaling mechanism
used.
- We decided NOT to change the scope of [mvpn-bm], i.e. scope remains to
(Continue reading)

Permalink | Reply | 5 comments |
headers
Silvija Andrijic Dry (sdry | 1 Mar 2007 14:35
Picon
Favicon

FW: I-D ACTION:draft-sdry-bmwg-mvpnscale-01.txt

Hi BMWG members,

We just wanted to let you know that new version of MVPN Scalability
Benchmarking draft is available and we would like to hear your feedback
on it.

Thanks,
Authors

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org] 
Sent: Wednesday, February 28, 2007 6:50 PM
To: i-d-announce <at> ietf.org
Subject: I-D ACTION:draft-sdry-bmwg-mvpnscale-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Multicast VPN Scalability Benchmarking
	Author(s)	: S. Dry, et al.
	Filename	: draft-sdry-bmwg-mvpnscale-01.txt
	Pages		: 58
	Date		: 2007-2-28
	
Multicast VPN (MVPN) is a service deployed by VPN service providers 
   to enable their customers to use IP multicast applications over VPNs.

   With the increased popularity the scalability of deploying such a 
   service is becoming of a great interest. This document defines 
   standard metric and test methodology for characterizing and comparing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-meth-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Benchmarking Methodology Working Group of the IETF.

	Title		: Benchmarking Methodology for IGP Data Plane Route Convergence
	Author(s)	: S. Poretsky, B. Imhoff
	Filename	: draft-ietf-bmwg-igp-dataplane-conv-meth-12.txt
	Pages		: 15
	Date		: 2007-3-1
	
This document describes the methodology for benchmarking Interior 
   Gateway Protocol (IGP) Route Convergence.   The methodology is to 
   be used for benchmarking IGP convergence time through externally 
   observable (black box) data plane measurements.  The methodology 
   can be applied to any link-state IGP, such as ISIS and OSPF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth-12.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-bmwg-igp-dataplane-conv-meth-12.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-app-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Benchmarking Methodology Working Group of the IETF.

	Title		: Considerations for Benchmarking IGP Data Plane Route Convergence
	Author(s)	: S. Poretsky
	Filename	: draft-ietf-bmwg-igp-dataplane-conv-app-12.txt
	Pages		: 6
	Date		: 2007-3-1
	
This document discusses considerations for benchmarking Interior 
   Gateway Protocol (IGP) Route Convergence for any link-state IGP, such 
   as Intermediate System-Intermediate System (ISIS) and Open-Shorted 
   Path first (OSPF).   A companion methodology document is to 
   be used for benchmarking IGP convergence time through externally 
   observable (black box) data plane measurements.  A companion 
   terminology document is to be referenced to support the benchmarking.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-12.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-term-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Benchmarking Methodology Working Group of the IETF.

	Title		: Terminology for Benchmarking IGP Data Plane Route Convergence
	Author(s)	: B. Imhoff, S. Poretsky
	Filename	: draft-ietf-bmwg-igp-dataplane-conv-term-12.txt
	Pages		: 16
	Date		: 2007-3-1
	
This document describes the terminology for benchmarking Interior 
   Gateway Protocol (IGP) Route Convergence.   The terminology is to 
   be used for benchmarking IGP convergence time through externally 
   observable (black box) data plane measurements.  The terminology 
   can be applied to any link-state IGP, such as ISIS and OSPF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-12.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-bmwg-igp-dataplane-conv-term-12.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-bmwg-protection-meth-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Benchmarking Methodology Working Group of the IETF.

	Title		: Methodology for benchmarking MPLS Protection mechanisms
	Author(s)	: R. Papneja, et al.
	Filename	: draft-ietf-bmwg-protection-meth-01.txt
	Pages		: 32
	Date		: 2007-3-2
	
This draft describes the methodology for benchmarking MPLS Protection 
     mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. 
     The  benchmarking  and  terminology  [TERM-ID]  are  to  be  used  for 
     benchmarking  MPLS  based  protection  mechanisms  [MPLS-FRR-EXT].  This 
     document provides test methodologies and test-bed setup for measuring 
     failover times while considering all dependencies that might impact 
     faster recovery of real time services riding on MPLS based primary 
     tunnel.  The terms used in the procedures included in this document are 
     defined in [TERM-ID].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-protection-meth-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chip Popoviciu (cpopovic | 5 Mar 2007 07:51
Picon
Favicon

WGLC on IPv6 Benchmarking - discussion review

Dear BMWG members,
 
I would like to recap last week's discussion on the IPv6 Methodology draft Last Call:
 
1) Based on the comment from David Newman and in observance of RFC1242, we will change "maximum throughput" to "throughput" in Appendix A.1 and A.2.
 
2) Based on the David Newman's suggestion, we will round down the theoretical rates listed in Appendix A.1 and will include a note regarding this round down as well as a reference to the tolerance due to clock slip.
 
3) Minimum Frame size for SONET. The proposal on the table is 48 bytes which leaves room just for a basic IPv6 header, no IP payload. I can see this as a useful test if the perspective is security threats oriented however, on a practical network such packets would not be present as pointed out by Curtis. I also want to point out that in RFC2544, the minimum IPv4 packet listed was realistic (20 bytes main header plus 8 bytes UDP header). In the case of Ethernet that was still smaller than the payload for the minim Ethernet frame size. In the case of SONET, shouldn't we take the same approach? IPv6 main header 40 bytes + 8 bytes UDP header (ECHO) which will give us 56 bytes minimum SONET frame size.
 
4) Maximum frame size for SONET. David Newman thinks it would be difficult to define the max frame size for SONET due to products supporting different values. In the Appendix we stopped at 4096. Should we make a note that "larger values might be supported by the various products. The maximum supported frame size should be used in benchmarking in addition to the recommended frame sizes."?
 
5) Maximum frame size for Ethernet. Dan Romascanu mentioned the increases in the Ethernet max frame size to 1522 in order to accommodate the IEEE 802.1Q VLAN header, and recently to 2000, as per IEEE 802.3as. The Appendix lists frame sizes up to 9216 bytes. Is the recommendation to include 2000 explicitly in order to have the data point for the size recommended by 802.3as?
 
We wanted to take the opportunity to provide through this draft some updates to RFC2544 such as changes in frame sizes and new, relevant media types. This is a good opportunity to do such updates so please send further comments on the points above or any other items related to the draft before the Last Call closes on March 20 (http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipv6-meth-01.txt).
 
Thank you to all those who sent comments so far.
 
Best Regards,
Chip
_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg
Permalink | Reply | 1 comment |
headers
McQuaid, Jim | 5 Mar 2007 14:42
Favicon

RE: WGLC on IPv6 Benchmarking - discussion review

A nice sumary of all the frame size issues, among other things.

 

I would suggest that the time has come to consider a reference document (not an appendix to another RFC) from BMWG that addressed the "frame sizes to test" issue itself.  This info RFC could repeat the accepted wisdom, contain new tables for new media or new variants and could also include guidelines for testing, such as those you suggest.

 

In other words, obsolete Appendix B of 2544 with a new document.

 

?

 

Jim McQuaid

 

NetQoS

 

From: Chip Popoviciu (cpopovic) [mailto:cpopovic <at> cisco.com]
Sent: Monday, March 05, 2007 1:51 AM
To: bmwg <at> ietf.org
Subject: [bmwg] WGLC on IPv6 Benchmarking - discussion review

 

Dear BMWG members,

 

I would like to recap last week's discussion on the IPv6 Methodology draft Last Call:

 

1) Based on the comment from David Newman and in observance of RFC1242, we will change "maximum throughput" to "throughput" in Appendix A.1 and A.2.

 

2) Based on the David Newman's suggestion, we will round down the theoretical rates listed in Appendix A.1 and will include a note regarding this round down as well as a reference to the tolerance due to clock slip.

 

3) Minimum Frame size for SONET. The proposal on the table is 48 bytes which leaves room just for a basic IPv6 header, no IP payload. I can see this as a useful test if the perspective is security threats oriented however, on a practical network such packets would not be present as pointed out by Curtis. I also want to point out that in RFC2544, the minimum IPv4 packet listed was realistic (20 bytes main header plus 8 bytes UDP header). In the case of Ethernet that was still smaller than the payload for the minim Ethernet frame size. In the case of SONET, shouldn't we take the same approach? IPv6 main header 40 bytes + 8 bytes UDP header (ECHO) which will give us 56 bytes minimum SONET frame size.

 

4) Maximum frame size for SONET. David Newman thinks it would be difficult to define the max frame size for SONET due to products supporting different values. In the Appendix we stopped at 4096. Should we make a note that "larger values might be supported by the various products. The maximum supported frame size should be used in benchmarking in addition to the recommended frame sizes."?

 

5) Maximum frame size for Ethernet. Dan Romascanu mentioned the increases in the Ethernet max frame size to 1522 in order to accommodate the IEEE 802.1Q VLAN header, and recently to 2000, as per IEEE 802.3as. The Appendix lists frame sizes up to 9216 bytes. Is the recommendation to include 2000 explicitly in order to have the data point for the size recommended by 802.3as?

 

We wanted to take the opportunity to provide through this draft some updates to RFC2544 such as changes in frame sizes and new, relevant media types. This is a good opportunity to do such updates so please send further comments on the points above or any other items related to the draft before the Last Call closes on March 20 (http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipv6-meth-01.txt).

 

Thank you to all those who sent comments so far.

 

Best Regards,

Chip

_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg
Permalink | Reply | 0 comments |
headers
Esa Salahuddin (esalahud | 5 Mar 2007 20:26
Picon
Favicon

Request for Opinions on Benchmarking the BFD protocol.

Hi folks,
 
Jay and I would like to hear your opinion on the idea of benchmarking the BFD protocol in the BMWG.
 
The BFD protocol is becoming an increasingly popular alternative to a variety of existing methods to detect forwarding failures on links between network elements. It is being proposed as the forwarding failure detection mechanism for a host of routing protocols, virtual links and p2mp topologies. It is a very useful in the situations where underlying physical media doesn't lend itself well to fast detection of failures. You can find extensive information on the BFD protocol itself at the BFD WG weblink http://tools.ietf.org/wg/bfd/
 
Please see http://www.ietf.org/internet-drafts/draft-salahuddin-bmwg-bfd-motivation-00.txt for the deails on the topic and our position and please let us know what do you think.
 
thx, esa
_______________________________________________
bmwg mailing list
bmwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg
Permalink | Reply | 9 comments |

Gmane