Subject: [bmwg] Multiple source to multiple destination IP multicast

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 12 Feb 2003 14:20:40 -0800

Kevin,

RFC2432, Section 1. Introduction, last Paragraph:

   Moreover, this document focuses on one source to many destinations
   profiling.  Elements of this document may require extension when
   considering multiple source to multiple destination IP multicast
   communication.

I would like to open a discussion about multiple source to multiple
destination testing and the possibility of extension to cover this
particular profiling.

The multicast benchmarking I have seen for publication, and for private
verification has all required multiple sources.  The testing has required
some percentage of the traffic to be mulcts spread across a group of ports.

I am very interested in hearing from other BMWGers, any experience or
requirements that use only one source to many destinations IP multicast.  So
far, no one has come forward with a real test case for this.

Jerry.

___________________________________________________________ 
Jerry Perser                         Spirent Communications
Director of Test Methodology         SmartBits Division 
Phone: 818.676.2320                  26750 Agoura Road 
Lab:   818.676.2337                  Calabasas, CA, 91302 
Cell:  818.292.6457                  Corp:  818.676.2300

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

---

From: Kevin Dubray <[email-masked]>
Date: Wed, 12 Feb 2003 18:37:42 -0500

Jerry,

The WG has discussed the N x M possibilities during the formation of
RFC 2432.  It was agreed to bound the work to the 1 source port to N
destination port, unidirectional traffic paradigm.  While we noted
that this may not be the most "interesting" paradigm, we agreed the
paradigm represented a good & useful first step.  We also agreed
that more sophisticated testing should be addressed in subsequent RFCs.

In light of the above, any discussion regarding multiple source to
multiple destination multicast would be for a supplemental I-D, not
the one currently being discussed.

So, let's focus on getting agreement in these simple cases first, before
we tackle the new and improved.

-Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Wed, 12 Feb 2003 18:37:42 -0500

Jerry,

-Kevin

---

From: David Newman <[email-masked]>
Date: Wed, 12 Feb 2003 18:19:40 -0800 (PST)

While I understand the urgency in getting the current ID situation
resolved, I also wouldn't ever contemplate offering *unicast* traffic to
just one port of a multiport switch or router (if device
forwarding/latency/jitter was what I was looking to measure). 

Why should multicast be any different?

I'm fine with doing the additional work in a separate document. My concern 
is that we are severely limiting the utility of the current ID by going 
with just one transmitter. 

dn

 On Wed, 12 Feb

---

From: David Newman <[email-masked]>
Date: Wed, 12 Feb 2003 18:19:40 -0800 (PST)

dn

 On Wed, 12 Feb

---

From: Kevin Dubray <[email-masked]>
Date: Thu, 13 Feb 2003 09:17:11 -0500

Folks, the scope of the current multicast methodology I-D was bound by
RFC 2432. Hence, we're not limiting the I-D's utility as it's utility is
in providing methodology as prescribed by RFC 2432.

Let's stay the course.  Put your energies in addressing more complex
test scenarios and methodologies in companion I-Ds.

Thanks,
Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Thu, 13 Feb 2003 09:17:11 -0500

Thanks,
Kevin