Subject: [multimob] multicast benchmarking

From: Hares Susan <[email-masked]>
Date: Thu, 25 Mar 2010 09:42:14 -0800

multi-mobers: 
 
A follow-up on my comments on implementation things to check in the draft
(Appendix C of the document). 
 
RFC 3918 provides a methodology for benchmarking.  Section 6.1/6.2 provides
join/leave tests.  Section 8.1 has tests under burdened load. 
 
Vendors like IXIA or Spirent - have test topologies for MLDv2/IGMPv3  which
provide these type of test - both in the inter-operable suites and
performance suites. Interpreting these scenarios for a mobile mode scenario
may help in checking out timing issues in the proxy-aggregation. I am simply
suggest things which are useful in testing out functionality and
interoperability of similar functional in this protocol.
 
These types of implementation testing usually occur after routing drafts
become working group drafts (through last call), and before finalizing on
the protocol (RFC basis) 
 
Lacking this type of experience or inter-operability testing, timing bugs
have known to lurk in the code shadows and emerge to cause problems in the
networks.  
 
Best wishes,
 
Sue Hares

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 25 Mar 2010 11:01:30 -0700

Hi Sue,

thanks for the pointer. This is useful for our implementation activities 
on MLD/IGMP proxy.

I don't think it is an issue with draft 
draft-ietf-multimob-pmipv6-base-solution, as this does not require any 
new implementations. Entities in the multicast-enabled PMIPv6 domain 
will behave as they do outside this deployment scenario.

So it is basically the choice of the deployer, which implementation of 
which vendor is chosen.

Best wishes,

Thomas

On 25.03.2010 10:42, Hares Susan wrote:
> multi-mobers:
> A follow-up on my comments on implementation things to check in the
> draft (Appendix C of the document).
> RFC 3918 provides a methodology for benchmarking. Section 6.1/6.2
> provides join/leave tests. Section 8.1 has tests under burdened load.
> Vendors like IXIA or Spirent - have test topologies for MLDv2/IGMPv3
> which provide these type of test - both in the inter-operable suites and
> performance suites. Interpreting these scenarios for a mobile mode
> scenario may help in checking out timing issues in the
> proxy-aggregation. I am simply suggest things which are useful in
> testing out functionality and interoperability of similar functional in
> this protocol.
> become working group drafts (through last call), and before finalizing
> on the protocol (RFC basis)
> Lacking this type of experience or inter-operability testing, timing
> bugs have known to lurk in the code shadows and emerge to cause problems
> in the networks.
> Best wishes,
> Sue Hares
>
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Hares Susan <[email-masked]>
Date: Thu, 25 Mar 2010 10:11:02 -0800

Thomas:

You are correct. I am not suggesting new features. 

You are correct - I am suggesting that early testing methodology for
inter-operable implementations (IETF focus) that will lessen problems in the
deployer of these multiple vendor solutions. In the routing area, protocols
have often required results to be returned back in order to pass on drafts
to the next stage. 

Of course, this working group controls its own pace. 

Best wishes, 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas C. Schmidt
Sent: Thursday, March 25, 2010 10:02 AM
To: [email-masked]
Subject: Re: [multimob] multicast benchmarking

Hi Sue,

thanks for the pointer. This is useful for our implementation activities on
MLD/IGMP proxy.

I don't think it is an issue with draft
draft-ietf-multimob-pmipv6-base-solution, as this does not require any new
implementations. Entities in the multicast-enabled PMIPv6 domain will behave
as they do outside this deployment scenario.

So it is basically the choice of the deployer, which implementation of which
vendor is chosen.

Best wishes,

Thomas

On 25.03.2010 10:42, Hares Susan wrote:
> which provide these type of test - both in the inter-operable suites 
> and performance suites. Interpreting these scenarios for a mobile mode 
> testing out functionality and interoperability of similar functional 
> in this protocol.
> These types of implementation testing usually occur after routing 
> drafts become working group drafts (through last call), and before 
> finalizing on the protocol (RFC basis) Lacking this type of experience 
> or inter-operability testing, timing bugs have known to lurk in the 
> code shadows and emerge to cause problems in the networks.
> Best wishes,
> Sue Hares
>
>
>

--