Subject: [rbridge] Document cut off dates for the July IETF meeting

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 24 May 2006 15:31:50 -0400

Hi,

You should note the following dates:

June 12, Monday - Working Group Chair approval for initial document
(Version -00) submissions appreciated by 09:00 ET (13:00 UTC/GMT)

June 19, Monday - Internet Draft Cut-off for initial document (-00)
submission by 09:00 ET (13:00 UTC/GMT)

June 26, Monday - Internet Draft final submission cut-off by 09:00 ET
(13:00 UTC/GMT)

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Wed, 24 May 2006 15:31:50 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Document cut off dates for the July IETF meeting
Status: RO
Content-Length: 388

Hi,

You should note the following dates:

June 12, Monday - Working Group Chair approval for initial document
(Version -00) submissions appreciated by 09:00 ET (13:00 UTC/GMT)

June 19, Monday - Internet Draft Cut-off for initial document (-00)
submission by 09:00 ET (13:00 UTC/GMT)

June 26, Monday - Internet Draft final submission cut-off by 09:00 ET
(13:00 UTC/GMT)

Thanks,
Donald

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>
Date: Mon, 15 May 2006 08:45:06 -0400
Cc: [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 4173

Radia,

	Please see below.

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Sunday, May 14, 2006 12:24 PM
--> To: Russ White
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Encapsulation of RBridge IS-IS 
--> routing messages
--> 
--> We need to make sure that the per-VLAN IS-IS instance carrying endnode 
--> information is forwardable just like any other packet to be flooded 
--> throughout the VLAN (e.g., unknown destination, multicast destination 
--> not derived from IP multicast), but still recognizable by the egress 
--> RBridges attached to that VLAN as an IS-IS message. Including the
special 
--> "default VLAN" that has no tag, that would carry endnode information for

--> links without VLAN tags.
-->

I can't parse this, and I don't think it's me.  :-)

When you say "per-VLAN IS-IS instance carrying endnode information", do
you mean "IS-IS message"?  Is the "endnode information" MAC related for
RBridges, or are these IS-IS messsages that are meant to be transported
transparently, VLAN-wide, by the RBridge campus - between IS-IS routers?

In the last sentence, what does the second "that" ("that would carry...")
refer to?  In other words, what is it that you are saying would carry
endnode information for links without VLAN tags?

--> 
--> We need the core IS-IS instance that carries RBridge-RBridge 
--> reachability information to be easily trappable and processed by 
--> every RBridge. (this is not the same as the default VLAN endnode 
--> instance, which only has to be processed by RBridges that have 
--> attached endnodes on links without VLAN tags).
-->

Same problem here.

If you mean "IS-IS message", then it seems that you are saying that 
the IS-IS messages specific to RBridge protocol would need to be
handled at each RBridge.  This would allow non-RBridge IS-IS message
exchanges to be ignored by RBridges.

However, how does this relate to Russ' question/comment?

As long as RBridge IS-IS instances do not share MAC addresses with
IS-IS routing instances, the distinction between RBridge and Routing
protocols exchanges would happen quite naturally.

If you want to distinguish the messages such that protocol instances
ignore the inappropriate protocol messages independent of addressing,
then you need to use different protocol indentifiers.

Which approach are you advocating?

--> 
--> It might be nice not to have lots of extraneous padding where it's not 
--> necessary. So I'd like the implementers to say what's most convenient 
--> for their implementations.
-->

At what point does either approach result in extraneous padding?

Or am I not understanding your point at all?  If not, could you
try re-phrasing?

Thanks in advance...

--
Eric

--> 
--> Radia
--> 
--> 
--> Russ White wrote:
--> 
--> >-----BEGIN PGP SIGNED MESSAGE-----
--> >Hash: SHA1
--> >
--> >
--> >  
--> >
--> >>>>I was thinking that the IS-IS used by routers would be on one l2
--> >>>>address, and the "local" IS-IS process would be on a 
--> different one.
--> >>>>        
--> >>>>
--> >>    Yep, that is the point I am (not successfully) trying to make.
--> >>    
--> >>
--> >
--> >The cat's out of the bag! Maybe we could get a call for 
--> consensus on
--> >this point? Perhaps we need to go back to Radia's original 
--> email, and
--> >try to have a list of all the options, and what their 
--> pro's and con's are?
--> >
--> >:-)
--> >
--> >Russ
--> >
--> >- --
--> >[email-masked] CCIE <>< Grace Alone
--> >
--> >-----BEGIN PGP SIGNATURE-----
--> >Version: GnuPG v1.4.2.2 (MingW32)
--> >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> >
--> >iD8DBQFEZzxvER27sUhU9OQRAj3TAJ9VLLCOWL8VJAuYHMdboA8CYb7b2ACgnoYg
--> >HMR/8UxLCbmKBpSEtKn7V2s=
--> >=nNjE
--> >-----END PGP SIGNATURE-----
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Sun, 14 May 2006 09:23:38 -0700
From: Radia Perlman <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1939

We need to make sure that the per-VLAN IS-IS instance carrying endnode 
information is forwardable
just like any other packet to be flooded throughout the VLAN (e.g., 
unknown destination, multicast
destination not derived from IP multicast), but still recognizable by 
the egress RBridges attached to
that VLAN as an IS-IS message. Including the special "default VLAN" that 
has no tag, that would
carry endnode information for links without VLAN tags.

We need the core IS-IS instance that carries RBridge-RBridge 
reachability information to be easily
trappable and processed by every RBridge. (this is not the same as the 
default VLAN endnode instance,
which only has to be processed by RBridges that have attached endnodes 
on links without VLAN tags).

It might be nice not to have lots of extraneous padding where it's not 
necessary. So I'd like the
implementers to say what's most convenient for their implementations.

Radia

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>  
>
>>>>I was thinking that the IS-IS used by routers would be on one l2
>>>>address, and the "local" IS-IS process would be on a different one.
>>>>        
>>>>
>>    Yep, that is the point I am (not successfully) trying to make.
>>    
>>
>
>The cat's out of the bag! Maybe we could get a call for consensus on
>this point? Perhaps we need to go back to Radia's original email, and
>try to have a list of all the options, and what their pro's and con's are?
>
>:-)
>
>Russ
>
>- --
>[email-masked] CCIE <>< Grace Alone
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.2.2 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFEZzxvER27sUhU9OQRAj3TAJ9VLLCOWL8VJAuYHMdboA8CYb7b2ACgnoYg
>HMR/8UxLCbmKBpSEtKn7V2s=
>=nNjE
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Date: Sun, 14 May 2006 10:19:27 -0400
From: Russ White <[email-masked]>
To: Dino Farinacci <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 781

>>> I was thinking that the IS-IS used by routers would be on one l2
>>> address, and the "local" IS-IS process would be on a different one.
> 
>     Yep, that is the point I am (not successfully) trying to make.

The cat's out of the bag! Maybe we could get a call for consensus on
this point? Perhaps we need to go back to Radia's original email, and
try to have a list of all the options, and what their pro's and con's are?

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Fri, 12 May 2006 10:45:06 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 213

>> I was thinking that the IS-IS used by routers would be on one l2
>> address, and the "local" IS-IS process would be on a different one.

    Yep, that is the point I am (not successfully) trying to make.

Dino

Date: Fri, 12 May 2006 13:42:24 -0400
From: Russ White <[email-masked]>
To: Dino Farinacci <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1190

>>>>     Since the IS-IS messages are link-local in the core RBridges I agree. But
>>>>     what about the instance that runs at the edges where the core forwards
>>>>     them like they would for any other packet?
>>> Wouldn't this be to the original IS-IS MAC address, and thus treated
>>> like any other layer 2 multicast?
> 
>     I was referring to the IS-IS messages used by RBridges and not the IS-IS
>     used by routers (for L3) attached to the RBridge network.

I was thinking that the IS-IS used by routers would be on one l2
address, and the "local" IS-IS process would be on a different one.

>>> and others...), so I don't see a big deal in doing a single process with
>>> constrained SPF for each vlan.
> 
>     I envision that really is the only way to go if the design expects to
>     scale to 4096 VLANs.

Agreed....

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Fri, 12 May 2006 08:43:40 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 685

>> >     Since the IS-IS messages are link-local in the core RBridges I agree. But
>> >     what about the instance that runs at the edges where the core forwards
>> >     them like they would for any other packet?
>> 
>> Wouldn't this be to the original IS-IS MAC address, and thus treated
>> like any other layer 2 multicast?

    I was referring to the IS-IS messages used by RBridges and not the IS-IS
    used by routers (for L3) attached to the RBridge network.

>> and others...), so I don't see a big deal in doing a single process with
>> constrained SPF for each vlan.

    I envision that really is the only way to go if the design expects to
    scale to 4096 VLANs.

Dino

From: "Gray, Eric" <[email-masked]>
To: Russ White <[email-masked]>, Dino Farinacci <[email-masked]>
Date: Fri, 12 May 2006 11:28:17 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 3242

Russ,

	I don't think we've collectively made a decision as to how we
would distinguish IS-IS messages from RBridge-IS-IS messages (as is
necessary to avoid confusion complexity if - for example - someone
were building an RBridge co-located with an IS-IS router).

	Radia has earlier made several suggestions, one of which was 
to use a distinct MAC mlticast address for RBridges.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Russ White
--> Sent: Friday, May 12, 2006 8:26 AM
--> To: Dino Farinacci
--> Cc: [email-masked]; [email-masked]
--> Subject: Re: [rbridge] Encapsulation of RBridge IS-IS 
--> routing messages
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> >>> Dino...I think what you're proposing is a special 
--> multicast address for 
--> >>> use only by IS-IS for RBridges.
--> > 
--> >     Yes, that is correct.
--> > 
--> >>> We don't need the shim header since we don't need TTL 
--> (IS-IS will not 
--> >>> flood the same pkt twice), or
--> > 
--> >     Since the IS-IS messages are link-local in the core 
--> RBridges I agree. But
--> >     what about the instance that runs at the edges where 
--> the core forwards
--> >     them like they would for any other packet?
--> 
--> Wouldn't this be to the original IS-IS MAC address, and thus treated
--> like any other layer 2 multicast?
--> 
--> >>> Outer header of IS-IS pkt would be:
--> >>> destination=new multicast address just for IS-IS RBridges
--> >>> source=transmitting RBridge
--> >>> Ethertype=I dunno...probably the one assigned for 
--> "encapsulated RBridge pkt"
--> > 
--> >     Can we use the same format as IS-IS uses today. The 
--> only difference is
--> >     the DA is different? That will reduce the changes to 
--> the existing
--> >     implementations.
--> 
--> This is the route I would prefer, as well.
--> 
--> >>> After the outer header, just VLAN tag
--> >>>
--> >>> After that, the IS-IS pkt.
--> > 
--> >     To to be more precise you are proposing IS-IS packets 
--> in .1q? Why? Will
--> >     the core switches do an IS-IS instance per VLAN? As I 
--> mentioned at the
--> >     last IETF, this is a tradeoff between fault isolation 
--> and scalability.
--> > 
--> >     It would be nice for someone to make a final call on this.
--> 
--> I don't see why we would want a process per vlan, unless 
--> we're worried
--> about a process failing (as opposed to a device). IS-IS already does
--> constrained SPF for various reasons (traffic engineering, 
--> fast reroute,
--> and others...), so I don't see a big deal in doing a single 
--> process with
--> constrained SPF for each vlan.
--> 
--> :-)
--> 
--> Russ
--> 
--> - --
--> [email-masked] CCIE <>< Grace Alone
--> 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.4.2.2 (MingW32)
--> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--> 
--> iD8DBQFEZH7AER27sUhU9OQRAl/GAJ4w/AuqNFkTdktPS7ppajJVCCY7CgCcDjon
--> ig0/ImC+JvFBLnLhJoEPd/Q=
--> =ZdT0
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 12 May 2006 08:25:36 -0400
From: Russ White <[email-masked]>
To: Dino Farinacci <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 2055

