[ipv6-wg] RIPE 554 Errata Page
Eric Vyncke (evyncke) evyncke at cisco.com
Wed May 29 11:16:57 CEST 2013
Ivan and Tim, As long as the 'MLD snooping' is not mandated for a layer-3 switch (and I do agree it is an oxymoron for people on this list) then I am fine. The verbiage could be something in the lines of Tim and Ivan, requiring/make optional MLD snooping ONLY for any layer-2 ports of the layer-3 switch. > -----Original Message----- > From: Ivan Pepelnjak [mailto:ipepelnjak at gmail.com] > Sent: mercredi 29 mai 2013 11:00 > To: Tim Chown > Cc: Eric Vyncke (evyncke); MarcoH; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE 554 Errata Page > > Have to agree. MLD Snooping should be OPTIONAL (or not required) for L3 > device __that has NO L2 forwarding functionality__. > > Not sure how many devices would match that description, and I'm almost > positive this is not what Eric is looking for, but this is the only safe way > to remove MLD snooping requirement. > > Explaining why you don't need MLD snooping on a L3-only port on a L2/L3 > switch is customer education ;) Start by thanking the marketing "wizards" > that turned bridges and routers into switches. > > Jan & Sander - can we get something along the lines of the first paragraph > into Errata doc? > > Ivan > > On 29.05.2013 10:33 , Tim Chown wrote: > > On 29 May 2013, at 08:43, Eric Vyncke (evyncke) <evyncke at cisco.com> wrote: > > [...] > >> As a vendor, we have an issue with 'MLD snooping (RFC 4541)' for a layer- > 3 device/switch which of course if you are a layer-3 port, you implement MLD > (RFC 3810) as stated in RIPE 554 but you do not implement the snooping which > is applicable to a layer-2 port. It can appear as splitting hair but you > cannot imagine the number of hours/calls I have to spend on this hair > splitting... So, please remove the MLD snooping requirement from a layer-3 > device. > > You say "layer-3 device/switch", I think you really mean "layer 3-only > device". If the device offers any layer 2 functionality, MLD snooping > becomes important. We had this issue with a specific brand of printer that > fell over in the face of seeing a few HD IPv6 IP-TV channels only last > month.
[ ipv6-wg Archives ]