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

[Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)]

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


Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4OJVqR21547 for <[e-mail]>; Wed, 24 May 2006 12:31:53 -0700 (PDT)
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k4OJVqQi023216 for <[e-mail]>; Wed, 24 May 2006 12:31:52 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4OJVp4d021587 for <[e-mail]>; Wed, 24 May 2006 14:31:51 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 May 2006 15:31:50 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Document cut off dates for the July IETF meeting
Thread-Index: AcZ/aLQ9bWBl0kUtQlS6UtcL/uZqcA==
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k4OJVqR21547
Subject: [rbridge] Document cut off dates for the July IETF meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2006 19:32:16 -0000
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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4FCjpB05186 for <[e-mail]>; Mon, 15 May 2006 05:45:51 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k4FCj8LB017429; Mon, 15 May 2006 08:45:08 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22133;  Mon, 15 May 2006 08:45:08 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <K7B0WVFZ>; Mon, 15 May 2006 08:45:07 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>
Date: Mon, 15 May 2006 08:45:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2006 14:55:17 -0000
Status: RO
Content-Length: 4173

Radia,

	Please see below.

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Sunday, May 14, 2006 12:24 PM
--> To: Russ White
--> Cc: [e-mail]
--> 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
--> >
--> >- --
--> >[e-mail] 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
--> >[e-mail]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4EGNgB04106 for <[e-mail]>; Sun, 14 May 2006 09:23:42 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 14 May 2006 09:23:35 -0700 (PDT)
Received: from sun.com ([129.150.20.236]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Sun, 14 May 2006 09:23:35 -0700 (PDT)
Date: Sun, 14 May 2006 09:23:38 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Russ White <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 14 May 2006 16:25:37 -0000
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
>
>- --
>[e-mail] 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
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4EEJfB00374 for <[e-mail]>; Sun, 14 May 2006 07:19:41 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by test-iport-3.cisco.com with ESMTP; 14 May 2006 07:19:35 -0700
Received: from [10.82.224.207] (rtp-vpn1-207.cisco.com [10.82.224.207]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4EEJYvF015428;  Sun, 14 May 2006 10:19:34 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sun, 14 May 2006 10:19:27 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Dino Farinacci <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 14 May 2006 16:04:28 -0000
Status: RO
Content-Length: 781

-----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

- --
[e-mail] 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-----


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4CHjvx06014 for <[e-mail]>; Fri, 12 May 2006 10:45:57 -0700 (PDT)
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 12 May 2006 10:45:07 -0700
X-IronPort-AV: i="4.05,122,1146466800";  d="scan'208"; a="1805258180:sNHT1655625790"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4CHj6jC026603;  Fri, 12 May 2006 10:45:06 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4CHj6Jj016831; Fri, 12 May 2006 10:45:06 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k4CHj6ub017609; Fri, 12 May 2006 10:45:06 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k4CHj6Ck017605; Fri, 12 May 2006 10:45:06 -0700
Date: Fri, 12 May 2006 10:45:06 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ White on Fri, 12 May 2006 13:42:24 -0400)
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=219; t=1147455906; x=1148319906; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dino=20Farinacci=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Encapsulation=20of=20RBridge=20IS-IS=20routing=20mes sages; X=v=3Dcisco.com=3B=20h=3DN9goOtsUiWXqYLloLFIjpv2mMhY=3D; b=jWpYxANEhQbR4swQTQ6bL8OdZLffm8Pp8bx0u94YH/9il9S/6P7COrEvsBjQ/oEeXHkqe/AC z0Za1S27Hr8VNsPPsHUmQuwPCFNyXWzkyH2wZiF1XuvF4q5wpqHBLZxK;
Authentication-Results: sj-dkim-6.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 17:46:17 -0000
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


Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4CHgXx04490 for <[e-mail]>; Fri, 12 May 2006 10:42:34 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2006 13:42:28 -0400
X-IronPort-AV: i="4.05,122,1146456000";  d="scan'208"; a="88456466:sNHT27888216"
Received: from [10.82.241.3] (rtp-vpn2-259.cisco.com [10.82.241.3]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4CHgRvF001003;  Fri, 12 May 2006 13:42:27 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 12 May 2006 13:42:24 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Dino Farinacci <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 17:43:12 -0000
Status: RO
Content-Length: 1190

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>     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

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEZMj/ER27sUhU9OQRApaRAKCbsCrQji4f93yepgqsbDCssV5z6ACffsUn
LNM9npMBF5WJyxXsLY2Q1x0=
=PMAt
-----END PGP SIGNATURE-----


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4CFhkx10579 for <[e-mail]>; Fri, 12 May 2006 08:43:46 -0700 (PDT)
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 12 May 2006 08:43:41 -0700
X-IronPort-AV: i="4.05,122,1146466800";  d="scan'208"; a="275858284:sNHT28523008"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4CFhfwS010913;  Fri, 12 May 2006 08:43:41 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4CFhesF026877; Fri, 12 May 2006 08:43:40 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k4CFhe90020010; Fri, 12 May 2006 08:43:40 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k4CFheZg020006; Fri, 12 May 2006 08:43:40 -0700
Date: Fri, 12 May 2006 08:43:40 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ White on Fri, 12 May 2006 08:25:36 -0400)
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=702; t=1147448621; x=1148312621; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dino=20Farinacci=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Encapsulation=20of=20RBridge=20IS-IS=20routing=20mes sages; X=v=3Dcisco.com=3B=20h=3DN9goOtsUiWXqYLloLFIjpv2mMhY=3D; b=nWdm/ZyHGmR+BwEPW7hITBNet9mPUn7IJgCNYuNbvJri3BeKqHPMfz+2ZaJcSC8ilhnLrUGJ 1vp5yTOEsMK+HITNDv2VpiUdbHrtnbgTfgNHtdwFjWvCRs4yyIs+o9B1;
Authentication-Results: sj-dkim-6.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 15:44:19 -0000
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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4CFSTx03015 for <[e-mail]>; Fri, 12 May 2006 08:28:29 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k4CFSJLB018717; Fri, 12 May 2006 11:28:19 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17189;  Fri, 12 May 2006 11:28:18 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMWV36>; Fri, 12 May 2006 11:28:18 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Russ White <[e-mail]>, Dino Farinacci <[e-mail]>
Date: Fri, 12 May 2006 11:28:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 15:29:13 -0000
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: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Russ White
--> Sent: Friday, May 12, 2006 8:26 AM
--> To: Dino Farinacci
--> Cc: [e-mail]; [e-mail]
--> 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
--> 
--> - --
--> [e-mail] 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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4CCPkx13507 for <[e-mail]>; Fri, 12 May 2006 05:25:46 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2006 08:25:41 -0400
X-IronPort-AV: i="4.05,121,1146456000";  d="scan'208"; a="88427205:sNHT29318780"
Received: from [10.82.241.3] (rtp-vpn2-259.cisco.com [10.82.241.3]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4CCPdvF024929;  Fri, 12 May 2006 08:25:39 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 12 May 2006 08:25:36 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Dino Farinacci <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 12:26:16 -0000
Status: RO
Content-Length: 2055

-----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

- --
[e-mail] 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-----


Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4C4n0x05233 for <[e-mail]>; Thu, 11 May 2006 21:49:00 -0700 (PDT)
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 11 May 2006 21:48:56 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4C4ms5Q011231;  Thu, 11 May 2006 21:48:54 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4C4mssF000776; Thu, 11 May 2006 21:48:54 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k4C4ms6J013006; Thu, 11 May 2006 21:48:54 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k4C4ms0W013002; Thu, 11 May 2006 21:48:54 -0700
Date: Thu, 11 May 2006 21:48:54 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Thu, 11 May 2006 19:42:49 -0700)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=681; t=1147409334; x=1148273334; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dino=20Farinacci=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Encapsulation=20of=20RBridge=20IS-IS=20routing=20mes sages; X=v=3Dcisco.com=3B=20h=3DN9goOtsUiWXqYLloLFIjpv2mMhY=3D; b=ENzJ0bKHit3OHpaTQTJW9rHuNQqfRwJTI6UhNCMOUlFRO4RrscnHJx8kB/dOPFq+Z+7xNJYs HXI6Zku4kCNn7Jxe+h6gxmJGbqr6Cj7/ZYxOmzxNDjEA9AmQvzQzIEqU;
Authentication-Results: sj-dkim-8.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 04:50:11 -0000
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


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4C4mgx05142 for <[e-mail]>; Thu, 11 May 2006 21:48:43 -0700 (PDT)
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 May 2006 21:48:02 -0700
X-IronPort-AV: i="4.05,117,1146466800";  d="scan'208"; a="275615736:sNHT94302818"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4C4m18i003179;  Thu, 11 May 2006 21:48:01 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4C4m1sF000568; Thu, 11 May 2006 21:48:01 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k4C4m18U012972; Thu, 11 May 2006 21:48:01 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k4C4m0GT012968; Thu, 11 May 2006 21:48:00 -0700
Date: Thu, 11 May 2006 21:48:00 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Thu, 11 May 2006 19:18:24 -0700)
References: <[e-mail]> <[e-mail]> <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=1239; t=1147409281; x=1148273281; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dino=20Farinacci=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Encapsulation=20of=20RBridge=20IS-IS=20routing=20mes sages; X=v=3Dcisco.com=3B=20h=3DN9goOtsUiWXqYLloLFIjpv2mMhY=3D; b=FOaPjgCxuyGU6rzShAePXKPWluP4hhqTR+T6urddtz9F+VQ9YKPK4s4YyiE7Udc9epaMbNM4 0qPmG+5u0nsctfNa2Mc382s2XijvKrY4yMDPB44LuSpxQhT8L+HlROHt;
Authentication-Results: sj-dkim-6.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 04:49:08 -0000
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

    


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4C2gsx15279 for <[e-mail]>; Thu, 11 May 2006 19:42:54 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 11 May 2006 19:42:49 -0700 (PDT)
Received: from sun.com ([129.150.23.189]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 11 May 2006 19:42:49 -0700 (PDT)
Date: Thu, 11 May 2006 19:42:49 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Radia Perlman <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 02:43:04 -0000
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
>>
>>
>>     
>>
>



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4C2IYx06307 for <[e-mail]>; Thu, 11 May 2006 19:18:34 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 11 May 2006 19:18:25 -0700 (PDT)
Received: from sun.com ([129.150.23.189]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 11 May 2006 19:18:23 -0700 (PDT)
Date: Thu, 11 May 2006 19:18:24 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Dino Farinacci <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 02:19:02 -0000
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
>
>
>    
>  
>



Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4C0Ddx17468 for <[e-mail]>; Thu, 11 May 2006 17:13:39 -0700 (PDT)
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 11 May 2006 17:13:34 -0700
X-IronPort-AV: i="4.05,117,1146466800";  d="scan'208"; a="275535711:sNHT29295828"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4C0DXiA017650;  Thu, 11 May 2006 17:13:33 -0700
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4C0DXsF027331; Thu, 11 May 2006 17:13:33 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k4C0DXYC000902; Thu, 11 May 2006 17:13:33 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k4C0DXTQ000898; Thu, 11 May 2006 17:13:33 -0700
Date: Thu, 11 May 2006 17:13:33 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Wed, 10 May 2006 18:50:56 -0700)
References: <[e-mail]>
DKIM-Signature: a=rsa-sha1; q=dns; l=769; t=1147392813; x=1148256813; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:Dino=20Farinacci=20<[e-mail]> |Subject:Re=3A=20[rbridge]=20Encapsulation=20of=20RBridge=20IS-IS=20routing=20mes sages; X=v=3Dcisco.com=3B=20h=3DN9goOtsUiWXqYLloLFIjpv2mMhY=3D; b=E0Tco9e5/6pp6Zv1eLJ0QZ/dQIY+jgdlD8X0ggB7Tl8NTxv1vQuV8EUzj5YeBN3dZSLdpsQ+ z5YWPrDPC1H0qJm8Y2TIRBMVO/KZOBm1sWDuOWc/4H9CkmGXuC/eGa9Y;
Authentication-Results: sj-dkim-8.cisco.com; header.From=[e-mail]; dkim=pass ( sig from cisco.com verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2006 00:14:04 -0000
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


    


Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BMdcx01603 for <[e-mail]>; Thu, 11 May 2006 15:39:38 -0700 (PDT)
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2006 15:39:31 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,117,1146466800";  d="scan'208"; a="27863638:sNHT21205980"
Received: from [10.82.240.107] (rtp-vpn2-107.cisco.com [10.82.240.107]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4BMdUTL022967;  Thu, 11 May 2006 18:39:30 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 11 May 2006 18:39:28 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2006 22:39:58 -0000
Status: RO
Content-Length: 1034

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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


- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEY70gER27sUhU9OQRAtuLAKD6rrdeM0r9GyhULxhmNVOLID0PIQCglPFU
LaPISH6+6fmNlDNa6w23ZA8=
=8zmG
-----END PGP SIGNATURE-----


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4B1p3x26234 for <[e-mail]>; Wed, 10 May 2006 18:51:03 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 10 May 2006 18:50:57 -0700 (PDT)
Received: from sun.com ([129.150.25.62]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 10 May 2006 18:50:56 -0700 (PDT)
Date: Wed, 10 May 2006 18:50:56 -0700
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Encapsulation of RBridge IS-IS routing messages
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2006 01:51:38 -0000
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





Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k490iUx05342 for <[e-mail]>; Mon, 8 May 2006 17:44:30 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k48LOrIH025968;  Mon, 8 May 2006 15:24:53 -0600 (MDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k48LOoOr591835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 8 May 2006 14:24:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 08 May 2006 14:24:50 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 09 May 2006 00:44:51 -0000
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



Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48Ltbx16894 for <[e-mail]>; Mon, 8 May 2006 14:55:37 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 May 2006 14:55:32 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,103,1146466800";  d="scan'208"; a="27602501:sNHT22027144"
Received: from [10.82.240.111] (rtp-vpn2-111.cisco.com [10.82.240.111]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k48LtSvF008370;  Mon, 8 May 2006 17:55:31 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 08 May 2006 17:55:26 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Gray, Eric" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 22:05:53 -0000
Status: RO
Content-Length: 2346

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> --> > 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

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEX75OER27sUhU9OQRAt51AJ9W2cJjNfAYs4spWgNPk3oksnqyHgCfViHE
+U1bA/uM4crigR2FXGa4qLw=
=6jDP
-----END PGP SIGNATURE-----


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48Ks9x18601 for <[e-mail]>; Mon, 8 May 2006 13:54:10 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k48Ks3x4004111; Mon, 8 May 2006 16:54:04 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04035;  Mon, 8 May 2006 16:54:04 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMR7JW>; Mon, 8 May 2006 16:54:03 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Erik Nordmark <[e-mail]>, Radia Perlman <[e-mail]>
Date: Mon, 8 May 2006 16:54:02 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 20:54:55 -0000
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: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Erik Nordmark
--> Sent: Monday, May 08, 2006 4:29 PM
--> To: Radia Perlman
--> Cc: [e-mail]
--> 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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48KSXx06778 for <[e-mail]>; Mon, 8 May 2006 13:28:33 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k48KSXaN008144 for <[e-mail]>; Mon, 8 May 2006 13:28:33 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k48KSWfV549014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 8 May 2006 13:28:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 08 May 2006 13:28:32 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 20:28:55 -0000
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


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48K4qx26441 for <[e-mail]>; Mon, 8 May 2006 13:04:55 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k48K4ax4002930; Mon, 8 May 2006 16:04:36 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28954;  Mon, 8 May 2006 16:04:36 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMR5VS>; Mon, 8 May 2006 16:04:35 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Radia Perlman <[e-mail]>
Date: Mon, 8 May 2006 16:04:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 20:05:55 -0000
Status: RO
Content-Length: 4805

Radia,

	Please see below...

--
Eric

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Monday, May 08, 2006 12:38 PM
--> To: [e-mail]
--> 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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48JSWx11302 for <[e-mail]>; Mon, 8 May 2006 12:28:33 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k48JSFx4001836; Mon, 8 May 2006 15:28:15 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24570;  Mon, 8 May 2006 15:28:15 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMRZJZ>; Mon, 8 May 2006 15:28:13 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Dino Farinacci <[e-mail]>
Date: Mon, 8 May 2006 15:28:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 19:28:48 -0000
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: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Dino Farinacci
--> Sent: Thursday, May 04, 2006 8:11 PM
--> To: [e-mail]
--> Cc: [e-mail]
--> 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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48Gbmx18707 for <[e-mail]>; Mon, 8 May 2006 09:37:48 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 08 May 2006 09:37:43 -0700 (PDT)
Received: from sun.com ([129.150.26.215]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 08 May 2006 09:37:43 -0700 (PDT)
Date: Mon, 08 May 2006 09:37:42 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 16:38:44 -0000
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




Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k48Do4x22629 for <[e-mail]>; Mon, 8 May 2006 06:50:04 -0700 (PDT)
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 May 2006 09:49:58 -0400
X-IronPort-AV: i="4.05,102,1146456000";  d="scan'208"; a="88092248:sNHT29671304"
Received: from [10.82.240.111] (rtp-vpn2-111.cisco.com [10.82.240.111]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k48DnvTL010707;  Mon, 8 May 2006 09:49:57 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 08 May 2006 09:49:55 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 13:50:58 -0000
Status: RO
Content-Length: 3122

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEX0yDER27sUhU9OQRAlPuAJ9gn5Rj3jQ/Qi2ORQXM0PetXAnddACeIrnI
jFVK+yeh2lepiLd+U8pB0Dk=
=HqNy
-----END PGP SIGNATURE-----


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k484Qsx06335 for <[e-mail]>; Sun, 7 May 2006 21:26:54 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sun, 07 May 2006 21:26:47 -0700 (PDT)
Received: from sun.com ([129.150.26.215]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Sun, 07 May 2006 21:26:45 -0700 (PDT)
Date: Sun, 07 May 2006 21:26:44 -0700
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Summary of layer 2 multicast stuff
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2006 04:27:36 -0000
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



Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k45IueN29262 for <[e-mail]>; Fri, 5 May 2006 11:56:40 -0700 (PDT)
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 May 2006 11:56:35 -0700
X-IronPort-AV: i="4.05,93,1146466800";  d="scan'208"; a="273238753:sNHT26487892"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k45IuYYg008804; Fri, 5 May 2006 11:56:34 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k45IuYa2019836; Fri, 5 May 2006 11:56:34 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k45IuYCK019832; Fri, 5 May 2006 11:56:34 -0700
Date: Fri, 5 May 2006 11:56:34 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ White on Fri, 05 May 2006 09:27:07 -0400)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2006 18:57:29 -0000
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


Received: from postal2.belairnetworks.com (Belair-gw.telecomottawa.net [142.46.200.242] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k45Ei5N06562 for <[e-mail]>; Fri, 5 May 2006 07:44:05 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 5 May 2006 10:43:50 -0400
Message-ID: <B3785208FF6119459354E44B555ADC0ADD6046@POSTAL2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Should layer 2 or layer 3 IP Multicast addresses beadvertised?
Thread-Index: AcZv4ryylJm+4FZSRMSLYq1XOWBrIAAYMAbw
From: "Jeff Joslin" <[e-mail]>
To: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k45Ei5N06562
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses beadvertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2006 14:44:36 -0000
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




Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k45DRKN03940 for <[e-mail]>; Fri, 5 May 2006 06:27:20 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 May 2006 06:27:10 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,93,1146466800";  d="scan'208"; a="27416512:sNHT7206065238"
Received: from [10.82.226.239] (rtp-vpn1-751.cisco.com [10.82.226.239]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k45DR9vF002909;  Fri, 5 May 2006 09:27:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 05 May 2006 09:27:07 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Dino Farinacci <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2006 13:28:29 -0000
Status: RO
Content-Length: 2515

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>     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

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEW1KrER27sUhU9OQRAlXnAJ9OCO81qKG5T8MYoTD6Bw3rUzrPpQCfaSup
Q2CvkLNkD5Mmn1xwX8edujc=
=jRnb
-----END PGP SIGNATURE-----


Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k451DhN10308 for <[e-mail]>; Thu, 4 May 2006 18:13:43 -0700 (PDT)
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 May 2006 03:13:38 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k451DZUE004134 for <[e-mail]>; Fri, 5 May 2006 03:13:36 +0200 (MEST)
Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA17822 for [e-mail]; Fri, 5 May 2006 02:13:35 +0100 (BST)
Date: Fri, 5 May 2006 02:13:35 +0100
From: Derek Fawcus <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, May 03, 2006 at 11:19:08AM -0400
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2006 01:14:20 -0000
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


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k450B1N13837 for <[e-mail]>; Thu, 4 May 2006 17:11:01 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 17:10:56 -0700
X-IronPort-AV: i="4.05,90,1146466800";  d="scan'208"; a="272934279:sNHT23367484"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k450AuVI017711; Thu, 4 May 2006 17:10:56 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k450Auq0027673; Thu, 4 May 2006 17:10:56 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k450AukF027669; Thu, 4 May 2006 17:10:56 -0700
Date: Thu, 4 May 2006 17:10:56 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ White on Thu, 04 May 2006 08:54:26 -0400)
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2006 00:11:28 -0000
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


Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k44CsdN02512 for <[e-mail]>; Thu, 4 May 2006 05:54:39 -0700 (PDT)
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 May 2006 08:54:34 -0400
X-IronPort-AV: i="4.05,87,1146456000"; d="scan'208"; a="87870594:sNHT30443560"
Received: from [10.82.216.227] (rtp-vpn3-227.cisco.com [10.82.216.227]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k44CsXvF023855 for <[e-mail]>; Thu, 4 May 2006 08:54:34 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 04 May 2006 08:54:26 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2006 12:55:10 -0000
Status: RO
Content-Length: 2453

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



> 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

- --
[e-mail] CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEWfmCER27sUhU9OQRAmIaAKDByFitEV4aKyUzjGfx/Q9uu037wgCfbh11
MjLTM3rbc3IE9FOQNl+QKVY=
=vNZf
-----END PGP SIGNATURE-----


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43L3PN28696 for <[e-mail]>; Wed, 3 May 2006 14:03:25 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 03 May 2006 14:03:20 -0700
X-IronPort-AV: i="4.05,85,1146466800";  d="scan'208"; a="1801091012:sNHT25462142"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k43L3KVI018135; Wed, 3 May 2006 14:03:20 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k43L3KIr019196; Wed, 3 May 2006 14:03:20 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k43L3KYp019192; Wed, 3 May 2006 14:03:20 -0700
Date: Wed, 3 May 2006 14:03:20 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Ether-type question (was RE: And what should the outer header of an IS-IS packet be?)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 21:03:55 -0000
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


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43KVmN17270 for <[e-mail]>; Wed, 3 May 2006 13:31:48 -0700 (PDT)
Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43KUhV17248; Wed, 3 May 2006 13:30:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 03 May 2006 13:30:38 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Mailing list reply-to insertion
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 20:32:59 -0000
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
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43I0eN12648 for <[e-mail]>; Wed, 3 May 2006 11:00:40 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k43I0bUm020472;  Wed, 3 May 2006 11:00:37 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k43I0ZJq135052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 May 2006 11:00:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 03 May 2006 11:00:01 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Mailing list reply-to insertion
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 18:00:56 -0000
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




Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43HcgN02245 for <[e-mail]>; Wed, 3 May 2006 10:38:42 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.56.144]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k43HcfrM008485 for <[e-mail]>; Wed, 3 May 2006 10:38:42 -0700 (PDT)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k43HceNQ123468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 May 2006 10:38:41 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 03 May 2006 10:38:07 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20060113)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Out of date milestones
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 17:38:51 -0000
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





Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43FJKV25260 for <[e-mail]>; Wed, 3 May 2006 08:19:21 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k43FJFx4019615 for <[e-mail]>; Wed, 3 May 2006 11:19:15 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04690 for <[e-mail]>; Wed, 3 May 2006 11:19:15 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMMFL3>; Wed, 3 May 2006 11:19:14 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Wed, 3 May 2006 11:19:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 15:19:52 -0000
Status: RO
Content-Length: 3462

Radia,

	Please see below... 

--> -----Original Message-----
--> From: [e-mail] 
--> [mailto:[e-mail]] 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] ---


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43ELNV27717 for <[e-mail]>; Wed, 3 May 2006 07:21:23 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k43ELGx4017695; Wed, 3 May 2006 10:21:17 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26504;  Wed, 3 May 2006 10:21:16 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMMC65>; Wed, 3 May 2006 10:21:16 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: Dino Farinacci <[e-mail]>
Date: Wed, 3 May 2006 10:21:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: [rbridge] Ether-type question (was RE: And what should the outer header of an IS-IS packet be?)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 14:21:36 -0000
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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k43DvvV17803 for <[e-mail]>; Wed, 3 May 2006 06:57:57 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k43Dvqx4017085 for <[e-mail]>; Wed, 3 May 2006 09:57:52 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23691 for <[e-mail]>; Wed, 3 May 2006 09:57:51 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMMB0B>; Wed, 3 May 2006 09:57:50 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Wed, 3 May 2006 09:57:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 13:58:42 -0000
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: [e-mail] 
--> [mailto:[e-mail]] 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:
--> 
--> >[e-mail] 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
--> >[e-mail]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k437gPV01290 for <[e-mail]>; Wed, 3 May 2006 00:42:25 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 53201954D9 for <[e-mail]>; Wed,  3 May 2006 09:42:19 +0200 (CEST)
Received: from [163.117.203.109] (unknown [163.117.203.109]) by smtp02.uc3m.es (Postfix) with ESMTP id 5992D954D0 for <[e-mail]>; Wed,  3 May 2006 09:42:18 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 03 May 2006 09:42:16 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[e-mail]>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 07:43:44 -0000
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
>>			 [e-mail]
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>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



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k436CkV28586 for <[e-mail]>; Tue, 2 May 2006 23:12:46 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 02 May 2006 23:12:41 -0700 (PDT)
Received: from sun.com ([129.150.27.108]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 02 May 2006 23:12:41 -0700 (PDT)
Date: Tue, 02 May 2006 23:12:41 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 06:13:45 -0000
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
>			 [e-mail]
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k433RuV01172 for <[e-mail]>; Tue, 2 May 2006 20:27:56 -0700 (PDT)
Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Fb81m-0002D7-00 for <[e-mail]>; Tue, 02 May 2006 23:27:50 -0400
From: Tim Shepard <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-reply-to: Your message of Tue, 02 May 2006 14:30:43 -0700. <[e-mail]> 
Date: Tue, 02 May 2006 23:27:50 -0400
Message-Id: <[e-mail]>
Sender: Tim Shepard <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 03:28:27 -0000
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
			 [e-mail]


Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k432AuV09029 for <[e-mail]>; Tue, 2 May 2006 19:10:57 -0700 (PDT)
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 19:10:51 -0700
X-IronPort-AV: i="4.05,81,1146466800";  d="scan'208"; a="1800799815:sNHT26924804"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k432ApVI015111 for <[e-mail]>; Tue, 2 May 2006 19:10:51 -0700 (PDT)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k432App8026898 for <[e-mail]>; Tue, 2 May 2006 19:10:51 -0700
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id k432ApWa026894; Tue, 2 May 2006 19:10:51 -0700
Date: Tue, 2 May 2006 19:10:51 -0700
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Tue, 02 May 2006 15:39:59 -0700)
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] And what should the outer header of an IS-IS packet be?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 02:11:27 -0000
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

    


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k431KjV23434 for <[e-mail]>; Tue, 2 May 2006 18:20:45 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 02 May 2006 18:20:39 -0700 (PDT)
Received: from sun.com ([129.150.27.108]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 02 May 2006 18:20:39 -0700 (PDT)
Date: Tue, 02 May 2006 18:20:39 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2006 01:21:35 -0000
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



Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42Nn5V24440 for <[e-mail]>; Tue, 2 May 2006 16:49:05 -0700 (PDT)
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 02 May 2006 16:48:53 -0700
X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B887D2AF; Tue, 2 May 2006 16:48:53 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 957D32AE for <[e-mail]>; Tue, 2 May 2006 16:48:53 -0700 (PDT)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DKW55871; Tue, 2 May 2006 16:48:53 -0700 (PDT)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 47CB220501 for <[e-mail]>; Tue, 2 May 2006 16:48:53 -0700 ( PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 2 May 2006 16:48:47 -0700
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Thread-Index: AcZuQSXC/tNNKhD6QWu6TCPeQLc2qwAAYrtQ
From: "Caitlin Bestler" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050207; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34343537454531412E303032412D412D; ENG=IBF; TS=20060502234854; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006050207_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 6849306F4I85216154-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k42Nn5V24440
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 23:49:37 -0000
Status: RO
Content-Length: 1695

[e-mail] 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?



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42NNHV16059 for <[e-mail]>; Tue, 2 May 2006 16:23:17 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 02 May 2006 16:23:12 -0700 (PDT)
Received: from sun.com ([129.150.27.108]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 02 May 2006 16:23:12 -0700 (PDT)
Date: Tue, 02 May 2006 16:23:12 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 23:23:30 -0000
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:

>[e-mail] 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
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42Me5V00943 for <[e-mail]>; Tue, 2 May 2006 15:40:05 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 02 May 2006 15:39:59 -0700 (PDT)
Received: from sun.com ([129.150.27.108]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 02 May 2006 15:39:59 -0700 (PDT)
Date: Tue, 02 May 2006 15:39:59 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] And what should the outer header of an IS-IS packet be?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 22:40:31 -0000
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



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42MPCV26018 for <[e-mail]>; Tue, 2 May 2006 15:25:12 -0700 (PDT)
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 02 May 2006 15:24:56 -0700
X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 097CC2AE; Tue, 2 May 2006 15:24:55 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 52F742B4 for <[e-mail]>; Tue, 2 May 2006 15:24:48 -0700 (PDT)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DKW24161; Tue, 2 May 2006 15:24:48 -0700 (PDT)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 13C1A20501 for <[e-mail]>; Tue, 2 May 2006 15:24:48 -0700 ( PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 2 May 2006 15:24:42 -0700
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
Thread-Index: AcZuNmEboxmmULOyQoOrTKRtksJ1PgAAHvCw
From: "Caitlin Bestler" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050206; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343537444136462E303030332D412D; ENG=IBF; TS=20060502222459; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006050206_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 684903B23NG12140761-01-01
Content-Type: text/plain; charset=us-ascii
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k42MPCV26018
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 22:25:34 -0000
Status: RO
Content-Length: 1031

[e-mail] 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.



Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42MNuV25578 for <[e-mail]>; Tue, 2 May 2006 15:23:56 -0700 (PDT)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 02 May 2006 15:20:42 -0700 (PDT)
Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 02 May 2006 15:20:41 -0700 (PDT)
Date: Tue, 02 May 2006 17:23:46 -0500
From: Lucy Yong <[e-mail]>
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <001c01c66e37$14886ea0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses beadvertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 22:24:37 -0000
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: [e-mail] [mailto:[e-mail]] 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: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 5:31 PM
--> To: [e-mail]
--> 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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge




Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42M1jV17084 for <[e-mail]>; Tue, 2 May 2006 15:01:45 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k42M1dx4001075 for <[e-mail]>; Tue, 2 May 2006 18:01:39 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08635 for <[e-mail]>; Tue, 2 May 2006 18:01:39 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <J3ZMLKKY>; Tue, 2 May 2006 18:01:39 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Date: Tue, 2 May 2006 18:01:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be	 advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 22:02:38 -0000
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: [e-mail] 
--> [mailto:[e-mail]] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 5:31 PM
--> To: [e-mail]
--> 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
--> [e-mail]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 


Received: from mail-mta.sunlabs.com (dyn50.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k42LUoV06059 for <[e-mail]>; Tue, 2 May 2006 14:30:50 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 02 May 2006 14:30:44 -0700 (PDT)
Received: from sun.com ([129.150.27.108]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 02 May 2006 14:30:44 -0700 (PDT)
Date: Tue, 02 May 2006 14:30:43 -0700
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2006 21:31:27 -0000
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



Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k41HCCQ28756 for <[e-mail]>; Mon, 1 May 2006 10:12:12 -0700 (PDT)
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k41HT6id022448 for <[e-mail]>; Mon, 1 May 2006 10:29:07 -0700 (MST)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k41HTL5L014579 for <[e-mail]>; Mon, 1 May 2006 12:29:21 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 1 May 2006 13:12:10 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF Meeting Survey
Thread-Index: AcZtM1obVRsNWSF8R2GkKAK0xhY9RgADqULA
From: "Eastlake III Donald-LDE008" <[e-mail]>
To: <[e-mail]>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id k41HCCQ28756
Subject: [rbridge] IETF Meeting Survey
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2006 17:12:57 -0000
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