>>> Dino...I think what you're proposing is a special multicast address for 
>>> use only by IS-IS for RBridges.
> 
>     Yes, that is correct.
> 
>>> We don't need the shim header since we don't need TTL (IS-IS will not 
>>> flood the same pkt twice), or
> 
>     Since the IS-IS messages are link-local in the core RBridges I agree. But
>     what about the instance that runs at the edges where the core forwards
>     them like they would for any other packet?

Wouldn't this be to the original IS-IS MAC address, and thus treated
like any other layer 2 multicast?

>>> Outer header of IS-IS pkt would be:
>>> destination=new multicast address just for IS-IS RBridges
>>> source=transmitting RBridge
>>> Ethertype=I dunno...probably the one assigned for "encapsulated RBridge pkt"
> 
>     Can we use the same format as IS-IS uses today. The only difference is
>     the DA is different? That will reduce the changes to the existing
>     implementations.

This is the route I would prefer, as well.

>>> After the outer header, just VLAN tag
>>>
>>> After that, the IS-IS pkt.
> 
>     To to be more precise you are proposing IS-IS packets in .1q? Why? Will
>     the core switches do an IS-IS instance per VLAN? As I mentioned at the
>     last IETF, this is a tradeoff between fault isolation and scalability.
> 
>     It would be nice for someone to make a final call on this.

I don't see why we would want a process per vlan, unless we're worried
about a process failing (as opposed to a device). IS-IS already does
constrained SPF for various reasons (traffic engineering, fast reroute,
and others...), so I don't see a big deal in doing a single process with
constrained SPF for each vlan.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Thu, 11 May 2006 21:48:54 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 664

>> Actually, maybe we want a different encapsulation for the main IS-IS 
>> instance
>> than the per-VLAN one, since we want the per-VLAN one to be forwarded like
>> any multicast packet to be delivered to links in that VLAN.
>> 
>> So...the per-VLAN one I think should have the same encapsulation as any 
>> data packet
>> to be delivered to VLAN A, i.e.
>> a) outer hdr=destination="all-RBridges", PT="encapsulated RBridge pkt
>> b) shim hdr: ingress RBridge, TTL
>> c) inner hdr: source=original RBridge injecting it, 
>> destination="all-RBridges", VLAN tag=VLAN A

    Sorry I repeated what you said but I sent my reply before getting this
    message.

Dino

Date: Thu, 11 May 2006 21:48:00 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1205

>> Dino...I think what you're proposing is a special multicast address for 
>> use only by IS-IS for RBridges.

    Yes, that is correct.

>> We don't need the shim header since we don't need TTL (IS-IS will not 
>> flood the same pkt twice), or

    Since the IS-IS messages are link-local in the core RBridges I agree. But
    what about the instance that runs at the edges where the core forwards
    them like they would for any other packet?

>> Outer header of IS-IS pkt would be:
>> destination=new multicast address just for IS-IS RBridges
>> source=transmitting RBridge
>> Ethertype=I dunno...probably the one assigned for "encapsulated RBridge pkt"

    Can we use the same format as IS-IS uses today. The only difference is
    the DA is different? That will reduce the changes to the existing
    implementations.

>> After the outer header, just VLAN tag
>> 
>> After that, the IS-IS pkt.

    To to be more precise you are proposing IS-IS packets in .1q? Why? Will
    the core switches do an IS-IS instance per VLAN? As I mentioned at the
    last IETF, this is a tradeoff between fault isolation and scalability.

    It would be nice for someone to make a final call on this.

Dino

Date: Thu, 11 May 2006 19:42:49 -0700
From: Radia Perlman <[email-masked]>
To: Radia Perlman <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1890

Actually, maybe we want a different encapsulation for the main IS-IS 
instance
than the per-VLAN one, since we want the per-VLAN one to be forwarded like
any multicast packet to be delivered to links in that VLAN.

So...the per-VLAN one I think should have the same encapsulation as any 
data packet
to be delivered to VLAN A, i.e.
a) outer hdr=destination="all-RBridges", PT="encapsulated RBridge pkt
b) shim hdr: ingress RBridge, TTL
c) inner hdr: source=original RBridge injecting it, 
destination="all-RBridges", VLAN tag=VLAN A

Then IS-IS pkt.

********
However, the "core IS-IS instance" can be as I proposed in the previuos 
email.

Radia

Radia Perlman wrote:

> Dino...I think what you're proposing is a special multicast address 
> for use only by IS-IS for RBridges.
> We don't need the shim header since we don't need TTL (IS-IS will not 
> flood the same pkt twice), or
> the "ingress RBridge" (since IS-IS does not send on a tree...each LSP 
> is sent to each nbr). We do
> need a VLAN tag though.
>
>
> So, unless anyone objects, the IS-IS pkt will look like this:
>
> Outer header of IS-IS pkt would be:
> destination=new multicast address just for IS-IS RBridges
> source=transmitting RBridge
> Ethertype=I dunno...probably the one assigned for "encapsulated 
> RBridge pkt"
>
>
> After the outer header, just VLAN tag
>
> After that, the IS-IS pkt.
>
> Radia
>
>
> ******
> But we could save space by not bothering with the shim header, an
>
> Dino Farinacci wrote:
>
>>
>>    To do a service to implementors:
>>
>>    c) the destination MAC address causes the packets to be sent to the
>>       control-plane processor.
>>
>>    This way a hardware forwarder doesn't have to do the extra checks you
>>    propose. Hardware forwards based on destination MAC address, so the
>>    IS-IS destination multicast MAC address means "pass it up".
>>
>> Dino
>>
>>
>>     
>>
>

Date: Thu, 11 May 2006 19:18:24 -0700
From: Radia Perlman <[email-masked]>
To: Dino Farinacci <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1155

Dino...I think what you're proposing is a special multicast address for 
use only by IS-IS for RBridges.
We don't need the shim header since we don't need TTL (IS-IS will not 
flood the same pkt twice), or
the "ingress RBridge" (since IS-IS does not send on a tree...each LSP is 
sent to each nbr). We do
need a VLAN tag though.

So, unless anyone objects, the IS-IS pkt will look like this:

Outer header of IS-IS pkt would be:
destination=new multicast address just for IS-IS RBridges
source=transmitting RBridge
Ethertype=I dunno...probably the one assigned for "encapsulated RBridge pkt"

After the outer header, just VLAN tag

After that, the IS-IS pkt.

Radia

******
But we could save space by not bothering with the shim header, an

Dino Farinacci wrote:

>
>    To do a service to implementors:
>
>    c) the destination MAC address causes the packets to be sent to the
>       control-plane processor.
>
>    This way a hardware forwarder doesn't have to do the extra checks you
>    propose. Hardware forwards based on destination MAC address, so the
>    IS-IS destination multicast MAC address means "pass it up".
>
>Dino
>
>
>    
>  
>

Date: Thu, 11 May 2006 17:13:33 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 748

>> a) outer Ethernet header: destination="all-RBridges", source=transmitted 
>> RBridge, Ethertype="encapsulated
>> RBridge packet" (note...this would be the same as a data packet for an 
>> unknown destination, or a multicast
>> data packet transmitted by RBridges)
>> b) we can save lots of room if we don't bother with DSAP encoding or the 
>> r header, but we do want the TTL.

    To do a service to implementors:

    c) the destination MAC address causes the packets to be sent to the
       control-plane processor.

    This way a hardware forwarder doesn't have to do the extra checks you
    propose. Hardware forwards based on destination MAC address, so the
    IS-IS destination multicast MAC address means "pass it up".

Dino

Date: Thu, 11 May 2006 18:39:28 -0400
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1034

> b) we can save lots of room if we don't bother with DSAP encoding or the 
> inner header, but we do want the TTL.
> 
> Outer Ethernet header has destination=new layer 2 multicast address (not 
> the same as the  layer 2 multicast used
> by RBridges for other flooded packets, but instead, specific to IS-IS)
> Ethertype="encapsulated RBridge packet"
> Source=transmitting RBridge
> 
> Shim header: it's only 4 bytes, and it has the TTL, so use it...contains 
> "ingress RBridge, and TTL"
> 
> Following the shim header, instead of a new inner Ethernet header, 
> perhaps just have the VLAN tag? Then
> directly start the IS-IS packet?

This sounds like the better way to do it.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Wed, 10 May 2006 18:50:56 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Encapsulation of RBridge IS-IS routing messages
Status: RO
Content-Length: 1720

I was rereading the (not yet submitted draft) and realized I'm not sure 
exactly what an IS-IS packet
should look like. I'm sure people will have strong feelings about this, 
so please think about this.

It seems a shame to bother with 2 headers, but perhaps it's the 
simplest. The most straightforward
way I think is:

a) outer Ethernet header: destination="all-RBridges", source=transmitted 
RBridge, Ethertype="encapsulated
RBridge packet" (note...this would be the same as a data packet for an 
unknown destination, or a multicast
data packet transmitted by RBridges)

shim header=19-bit nickname of ingress RBridge, TTL

inner Ethernet header: no useful information other than VLAN tag (to 
separate out the VLAN-specific IS-IS that
reports endnode information from the "core" RBridge IS-IS instance)

The way to tell an IS-IS packet from a data packet is based on the DSAP 
in the inner Ethernet header (and yeah...given that it's IS-IS, it 
wouldn't be an Ethertype...it would be a SAP...the "protocol type" would be
a length, and there would be a DSAP)

**********
So an alternative encoding:

b) we can save lots of room if we don't bother with DSAP encoding or the 
inner header, but we do want the TTL.

Outer Ethernet header has destination=new layer 2 multicast address (not 
the same as the  layer 2 multicast used
by RBridges for other flooded packets, but instead, specific to IS-IS)
Ethertype="encapsulated RBridge packet"
Source=transmitting RBridge

Shim header: it's only 4 bytes, and it has the TTL, so use it...contains 
"ingress RBridge, and TTL"

Following the shim header, instead of a new inner Ethernet header, 
perhaps just have the VLAN tag? Then
directly start the IS-IS packet?

Radia

