RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing Draft(06)

["Tom Alexander" <[e-mail]>]

And to complete the process of discussing VeriWave product development on
the BMWG reflector, I'm sure that as soon as we figure out a way of
unambiguously linking MAC and IP addresses such that they remain linked
across application invocations, we'll be back to using
draft-ietf-bmwg-hash-stuffing-xx.txt.

Cheers,

- Tom

P.S. In defence of VeriWave management (well, maybe), I doubt that any of
them know that draft-ietf-bmwg-hash-stuffing-06.txt even exists. ;-) I got
the random addresses put on hold after a particularly nasty debacle at a key
customer site. When we figure out the WLAN-specific solution to this issue,
rest assured that it will be published in
draft-perser-wlan-switch-benchmarking-01.txt.


-----Original Message-----
From: Jerry Perser [mailto:[e-mail]] 
Sent: Tuesday, November 14, 2006 10:15 AM
To: [e-mail]
Subject: RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
Draft(06)

Scott,

I'm surprised you forgot my name (/e weeps inside).  I was the one at the
microphone.  I was trying to make my time at the microphone short so we
wouldn't run over.  So let me expand more here.

In February 2006, Veriwave implemented random MAC addresses per
draft-ietf-bmwg-hash-stuffing-05.txt.  We released a product that ran BMWG
test suite.  Sometime after that, I posted my implementation notes and Mr.
Newman was kind enough to include them in draft-06.

>From February to this day, random MAC addresses have not been a problem on
my test bed.  My test bed consists of two different Access Points connected
together by a L2 switch.  I don't have an AP controller to test with.  On
the other hand, Veriwave Customer Support Department were finding problem
with certain AP controllers.  Tom Alexander did a good description of the
problem so I would go into it.

During Mr. Newman's public test
(http://www.networkworld.com/2006/110606-wifi-test-index.html), we used
pseudorandom MAC addresses with a fixed random seed (David, the seed I used
in on line 22 in GUI.py). The 500 MAC addresses used appeared completely
random to the SUT/DUT and to anyone looking at the packet dumps.  This is
still complies with draft-ietf-bmwg-hash-stuffing-06.txt, and helps the
repeatability of the tests.  But during the test, Veriwave's management
decided to remove the random MAC address function from the released product.
Veriwave's WaveApps 2.2 contains random MAC addresses, version 2.3 does not.

I want to restate this: I, as an individual, believe
draft-ietf-bmwg-hash-stuffing-06.txt is finished with last call and should
be forwarded to the AD.  My current benefactor/employer, Veriwave, has
temporary decided to disable my implementation of
draft-ietf-bmwg-hash-stuffing-06.txt.

At the Microphone, I poked Veriwave's CTO and asked him if he could look
into this.  This problem looks like it's related to wireless LAN switches
and wireless LAN meshes (the last presentation at the BMWG meeting).

Jerry Perser

> -----Original Message-----
> From: Poretsky, Scott [mailto:[e-mail]]
> Sent: Monday, November 13, 2006 11:29 AM
> To: David Newman
> Cc: [e-mail]
> Subject: RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
> Draft(06)
> 
> 
> Hi David,
> 
> At IETF 67 this week it was mentioned at the microphone of the BMWG
> meeting that one of the test equipment vendors would not be implementing
> to this draft.  I believe it was Veriwave.  Could you please comment
> more on that?
> 
> Scott
> 
> -----Original Message-----
> From: David Newman [mailto:[e-mail]]
> Sent: Wednesday, November 08, 2006 10:36 AM
> Cc: [e-mail]
> Subject: Re: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
> Draft(06)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Romascanu, Dan (Dan) wrote:
> > In general I believe that the draft is ready for submission to the
> IESG.
> > I have a few non-critical comments that I believe should be taken into
> > consideration in a future revision of the document, but prior to
> > approval by the IESG.
> >
> > 1. Terminology and Acronyms - the document could benefit from a short
> > terminology section. Also, there is broad usage of acronyms, without
> > acronym explanation in a separate section or expansion at first
> > occurrence
> > 2. Section 2 refers to Ethernet MAC addresses. Actually BMWG documents
> > that fall under the scope of this document could cover a broader range
> > of IEEE 802 technologies out of which Ethernet is just one, for
> example
> > IEEE 802.11 wireless LAN. I suggest that the scope of this section and
> > the text where relevant is changed so that it covers IEEE 802 rather
> > than just Ethernet.
> 
> We've had other suggestions for this ID to cover more than 802.3:
> 
> - --In response to input from Jerry Perser, we modified section 4.2 to
> include an example covering 802.11 roaming.
> 
> Given that 802.3 and 802.11 share a common MAC address format (48 bits,
> OUI in the same place), no 802.11-specific modification is needed for
> the address pattern recommended here
> 
> - --In response to input from Scott Poretsky, we added section 4.3 on
> MPLS
> label contents
> 
> Thanks very much for the positive feedback.
> 
> dn
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> 
> iD8DBQFFUflMyPxGVjntI4IRApXBAKD4W1vrhyb4ByZeKy1OHkb2pl/zRQCghwhP
> M+zHhZm5To/DfYMnNJzwwzY=
> =KHra
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.14.3/531 - Release Date: 11/12/2006



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


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