Date: Mon, 08 May 2006 14:24:50 -0700
From: Erik Nordmark <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 1049

Gray, Eric wrote:
> Erik,
> 
> 	The only thing special about an edge RBridge is that it
> has at least one interface onto a LAN segment where there is at
> least one Ethernet end-station that is not an RBridge.  I think
> (based on the last conversation I had on this topic) that - of
> all edge RBridges - only those that win the Designated RBridge
> election will ever advertise any kind of MAC reachability or
> interest into the RBridge campus.

Agreed.

> 	That being the case, there are two things to realize: 
> 
> 1) Any RBridge may be an edge RBridge.
> 2) The only way that a "non-edge" Rbridge would learn of a 
>    multicast address of interest is via another RBridge.

My point for #2 is that this learning can be done in two very different 
ways:
  - snoop the IGMP/MLD messages everywhere (and for the "non-edge" case 
those are encapsulated just like other packets)
  - only the edge snoops the IGMP/MLD messages and based on this 
learning advertises the multicast membership as some LSAs (or other 
explicit container)

    Erik

Date: Mon, 08 May 2006 17:55:26 -0400
From: Russ White <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 2346

> --> > I would leave the specific mechanism open, while requiring 
> --> > optimization, and write a separate doc on how to actually do 
> --> > the optimization using IGMP snooping. Other mechanisms might 
> --> > show up that might be more efficient/etc., so there's no 
> --> > reason to tie the rbridges docs to one specific mechanism.
> --> >
> --> I can't imagine new mechanisms happening, and I don't see how it 
> --> simplified anything to make it a separate document. 
> 
> You're joking, right?
> 
> This is all about new mechanisms to do Ethernet forwarding
> and we're talking about using specific mechanisms to allow
> us to optimize multicast/VLAN forwarding.
> 
> Given this context, how can we not imagine new mechanisms?
> 
> At first, it seems simpler to keep this in a single document,
> and that may well be the way to go.  However, if we imagine
> that other mechanisms might also be used, then we should be
> writing the main protocol document such that these other ways
> can be "plugged in".

In fact, I can already imagine one, which is why I said this.... It's
not a matter of any new idea being brilliant, just that we should leave
room for it, probably. :-)

> --> And although it is "safe" for some inner RBridge not to filter, 
> --> it isn't safe to make it optional for RBridges to discover 
> --> locations of multicast receivers and announce the location of 
> --> them...because filtering RBridges will be assuming that lack of 
> --> information about interest on a link means they don't need to 
> --> forward there. So that form of optimization is not safe to be 
> --> optional.
> 
> I don't think anyone is arguing that the discovery of multicast
> listener locations should be optional.  What I see being argued
> here is that we should not restrict the mechanism to apply only
> to what we know now, specifically that we could use IGMP snooping
> to learn MAC multicast associated IP multicast listeners, unless 
> we do not have a choice.

Agreed.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

From: "Gray, Eric" <[email-masked]>
To: Erik Nordmark <[email-masked]>, Radia Perlman <[email-masked]>
Date: Mon, 8 May 2006 16:54:02 -0400 
Cc: [email-masked]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 3974

Erik,

	The only thing special about an edge RBridge is that it
has at least one interface onto a LAN segment where there is at
least one Ethernet end-station that is not an RBridge.  I think
(based on the last conversation I had on this topic) that - of
all edge RBridges - only those that win the Designated RBridge
election will ever advertise any kind of MAC reachability or
interest into the RBridge campus.

	That being the case, there are two things to realize: 

1) Any RBridge may be an edge RBridge.
2) The only way that a "non-edge" Rbridge would learn of a 
   multicast address of interest is via another RBridge.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Erik Nordmark
--> Sent: Monday, May 08, 2006 4:29 PM
--> To: Radia Perlman
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Summary of layer 2 multicast stuff
--> 
--> Radia Perlman wrote:
--> 
--> > 4) IPv6 multicasts are more problematic, if it's really 
--> true that other 
--> > applications might use those
--> > l2 addresses. (how big a block of the locally derived 
--> addresses is IPv6 
--> > using? Why are they
--> > using locally derived addresses?) There are several 
--> options for how we 
--> > deal with this:
--> > a) don't optimize IPv6 multicast flooding
--> > b) ignore the possibility of other applications using 
--> those l2 multicast 
--> > addresses...those other applications
--> > should know that IPv6 are using those addresses, so even 
--> though it's not 
--> > "owned" by IETF, other
--> > applications should design around them, and if things are 
--> flaky for them 
--> > as a result (because RBridges
--> > will not deliver a frame addressed to one of those 
--> addresses unless 
--> > there is an IPv6 multicast router
--> > and/or an IGMP report received)
--> > c) do flooding optimization for the IPv6 block only if 
--> the Ethertype on 
--> > the inside packet indicates
--> > it is an IPv6 packet
--> 
--> This is an issue for IGMP/MLD snooping in general, hence 
--> there isn't 
--> anything specific to rbridges here. I don't know if there 
--> is any work on 
--> the IGMP/MLD snooping document going on in Magma. Perhaps 
--> Dino knows.
--> 
--> > 5) l2 multicasts that aren't IP...since there is no 
--> universally deployed 
--> > "wish to receive" for these
--> > multicast addresses, I see no choice for RBridges than to 
--> not attempt to 
--> > optimize for these
--> > addresses (i.e., send these everywhere). Conceivably in 
--> the future there 
--> > might be some application
--> > that gets deployed where all endnodes announce somehow, 
--> but given that 
--> > current RBridges can't
--> > be designed to recognize that future application, I don't 
--> see how we can 
--> > design to optimize those.
--> > My guess is that any high volume multicast applications 
--> will just do it 
--> > with IP rather than
--> > inventing their own mechanism.
--> 
--> Agree in principle.
--> 
--> But there is an architectural issue about the placement of 
--> the learning 
--> of multicast membership that I think we should discuss: Is this 
--> (IGMP/MLD snooping and potentially future different ways) something 
--> which only the edge rbridges do, and then they propagate 
--> what they've 
--> learned as some link-state advertisements to the other 
--> rbridges, *or* is 
--> it something that we expect all the rbridges to do?
--> 
--> (One can draw parallels between this multicast issue and 
--> the unicast 
--> issue of whether or not we limit learning of station MAC 
--> addresses to 
--> the edge rbridges.)
--> 
--> *If* the multicast learning is limited to the edge rbridge, 
--> it might be 
--> more feasible to introduce some new multicast learning approach.
--> 
-->     Erik
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Mon, 08 May 2006 13:28:32 -0700
From: Erik Nordmark <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 2547

Radia Perlman wrote:

> 4) IPv6 multicasts are more problematic, if it's really true that other 
> applications might use those
> l2 addresses. (how big a block of the locally derived addresses is IPv6 
> using? Why are they
> using locally derived addresses?) There are several options for how we 
> deal with this:
> a) don't optimize IPv6 multicast flooding
> b) ignore the possibility of other applications using those l2 multicast 
> addresses...those other applications
> should know that IPv6 are using those addresses, so even though it's not 
> "owned" by IETF, other
> applications should design around them, and if things are flaky for them 
> as a result (because RBridges
> will not deliver a frame addressed to one of those addresses unless 
> there is an IPv6 multicast router
> and/or an IGMP report received)
> c) do flooding optimization for the IPv6 block only if the Ethertype on 
> the inside packet indicates
> it is an IPv6 packet

This is an issue for IGMP/MLD snooping in general, hence there isn't 
anything specific to rbridges here. I don't know if there is any work on 
the IGMP/MLD snooping document going on in Magma. Perhaps Dino knows.

> 5) l2 multicasts that aren't IP...since there is no universally deployed 
> "wish to receive" for these
> multicast addresses, I see no choice for RBridges than to not attempt to 
> optimize for these
> addresses (i.e., send these everywhere). Conceivably in the future there 
> might be some application
> that gets deployed where all endnodes announce somehow, but given that 
> current RBridges can't
> be designed to recognize that future application, I don't see how we can 
> design to optimize those.
> My guess is that any high volume multicast applications will just do it 
> with IP rather than
> inventing their own mechanism.

Agree in principle.

But there is an architectural issue about the placement of the learning 
of multicast membership that I think we should discuss: Is this 
(IGMP/MLD snooping and potentially future different ways) something 
which only the edge rbridges do, and then they propagate what they've 
learned as some link-state advertisements to the other rbridges, *or* is 
it something that we expect all the rbridges to do?

(One can draw parallels between this multicast issue and the unicast 
issue of whether or not we limit learning of station MAC addresses to 
the edge rbridges.)

*If* the multicast learning is limited to the edge rbridge, it might be 
more feasible to introduce some new multicast learning approach.

    Erik

From: "Gray, Eric" <[email-masked]>
To: Radia Perlman <[email-masked]>
Date: Mon, 8 May 2006 16:04:34 -0400 
Cc: [email-masked]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 4805

Radia,

	Please see below...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Monday, May 08, 2006 12:38 PM
--> To: [email-masked]
--> Subject: Re: [rbridge] Summary of layer 2 multicast stuff
--> 
--> 
--> 
--> Russ White wrote
--> 
--> >
--> > I would leave the specific mechanism open, while requiring 
--> > optimization, and write a separate doc on how to actually do 
--> > the optimization using IGMP snooping. Other mechanisms might 
--> > show up that might be more efficient/etc., so there's no 
--> > reason to tie the rbridges docs to one specific mechanism.
--> >
--> I can't imagine new mechanisms happening, and I don't see how it 
--> simplified anything to make it a separate document. 

You're joking, right?

This is all about new mechanisms to do Ethernet forwarding
and we're talking about using specific mechanisms to allow
us to optimize multicast/VLAN forwarding.

Given this context, how can we not imagine new mechanisms?

At first, it seems simpler to keep this in a single document,
and that may well be the way to go.  However, if we imagine
that other mechanisms might also be used, then we should be
writing the main protocol document such that these other ways
can be "plugged in".

--> And although it is "safe" for some inner RBridge not to filter, 
--> it isn't safe to make it optional for RBridges to discover 
--> locations of multicast receivers and announce the location of 
--> them...because filtering RBridges will be assuming that lack of 
--> information about interest on a link means they don't need to 
--> forward there. So that form of optimization is not safe to be 
--> optional.

I don't think anyone is arguing that the discovery of multicast
listener locations should be optional.  What I see being argued
here is that we should not restrict the mechanism to apply only
to what we know now, specifically that we could use IGMP snooping
to learn MAC multicast associated IP multicast listeners, unless 
we do not have a choice.

I have also seen suggestions made that make it seem as if we 
certainly have a choice.

--> 
--> >
--> > Or, make IPv6 optimization optional, and leave it outside 
--> > the scope of this doc to discuss possible mechanisms. If 
--> > we separate this problem out, we can think about it later, 
--> > once the base documents are done, and we might possibly 
--> > come up with a solution.
--> >
--> As above, if we make discovery of IPv6 receivers and announcement
--> of them optional now, I don't think it will ever be safe to add 
--> it later, since there will be some RBridges that would not recognize
--> whatever the announcement is, and would not advertise it, so future 
--> RBridges would not be able to assume it is safe to deliver to a link 
--> that they don't know for certain does NOT have listeners.
-->

If this were true, we would not now be able to use BGP for stuff
like IPv6 and MPLS-VPNs.

In most of the protocol work I've seen done in the IETF in recent
years, the possibility that the protocol may need to be extended -
and that version compatibility (possibly including some form of 
capability negotiation) MAY need to take place - is something that 
MUST be built into the first version of the protocol.

I think it is a bad idea to assume that will not be the case with
RBridge protocols as well.

In the case of this particular discussion about multicast listener
announcements, for example, we SHOULD define a protocol mechanism 
for carrying these announcements that -

1) generally defines how we would transport these announcements
   across the RBridge campus (including all information that we
   know we will need in order to use these annoucements)
2) specifically defines the details of the mechanism as we would
   define it for what we know now (including IP multicast associated
   MAC mulitcast addresses learned from IGMP)
3) defines behaviors for all RBridges with respect to handling of
   any such announcements that are not understood by a local RBridge
   (e.g. - the local RBridge transports them transparently, with the
   content treated as opaque, to adjacent peers along with any other
   announcements)

Also defined should be the mechanism used to determine forwarding
tactics for MAC multicast traffic when there is a mix of traffic
where some MUST be treated as if it were broadcast and others MAY
be filtered based on "interest" information learned from other
RBridges.

--> I suspect that sentence has too many negatives to parse, 
--> but I hope I got the parity right.
--> 
--> Radia
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: Dino Farinacci <[email-masked]>
Date: Mon, 8 May 2006 15:28:13 -0400 
Cc: [email-masked]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
Status: RO
Content-Length: 5639

Dino,

	I agree that - for a specific subset of RBridge deployment
scenarios (possibly most significant deployment scenarios, maybe
all important ones) - it is more than just desirable that all of
the RBridges implement both VLAN and Multicast optimizations.

	I am not trying to say anything contrary to this.  Nor am
I trying to argue that other deployment scenarios are somehow of
greater number or importance.

	What I am saying is that there is a difference between what
might make sense in a variety of different RBridge implementations, 
and what we have to specify in order to define interoperable RBridge 
implementations.

	The difference is that an RBridge - as a functional abstract
concept - does not need to implement these optimizations in order
to function interoperably with other RBridges.  This remains true
even if some RBridges fully implement these optimizations and some
implement only the message forwarding and information exchanges to
make that possible (without implementing the optimizations).

	Argument that a device that does not implement optimizations 
will be effectively disfunctional in a deployment scenario that 
requires full support for these optimizations is both correct and 
obvious.  We envision a scenario in which XYZ is required and then 
say that not having XYZ in that scenario is a problem.  That is very 
clearly going to be the case, because this represents a tautology.

	However, the fact that implementations need to have a feature
(a set of optimization in this case) in order to satisfy requirements
of a particular deployment has nothing to do with whether or not the
term "MAY", "SHOULD" or "MUST" applies in a protocol specification.
What determines which of these words applies is 1) the way they are
defined in RFC 2119 and 2) the degree to which interoperability is 
dependent on implementing that feature.

	We cannot, and should not, stretch the meaning of the terms
defined in RFC 2119 for the sake of convenience.  If something is
required for interoperability in implementing a specification, it is 
a MUST.  If something is expected in an interoperable implementation 
of a specification, but might not be required in every case, it is a 
SHOULD.  If something is allowed, but neither expected, nor required,
it is a MAY.

	As a result of all of the things we've discussed over the past
several months, it is clear that - with very little stretching - we
can make the word SHOULD apply to VLAN and Multicast optimization.
With similar stretching, we could make the word MAY apply as well.

	But - particularly since it has been abundantly demonstrated 
that it is not necessary for every implementation to implement every 
one of these optimizations in order to achieve interoperability - it 
is not possible to stretch this to the point that MUST would apply 
to the implementation of the optimizations.  The implementation of 
message forwarding and information exchanges is required to support 
the optimizations and is therefore a MUST.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Dino Farinacci
--> Sent: Thursday, May 04, 2006 8:11 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] Should layer 2 or layer 3 IP 
--> Multicast addresses be advertised?
--> 
--> >> I don't know if I understand this, actually.... Today, 
--> what happens is
--> >> we get layer 2 multicast, and forward it everywhere. We use IGMP
--> >> snooping to optimized that flooding, on the assumption 
--> that anything
--> >> being sent to a layer 2 multicast address that maps to a layer 3
--> >> multicast address must be an IP originated multicast (as 
--> it should be,
--> >> based on the mapping rules), and thus, we can optimize 
--> these multicasts
--> >> based on the layer 3 information.
--> 
-->     The optimization is not based on a L3 multicast address 
--> mapping to a L2
-->     multicast address but the fact there is receiver 
--> membership signalling.
-->  
-->     If L2 apps implemented GMRP/GARP, we could optimize for 
--> non-IP multicast
-->     as well.
--> 
--> >> So, in light of this, shouldn't an rbridge just act the 
--> same way? In the
--> >> absence of other information, we should flood multicast 
--> through the
--> >> vlan. IGMP snooping and "other mechanisms" MAY be used 
--> to optimize the
--> >> tree, but we can't count on these. They are good 
--> optimizations, and we
--> 
-->     SHOULD or even MUST.
--> 
-->     I wish some enterprise multicast deployers on this list 
--> would speak up and
-->     indicate not doing this optimization is a non-starter. 
--> That is what
-->     they have told me anyways. 
--> 
--> >> - -- Put it on the agenda to talk about using other, 
--> rbridge specific,
--> >> mechanisms to find this sort of information. For 
--> instance, we could
--> >> postulate a mechanism where we do conflate l2 and l3 addresses in
--> >> rbridge advertisements, and build an l3 tree for 
--> multicast in parallel
--> >> with the l2 tree, restricting the l2 tree based on the l3 tree.
--> 
-->     If someone doesn't think this assumption is too 
--> restrictive and assumed
-->     that senders must also be receivers, then the rBridges 
--> directly connected
-->     to the hosts could do the signalling inside of the 
--> rBridge network.
-->    
-->     This way we don't have to do flooding for non-signaled 
--> protocols.
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Mon, 08 May 2006 09:37:42 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 1592

Russ White wrote

>
>I would leave the specific mechanism open, while requiring optimization,
>and write a separate doc on how to actually do the optimization using
>IGMP snooping. Other mechanisms might show up that might be more
>efficient/etc., so there's no reason to tie the rbridges docs to one
>specific mechanism.
>
I can't imagine new mechanisms happening, and I don't see how it 
simplified anything to make it a separate
document. And although it is "safe" for some inner RBridge not to 
filter, it isn't safe to make it
optional for RBridges
to discover locations of multicastreceivers and announce the
location of them...because filtering RBridges will be assuming that lack
of information about interest on a link means they don't need to forward 
there. So that form of
optimization is not safe to be optional.

>
>Or, make IPv6 optimization optional, and leave it outside the scope of
>this doc to discuss possible mechanisms. If we separate this problem
>out, we can think about it later, once the base documents are done, and
>we might possibly come up with a solution.
>
As above, if we make discovery of IPv6 receivers and announcement of 
them optional now, I don't
think it will ever be safe to add it later, since there will be some 
RBridges that would not recognize
whatever the announcement is, and would not advertise it, so future 
RBridges would not be able
to assume it is safe to deliver to a link that they don't know for 
certain does NOT have listeners.
I suspect that sentence has too many negatives to parse, but I hope I 
got the parity right.

Radia

Date: Mon, 08 May 2006 09:49:55 -0400
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 3122

> 1) RBridges will advertise layer 2 multicast addresses (rather than
> IPv4 or IPv6 multicast addresses to which those l2 multicasts derive)
> 
> 
> 2) It's pretty clear we know how to do IPv4 multicasts. Since all
> IPv4 multicast endnodes do IGMP, and since the derived l2 multicasts
> are "owned" by IETF, we don't have to worry about any other 
> applications that don't do IGMP using these addresses, so it is safe
> to optimize the flooding (send only to links that have a multicast
> router and/or an endnode that has announced through IGMP it wants to
> receive the multicast.

I would leave the specific mechanism open, while requiring optimization,
and write a separate doc on how to actually do the optimization using
IGMP snooping. Other mechanisms might show up that might be more
efficient/etc., so there's no reason to tie the rbridges docs to one
specific mechanism.

> 3) Optimizing IPv4 multicast will be a MUST for RBridges

Agreed.

> 
> 4) IPv6 multicasts are more problematic, if it's really true that
> other applications might use those l2 addresses. (how big a block of
> the locally derived addresses is IPv6 using? Why are they using
> locally derived addresses?) There are several options for how we deal
> with this: a) don't optimize IPv6 multicast flooding b) ignore the
> possibility of other applications using those l2 multicast 
> addresses...those other applications should know that IPv6 are using
> those addresses, so even though it's not "owned" by IETF, other 
> applications should design around them, and if things are flaky for
> them as a result (because RBridges will not deliver a frame addressed
> to one of those addresses unless there is an IPv6 multicast router 
> and/or an IGMP report received) c) do flooding optimization for the
> IPv6 block only if the Ethertype on the inside packet indicates it is
> an IPv6 packet

Or, make IPv6 optimization optional, and leave it outside the scope of
this doc to discuss possible mechanisms. If we separate this problem
out, we can think about it later, once the base documents are done, and
we might possibly come up with a solution.

> 5) l2 multicasts that aren't IP...since there is no universally
> deployed "wish to receive" for these multicast addresses, I see no
> choice for RBridges than to not attempt to optimize for these 
> addresses (i.e., send these everywhere). Conceivably in the future
> there might be some application that gets deployed where all endnodes
> announce somehow, but given that current RBridges can't be designed
> to recognize that future application, I don't see how we can design
> to optimize those. My guess is that any high volume multicast
> applications will just do it with IP rather than inventing their own
> mechanism.

Agreed.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Sun, 07 May 2006 21:26:44 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Summary of layer 2 multicast stuff
Status: RO
Content-Length: 2241

Well, there's been a bunch of emails, so this is my attempt to summarize 
the general consensus.

1) RBridges will advertise layer 2 multicast addresses (rather than IPv4 
or IPv6 multicast addresses
to which those l2 multicasts derive)

2) It's pretty clear we know how to do IPv4 multicasts. Since all IPv4 
multicast endnodes do IGMP,
and since the derived l2 multicasts are "owned" by IETF, we don't have 
to worry about any other
applications that don't do IGMP using these addresses, so it is safe to 
optimize the flooding (send
only to links that have a multicast router and/or an endnode that has 
announced through IGMP
it wants to receive the multicast.

3) Optimizing IPv4 multicast will be a MUST for RBridges

4) IPv6 multicasts are more problematic, if it's really true that other 
applications might use those
l2 addresses. (how big a block of the locally derived addresses is IPv6 
using? Why are they
using locally derived addresses?) There are several options for how we 
deal with this:
a) don't optimize IPv6 multicast flooding
b) ignore the possibility of other applications using those l2 multicast 
addresses...those other applications
should know that IPv6 are using those addresses, so even though it's not 
"owned" by IETF, other
applications should design around them, and if things are flaky for them 
as a result (because RBridges
will not deliver a frame addressed to one of those addresses unless 
there is an IPv6 multicast router
and/or an IGMP report received)
c) do flooding optimization for the IPv6 block only if the Ethertype on 
the inside packet indicates
it is an IPv6 packet

5) l2 multicasts that aren't IP...since there is no universally deployed 
"wish to receive" for these
multicast addresses, I see no choice for RBridges than to not attempt to 
optimize for these
addresses (i.e., send these everywhere). Conceivably in the future there 
might be some application
that gets deployed where all endnodes announce somehow, but given that 
current RBridges can't
be designed to recognize that future application, I don't see how we can 
design to optimize those.
My guess is that any high volume multicast applications will just do it 
with IP rather than
inventing their own mechanism.

Radia

Date: Fri, 5 May 2006 11:56:34 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Status: RO
Content-Length: 414

>> I suppose my main point is that the architecture doc, and most other
>> docs, could say: "Multicast flooding MUST be optimized to allow
>> knowledge of receiver group membership to prune the layer 2 flooding
>> tree calculated by the rbridge." And then leave the specific mechanism
>> of how this is done to future documents, rather than getting bogged down
>> in it here.

    That would be perfect IMO.

Dino

content-class: urn:content-classes:message
Date: Fri, 5 May 2006 10:43:50 -0400
From: "Jeff Joslin" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses beadvertised?
Status: RO
Content-Length: 1769

On 2006-05-04, Derek Fawcus wrote:
> 
> On Wed, May 03, 2006 at 11:19:08AM -0400, Gray, Eric wrote:
> >
> > These are fair assumptions, at this time.  In fact, I would go a
> > bit further and speculate that nobody is using any MAC multicast
> > address except in a relatively small set of well-known multicast
> > addresses and address ranges - including the IP multicast MAC
> > multicast address range.
> 
> Well for IPv4 maybe,  but for IPv6 one may have a problem.
 
Eric claims "nobody is using any MAC multicast address..." but
I disagree. For example, 802.11 Access Points generate Station
Announce messages to a multicast address, and a new client's MAC
as the SA. These multicasts flood the bridged network and cause
bridge forwarding tables to be updated to the current location
of the client.

I also see network management multicasts using vendor-assigned
addresses. 

(Aside 1: the original 802.11 specification did not describe how
inter-AP mobility was supposed to work, but the consensus 
solution is to implement the multicast messages as described
above. Each vendor uses a multicast address with their own OUI
as the DA. The 802.11F Inter-AP Protocol "Best Practice" specified
the use of an ADD-Notify message using IP multicast address
224.0.1.178. But 802.11F was never widely implemented and is now
deprecated. I had a quick look at the draft mobility spec, 11r,
and could not find an equivalent message.)

(Aside 2: the IEEE 802 11s Task Group is standardizing a WLAN
mesh networking protocol. They are creating a framework to
support choices of forwarding algorithms. RBridging could be
one of those, but it has not been seriously proposed as far as
I know. Last I checked, a version of AODV was to be the
mandatory-to-support option.)

Jeff

Date: Fri, 05 May 2006 09:27:07 -0400
From: Russ White <[email-masked]>
To: Dino Farinacci <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Status: RO
Content-Length: 2515

>     The optimization is not based on a L3 multicast address mapping to a L2
>     multicast address but the fact there is receiver membership signalling.
>  
>     If L2 apps implemented GMRP/GARP, we could optimize for non-IP multicast
>     as well.

Yes, certainly....

>>> So, in light of this, shouldn't an rbridge just act the same way? In the
>>> absence of other information, we should flood multicast through the
>>> vlan. IGMP snooping and "other mechanisms" MAY be used to optimize the
>>> tree, but we can't count on these. They are good optimizations, and we
> 
>     SHOULD or even MUST.
> 
>     I wish some enterprise multicast deployers on this list would speak up and
>     indicate not doing this optimization is a non-starter. That is what
>     they have told me anyways. 

I don't mind SHOULD or MUST, at all.

>>> - -- Put it on the agenda to talk about using other, rbridge specific,
>>> mechanisms to find this sort of information. For instance, we could
>>> postulate a mechanism where we do conflate l2 and l3 addresses in
>>> rbridge advertisements, and build an l3 tree for multicast in parallel
>>> with the l2 tree, restricting the l2 tree based on the l3 tree.
> 
>     If someone doesn't think this assumption is too restrictive and assumed
>     that senders must also be receivers, then the rBridges directly connected
>     to the hosts could do the signalling inside of the rBridge network.
>    
>     This way we don't have to do flooding for non-signaled protocols.

I suppose my main point is that the architecture doc, and most other
docs, could say: "Multicast flooding MUST be optimized to allow
knowledge of receiver group membership to prune the layer 2 flooding
tree calculated by the rbridge." And then leave the specific mechanism
of how this is done to future documents, rather than getting bogged down
in it here.

There are likely to be multiple ways of doing this for each given l3
protocol--IGMP snooping, including l3 membership in the LSPs (probably
the easiest, long term), other forms of snooping, and maybe even ideas
we've not thought of yet. Let's just incubate those ideas in another
doc, perhaps.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Fri, 5 May 2006 02:13:35 +0100
From: Derek Fawcus <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Status: RO
Content-Length: 1213

On Wed, May 03, 2006 at 11:19:08AM -0400, Gray, Eric wrote:
> 
> The main issue in this entire context is that we are assuming
> that we can know for sure that nobody uses multicast addresses
> in the range that is used for IP multicast to MAC mapping unless
> they are in fact using it for IP multicast and using IGMP to do
> this.  We are also implicitly assuming that there are no other
> well-known MAC multicast addresses or address ranges.
> 
> These are fair assumptions, at this time.  In fact, I would go a
> bit further and speculate that nobody is using any MAC multicast
> address except in a relatively small set of well-known multicast
> addresses and address ranges - including the IP multicast MAC
> multicast address range.  

Well for IPv4 maybe,  but for IPv6 one may have a problem.

IPv6 uses 0x33 0x33;  which (AFAIK) is a local allocation.
So any other application is free to use this range.

So if the rbridge was to try and optimise the sending of packets
to such MAC addresses based upon knowledge gleaned from MLD,  it
would also have to inspect the ethertype of the forwarded packet.

Then only optimise 0x86dd,  while flooding other ethertypes using
a MAC in the 0x33 0x33 range.

DF

Date: Thu, 4 May 2006 17:10:56 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Status: RO
Content-Length: 1882

>> I don't know if I understand this, actually.... Today, what happens is
>> we get layer 2 multicast, and forward it everywhere. We use IGMP
>> snooping to optimized that flooding, on the assumption that anything
>> being sent to a layer 2 multicast address that maps to a layer 3
>> multicast address must be an IP originated multicast (as it should be,
>> based on the mapping rules), and thus, we can optimize these multicasts
>> based on the layer 3 information.

    The optimization is not based on a L3 multicast address mapping to a L2
    multicast address but the fact there is receiver membership signalling.
 
    If L2 apps implemented GMRP/GARP, we could optimize for non-IP multicast
    as well.

>> So, in light of this, shouldn't an rbridge just act the same way? In the
>> absence of other information, we should flood multicast through the
>> vlan. IGMP snooping and "other mechanisms" MAY be used to optimize the
>> tree, but we can't count on these. They are good optimizations, and we

    SHOULD or even MUST.

    I wish some enterprise multicast deployers on this list would speak up and
    indicate not doing this optimization is a non-starter. That is what
    they have told me anyways. 

>> - -- Put it on the agenda to talk about using other, rbridge specific,
>> mechanisms to find this sort of information. For instance, we could
>> postulate a mechanism where we do conflate l2 and l3 addresses in
>> rbridge advertisements, and build an l3 tree for multicast in parallel
>> with the l2 tree, restricting the l2 tree based on the l3 tree.

    If someone doesn't think this assumption is too restrictive and assumed
    that senders must also be receivers, then the rBridges directly connected
    to the hosts could do the signalling inside of the rBridge network.
   
    This way we don't have to do flooding for non-signaled protocols.

Dino

Date: Thu, 04 May 2006 08:54:26 -0400
From: Russ White <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Status: RO
Content-Length: 2453

> That is why - from an architectural perspective - we should 
> assume that an egress RBridge "figures out" what MAC multicast
> addresses it should announce interest in "somehow" and then it
> advertises interest in those MAC multicast addresses to other
> RBridges.  The one example we can point to today would be as a 
> result of using IGMP snooping (and we should mention that), but 
> we should not assume that will be the only way this will ever 
> happen.

I don't know if I understand this, actually.... Today, what happens is
we get layer 2 multicast, and forward it everywhere. We use IGMP
snooping to optimized that flooding, on the assumption that anything
being sent to a layer 2 multicast address that maps to a layer 3
multicast address must be an IP originated multicast (as it should be,
based on the mapping rules), and thus, we can optimize these multicasts
based on the layer 3 information.

So, in light of this, shouldn't an rbridge just act the same way? In the
absence of other information, we should flood multicast through the
vlan. IGMP snooping and "other mechanisms" MAY be used to optimize the
tree, but we can't count on these. They are good optimizations, and we
should use them if we have them, but we probably shouldn't specify the
mechanism used to discover the layer 3 multicast topology, I wouldn't
think (?).

Hmmm.... I wonder if we should:

- -- Require optimization of the tree when layer 3 information allowing
the optimization of the tree is available.

- -- Allow the use of IGMP snooping to provide such learning of layer 3
information.

- -- Put it on the agenda to talk about using other, rbridge specific,
mechanisms to find this sort of information. For instance, we could
postulate a mechanism where we do conflate l2 and l3 addresses in
rbridge advertisements, and build an l3 tree for multicast in parallel
with the l2 tree, restricting the l2 tree based on the l3 tree.

While we don't have consensus on such things right this moment, writing
the current drafts such that some future mechanism could be devised
appears to be the best strategy.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

Date: Wed, 3 May 2006 14:03:20 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] Ether-type question (was RE: And what should the outer header of an IS-IS packet be?)
Status: RO
Content-Length: 307

>> 	3) Using a new Ether-type to distinguish an MPLS-like SHIM
>> 	   from MPLS label encasulated traffic.
>> 
>> At the moment, I believe we are all assuming that we will end up
>> going with choice 3.

    So, you are saying IS-IS packets will be encapsulated with the shim
    header format. Okay.

Dino

Date: Wed, 03 May 2006 13:30:38 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Mailing list reply-to insertion
Status: RO
Content-Length: 1429

That configuration was copied from another mailing list, and as you note
is probably not what is desired.

I've already updated it to be consistent with what other lists already do.

FYI - there have been other lists complaining about 'subscriber-only'
mode, where non-subscriber posts are not moderated, but are rejected
with a notice of how to proceed.

This list is currently configured that way; if someone wants to
volunteer to moderate non-subscriber posts, I can set the system up so
they can do so. I do not have time and will not volunteer for that task
- I already end up reviewing about 5-10 posts a day from members that
are held for approval (most are spam on the borderline).

Joe

Erik Nordmark wrote:
> The rbridge mailing list currently inserts a reply-to field.
> 
> The other IETF-related mailing lists I've looked at don't seem to do this.
> The question is whether we should change the rbridge list to no longer 
> do this.
> 
> The benefits of the reply-to is that the messages stay on the list and 
> there isn't a lot of cc's accumulating to the email threads.
> 
> The disadvantage is that it's easier to accidentally have private 
> replies go to the list.
> 
> Any objections to change the list to no longer insert a reply-to?
> 
>      Erik and Donald
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

Date: Wed, 03 May 2006 11:00:01 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Mailing list reply-to insertion
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 536

The rbridge mailing list currently inserts a reply-to field.

The other IETF-related mailing lists I've looked at don't seem to do this.
The question is whether we should change the rbridge list to no longer 
do this.

The benefits of the reply-to is that the messages stay on the list and 
there isn't a lot of cc's accumulating to the email threads.

The disadvantage is that it's easier to accidentally have private 
replies go to the list.

Any objections to change the list to no longer insert a reply-to?

     Erik and Donald

Date: Wed, 03 May 2006 10:38:07 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Out of date milestones
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2100

The WGs current set of milestones are out of date:
Aug 2005	  	Accept architecture document as a WG work item
Sep 2005	  	Accept base protocol specification as a WG document
Oct 2005	  	Accept routing protocol requirements as a WG work item
Nov 2005	  	Submit architecture document to IEEE/IETF expert review
Jan 2006	  	Submit architecture document to the IESG for publication as
an Informational RFC
Mar 2006	  	Submit routing protocol requirements to the IESG for
publication as an Informational RFC
Mar 2006	  	Choose routing protocol(s) that can meet the requirements
Apr 2006	  	Start work with routing area WG(s) to undertake TRILL extensions
Aug 2006	  	Submit base protocol specification to IEEE/IETF expert review
Oct 2006	  	Base protocol specification submitted to the IESG for
publication as a Proposed Standard RFC
Feb 2007	  	Re-charter or shut down the WG

The above list also doesn't talk about a separate problem statement and
applicability document, and it makes sense to add milestones for that
document.

What to folks (in particular authors and editors) think about this
proposed list:

June 2006	  	Accept architecture document as a WG work item
DONE		  	Accept base protocol specification as a WG document
June 2006	  	Accept routing protocol requirements as a WG work item
DONE		  	Accept problem statement and applicability as a WG work item

Aug 2006		Submit problem statement and applicability to IESG for 
Informational RFC
Aug 2006	  	Submit architecture document to IEEE/IETF expert review
Nov 2006	  	Submit architecture document to the IESG for publication as 
an Informational RFC
Aug 2006	  	Submit routing protocol requirements to the IESG for 
publication as an Informational RFC
Dec 2006	  	Choose routing protocol(s) that can meet the requirements
DONE		  	Start work with routing area WG(s) to undertake TRILL extensions
Dec 2006	  	Submit base protocol specification to IEEE/IETF expert review
Mar 2007	  	Base protocol specification submitted to the IESG for 
publication as a Proposed Standard RFC
July 2007	  	Re-charter or shut down the WG

    Erik

From: "Gray, Eric" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Wed, 3 May 2006 11:19:08 -0400 
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3462

Radia,

	Please see below... 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Wednesday, May 03, 2006 2:13 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Should layer 2 or layer 3 IP 
--> Multicast addresses be advertised?
--> 
--> Tim,
--> 
--> There isn't a problem. There's a block of layer 2 multicast 
--> addresses derived from IP multicast addresses. These are the 
--> only multicast addresses that RBridges are attempting to 
--> optimize delivery of.
--> 
--> Other layer 2 multicast addresses just get delivered to all 
--> links, like bridges would do.
--> 

This is the assumption that bothers me.  Tim is correct in his
comment that there may be other mechanisms for advertising any
interest in MAC multicast addresses - besides IGMP.

Currently, we can feel relatively certain that either this is
the only case that exists, or the only case that we care about
in this context.  However, this is hardly a "future-proof" way
of doing architectural design.

That is why - from an architectural perspective - we should 
assume that an egress RBridge "figures out" what MAC multicast
addresses it should announce interest in "somehow" and then it
advertises interest in those MAC multicast addresses to other
RBridges.  The one example we can point to today would be as a 
result of using IGMP snooping (and we should mention that), but 
we should not assume that will be the only way this will ever 
happen.

The main issue in this entire context is that we are assuming
that we can know for sure that nobody uses multicast addresses
in the range that is used for IP multicast to MAC mapping unless
they are in fact using it for IP multicast and using IGMP to do
this.  We are also implicitly assuming that there are no other
well-known MAC multicast addresses or address ranges.

These are fair assumptions, at this time.  In fact, I would go a
bit further and speculate that nobody is using any MAC multicast
address except in a relatively small set of well-known multicast
addresses and address ranges - including the IP multicast MAC
multicast address range.  

The reason why I strongly suspect this is because applications 
that might use multicast will do one of the following:

1) Use well-known multicast MAC addresses that are know to work
   and be supported by all existing L2 (and below) forwarding 
   devices,
2) Have a mechanism for negotiating and communicating multicast
   MAC usage,
3) Rely on the fact that multicast addressed frames are in fact 
   treated as broadcast frames, or
4) Use the all-ones broadcast address instead.

In general, if the application relies on broadcast-like frame
distribution, it almost certainly uses the all-ones broadcast 
MAC address.  This seems obvious because the only result that
appears to have come out of deployment of switches that don't 
"broadcast" multicast frames has been work to make sure that
they do forward them in the limited set of specific cases that
apply today (i.e. - IP multicast in particular).

The obvious corrolary to this is that any application that uses
a MAC multicast address assumes that there is some potential for
benefits from less-than-broadcast, domain-wide, distribution of
MAC multicast frames.  Clearly this implies development of some
mechanism(s) to support limited distribution (e.g. - IGMP snooping).

--
Eric

--- [SNIP] ---

From: "Gray, Eric" <[email-masked]>
To: Dino Farinacci <[email-masked]>
Date: Wed, 3 May 2006 10:21:15 -0400 
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Ether-type question (was RE: And what should the outer header of an IS-IS packet be?)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1205

Dino,

	I suspect that this is a reference to the possibility that
we will probably have to get a new Ether-type assigned to support
the SHIM encapsulation of frames forwarded between RBridges.

	This is a strong possibility, given that current choices
include:

	1) Using standard Ethernet re-encapsulation (allowing the
	   use of the various existing Ether-types, but requiring
	   more smarts in egress RBridges and using up more bits 
	   on the wire)
	2) Using MPLS label encapsulation as-is (potentially with
	   a boat-load of its own problems and complexities)
	3) Using a new Ether-type to distinguish an MPLS-like SHIM
	   from MPLS label encasulated traffic.

At the moment, I believe we are all assuming that we will end up
going with choice 3.

-->

--- [SNIP] ---

--> 
--> >> c) the same as the new Ethertype we will need assigned 
--> >>    to indicate that the frame is an RBridge-encapsulated 
--> >>    frame?
--> 
-->     I can't parse this. What do you mean? The same as what?
--> 

--- [SNIP] ---

--> 
--> Dino
--> 
-->     
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Wed, 3 May 2006 09:57:42 -0400 
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4213

Radia,

	We need to be careful not to conflate advertising of MAC
multicast addresses in support of IP multicast and advertising 
of the IP(v4/v6) multicast addresses, themselves.

	Mechanisms for determining associations of IP multicast
addresses and MAC multicast addresses are out of scope for the
RBridge protocol specification, as are mechanisms for announcing
L3 multicast reachability.  We can (and maybe should) talk about
these things, but we are not defining them and we should avoid
potentially cross-defining them in potential conflict with the
way they are - or will be - defined elsewhere.

	RBridges are layer two devices.  Mixing up the terminology
is bound to create confusion just as mixing up technologies is
bound to create complexity.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 7:23 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Should layer 2 or layer 3 IP 
--> Multicast addresses be advertised?
--> 
--> The purpose of the RBridge snooping on IGMP, and in 
--> general, watching 
--> the IP multicast is
--> not to replace IP multicast, but to optimize delivery of IP data 
--> multicast within a campus. If
--> there was a very high volume multicast application that was 
--> only being 
--> received by one listener,
--> RBridges can ensure that packets for that application only 
--> get delivered 
--> to the one link on which
--> there is a listener.
--> 
--> If we decided RBridges should ignore the issue entirely, 
--> and treat IP 
--> multicast like any layer 2 multicast,
--> then all IP multicast packets would be flooded, through the 
--> ingress-RBridge tree on which they were injected,
--> to all links in the campus. This would be correct behavior, in that 
--> multicast packets would get delivered,
--> but it would not be optimal behavior, since there would be 
--> unnecessary 
--> traffic on lots of links.
--> 
--> So this is similar to IGMP snooping switches, although it works 
--> differently for RBridges than it does
--> with pure switches, since RBridges explicitly say the 
--> information (where 
--> IP listeners are for each IP multicast
--> group, where IP multicast routers are) in link state 
--> information, and 
--> the information doesn't have to change
--> if interior links in the campus go up or down (as they 
--> would with IGMP 
--> snooping switches, that are
--> inferring things based on the direction from which they see IGMP 
--> notification messages and such).
--> 
--> Radia
--> 
--> 
--> 
--> Caitlin Bestler wrote:
--> 
--> >[email-masked] wrote:
--> >  
--> >
--> >>Radia,
--> >>
--> >>	I would lean toward (b).
--> >>
--> >>	In part, that is because we don't (to my knowledge)
--> >>have a working group consensus to necessarily include "IP 
--> multicast"
--> >>(as opposed to MAC multicast) awareness in RBridges.  I think
--> >>we need to have that consensus before we talk about including
--> >>any kind of IPv4/v6 addresses in RBridge advertisements.
--> >>
--> >>	We may need to have consensus on other things before we
--> >>do that as well - like how appropriate it is to use RBridge
--> >>protocols as a substitute for multicast routing protocols.
--> >>
--> >>    
--> >>
--> >It would also be inconsistent. The Multicast routing protocols
--> >are responsible for determining which subnets a multicast
--> >datagram needs to reach. The RBridge multicast support should
--> >take over after than point (and deal with MAC multicast only).
--> >
--> >  
--> >
--> >>	But my leaning is also because we can be more
--> >>consistent in storing MAC layer reachability if we are being
--> >>consistent and only advertising MAC layer reachability in
--> >>RBridge protocol.
--> >>
--> >>    
--> >>
--> >
--> >I agree.
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Wed, 03 May 2006 09:42:16 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4146

Radia Perlman wrote:

>Tim,
>
>There isn't a problem. There's a block of layer 2 multicast addresses 
>derived from IP multicast
>addresses. These are the only multicast addresses that RBridges are 
>attempting to optimize delivery of.
>Other layer 2 multicast addresses just get delivered to all links, like 
>bridges would do.
>
>So there's no correctness issue, since when in doubt RBridges will 
>deliver multicast packets to all links.
>As an optimization issue, it's nice if they can be more specific, and 
>only deliver to links with listeners.
>I believe IEEE has somewhat recently standardized something similar to 
>IGMP, but at layer 2, where
>layer 2 endnodes can announce what layer 2 multicast addresses they wish 
>to receive. But unless
>it were universally implemented (and I've heard it is not very widely 
>implemented, and certainly not universally
>implemented) bridges would not be able to assume, from lack of an 
>announcement, that nobody on the
>link needs the packet, so they'd have to deliver everywhere.
>
>So that is what RBridges will do...deliver multicasts to all links 
>within the VLAN, other than the particular
>l2 multicast block that is derived from IP multicast, where since some 
>version of IGMP is implemented by all IP
>endnodes that are receiving IP multicasts, lack of receipt of an IGMP 
>announcement does mean it is
>safe not to deliver a packet to that link.
>
>Radia
>
>Tim Shepard wrote:
>
>  
>
>>Radia Perlman wrote:
>>
>> 
>>
>>    
>>
>>>I'm trying to write up the RBridge/IP multicast interaction. What should
>>>a Designated RBridge put into
>>>its link state information regarding IP multicast listeners?
>>>
>>>The possibilities are:
>>>a) IPv4 multicast addresses, and IPv6 multicast addresses
>>>b) layer 2 multicast addresses derived from any of the groups the 
>>>RBridge has heard in IGMP Notification Messages from attached endnodes.
>>>c) compressed layer 2 multicast addresses (i.e., leave off the top two 
>>>bytes).
>>>
>>>Either works. Does anyone care? The nice thing about b) is that it
>>>doesn't have to be different information for IPv4 than IPv6. The
>>>nice thing about a) is that it is a little bit less information in
>>>the case of IPv4 (but more information in the case of IPv6). The
>>>nice thing about c) is that it compresses the information (does IPv6
>>>have the same block of layer 2 multicast addresses derived from IPv6
>>>multicast addresses as for IPv4 multicast addresses?)
>>>   
>>>
>>>      
>>>
>>There seems to be an architectural flaw lurking in here.
>>What if someone wanted to make use of some protocol other than IPv4 or
>>IPv6 over an rbridge campus?  If it only uses unicast, then the
>>rbridge machinery should work just fine.
>>
>>But if it uses ethernet multicast frames, then the rbridge system has
>>no way of determining who might be listening, other than to snoop into
>>higher level protocols that control the multicast routing.
>>
>>Of course I'm assuming that there's no protocol somewhere in the 802.*
>>specifications that allows an ethernet host to announce to an ethernet
>>switch which ethernet multicast addresses it is interested in.  But it
>>seems there should be such a thing.
>>
>>Should specifying that should happen in the IEEE 802 process somehow?
>>(I am assuming that it does not already exist.)
>>
>>
>>			-Tim Shepard
>>			 [email-masked]
>>_______________________________________________
>>rbridge mailing list
>>[email-masked]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>
Radia,
        I am not following the discussion, so excuse me if my reasoning 
is not correct. I understand that you refer to "IGMP snooping" and 
Generic Multicast Registration Protocol (GMRP) when talking about 
bridges.  I would say that it seems safer and simpler regarding 
compatibility, to follow the bridges approach of sniffing IGMP packets 
and distributing the information.
So option  b) seems to be the right election.
Guillermo
        
Guillermo

Date: Tue, 02 May 2006 23:12:41 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3396

Tim,

There isn't a problem. There's a block of layer 2 multicast addresses 
derived from IP multicast
addresses. These are the only multicast addresses that RBridges are 
attempting to optimize delivery of.
Other layer 2 multicast addresses just get delivered to all links, like 
bridges would do.

So there's no correctness issue, since when in doubt RBridges will 
deliver multicast packets to all links.
As an optimization issue, it's nice if they can be more specific, and 
only deliver to links with listeners.
I believe IEEE has somewhat recently standardized something similar to 
IGMP, but at layer 2, where
layer 2 endnodes can announce what layer 2 multicast addresses they wish 
to receive. But unless
it were universally implemented (and I've heard it is not very widely 
implemented, and certainly not universally
implemented) bridges would not be able to assume, from lack of an 
announcement, that nobody on the
link needs the packet, so they'd have to deliver everywhere.

So that is what RBridges will do...deliver multicasts to all links 
within the VLAN, other than the particular
l2 multicast block that is derived from IP multicast, where since some 
version of IGMP is implemented by all IP
endnodes that are receiving IP multicasts, lack of receipt of an IGMP 
announcement does mean it is
safe not to deliver a packet to that link.

Radia

Tim Shepard wrote:

>Radia Perlman wrote:
>
>  
>
>>I'm trying to write up the RBridge/IP multicast interaction. What should
>>a Designated RBridge put into
>>its link state information regarding IP multicast listeners?
>>
>>The possibilities are:
>>a) IPv4 multicast addresses, and IPv6 multicast addresses
>>b) layer 2 multicast addresses derived from any of the groups the 
>>RBridge has heard in IGMP Notification Messages from attached endnodes.
>>c) compressed layer 2 multicast addresses (i.e., leave off the top two 
>>bytes).
>>
>>Either works. Does anyone care? The nice thing about b) is that it
>>doesn't have to be different information for IPv4 than IPv6. The
>>nice thing about a) is that it is a little bit less information in
>>the case of IPv4 (but more information in the case of IPv6). The
>>nice thing about c) is that it compresses the information (does IPv6
>>have the same block of layer 2 multicast addresses derived from IPv6
>>multicast addresses as for IPv4 multicast addresses?)
>>    
>>
>
>
>There seems to be an architectural flaw lurking in here.
>What if someone wanted to make use of some protocol other than IPv4 or
>IPv6 over an rbridge campus?  If it only uses unicast, then the
>rbridge machinery should work just fine.
>
>But if it uses ethernet multicast frames, then the rbridge system has
>no way of determining who might be listening, other than to snoop into
>higher level protocols that control the multicast routing.
>
>Of course I'm assuming that there's no protocol somewhere in the 802.*
>specifications that allows an ethernet host to announce to an ethernet
>switch which ethernet multicast addresses it is interested in.  But it
>seems there should be such a thing.
>
>Should specifying that should happen in the IEEE 802 process somehow?
>(I am assuming that it does not already exist.)
>
>
>			-Tim Shepard
>			 [email-masked]
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

From: Tim Shepard <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Tue, 02 May 2006 23:27:50 -0400
Sender: Tim Shepard <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1826

Radia Perlman wrote:

> I'm trying to write up the RBridge/IP multicast interaction. What should
> a Designated RBridge put into
> its link state information regarding IP multicast listeners?
> 
> The possibilities are:
> a) IPv4 multicast addresses, and IPv6 multicast addresses
> b) layer 2 multicast addresses derived from any of the groups the 
> RBridge has heard in IGMP Notification Messages from attached endnodes.
> c) compressed layer 2 multicast addresses (i.e., leave off the top two 
> bytes).
> 
> Either works. Does anyone care? The nice thing about b) is that it
> doesn't have to be different information for IPv4 than IPv6. The
> nice thing about a) is that it is a little bit less information in
> the case of IPv4 (but more information in the case of IPv6). The
> nice thing about c) is that it compresses the information (does IPv6
> have the same block of layer 2 multicast addresses derived from IPv6
> multicast addresses as for IPv4 multicast addresses?)

There seems to be an architectural flaw lurking in here.
What if someone wanted to make use of some protocol other than IPv4 or
IPv6 over an rbridge campus?  If it only uses unicast, then the
rbridge machinery should work just fine.

But if it uses ethernet multicast frames, then the rbridge system has
no way of determining who might be listening, other than to snoop into
higher level protocols that control the multicast routing.

Of course I'm assuming that there's no protocol somewhere in the 802.*
specifications that allows an ethernet host to announce to an ethernet
switch which ethernet multicast addresses it is interested in.  But it
seems there should be such a thing.

Should specifying that should happen in the IEEE 802 process somehow?
(I am assuming that it does not already exist.)

			-Tim Shepard
			 [email-masked]

Date: Tue, 2 May 2006 19:10:51 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] And what should the outer header of an IS-IS packet be?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 659

>> a) the same as IS-IS for routers?

    Nope. Keep them separate so they don't collide.

>> b) a new Ethertype?

    IS-IS doesn't run in an ethertype now. It runs in a 802.2 DSAP. I think 
    this shouldn't change. Just in case there is hardware out there that might
    key on this field. DSAP space is 8-bits, so they have historically been
    treated as precious.

>> c) the same as the new Ethertype we will need assigned to indicate that 
>> the frame is
>> an RBridge-encapsulated frame?

    I can't parse this. What do you mean? The same as what?

    I would vote for:

    d) A new MAC address coming out of the 0x0180C2 OUI range.

Dino

Date: Tue, 02 May 2006 18:20:39 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1369

Caitlin Bestler wrote:

>
>But wouldn't that require that the RBridge not only understand
>what conclusions it reached about where a given layer 3 multicast
>needed to reach, but keep all of the information so that if an
>IP address migrated it could recalculate?
>
Absolutely. Just like it has to keep track of unicast destinations (in 
the current design).

Actually, there was some discussion of the issue with unicast. An 
alternative design would
have the Designated RB learn the source address from received 
unencapsulated data packets,
and not have RBridges in the core learn any of the endnode addresses. 
This would eliminate
the necessity of including this information in link state information. 
The downside is that
it means more packets would get flooded. Also, for ports in which 
RBridges can immediately
tell if an endnode is disconnected, the link state advertisement 
mechanism would be more
responsive.

It wouldn't be that big a modification of the design to take this 
philosophy rather than "advertise everything
in link state information", but we do need to pick one way and not keep 
oscillating. I don't think it's
a big deal. I think I tried to have a thread about this awhile ago and 
there wasn't much discussion, perhaps
because I wasn't clear about the issue. I *think* you are talking about 
the analogous thing with multicast.

Radia

Content-class: urn:content-classes:message
Date: Tue, 2 May 2006 16:48:47 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1695

[email-masked] wrote:
> The purpose of the RBridge snooping on IGMP, and in general,
> watching the IP multicast is not to replace IP multicast, but
> to optimize delivery of IP data multicast within a campus. If
> there was a very high volume multicast application that was
> only being received by one listener, RBridges can ensure that
> packets for that application only get delivered to the one
> link on which there is a listener.
> 
> If we decided RBridges should ignore the issue entirely, and
> treat IP multicast like any layer 2 multicast, then all IP
> multicast packets would be flooded, through the
> ingress-RBridge tree on which they were injected, to all
> links in the campus. This would be correct behavior, in that
> multicast packets would get delivered, but it would not be
> optimal behavior, since there would be unnecessary traffic on lots of
> links. 
> 
> So this is similar to IGMP snooping switches, although it
> works differently for RBridges than it does with pure
> switches, since RBridges explicitly say the information
> (where IP listeners are for each IP multicast group, where IP
> multicast routers are) in link state information, and the
> information doesn't have to change if interior links in the
> campus go up or down (as they would with IGMP snooping
> switches, that are inferring things based on the direction
> from which they see IGMP notification messages and such).
> 
> Radia
> 

Understood.

But wouldn't that require that the RBridge not only understand
what conclusions it reached about where a given layer 3 multicast
needed to reach, but keep all of the information so that if an
IP address migrated it could recalculate?

Date: Tue, 02 May 2006 16:23:12 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2610

The purpose of the RBridge snooping on IGMP, and in general, watching 
the IP multicast is
not to replace IP multicast, but to optimize delivery of IP data 
multicast within a campus. If
there was a very high volume multicast application that was only being 
received by one listener,
RBridges can ensure that packets for that application only get delivered 
to the one link on which
there is a listener.

If we decided RBridges should ignore the issue entirely, and treat IP 
multicast like any layer 2 multicast,
then all IP multicast packets would be flooded, through the 
ingress-RBridge tree on which they were injected,
to all links in the campus. This would be correct behavior, in that 
multicast packets would get delivered,
but it would not be optimal behavior, since there would be unnecessary 
traffic on lots of links.

So this is similar to IGMP snooping switches, although it works 
differently for RBridges than it does
with pure switches, since RBridges explicitly say the information (where 
IP listeners are for each IP multicast
group, where IP multicast routers are) in link state information, and 
the information doesn't have to change
if interior links in the campus go up or down (as they would with IGMP 
snooping switches, that are
inferring things based on the direction from which they see IGMP 
notification messages and such).

Radia

Caitlin Bestler wrote:

>[email-masked] wrote:
>  
>
>>Radia,
>>
>>	I would lean toward (b).
>>
>>	In part, that is because we don't (to my knowledge)
>>have a working group consensus to necessarily include "IP multicast"
>>(as opposed to MAC multicast) awareness in RBridges.  I think
>>we need to have that consensus before we talk about including
>>any kind of IPv4/v6 addresses in RBridge advertisements.
>>
>>	We may need to have consensus on other things before we
>>do that as well - like how appropriate it is to use RBridge
>>protocols as a substitute for multicast routing protocols.
>>
>>    
>>
>It would also be inconsistent. The Multicast routing protocols
>are responsible for determining which subnets a multicast
>datagram needs to reach. The RBridge multicast support should
>take over after than point (and deal with MAC multicast only).
>
>  
>
>>	But my leaning is also because we can be more
>>consistent in storing MAC layer reachability if we are being
>>consistent and only advertising MAC layer reachability in
>>RBridge protocol.
>>
>>    
>>
>
>I agree.
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Date: Tue, 02 May 2006 15:39:59 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] And what should the outer header of an IS-IS packet be?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 773

The current draft says IS-IS routing messages (for RBridges) will be 
sent to a different multicast
address than the IP router instance of IS-IS. That seems reasonable.

Another question though is what should the Ethertype be for such messages?

a) the same as IS-IS for routers?
b) a new Ethertype?
c) the same as the new Ethertype we will need assigned to indicate that 
the frame is
an RBridge-encapsulated frame?

Not even sure what the pros and cons are. Perhaps a) might freak out an 
IS-IS router...to see something
with the IS-IS Ethertype but to an unknown multicast address? If we do 
c), then we need a way of
distinguishing this as an IS-IS packet rather than an encapsulated data 
packet. If we do b), then we
eat up Ethertypes. How precious are they?

Radia

Content-class: urn:content-classes:message
Date: Tue, 2 May 2006 15:24:42 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1031

[email-masked] wrote:
> Radia,
> 
> 	I would lean toward (b).
> 
> 	In part, that is because we don't (to my knowledge)
> have a working group consensus to necessarily include "IP multicast"
> (as opposed to MAC multicast) awareness in RBridges.  I think
> we need to have that consensus before we talk about including
> any kind of IPv4/v6 addresses in RBridge advertisements.
> 
> 	We may need to have consensus on other things before we
> do that as well - like how appropriate it is to use RBridge
> protocols as a substitute for multicast routing protocols.
> 
It would also be inconsistent. The Multicast routing protocols
are responsible for determining which subnets a multicast
datagram needs to reach. The RBridge multicast support should
take over after than point (and deal with MAC multicast only).

> 	But my leaning is also because we can be more
> consistent in storing MAC layer reachability if we are being
> consistent and only advertising MAC layer reachability in
> RBridge protocol.
> 

I agree.

Date: Tue, 02 May 2006 17:23:46 -0500
From: Lucy Yong <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Importance: Normal
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses beadvertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3280

I agree with Eric that multicast MAC address is relatively spares,
therefore, no need to compress. My question is how to generate a unique
multicast MAC address? Who has the authority to generate that and base on
what rules?

Lucy
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gray, Eric
Sent: Tuesday, May 02, 2006 5:02 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses
beadvertised?

Radia,

	I would lean toward (b).

	In part, that is because we don't (to my knowledge) have
a working group consensus to necessarily include "IP multicast"
(as opposed to MAC multicast) awareness in RBridges.  I think 
we need to have that consensus before we talk about including 
any kind of IPv4/v6 addresses in RBridge advertisements. 

	We may need to have consensus on other things before we 
do that as well - like how appropriate it is to use RBridge
protocols as a substitute for multicast routing protocols. 

	But my leaning is also because we can be more consistent 
in storing MAC layer reachability if we are being consistent 
and only advertising MAC layer reachability in RBridge protocol.

	In general, multicast MAC address advertisements will be
relatively sparse in comparison with unicast MAC addresses, so
using compression that only works for multicast addresses seems
to lean in the direction of optimizing for the uncommon case.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 5:31 PM
--> To: [email-masked]
--> Subject: [rbridge] Should layer 2 or layer 3 IP Multicast 
--> addresses be advertised?
--> 
--> I'm trying to write up the RBridge/IP multicast 
--> interaction. What should 
--> a Designated RBridge put into
--> its link state information regarding IP multicast listeners?
--> 
--> The possibilities are:
--> a) IPv4 multicast addresses, and IPv6 multicast addresses
--> b) layer 2 multicast addresses derived from any of the groups the 
--> RBridge has heard in
--> IGMP Notification Messages from attached endnodes.
--> c) compressed layer 2 multicast addresses (i.e., leave off 
--> the top two 
--> bytes).
--> 
--> Either works. Does anyone care? The nice thing about b) is that it 
--> doesn't have to be different information
--> for IPv4 than IPv6. The nice thing about a) is that it is a 
--> little bit 
--> less information in the case of IPv4 (but
--> more information in the case of IPv6). The nice thing about 
--> c) is that 
--> it compresses the information
--> (does IPv6 have the same block of layer 2 multicast 
--> addresses derived 
--> from IPv6 multicast addresses
--> as for IPv4 multicast addresses?)
--> 
--> If the IPv6 and IPv4 layer 2 blocks for derived multicast 
--> addresses, I'd 
--> lean towards c). But does
--> anyone else have an opinion?
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked]
http://www.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Tue, 2 May 2006 18:01:37 -0400 
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2628

Radia,

	I would lean toward (b).

	In part, that is because we don't (to my knowledge) have
a working group consensus to necessarily include "IP multicast"
(as opposed to MAC multicast) awareness in RBridges.  I think 
we need to have that consensus before we talk about including 
any kind of IPv4/v6 addresses in RBridge advertisements. 

	We may need to have consensus on other things before we 
do that as well - like how appropriate it is to use RBridge
protocols as a substitute for multicast routing protocols. 

	But my leaning is also because we can be more consistent 
in storing MAC layer reachability if we are being consistent 
and only advertising MAC layer reachability in RBridge protocol.

	In general, multicast MAC address advertisements will be
relatively sparse in comparison with unicast MAC addresses, so
using compression that only works for multicast addresses seems
to lean in the direction of optimizing for the uncommon case.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 5:31 PM
--> To: [email-masked]
--> Subject: [rbridge] Should layer 2 or layer 3 IP Multicast 
--> addresses be advertised?
--> 
--> I'm trying to write up the RBridge/IP multicast 
--> interaction. What should 
--> a Designated RBridge put into
--> its link state information regarding IP multicast listeners?
--> 
--> The possibilities are:
--> a) IPv4 multicast addresses, and IPv6 multicast addresses
--> b) layer 2 multicast addresses derived from any of the groups the 
--> RBridge has heard in
--> IGMP Notification Messages from attached endnodes.
--> c) compressed layer 2 multicast addresses (i.e., leave off 
--> the top two 
--> bytes).
--> 
--> Either works. Does anyone care? The nice thing about b) is that it 
--> doesn't have to be different information
--> for IPv4 than IPv6. The nice thing about a) is that it is a 
--> little bit 
--> less information in the case of IPv4 (but
--> more information in the case of IPv6). The nice thing about 
--> c) is that 
--> it compresses the information
--> (does IPv6 have the same block of layer 2 multicast 
--> addresses derived 
--> from IPv6 multicast addresses
--> as for IPv4 multicast addresses?)
--> 
--> If the IPv6 and IPv4 layer 2 blocks for derived multicast 
--> addresses, I'd 
--> lean towards c). But does
--> anyone else have an opinion?
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Tue, 02 May 2006 14:30:43 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1065

I'm trying to write up the RBridge/IP multicast interaction. What should 
a Designated RBridge put into
its link state information regarding IP multicast listeners?

The possibilities are:
a) IPv4 multicast addresses, and IPv6 multicast addresses
b) layer 2 multicast addresses derived from any of the groups the 
RBridge has heard in
IGMP Notification Messages from attached endnodes.
c) compressed layer 2 multicast addresses (i.e., leave off the top two 
bytes).

Either works. Does anyone care? The nice thing about b) is that it 
doesn't have to be different information
for IPv4 than IPv6. The nice thing about a) is that it is a little bit 
less information in the case of IPv4 (but
more information in the case of IPv6). The nice thing about c) is that 
it compresses the information
(does IPv6 have the same block of layer 2 multicast addresses derived 
from IPv6 multicast addresses
as for IPv4 multicast addresses?)

If the IPv6 and IPv4 layer 2 blocks for derived multicast addresses, I'd 
lean towards c). But does
anyone else have an opinion?

Radia

Content-class: urn:content-classes:message
Date: Mon, 1 May 2006 13:12:10 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] IETF Meeting Survey
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 227

Hi,

If you have any feedback on IETF meetings, please go to
http://www.surveymonkey.com/s.asp?u=649182049947
where there is a short survey that focuses primarily, but 
not exclusively, on the Dallas meeting.

Thanks,
Donald