[rbridge] Shared VLAN learning: What is it and why should we care?

[Radia.Perlman at sun.com (Radia Perlman)]

I don't understand a lot of what's being said on this thread, and I 
suspect everyone is
talking about subtly different solutions to a fairly esoteric set of 
somewhat related problems (sharing
an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, 
...). As Dale Carder mentioned,
and gave us some pointers, there are several somewhat overlapping 
proposals floating around the industry.
I believe there isn't a single cleanly stated problem, or a single 
cleanly statable solution.

So TRILL should do something. Whatever it is, I want to be able to 
understand what it is that RBridges should do.

But to answer Russ's questions (see at bottom of this note) -- the 
current RBridge protocol
spec assumes that *all* RBridges filter based on VLAN tag.
So an RBridge in the core, even if it doesn't attach to VLAN A, knows 
which other RBridges do. This
allows efficient distribution of VLAN A traffic, for instance, the IS-IS 
announcements of VLAN A endnode
information.

The reason we need to let all the RBridges know what VLANs are in a 
group, say {Z, A, B, C, D},
where Z is the primary, is so that an RBridge in
the core knows that something tagged with VLAN Z needs to be transmitted 
to all links in any of the
5 VLAN tags {Z, A, B, C, D} and something tagged with one of the 
secondaries, say A, needs to go to
A and Z.

An example -- suppose there is an IP router R on VLAN Z (the primary). 
When R does an ARP for an
endnode "d" in the IP subnet, R has no idea about VLANs, and the RBridge 
RB1 that R attaches to, although
RB1 might know that there's a grouping of VLANs, doesn't know which VLAN 
to transmit the ARP to.
Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a 
copy to each of {Z, A, B, C, D}.

So RBridges in the core have to know to send the ARP along the 
distribution tree to all ports that are
in any of the VLANs in the set.

In theory we could ignore VLAN tags, except at the final hop, and then, 
as Russ said, it
would be just an optimization for the RBridges in the core to know about
the groupings. But I still think things would be weird
if the final RBridges had inconsistent configurations of the VLAN 
groupings, so I think it's a good idea to
make sure all the RBridges agree on the groupings.

To summarize, it's good for them to agree because of three reasons:
a) we can do optimal delivery of multicasts, filtering within the core 
rather than just at the final hop
b) we detect misconfiguration
c) we allow more central configuration (we don't need to configure all 
the RBridges, though that's a bit
dangerous if all the RBridges that have been configured go down, since 
suddenly the groupings might disappear)

Radia



As for Russ's last questions:

>> 3. Does this have a larger impact on multicast, or smaller?

I don't understand the question, though given that he put a smiley face in, perhaps
it was a joke. I'm hoping that someone, tomorrow, will inform me that all this
SVL/FID stuff was a joke...

Radia




Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>  
>
>>To avoid requiring configuration of all RBridges with these FIDs, and
>>still allow multicast filtering, I propose we have RBridges advertise,
>>in their IS-IS core instance, FIDs that they are configured with. So at 
>>least one RBridge will say "Hey guys,
>>I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other 
>>RBridges will, I guess
>>believe him.
>>    
>>
>
>I'm trying to sort through this entire thing, and I wanted to ask:
>
>1. The reason we'd want to configure this on all rbridges would be to
>optimize traffic flow?
>
>2. If 1 is true, and we didn't do the configuration on all rbridges, how
>much less efficient would the rbridge network be?
>
>3. Does this have a larger impact on multicast, or smaller?
>
>:-)
>
>Russ
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg
>DSuMdrc10XgRmx8w4PdN/f4=
>=ItDw
>-----END PGP SIGNATURE-----
>  
>



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l316dije029839 for <[e-mail]>; Sat, 31 Mar 2007 23:39: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]; Sat, 31 Mar 2007 23:39:30 -0700 (PDT)
Received: from sun.com ([129.150.16.145]) 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]; Sat, 31 Mar 2007 23:39:29 -0700 (PDT)
Date: Sat, 31 Mar 2007 23:39:45 -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]>
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] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2007 06:40:09 -0000
Status: RO
Content-Length: 4104

I don't understand a lot of what's being said on this thread, and I 
suspect everyone is
talking about subtly different solutions to a fairly esoteric set of 
somewhat related problems (sharing
an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, 
...). As Dale Carder mentioned,
and gave us some pointers, there are several somewhat overlapping 
proposals floating around the industry.
I believe there isn't a single cleanly stated problem, or a single 
cleanly statable solution.

So TRILL should do something. Whatever it is, I want to be able to 
understand what it is that RBridges should do.

But to answer Russ's questions (see at bottom of this note) -- the 
current RBridge protocol
spec assumes that *all* RBridges filter based on VLAN tag.
So an RBridge in the core, even if it doesn't attach to VLAN A, knows 
which other RBridges do. This
allows efficient distribution of VLAN A traffic, for instance, the IS-IS 
announcements of VLAN A endnode
information.

The reason we need to let all the RBridges know what VLANs are in a 
group, say {Z, A, B, C, D},
where Z is the primary, is so that an RBridge in
the core knows that something tagged with VLAN Z needs to be transmitted 
to all links in any of the
5 VLAN tags {Z, A, B, C, D} and something tagged with one of the 
secondaries, say A, needs to go to
A and Z.

An example -- suppose there is an IP router R on VLAN Z (the primary). 
When R does an ARP for an
endnode "d" in the IP subnet, R has no idea about VLANs, and the RBridge 
RB1 that R attaches to, although
RB1 might know that there's a grouping of VLANs, doesn't know which VLAN 
to transmit the ARP to.
Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a 
copy to each of {Z, A, B, C, D}.

So RBridges in the core have to know to send the ARP along the 
distribution tree to all ports that are
in any of the VLANs in the set.

In theory we could ignore VLAN tags, except at the final hop, and then, 
as Russ said, it
would be just an optimization for the RBridges in the core to know about
the groupings. But I still think things would be weird
if the final RBridges had inconsistent configurations of the VLAN 
groupings, so I think it's a good idea to
make sure all the RBridges agree on the groupings.

To summarize, it's good for them to agree because of three reasons:
a) we can do optimal delivery of multicasts, filtering within the core 
rather than just at the final hop
b) we detect misconfiguration
c) we allow more central configuration (we don't need to configure all 
the RBridges, though that's a bit
dangerous if all the RBridges that have been configured go down, since 
suddenly the groupings might disappear)

Radia



As for Russ's last questions:

>> 3. Does this have a larger impact on multicast, or smaller?

I don't understand the question, though given that he put a smiley face in, perhaps
it was a joke. I'm hoping that someone, tomorrow, will inform me that all this
SVL/FID stuff was a joke...

Radia




Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>  
>
>>To avoid requiring configuration of all RBridges with these FIDs, and
>>still allow multicast filtering, I propose we have RBridges advertise,
>>in their IS-IS core instance, FIDs that they are configured with. So at 
>>least one RBridge will say "Hey guys,
>>I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other 
>>RBridges will, I guess
>>believe him.
>>    
>>
>
>I'm trying to sort through this entire thing, and I wanted to ask:
>
>1. The reason we'd want to configure this on all rbridges would be to
>optimize traffic flow?
>
>2. If 1 is true, and we didn't do the configuration on all rbridges, how
>much less efficient would the rbridge network be?
>
>3. Does this have a larger impact on multicast, or smaller?
>
>:-)
>
>Russ
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg
>DSuMdrc10XgRmx8w4PdN/f4=
>=ItDw
>-----END PGP SIGNATURE-----
>  
>



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UNIG8J024964 for <[e-mail]>; Fri, 30 Mar 2007 16:18:16 -0700 (PDT)
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: Fri, 30 Mar 2007 14:43:01 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
thread-index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQAAJwEQAAAMshMAACF4EQ
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Russ White" <[e-mail]>, "Radia Perlman" <[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 l2UNIG8J024964
Cc: [e-mail]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 23:18:43 -0000
Status: RO
Content-Length: 3377

Caitlin,

inline

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]]
> Sent: Friday, March 30, 2007 1:45 PM
> To: Silvano Gai; Russ White; Radia Perlman
> Cc: [e-mail]
> Subject: RE: [rbridge] Shared VLAN learning: What is it and why should
we
> care?
> 
> 
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[e-mail]]
> > Sent: Friday, March 30, 2007 1:26 PM
> > To: Caitlin Bestler; Russ White; Radia Perlman
> > Cc: [e-mail]
> > Subject: RE: [rbridge] Shared VLAN learning: What is it and
> > why should we care?
> >
> > Caitlin,
> >
> > You say:
> >
> > >
> > > The most recent drafts effectively block that, by only
distributing
> > > endnode discovery information within a VLAN.
> >
> > Can we agree that:
> > - FID is a concept internal to the box;
> > - FID is never present in any frame;
> > - The VID to FID mapping is internal to each box and
> > potentially different on different boxes;
> > - The VID to FID mapping is never propagated in today networks.
> >
> > If we have agreed the previous, let's consider what triggers
learning:
> > - In bridges the reception of a data frame with a {VID, MAC
> > address} pair;
> > - In Rbridges the reception of a per VLAN instance ISIS PDU
> > that contains a {VID, MAC address} pair.
> > I don't see any difference.
> >
> 
> Following the lines of the example Radia posted, endnode IP J MAC X
> was previously on VLAN A where RBridge S learned of its existence.
> 
> Now endnode IP J/MAC X is migrated to VLAN B where RBRidge T learns
> of its existence. This is an extremely plausible scenario where VLANs
> A and B represent logical functions within a company. Or it could be
as
> simple as someone carrying a laptop from a "secure" area to another
> area within the same buildig.
> 
> Meanwhile, Router Z receives an incoming packet with destination IP J.
> Since that is not in its ARP tables, it sends an ARP request.

On which VLAN does the router Z send the request?
It must be either A or B. The way this is decided is a longest prefix
match on IP J that returns a directly connected sub-interface. The VLAN
associated to that sub-interface is the one on which the ARP is sent.
If it is A, S replies.
If it is B, T replies.

What am I missing?

Two more points:

1) An endnode cannot move from one VLAN to another keeping its IP
address (excluding the Private VLAN case that was not under discussion
when this thread about SVL started).

2) IMHO ARP proxy in Rbridges creates more corner cases of the problem
that it solves. In Dinesh presentation from 03 to 04 there was a slide
about making it optional and separating it to another draft.

-- Silvano


 Both
> RBridge S and RBridge T, acting as PRoxy ARPs, will answer.
> 
> What is Router Z supposed to do? If it just accepts both ARP responses
> and only keeps the last one, it could easily forward the packet to
> VLAN A and thereby cause the connection to ultimately drop.
> 
> The root cause of this problem is that RBridge T did not share its
> discovery of IP J/MAC X with RBridge S, even though they are part
> of the same FID.
> 
> This can be done with exposing VID/FID mappings on the wire. You
> export an "discovery-only VID" list instead. But I do not see how it
> can be done if discovery announcements are shared exclusively
> within VIDs without exception.
> 
> 




Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UKk2nN013559 for <[e-mail]>; Fri, 30 Mar 2007 13:46:02 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 30 Mar 2007 13:45:54 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B0E732AE; Fri, 30 Mar 2007 13:45:54 -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 9A2932B4; Fri, 30 Mar 2007 13:45:53 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDC09605; Fri, 30 Mar 2007 13:45:48 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9148469CAA; Fri, 30 Mar 2007 13:45:47 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 30 Mar 2007 13:45:22 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
Thread-Index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQAAJwEQAAAMshMA==
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Russ White" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 6A13A88837010620226-04-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 l2UKk2nN013559
Cc: [e-mail]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 20:46:13 -0000
Status: RO
Content-Length: 2232

 

> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]] 
> Sent: Friday, March 30, 2007 1:26 PM
> To: Caitlin Bestler; Russ White; Radia Perlman
> Cc: [e-mail]
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> Caitlin,
> 
> You say:
> 
> > 
> > The most recent drafts effectively block that, by only distributing 
> > endnode discovery information within a VLAN.
> 
> Can we agree that:
> - FID is a concept internal to the box;
> - FID is never present in any frame;
> - The VID to FID mapping is internal to each box and 
> potentially different on different boxes;
> - The VID to FID mapping is never propagated in today networks.
> 
> If we have agreed the previous, let's consider what triggers learning:
> - In bridges the reception of a data frame with a {VID, MAC 
> address} pair;
> - In Rbridges the reception of a per VLAN instance ISIS PDU 
> that contains a {VID, MAC address} pair.
> I don't see any difference.
> 

Following the lines of the example Radia posted, endnode IP J MAC X
was previously on VLAN A where RBridge S learned of its existence.

Now endnode IP J/MAC X is migrated to VLAN B where RBRidge T learns
of its existence. This is an extremely plausible scenario where VLANs
A and B represent logical functions within a company. Or it could be as
simple as someone carrying a laptop from a "secure" area to another
area within the same buildig.

Meanwhile, Router Z receives an incoming packet with destination IP J.
Since that is not in its ARP tables, it sends an ARP request. Both
RBridge S and RBridge T, acting as PRoxy ARPs, will answer.

What is Router Z supposed to do? If it just accepts both ARP responses
and only keeps the last one, it could easily forward the packet to
VLAN A and thereby cause the connection to ultimately drop.

The root cause of this problem is that RBridge T did not share its
discovery of IP J/MAC X with RBridge S, even though they are part
of the same FID.

This can be done with exposing VID/FID mappings on the wire. You
export an "discovery-only VID" list instead. But I do not see how it
can be done if discovery announcements are shared exclusively
within VIDs without exception.






Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UKQRNO007769 for <[e-mail]>; Fri, 30 Mar 2007 13:26:27 -0700 (PDT)
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: Fri, 30 Mar 2007 13:26:20 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
thread-index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQAAJwEQA=
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Russ White" <[e-mail]>, "Radia Perlman" <[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 l2UKQRNO007769
Cc: [e-mail]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 20:26:41 -0000
Status: RO
Content-Length: 1145

Caitlin,

You say:

> 
> The most recent drafts effectively block that, by only distributing
> endnode discovery information within a VLAN.

Can we agree that:
- FID is a concept internal to the box;
- FID is never present in any frame;
- The VID to FID mapping is internal to each box and potentially
different on different boxes;
- The VID to FID mapping is never propagated in today networks.

If we have agreed the previous, let's consider what triggers learning:
- In bridges the reception of a data frame with a {VID, MAC address}
pair;
- In Rbridges the reception of a per VLAN instance ISIS PDU that
contains a {VID, MAC address} pair.
I don't see any difference.

Both Rbridges and Bridges learn this information as SVL or IVL,
depending on their configuration. It is an internal decision of each
device. It is not something that is or must be propagated among devices.
Again, I don't see any difference.

The only caution is that an RBridge must only include in its ISIS
announcement the {VID, MAC address} pairs that it has learnt observing
traffic, not the ones that derives from its internal mapping of VIDs to
FIDs.

-- Silvano





Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UJFSDd018477 for <[e-mail]>; Fri, 30 Mar 2007 12:15:29 -0700 (PDT)
Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 30 Mar 2007 12:15:21 -0700
X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0FFBE2AF; Fri, 30 Mar 2007 12:15:21 -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 EED602AE; Fri, 30 Mar 2007 12:15:20 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDB87311; Fri, 30 Mar 2007 12:15:19 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 215A769CA7; Fri, 30 Mar 2007 12:15:18 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 30 Mar 2007 12:15:03 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
Thread-Index: Acdy+FADBsmijBewQ7WLuxDwY6HE1gABPjPQ
From: "Caitlin Bestler" <[e-mail]>
To: "Russ White" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 6A13BE433A410515852-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 l2UJFSDd018477
Cc: [e-mail]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 19:15:41 -0000
Status: RO
Content-Length: 3528

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ White
> Sent: Friday, March 30, 2007 11:20 AM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> > To avoid requiring configuration of all RBridges with these 
> FIDs, and 
> > still allow multicast filtering, I propose we have RBridges 
> advertise, 
> > in their IS-IS core instance, FIDs that they are configured 
> with. So 
> > at least one RBridge will say "Hey guys, I think VLANs Z, 
> A, B, C, and 
> > D form a FID with primary=Z" and the other RBridges will, I guess 
> > believe him.
> 
> I'm trying to sort through this entire thing, and I wanted to ask:
> 
> 1. The reason we'd want to configure this on all rbridges 
> would be to optimize traffic flow?
> 
> 2. If 1 is true, and we didn't do the configuration on all 
> rbridges, how much less efficient would the rbridge network be?
> 
> 3. Does this have a larger impact on multicast, or smaller?
> 

No, I'd say that the purpose of this is to enable bridge that
do Shared Learning to also be RBridges.

The most recent drafts effectively block that, by only distributing
endnode discovery information within a VLAN. An RBridge that did shared
learning would need to know of updates not so that it could forward
packets to those addresses, but so that it could delete conflicting
uses of the same MAC address from its tables.

I believe there is a strong concensus that we do not want to forward
all endnode discovery updates to all RBridges on the presumption that
any of them could be doing shared learning. Since most bridges,
and presumably most RBridges, do Independent Learning this would
be an undesirable default.

That leaves, in my evaluation, two ways to deal with this issue.

One, you could simply state that the shared discovery information
assumes Independent Learning and effectively require all RBridges
to do independent learning (theoretically they could do shared
learning "locally" but then share information as though they were
independent, but that would be harder than just doing independent
learning). Essentially, go ahead and block it, but be explicit
about this restriction in the specification.

Two, you could include information in the RBridge advertisements
that lets you more accurately determine which RBridges require
which endnode discovery updates. For example, knowing VID to FID
mapping for each RBridge would definitely accomplish this. I
have suggested that a simpler listing of "additional VIDs" would
be sufficient. In either case the goal is not to send more unicast
or multicast traffic, merely to send more endnode discoveries.

Radia's email cites a scenario where migration of IP addresses
between VLANs is normal, and it is highly desirable that a given
IP and MAC Address be found in at most one of the VLANs. The
shared router's Proxy ARP wants to have a single location for
the IP address, not a current and a stale one. This is a
scenario that should be kept in mind. The other common motivation
for shared learning is even simpler to understand; 48-bit keys
are cheaper than 60-bit keys. If you have 48-bit keys, changing
to 60-bit keys can be more challenging that just adding functionality
by firmware/software. So there are motivations for having a global
MAC Address actually be global at both the usage and implementation
planes.






Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UIkspf010667 for <[e-mail]>; Fri, 30 Mar 2007 11:46:54 -0700 (PDT)
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: Fri, 30 Mar 2007 11:46:41 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
thread-index: Acdx0NmECgz5lw9xR+OCHNz8951f4gBKC8Uw
References: <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[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 l2UIkspf010667
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 18:47:05 -0000
Status: RO
Content-Length: 5130

Radia,

Catching up with my emails, inline

... snip ...

> 
> To avoid requiring configuration of all RBridges with these FIDs, and
> still allow multicast filtering, I propose we have RBridges advertise,
> in their IS-IS core instance, FIDs that they are configured with. So
at
> least one RBridge will say "Hey guys,
> I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the
other
> RBridges will, I guess
> believe him.
> 
> What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that
> FID Z = {Z,A,D, F} is an interesting question, but at least there is
> enough information to log an error. Lot of possibilities for
overlapping
> FIDs, inconsistent FIDs, etc.
> I assume all those will be errors. If there is a FID called "Z", then
> everyone better agree about what the
> VLAN membership of Z is, and none of the VLANs in Z better be in any
> other FIDs.
> 

Today bridges don't announce the association between VID and FID and I
am not sure why RBridges should act differently. There are many
combinations of FID to VID mapping that are perfectly compatible, for
example an RBridge may have more granularity than another RBridge.

> Once there is a FID of {Z, A, B, C, D}, there will no longer be
> a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D.

The main purpose of the VLAN instance is learning of end-node MAC
addresses. This is always done on the VID, never on the FID. Therefore
IMHO it is incorrect to suppress the IS-IS VLAN instances.

I am even not sure what that means. In IVL there is a FID for each VID,
are we going to suppress all the VID?

Also consider that it is always legal to insert an IVL RBridge in a
network of RBridges that do SVL. How will the IVL Rbridge learn, if
there are no more per VLAN instances?

I repeat what I already said in a previous email: "... in bridges what
triggers learning is always the reception of a frame that has a {VID,
MAC-address} pair. The fact that the VID, on that particular bridge,
shares the FID with other VIDs is what causes shared learning. But
shared learning NEVER propagates. TRILL MUST NOT propagate shared
learning. IT MUST always propagate {VID, MAC-address}. Recipients may
decide to do individual or shared learning."

> Instead
> the Z-instance will announce VLANs A, B, C, and D membership as well
as
> VLAN Z membership.
> 
> The Z-instance of IS-IS will specify which MAC addresses are in which
> VLAN.
> So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f},
> {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case
> letters are endnode MAC
> addresses. The upper case letters are 12-bit VLAN IDs.
> 
> Multicast packets marked as VLAN Z (inner VLAN) will be sent to
> all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of
> IS-IS will
> be delivered to all RBridges in Z, A, B, C, and D.
> 
> That way RBridges with ports in Z, A, B, C, and/or D will learn all
the
> endnode addresses
> in any of those VLANs (all the ports in FID Z).
> 
> If ingress RB1 is attached to Z, and receives a packet with
> destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z
> 's endnode
> membership. As soon as RB1 finds it, let's say, as reported by
> RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2,
> leaving the tag as Z. When RB2 decapsulates the packet, I assume it
will
> rewrite the inner VLAN tag from "Z" to "D".
> 
> 
> &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
> Conclusions:
> 
> The changes to the spec:
> 
> a) announce in the core instance, FIDs as a set of VLANs, the
> first listed being the "primary".

I don't see why this is necessary or useful.

> 
> b) multicast forwarding: if the packet is (inner) tagged with
> the VLAN ID of a primary VLAN in a FID,

The frames MUST always be tagged with the VLAN they belong to, not with
the primary VLAN.

-- Silvano


 forward the packet on
> all in the links in the selected tree that lead to any of the VLANs
> in the FID. If the packet is tagged with the VLAN ID of a non-primary
> VLAN in a FID, forward the packet on all the ports that reach
> links in either that VLAN or in the primary VLAN for that FID.
> 
> c) when ingressing a packet with destination D, tagged with a
> VLAN tag of a primary VLAN in a FID, check the endnode information
> for all the VLANs in the FID to determine the egress RBridge.
> 
> d) when ingressing a packet with destination D, tagged with
> a VLAN tag of a secondary VLAN in a FID, check the endnode
> information for exactly two VLANs; the one the packet is
> currently tagged with, and the primary VLAN for that FID, to
> determine the egress RBridge.
> 
> e) if two RBridges, in the core instance, report inconsistent FID
> membership, what should we do?
> 
> (Note: There was a fortune cookie program in Unix, one of the fortunes
> being "Never check for an error
> condition that you don't know how to handle". For the record--I think
> that's a cute joke but really bad policy.).
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UIJcl2001925 for <[e-mail]>; Fri, 30 Mar 2007 11:19:38 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2007 11:19:38 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2UIJcIc019305;  Fri, 30 Mar 2007 11:19:38 -0700
Received: from [128.107.114.151] (dhcp-128-107-114-151.cisco.com [128.107.114.151]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2UIJcEi023150; Fri, 30 Mar 2007 18:19:38 GMT
Message-ID: <[e-mail]>
Date: Fri, 30 Mar 2007 14:19:39 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.3.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1041; t=1175278778; x=1176142778; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Shared=20VLAN=20learning=3A=20What=20is=2 0it=20and=20why=20should=20we=0A=20care? |Sender:=20; bh=RadJTSRthmPDac94gHuhbS1imkj0P3U7a/kxEL+CSJE=; b=BXbSECO/K/LltftDzMPR+Hok4sNqCiKrhlXV+OzVj7687/hPHx8aEQHfw0WgkEuN3hERIjTx O/86aLshgdffj2QirtsBA5wkN4wyRNt1RiZQDsHUywM3afHbWzg6fGBI;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 18:20:05 -0000
Status: RO
Content-Length: 1034

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



> To avoid requiring configuration of all RBridges with these FIDs, and
> still allow multicast filtering, I propose we have RBridges advertise,
> in their IS-IS core instance, FIDs that they are configured with. So at 
> least one RBridge will say "Hey guys,
> I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other 
> RBridges will, I guess
> believe him.

I'm trying to sort through this entire thing, and I wanted to ask:

1. The reason we'd want to configure this on all rbridges would be to
optimize traffic flow?

2. If 1 is true, and we didn't do the configuration on all rbridges, how
much less efficient would the rbridge network be?

3. Does this have a larger impact on multicast, or smaller?

:-)

Russ


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

iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg
DSuMdrc10XgRmx8w4PdN/f4=
=ItDw
-----END PGP SIGNATURE-----


Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UHwjRo024919 for <[e-mail]>; Fri, 30 Mar 2007 10:58:45 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 30 Mar 2007 10:58:35 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A3A812B1; Fri, 30 Mar 2007 10:58:35 -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 DB4762B3; Fri, 30 Mar 2007 10:58:34 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FDB65299; Fri, 30 Mar 2007 10:58:32 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 2E40F69CA3; Fri, 30 Mar 2007 10:58:32 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 30 Mar 2007 10:58:31 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
Thread-Index: Acdx0YXEJDs4bfPnQXu2XCSKkryjcQBIk5/A
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, [e-mail]
X-WSS-ID: 6A13904137010567086-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 l2UHwjRo024919
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 17:59:04 -0000
Status: RO
Content-Length: 2270

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Radia Perlman
> Sent: Wednesday, March 28, 2007 11:56 PM
> To: [e-mail]
> Subject: [rbridge] Shared VLAN learning: What is it and why 
> should we care?
> 
> 
> 
> But how do two endnodes in different VLANs, but in the same 
> IP address block communicate? S will ARP, like before, 
> because IP nodes are (blissfully) unaware of VLANs. 
> The answer people tell me
> is "in that case communication between S and D has to go 
> through the IP router". OK. So how would that work? The 
> answer I get is "the switch does proxy ARP on behalf of the 
> IP router". 
> I don't understand that. How does the
> switch know *when* to proxy ARP? The switch doesn't 
> necessarily know which VLAN node D is in.
> 

As others have already answered, the "switch" does not
forward the traffic between the two VLANs sharing the
same IP subnet, but rather some router-like ProxyARP
functionality.

This can be desirable/acceptable precisely because the
traffic is going through this L3-aware entity. The two
sub-groups may be willing to exchange traffic, but unwilling
to grant each other unchecked/unlogged/unfiltered access.
If the traffic can only be forwarded at L3 it is subject
to L3 firewalling/logging/etc.

While the same protocols did not apply, I recall a very
similar issue with traffic between cable modems. There was
no real reason to flat forbid such traffic, but it was 
definitely something that you did not want  to be handled
at the reflex/L2 layer where it could not be throttled/
logged/monitored/etc.

> 
> e) if two RBridges, in the core instance, report inconsistent FID 
> membership, what should we do?
> 

One way to avoid that would be for each RBridge to simply 
advertise which VIDs it forwarded to, and which additional
VIDs that its FIDs overlapped with. The first set determines
what it needs to know for forwarding purposes, the second
set determines what it needs to know for purposes of deleting
entries.

Expressed that way, there is no need for FIDs to be consistent.
At least for RBridge protocol purposes, consistency of FID
mapping is still highly desirable for the preservation of
network administrator sanity.




Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2UHWufx017546 for <[e-mail]>; Fri, 30 Mar 2007 10:32:56 -0700 (PDT)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2007 10:32:56 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2UHWtdb024681 for <[e-mail]>; Fri, 30 Mar 2007 10:32:55 -0700
Received: from [128.107.114.151] (dhcp-128-107-114-151.cisco.com [128.107.114.151]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UHWrMF002727 for <[e-mail]>; Fri, 30 Mar 2007 17:32:55 GMT
Message-ID: <[e-mail]>
Date: Fri, 30 Mar 2007 13:32:51 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.3.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1414; t=1175275975; x=1176139975; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Russ=20White=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Last=20Call=3A=20draft-ietf-trill-routing -reqs=20(TRILL=20Routing=0A=20Requirements=20in=20Support=20of=20RBridges) =20to=20Informational=20RFC |Sender:=20; bh=clWrbvl8hFQ7STdhTwhzAxNCBdhR38CsZuvF+zw6oyI=; b=SpXi9NBZ6/lZYY02h+DsBbkKX8dFTUxOvMgas5fS+4xE6H1V8i10xMAPvz2uT8TOioor4yla 5uPfk+f0ia9oPvzKGo60jMWNlyjyUUtchUEBWAjY98TnvVrfzfKr0CXs;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 17:33:04 -0000
Status: RO
Content-Length: 1401

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


I have reviewed this draft, and it looks fine to move forward.

:-)

Russ

The IESG wrote:
> The IESG has received a request from the Transparent Interconnection of 
> Lots of Links WG (trill) to consider the following document:
> 
> - 'TRILL Routing Requirements in Support of RBridges '
>    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2007-03-30. Exceptionally, 
> comments may be sent to [e-mail] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGDUnDER27sUhU9OQRAlzmAKCoQJYPvvBSpfSGhtZ2MDz4c42Z9QCfa9Gd
9NHP/EKeE6dvru91n4QNSr0=
=t7jc
-----END PGP SIGNATURE-----


Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2U4ItJ3014516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 29 Mar 2007 21:18:55 -0700 (PDT)
Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep  5 2006)) id <[e-mail]> for [e-mail]; Thu, 29 Mar 2007 23:18:54 -0500 (CDT)
Received: from [192.168.1.102] (mdsnwikwbas08-pool6-a4.mdsnwikw.tds.net [69.129.197.4]) by smtpauth1.wiscmail.wisc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep  5 2006)) with ESMTPSA id <[e-mail]>; Thu, 29 Mar 2007 23:18:54 -0500 (CDT)
Date: Thu, 29 Mar 2007 23:18:52 -0500
From: "Dale W. Carder" <[e-mail]>
In-reply-to: <[e-mail]>
To: Radia Perlman <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
X-Spam-Report: AuthenticatedSender=yes, SenderIP=192.168.1.102
X-Spam-PmxInfo: Server=avs-11, Version=5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.29.210642, SenderIP=192.168.1.102
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 04:19:14 -0000
Status: RO
Content-Length: 10833

Comments inline:

On Mar 29, 2007, at 1:56 AM, Radia Perlman wrote:

> Hopefully this explanation will be clear enough for people to at least
> figure out whether we
> are all talking about the same thing. Of course, feel free to  
> correct me
> if my understanding is wrong.
>
> First we need to understand what problem it is trying to solve.

It may be helpful to read IEEE 802.1Q-2005, Annex B.1.3 Asymmetric VLANs

Also, similar problems (with different solutions, of course) are given
in RFC 3069 and also draft-sanjib-private-vlan-06.txt

TRILL sould allow one of those solutions in addition to allowing Shared
Vlan Learning as described in 802.1q.

I think the ideas behind this also somewhat remind me of ATM half- 
bridging.

> This is
> my understanding of that:
>
> THE PROBLEM
> ------------------
>
> Someone has a block of IP addresses to divvy up among
> a set of different organizations. Let's say the address block has
> 100 addresses, and there are 4 organizations. One strategy might be
> to give each organization 1/4 of the IP addresses each, and then
> possibly even
> wind up having separate IP subnets (if the addresses can be assigned
> to be in different prefixes).
>
> The problem, though, is that you don't know in advance how many  
> addresses
> each organization will need. Perhaps even the IP address block is
> oversubscribed,
> so that there are more potential switch ports than IP addresses,  
> and you
> just hope that not everyone connects at once (or if they do, they  
> don't
> get an IP address).
>
> So we're going to allow basically random assignment of IP addresses
> within the IP address block to each of the four organizations.
>
> But you still want to keep the organizations separate, as in, they  
> don't
> see each other's traffic. They
> don't get bothered with each other's ARPs and so forth. And you don't
> want to change the IP nodes
> (endnodes or routers)
> to know anything funny is going on.
>
> So you use VLANs to separate the communities. A particular port
> on a switch/bridge in a L2 cloud
> is configured as to what community the attached endnode belongs to, by
> having it configured with a VLAN ID.
>
> But you'd like all the IP nodes in the cloud, even though in different
> communities, to share the same IP router, also possibly other  
> services such
> as the DHCP server. And we don't want the IP router
> to have to know about the different communities. The IP router just
> thinks the cloud is one big happy can't-we-all-just-get-along IP  
> subnet.
>
> But the bridges inside the L2 cloud have to somehow do two things:
> a) enforce some sort of separation between the communities, and
> b) allow them all to talk to the IP router.
>
> So this is how they are doing this. Assign each of the 4 communities a
> VLAN ID, say
> VLANs A, B, C, and D. Now what VLAN ID should the IP router belong to?
> You want it
> to be able to talk to nodes in any of the VLANs {A, B, C, or D}.
>
> The way this is done is to declare a VLAN group known as a FID  
> (filtering
> ID for those that want to see an acronym expanded -- personally, the
> expansion of that acronym didn't help me understand what a FID is).
> So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one of the  
> IDs,
> say Z, being the "primary". The IP router that serves all the  
> communities
> (in this case, A, B, C, D) will be assigned to the "primary" VLAN, in
> this case, Z. Endnodes
> will be in one of {A, B, C, D}. IP routers serving these  
> communities will
> be assigned VLAN Z.
>
> To clarify, if there are n communities, there will be n+1 VLANs, one
> for each of the communities, and one for the IP router(s) serving
> the communities in that IP subnet.
>
> Switches are configured to know that {Z, A, B, C, D} is a special
> grouping of VLANs, such
> that something transmitted from a VLAN Z port goes to all ports in the
> group, i.e., all ports in
> Z, A, B, C, and D. However, something transmitted from a VLAN A port
> goes only to ports in
> VLAN A and VLAN Z. Something from VLAN B goes to ports in VLAN B  
> and VLAN Z.
>
> *************
> Now a little quiz...
>
> For those of you that are following-- and in case I actually have
> captured the concept,
> let me ask a question.
>
> How do two endnodes in the IP subnet talk to each other?

I think in the 802.1Q Shared Vlan Learning case, this is assumed not
to occur, or at least not by using bridges.  There are some other  
comments
in 802.1Q-2005 Annex B about constraints for using SVL's that might
apply.

> The first case is two endnodes in VLAN A, say S and D.
> S, observing that D is in the same subnet, will ARP. Since D is in the
> same VLAN, it will receive
> the ARP request, and respond. Everything works fine.
>
> But how do two endnodes in different VLANs, but in the same IP address
> block communicate? S will
> ARP, like before, because IP nodes are (blissfully) unaware of VLANs.
> The answer people tell me
> is "in that case communication between S and D has to go through  
> the IP
> router". OK. So how would
> that work? The
> answer I get is "the switch does proxy ARP on behalf of the IP  
> router".
> I don't understand that.

Cisco calls this feature "local-proxy-arp".  This feature makes the  
router
respond to *all* ARP requests on a subnet, and forward traffic  
between all
hosts on the subnet.

> How does the
> switch know *when* to proxy ARP? The switch doesn't necessarily know
> which VLAN node D is in.

This is the enhanced proxy-arp capable router's responsibility, not the
switch.

> *******************
> Well, bravely continuing on...
>
>
> Endnode MAC address learning is done by VLAN as before. If a frame is
> received by bridge b on
> port p, with source S, from VLAN A, then bridge b remembers that {S,
> VLAN A} is on port p.
>
> Furthermore, a Z-tagged unicast frame is checked against the learning
> tables of Z, A, B, C, D, to determine where to forward it. So if  
> bridge
> b receives
> a frame with
> destination=D, bridge b checks for D in any of the VLANs Z, A, B,  
> C, D, and
> forwards accordingly.
>
>
>
> &&&&&&&&&&&&&&&&&
> So, that's how bridges work (I hope). So how would we support this
> functionality in
> RBridges?
>
> As it turns out, despite the complexity of the concept,
> it will not be that difficult to support this with RBridges, and
> even in a somewhat more optimal way, since RBridges can do multicast
> filtering within the core rather that just at the final port.
>
> RBridges, like bridges, would have to be configured with FIDs, i.e.,
> VLAN groupings as described above.
>
> Let's call a FID by the name of the "primary" VLAN; in our example, Z.
>
> RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, A, B,  
> C, D are
> all 12-bit VLAN IDs.
>
> To avoid requiring configuration of all RBridges with these FIDs,
> and
> still allow multicast filtering, I propose we have RBridges advertise,
> in their IS-IS core instance, FIDs that they are configured with.  
> So at
> least one RBridge will say "Hey guys,
> I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the  
> other
> RBridges will, I guess
> believe him.
>
> What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that
> FID Z = {Z,A,D, F} is an interesting question, but at least there is
> enough information to log an error. Lot of possibilities for  
> overlapping
> FIDs, inconsistent FIDs, etc.
> I assume all those will be errors. If there is a FID called "Z", then
> everyone better agree about what the
> VLAN membership of Z is, and none of the VLANs in Z better be in any
> other FIDs.
>
> Once there is a FID of {Z, A, B, C, D}, there will no longer be
> a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D.
> Instead
> the Z-instance will announce VLANs A, B, C, and D membership as  
> well as
> VLAN Z membership.
>
> The Z-instance of IS-IS will specify which MAC addresses are in  
> which VLAN.
> So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f},
> {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case
> letters are endnode MAC
> addresses. The upper case letters are 12-bit VLAN IDs.
>
> Multicast packets marked as VLAN Z (inner VLAN) will be sent to
> all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of
> IS-IS will
> be delivered to all RBridges in Z, A, B, C, and D.
>
> That way RBridges with ports in Z, A, B, C, and/or D will learn all  
> the
> endnode addresses
> in any of those VLANs (all the ports in FID Z).
>
> If ingress RB1 is attached to Z, and receives a packet with
> destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z
> 's endnode
> membership. As soon as RB1 finds it, let's say, as reported by
> RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2,
> leaving the tag as Z. When RB2 decapsulates the packet, I assume it  
> will
> rewrite the inner VLAN tag from "Z" to "D".
>
>
> &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
> Conclusions:
>
> The changes to the spec:
>
> a) announce in the core instance, FIDs as a set of VLANs, the
> first listed being the "primary".
>
> b) multicast forwarding: if the packet is (inner) tagged with
> the VLAN ID of a primary VLAN in a FID, forward the packet on
> all in the links in the selected tree that lead to any of the VLANs
> in the FID. If the packet is tagged with the VLAN ID of a non-primary
> VLAN in a FID, forward the packet on all the ports that reach
> links in either that VLAN or in the primary VLAN for that FID.
>
> c) when ingressing a packet with destination D, tagged with a
> VLAN tag of a primary VLAN in a FID, check the endnode information
> for all the VLANs in the FID to determine the egress RBridge.
>
> d) when ingressing a packet with destination D, tagged with
> a VLAN tag of a secondary VLAN in a FID, check the endnode
> information for exactly two VLANs; the one the packet is
> currently tagged with, and the primary VLAN for that FID, to
> determine the egress RBridge.
>
> e) if two RBridges, in the core instance, report inconsistent FID
> membership, what should we do?
>
> (Note: There was a fortune cookie program in Unix, one of the fortunes
> being "Never check for an error
> condition that you don't know how to handle". For the record--I think
> that's a cute joke but really bad policy.).
>
> Radia



Off-list, Radia asked me

> a) why not just make them all one broadcast/multicast domain? What  
> exactly are people trying to
> accomplish by making them separate but still all able to talk?

Limit the size of the broadcast domain.  An example would be for  
large-scale
wireless networks, where irrelevant broadcasts eat up valuable airtime.

Another example for large-scale switched networks would be to  
separate what
would have been one gigantic spanning-tree domain into separate domains.

Dale


Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2TMw1OF026410 for <[e-mail]>; Thu, 29 Mar 2007 15:58:02 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 29 Mar 2007 15:57:39 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5CD8C2AF; Thu, 29 Mar 2007 15:57:39 -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 46B6F2AE; Thu, 29 Mar 2007 15:57:39 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCZ62008; Thu, 29 Mar 2007 15:57:38 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id A108A69CA4; Thu, 29 Mar 2007 15:57:38 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 29 Mar 2007 15:57:37 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
Thread-Index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPAAAHGhTAABgZIoAAAMLaw
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Sanjay Sane (sanjays)" <[e-mail]>, "Radia Perlman" <[e-mail]>, [e-mail]
X-WSS-ID: 6A129BE937010263668-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 l2TMw1OF026410
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 22:58:33 -0000
Status: RO
Content-Length: 2476

Silvano Gai wrote:
> Caitlin,
> 
> inline
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Caitlin Bestler Sent: Thursday, March 29, 2007 1:03 PM
>> To: Sanjay Sane (sanjays); Radia Perlman; [e-mail]
>> Subject: Re: [rbridge] Shared VLAN learning: What is it and
> why should
> we
>> care?
>> 
>> [e-mail] wrote:
>>> To answer your quiz: the "enhanced" proxy arp feature is to be
>>> supported by the router, NOT by the switch. The enhancement is
>>> essentially to be able to proxy arp for local hosts, i.e for those
>>> hosts which are on the same subnet as the router interface. This is
>>> the "ip local proxy arp" supported feature at least in Cisco
>>> implementations. 
>>> 
>>> This way, the L3 communication between the hosts belonging to
>>> different secondary vlans, is achieved *only* via the router. i.e.
>>> if host ip-A (vlan-A) wants to talk to ip-D (vlan-D), it would take
>>> 2 hops: mac-A --> mac-router mac-router --> mac-D
>>> I think we should preserve this behavior with rbridges.
>>> Changing the vlans of the packet should NOT be done by rbridges,
>>> imo. 
>>> 
>>> -Sanjay
>>> 
>>> 
>>> 
>> I would agree that 'routing' between VLAN-A and VLAN-D should only be
>> done as a result of an explicitly created 'route', and that this is
>> part of being a proxy ARP. 
>> 
>> I don't see any real problem with an RBridge doing so, as long as it
>> only does so based on explicit instructions from the network
>> administrators. It definitely must not just assume that it is ok to
>> forward packets between two VLANs based upon their both using the
>> same subnet. 
>> 
>> While this functionality is certainly more natural in a router, is
>> there any reason to forbid explicitly delegating this task to
>> RBridges? It could save a few hops on the end-to-end path.
> 
> 
> Are we talking standards or products? Products can do
> whatever they want, we don't care. IMHO the RBridge standard
> MUST NOT specify IP routing functionality. IETF has already
> tons of standards in the IP area.
> 

It would probably be safe to mandate that the RBridge MUST NOT
forward from VLAN to VLAN, as part of its RBridge functionality.
If a *product* includes some additional non-RBRidge functionality
that would be fine. But I would not want language that implied 
that because you called your box an RBridge that you MUST NOT
include this feature in the same box.




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2TMs6FZ025264 for <[e-mail]>; Thu, 29 Mar 2007 15:54:07 -0700 (PDT)
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: Thu, 29 Mar 2007 15:54:00 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
thread-index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPAAAHGhTAABgZIoA==
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Sanjay Sane \(sanjays\)" <[e-mail]>, "Radia Perlman" <[e-mail]>, <[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 l2TMs6FZ025264
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 22:54:36 -0000
Status: RO
Content-Length: 2219

Caitlin,

inline

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Caitlin Bestler
> Sent: Thursday, March 29, 2007 1:03 PM
> To: Sanjay Sane (sanjays); Radia Perlman; [e-mail]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
we
> care?
> 
> [e-mail] wrote:
> > To answer your quiz: the "enhanced" proxy arp feature is to
> > be supported by the router, NOT by the switch. The
> > enhancement is essentially to be able to proxy arp for local
> > hosts, i.e for those hosts which are on the same subnet as
> > the router interface. This is the "ip local proxy arp"
> > supported feature at least in Cisco implementations.
> >
> > This way, the L3 communication between the hosts belonging to
> > different secondary vlans, is achieved *only* via the router.
> > i.e. if host ip-A
> > (vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops:
> > mac-A --> mac-router
> > mac-router --> mac-D
> > I think we should preserve this behavior with rbridges.
> > Changing the vlans of the packet should NOT be done by rbridges,
imo.
> >
> > -Sanjay
> >
> >
> >
> I would agree that 'routing' between VLAN-A and VLAN-D
> should only be done as a result of an explicitly created
> 'route', and that this is part of being a proxy ARP.
> 
> I don't see any real problem with an RBridge doing so,
> as long as it only does so based on explicit instructions
> from the network administrators. It definitely must not
> just assume that it is ok to forward packets between
> two VLANs based upon their both using the same subnet.
> 
> While this functionality is certainly more natural
> in a router, is there any reason to forbid explicitly
> delegating this task to RBridges? It could save a few
> hops on the end-to-end path.


Are we talking standards or products? Products can do whatever they
want, we don't care. IMHO the RBridge standard MUST NOT specify IP
routing functionality. IETF has already tons of standards in the IP
area.

-- Silvano


> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2TK35f2006415 for <[e-mail]>; Thu, 29 Mar 2007 13:03:05 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 29 Mar 2007 13:02:57 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 378842AF; Thu, 29 Mar 2007 13:02:57 -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 234282AE; Thu, 29 Mar 2007 13:02:57 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCZ26330; Thu, 29 Mar 2007 13:02:52 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id D6E7369CA3; Thu, 29 Mar 2007 13:02:51 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 29 Mar 2007 13:02:51 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
Thread-Index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPAAAHGhTA=
From: "Caitlin Bestler" <[e-mail]>
To: "Sanjay Sane (sanjays)" <[e-mail]>, "Radia Perlman" <[e-mail]>, [e-mail]
X-WSS-ID: 6A12C4FB38G10239458-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 l2TK35f2006415
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 20:03:32 -0000
Status: RO
Content-Length: 1435

[e-mail] wrote:
> To answer your quiz: the "enhanced" proxy arp feature is to
> be supported by the router, NOT by the switch. The
> enhancement is essentially to be able to proxy arp for local
> hosts, i.e for those hosts which are on the same subnet as
> the router interface. This is the "ip local proxy arp"
> supported feature at least in Cisco implementations.
> 
> This way, the L3 communication between the hosts belonging to
> different secondary vlans, is achieved *only* via the router.
> i.e. if host ip-A
> (vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops:
> mac-A --> mac-router
> mac-router --> mac-D
> I think we should preserve this behavior with rbridges.
> Changing the vlans of the packet should NOT be done by rbridges, imo.
> 
> -Sanjay
> 
> 
> 
I would agree that 'routing' between VLAN-A and VLAN-D
should only be done as a result of an explicitly created
'route', and that this is part of being a proxy ARP.

I don't see any real problem with an RBridge doing so,
as long as it only does so based on explicit instructions
from the network administrators. It definitely must not
just assume that it is ok to forward packets between
two VLANs based upon their both using the same subnet.

While this functionality is certainly more natural 
in a router, is there any reason to forbid explicitly
delegating this task to RBridges? It could save a few
hops on the end-to-end path.





Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2TJa9rG026569 for <[e-mail]>; Thu, 29 Mar 2007 12:36:09 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2007 12:36:10 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2TJa8vJ028756;  Thu, 29 Mar 2007 12:36:08 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2TJa8ZT002865; Thu, 29 Mar 2007 19:36:08 GMT
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 29 Mar 2007 12:36:03 -0700
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: Thu, 29 Mar 2007 12:36:03 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Shared VLAN learning: What is it and why should we care?
Thread-Index: Acdx0V5snDV1JueHTzeTSTFu3o4bjwAZATPA
References: <[e-mail]>
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Mar 2007 19:36:03.0663 (UTC) FILETIME=[7CD8BDF0:01C77239]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10349; t=1175196968; x=1176060968; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:=20RE=3A=20[rbridge]=20Shared=20VLAN=20learning=3A=20What=20is=2 0it=20and=20why=20should=20we=20care? |Sender:=20; bh=HjTQS0FKB0OBD8niMorXq16o9iVx8kfo8LbW/HpkOxk=; b=FznEt6+nHXG2hnYCrRSL0r1rC5plQGPZpfszUrZYxOfskvY8TwsJaUyeckcAFYRFUfMKaR/M jGJF2awMJumn0GVFNwcHdQ3Ml82FXGpzeNPMB3PcWUVJWR1teSAEBgo2;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
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 l2TJa9rG026569
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 19:37:20 -0000
Status: RO
Content-Length: 10044

To answer your quiz: the "enhanced" proxy arp feature is to be supported
by the router, NOT by the switch. The enhancement is essentially to be
able to proxy arp for local hosts, i.e for those hosts which are on the
same subnet as the router interface. This is the "ip local proxy arp"
supported feature at least in Cisco implementations. 

This way, the L3 communication between the hosts belonging to different
secondary vlans, is achieved *only* via the router. i.e. if host ip-A
(vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops:
mac-A --> mac-router 
mac-router --> mac-D
I think we should preserve this behavior with rbridges. Changing the
vlans of the packet should NOT be done by rbridges, imo. 

-Sanjay

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, March 28, 2007 11:56 PM
To: [e-mail]
Subject: [rbridge] Shared VLAN learning: What is it and why should we
care?

Hopefully this explanation will be clear enough for people to at least
figure out whether we are all talking about the same thing. Of course,
feel free to correct me if my understanding is wrong.

First we need to understand what problem it is trying to solve. This is
my understanding of that:

THE PROBLEM
------------------

Someone has a block of IP addresses to divvy up among a set of different
organizations. Let's say the address block has 100 addresses, and there
are 4 organizations. One strategy might be to give each organization 1/4
of the IP addresses each, and then possibly even wind up having separate
IP subnets (if the addresses can be assigned to be in different
prefixes).

The problem, though, is that you don't know in advance how many
addresses each organization will need. Perhaps even the IP address block
is oversubscribed, so that there are more potential switch ports than IP
addresses, and you just hope that not everyone connects at once (or if
they do, they don't get an IP address).

So we're going to allow basically random assignment of IP addresses
within the IP address block to each of the four organizations.

But you still want to keep the organizations separate, as in, they don't
see each other's traffic. They don't get bothered with each other's ARPs
and so forth. And you don't want to change the IP nodes (endnodes or
routers) to know anything funny is going on.

So you use VLANs to separate the communities. A particular port on a
switch/bridge in a L2 cloud is configured as to what community the
attached endnode belongs to, by having it configured with a VLAN ID.

But you'd like all the IP nodes in the cloud, even though in different
communities, to share the same IP router, also possibly other services
such as the DHCP server. And we don't want the IP router to have to know
about the different communities. The IP router just thinks the cloud is
one big happy can't-we-all-just-get-along IP subnet.

But the bridges inside the L2 cloud have to somehow do two things:
a) enforce some sort of separation between the communities, and
b) allow them all to talk to the IP router.

So this is how they are doing this. Assign each of the 4 communities a
VLAN ID, say VLANs A, B, C, and D. Now what VLAN ID should the IP router
belong to? 
You want it
to be able to talk to nodes in any of the VLANs {A, B, C, or D}.

The way this is done is to declare a VLAN group known as a FID
(filtering ID for those that want to see an acronym expanded --
personally, the expansion of that acronym didn't help me understand what
a FID is).
So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one of the IDs,
say Z, being the "primary". The IP router that serves all the
communities (in this case, A, B, C, D) will be assigned to the "primary"
VLAN, in this case, Z. Endnodes will be in one of {A, B, C, D}. IP
routers serving these communities will be assigned VLAN Z.

To clarify, if there are n communities, there will be n+1 VLANs, one for
each of the communities, and one for the IP router(s) serving the
communities in that IP subnet.

Switches are configured to know that {Z, A, B, C, D} is a special
grouping of VLANs, such that something transmitted from a VLAN Z port
goes to all ports in the group, i.e., all ports in Z, A, B, C, and D.
However, something transmitted from a VLAN A port goes only to ports in
VLAN A and VLAN Z. Something from VLAN B goes to ports in VLAN B and
VLAN Z.

*************
Now a little quiz...

For those of you that are following-- and in case I actually have
captured the concept, let me ask a question.

How do two endnodes in the IP subnet talk to each other?
The first case is two endnodes in VLAN A, say S and D.
S, observing that D is in the same subnet, will ARP. Since D is in the
same VLAN, it will receive the ARP request, and respond. Everything
works fine.

But how do two endnodes in different VLANs, but in the same IP address
block communicate? S will ARP, like before, because IP nodes are
(blissfully) unaware of VLANs. 
The answer people tell me
is "in that case communication between S and D has to go through the IP
router". OK. So how would that work? The answer I get is "the switch
does proxy ARP on behalf of the IP router". 
I don't understand that. How does the
switch know *when* to proxy ARP? The switch doesn't necessarily know
which VLAN node D is in.

*******************
Well, bravely continuing on...



Endnode MAC address learning is done by VLAN as before. If a frame is
received by bridge b on port p, with source S, from VLAN A, then bridge
b remembers that {S, VLAN A} is on port p.

Furthermore, a Z-tagged unicast frame is checked against the learning
tables of Z, A, B, C, D, to determine where to forward it. So if bridge
b receives a frame with destination=D, bridge b checks for D in any of
the VLANs Z, A, B, C, D, and forwards accordingly.



&&&&&&&&&&&&&&&&&
So, that's how bridges work (I hope). So how would we support this 
functionality in
RBridges?

As it turns out, despite the complexity of the concept,
it will not be that difficult to support this with RBridges, and
even in a somewhat more optimal way, since RBridges can do multicast
filtering within the core rather that just at the final port.

RBridges, like bridges, would have to be configured with FIDs, i.e., 
VLAN groupings as described above.

Let's call a FID by the name of the "primary" VLAN; in our example, Z.

RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, A, B, C, D
are
all 12-bit VLAN IDs.

To avoid requiring configuration of all RBridges with these FIDs, and
still allow multicast filtering, I propose we have RBridges advertise,
in their IS-IS core instance, FIDs that they are configured with. So at 
least one RBridge will say "Hey guys,
I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other

RBridges will, I guess
believe him.

What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that
FID Z = {Z,A,D, F} is an interesting question, but at least there is
enough information to log an error. Lot of possibilities for overlapping

FIDs, inconsistent FIDs, etc.
I assume all those will be errors. If there is a FID called "Z", then 
everyone better agree about what the
VLAN membership of Z is, and none of the VLANs in Z better be in any 
other FIDs.

Once there is a FID of {Z, A, B, C, D}, there will no longer be
a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. 
Instead
the Z-instance will announce VLANs A, B, C, and D membership as well as 
VLAN Z membership.

The Z-instance of IS-IS will specify which MAC addresses are in which
VLAN.
So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f},
{A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case 
letters are endnode MAC
addresses. The upper case letters are 12-bit VLAN IDs.

Multicast packets marked as VLAN Z (inner VLAN) will be sent to
all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of 
IS-IS will
be delivered to all RBridges in Z, A, B, C, and D.

That way RBridges with ports in Z, A, B, C, and/or D will learn all the 
endnode addresses
in any of those VLANs (all the ports in FID Z).

If ingress RB1 is attached to Z, and receives a packet with
destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z 
's endnode
membership. As soon as RB1 finds it, let's say, as reported by
RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2,
leaving the tag as Z. When RB2 decapsulates the packet, I assume it will
rewrite the inner VLAN tag from "Z" to "D".


&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Conclusions:

The changes to the spec:

a) announce in the core instance, FIDs as a set of VLANs, the
first listed being the "primary".

b) multicast forwarding: if the packet is (inner) tagged with
the VLAN ID of a primary VLAN in a FID, forward the packet on
all in the links in the selected tree that lead to any of the VLANs
in the FID. If the packet is tagged with the VLAN ID of a non-primary
VLAN in a FID, forward the packet on all the ports that reach
links in either that VLAN or in the primary VLAN for that FID.

c) when ingressing a packet with destination D, tagged with a
VLAN tag of a primary VLAN in a FID, check the endnode information
for all the VLANs in the FID to determine the egress RBridge.

d) when ingressing a packet with destination D, tagged with
a VLAN tag of a secondary VLAN in a FID, check the endnode
information for exactly two VLANs; the one the packet is
currently tagged with, and the primary VLAN for that FID, to
determine the egress RBridge.

e) if two RBridges, in the core instance, report inconsistent FID 
membership, what should we do?

(Note: There was a fortune cookie program in Unix, one of the fortunes 
being "Never check for an error
condition that you don't know how to handle". For the record--I think 
that's a cute joke but really bad policy.).

Radia



_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2T6towL006168 for <[e-mail]>; Wed, 28 Mar 2007 23:55: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]; Wed, 28 Mar 2007 23:55:50 -0700 (PDT)
Received: from sun.com ([129.150.16.120]) 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, 28 Mar 2007 23:55:48 -0700 (PDT)
Date: Wed, 28 Mar 2007 23:56:04 -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] Shared VLAN learning: What is it and why should we care?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 06:56:55 -0000
Status: RO
Content-Length: 8929

Hopefully this explanation will be clear enough for people to at least 
figure out whether we
are all talking about the same thing. Of course, feel free to correct me 
if my understanding is wrong.

First we need to understand what problem it is trying to solve. This is 
my understanding of that:

THE PROBLEM
------------------

Someone has a block of IP addresses to divvy up among
a set of different organizations. Let's say the address block has
100 addresses, and there are 4 organizations. One strategy might be
to give each organization 1/4 of the IP addresses each, and then 
possibly even
wind up having separate IP subnets (if the addresses can be assigned
to be in different prefixes).

The problem, though, is that you don't know in advance how many addresses
each organization will need. Perhaps even the IP address block is 
oversubscribed,
so that there are more potential switch ports than IP addresses, and you
just hope that not everyone connects at once (or if they do, they don't
get an IP address).

So we're going to allow basically random assignment of IP addresses
within the IP address block to each of the four organizations.

But you still want to keep the organizations separate, as in, they don't 
see each other's traffic. They
don't get bothered with each other's ARPs and so forth. And you don't 
want to change the IP nodes
(endnodes or routers)
to know anything funny is going on.

So you use VLANs to separate the communities. A particular port
on a switch/bridge in a L2 cloud
is configured as to what community the attached endnode belongs to, by
having it configured with a VLAN ID.

But you'd like all the IP nodes in the cloud, even though in different
communities, to share the same IP router, also possibly other services such
as the DHCP server. And we don't want the IP router
to have to know about the different communities. The IP router just
thinks the cloud is one big happy can't-we-all-just-get-along IP subnet.

But the bridges inside the L2 cloud have to somehow do two things:
a) enforce some sort of separation between the communities, and
b) allow them all to talk to the IP router.

So this is how they are doing this. Assign each of the 4 communities a 
VLAN ID, say
VLANs A, B, C, and D. Now what VLAN ID should the IP router belong to? 
You want it
to be able to talk to nodes in any of the VLANs {A, B, C, or D}.

The way this is done is to declare a VLAN group known as a FID (filtering
ID for those that want to see an acronym expanded -- personally, the
expansion of that acronym didn't help me understand what a FID is).
So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one of the IDs,
say Z, being the "primary". The IP router that serves all the communities
(in this case, A, B, C, D) will be assigned to the "primary" VLAN, in 
this case, Z. Endnodes
will be in one of {A, B, C, D}. IP routers serving these communities will
be assigned VLAN Z.

To clarify, if there are n communities, there will be n+1 VLANs, one
for each of the communities, and one for the IP router(s) serving
the communities in that IP subnet.

Switches are configured to know that {Z, A, B, C, D} is a special 
grouping of VLANs, such
that something transmitted from a VLAN Z port goes to all ports in the 
group, i.e., all ports in
Z, A, B, C, and D. However, something transmitted from a VLAN A port 
goes only to ports in
VLAN A and VLAN Z. Something from VLAN B goes to ports in VLAN B and VLAN Z.

*************
Now a little quiz...

For those of you that are following-- and in case I actually have 
captured the concept,
let me ask a question.

How do two endnodes in the IP subnet talk to each other?
The first case is two endnodes in VLAN A, say S and D.
S, observing that D is in the same subnet, will ARP. Since D is in the 
same VLAN, it will receive
the ARP request, and respond. Everything works fine.

But how do two endnodes in different VLANs, but in the same IP address 
block communicate? S will
ARP, like before, because IP nodes are (blissfully) unaware of VLANs. 
The answer people tell me
is "in that case communication between S and D has to go through the IP 
router". OK. So how would
that work? The
answer I get is "the switch does proxy ARP on behalf of the IP router". 
I don't understand that. How does the
switch know *when* to proxy ARP? The switch doesn't necessarily know 
which VLAN node D is in.

*******************
Well, bravely continuing on...



Endnode MAC address learning is done by VLAN as before. If a frame is
received by bridge b on
port p, with source S, from VLAN A, then bridge b remembers that {S, 
VLAN A} is on port p.

Furthermore, a Z-tagged unicast frame is checked against the learning
tables of Z, A, B, C, D, to determine where to forward it. So if bridge 
b receives
a frame with
destination=D, bridge b checks for D in any of the VLANs Z, A, B, C, D, and
forwards accordingly.



&&&&&&&&&&&&&&&&&
So, that's how bridges work (I hope). So how would we support this 
functionality in
RBridges?

As it turns out, despite the complexity of the concept,
it will not be that difficult to support this with RBridges, and
even in a somewhat more optimal way, since RBridges can do multicast
filtering within the core rather that just at the final port.

RBridges, like bridges, would have to be configured with FIDs, i.e., 
VLAN groupings as described above.

Let's call a FID by the name of the "primary" VLAN; in our example, Z.

RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z, A, B, C, D are
all 12-bit VLAN IDs.

To avoid requiring configuration of all RBridges with these FIDs, and
still allow multicast filtering, I propose we have RBridges advertise,
in their IS-IS core instance, FIDs that they are configured with. So at 
least one RBridge will say "Hey guys,
I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the other 
RBridges will, I guess
believe him.

What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says that
FID Z = {Z,A,D, F} is an interesting question, but at least there is
enough information to log an error. Lot of possibilities for overlapping 
FIDs, inconsistent FIDs, etc.
I assume all those will be errors. If there is a FID called "Z", then 
everyone better agree about what the
VLAN membership of Z is, and none of the VLANs in Z better be in any 
other FIDs.

Once there is a FID of {Z, A, B, C, D}, there will no longer be
a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or D. 
Instead
the Z-instance will announce VLANs A, B, C, and D membership as well as 
VLAN Z membership.

The Z-instance of IS-IS will specify which MAC addresses are in which VLAN.
So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f},
{A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The lower case 
letters are endnode MAC
addresses. The upper case letters are 12-bit VLAN IDs.

Multicast packets marked as VLAN Z (inner VLAN) will be sent to
all links in Z, A, B, C, or D. So the LSPs in the VLAN Z instance of 
IS-IS will
be delivered to all RBridges in Z, A, B, C, and D.

That way RBridges with ports in Z, A, B, C, and/or D will learn all the 
endnode addresses
in any of those VLANs (all the ports in FID Z).

If ingress RB1 is attached to Z, and receives a packet with
destination D tagged as Z, RB1 checks for D in VLANs A, B, C, D, and Z 
's endnode
membership. As soon as RB1 finds it, let's say, as reported by
RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2,
leaving the tag as Z. When RB2 decapsulates the packet, I assume it will
rewrite the inner VLAN tag from "Z" to "D".


&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Conclusions:

The changes to the spec:

a) announce in the core instance, FIDs as a set of VLANs, the
first listed being the "primary".

b) multicast forwarding: if the packet is (inner) tagged with
the VLAN ID of a primary VLAN in a FID, forward the packet on
all in the links in the selected tree that lead to any of the VLANs
in the FID. If the packet is tagged with the VLAN ID of a non-primary
VLAN in a FID, forward the packet on all the ports that reach
links in either that VLAN or in the primary VLAN for that FID.

c) when ingressing a packet with destination D, tagged with a
VLAN tag of a primary VLAN in a FID, check the endnode information
for all the VLANs in the FID to determine the egress RBridge.

d) when ingressing a packet with destination D, tagged with
a VLAN tag of a secondary VLAN in a FID, check the endnode
information for exactly two VLANs; the one the packet is
currently tagged with, and the primary VLAN for that FID, to
determine the egress RBridge.

e) if two RBridges, in the core instance, report inconsistent FID 
membership, what should we do?

(Note: There was a fortune cookie program in Unix, one of the fortunes 
being "Never check for an error
condition that you don't know how to handle". For the record--I think 
that's a cute joke but really bad policy.).

Radia





Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2T62SYm021618 for <[e-mail]>; Wed, 28 Mar 2007 23:02:28 -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, 28 Mar 2007 23:02:18 -0700 (PDT)
Received: from sun.com ([129.150.16.120]) 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, 28 Mar 2007 23:02:16 -0700 (PDT)
Date: Wed, 28 Mar 2007 23:02:33 -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] I completely misunderstood what "shared VLAN learning" was
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 06:03:04 -0000
Status: RO
Content-Length: 1715

I took the words "shared VLAN learning" and came up with a concept
that could be described by those words. But that's not what IEEE 802 
means by those words.

Anyway, in my next email to the list, I will describe my current 
understanding of what it is, and how we can support
it with TRILL. If indeed people are deploying this feature in layer 2, I 
think TRILL should support it.

Anyway, it took a really long time for Dinesh to explain to me what 
shared 802-style VLAN learning actually is,
and I'm still not totally sure I understand it.
Especially since when I found other 802 types in the hallways during 
IETF to ask detailed questions, I got
inconsistent answers.  And especially because I still don't understand 
how a few things actually would
work.

And now a plea -- I'm not the only one that has been confused. I suspect 
a lot of people just gave
up on trying to understand the issue. If you don't understand an issue, 
it's OK to ask someone to
explain it.

And please -- the more IEEE 802 literate people on the mailing list
should try to make fewer assumptions about what
people on this mailing understand about 802 arcana. So for instance, 
most people (including me) didn't
know what a "FID" was. It's common for email threads to be 
incomprehensible because people really
are making different assumptions, and not understanding each other.

It's always a good idea to explain everything carefully, with limited 
jargon, to ensure that everyone is
talking about the same thing. Which we weren't, in the case of the 
"shared VLAN learning" thread.

Anyway, I'm sure you're all looking forward to my next message where the 
exciting concept of
"shared VLAN learning" will be revealed.

Radia





Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2MG8dsF001285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 22 Mar 2007 09:08:39 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l2MG8UMh015120; Thu, 22 Mar 2007 10:08:30 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 22 Mar 2007 11:08:30 -0500
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: Thu, 22 Mar 2007 11:08:21 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
Thread-Index: Acdr7SvIBqQIIId6QPKNd2lipnaOwwArmFXQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>
X-OriginalArrivalTime: 22 Mar 2007 16:08:30.0737 (UTC) FILETIME=[556EC810:01C76C9C]
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 l2MG8dsF001285
Cc: [e-mail], [e-mail], IETF-Announce <[e-mail]>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2007 16:08:47 -0000
Status: RO
Content-Length: 2384

Dinesh,

	Please see one more question below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[e-mail]] 
> Sent: Wednesday, March 21, 2007 3:15 PM
> To: Eric Gray (LO/EUS)
> Cc: [e-mail]; [e-mail]; IETF-Announce
> Subject: Re: [rbridge] Last Call: 
> draft-ietf-trill-routing-reqs (TRILL Routing Requirements in 
> Support of RBridges) to Informational RFC
> 
> Hi Eric,
> 
> Eric Gray (LO/EUS) wrote:
> >>   - "Inefficient inter-bridge connection usage". What do you 
> >>     mean by this phrase?
> >>     
> >
> >   
> I guess my issue is the choice of words "inter-bridge 
> connection usage". 
> "connection" is undefined and not sure if it is the right word.
> > If traffic is demonstrably required to traverse more links
> > than some theoretical minimum, than link utilization is -
> > by definition - less efficient than it theoretically can
> > be.
> >   
> If this what you want to say, something along the lines of
"Non-optimal 
> pair-wise forwarding of unicast frames using spanning tree also
results 
> in inefficient usage of links" will be sufficient. However, I think
that 
> merely stating the lack of non-optimal pair-wise forwarding is
sufficient 
> to imply this and many other issues around this style.

I'm not sure how much clearer it is to say what you're suggesting
than what it already says.  However this is not critical text, so
what would you like it to say and where would you like it to go?

What I'm asking for is "replace text saying <$*%&(%)> with new text
saying <*$&*@(_&$&>"...

> >> What is proposed in the current solution is to run a spanning tree 
> >> protocol instance per port which maybe not scalable. 
> >>
> >> I think something like "It's strongly desirable to minimize the
> >> interaction between the bridges and Rbridges and constrain a 
> >> spanning tree" is more appropriate.
> >>     
> >
> > Yet it is difficult to imagine how this would translate to a 
> > requirement that would make sense to someone evaluating the 
> > acceptability of a routing protocol for the TRILL problem-space.
> > Perhaps it would be simpler to omit the offending text?
> >   
> OK with me.
> 
> Dinesh
> 
> -- 
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> 



Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id l2MD2QwM004569 for <[e-mail]>; Thu, 22 Mar 2007 06:02:27 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-7.tower-119.messagelabs.com!1174568545!10969164!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 32712 invoked from network); 22 Mar 2007 13:02:25 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 22 Mar 2007 13:02:25 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l2MD2PXO021980 for <[e-mail]>; Thu, 22 Mar 2007 06:02:25 -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 l2MD2Ol9028854 for <[e-mail]>; Thu, 22 Mar 2007 08:02:24 -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: Thu, 22 Mar 2007 09:02:23 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Meeting Presentations Updated
thread-index: AcdsfrCTtHr45zLVQyCHOkQxQ3R7Cg==
From: "Eastlake III Donald-LDE008" <[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 l2MD2QwM004569
Subject: [rbridge] WG Meeting Presentations Updated
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2007 13:02:37 -0000
Status: RO
Content-Length: 412

Several of the presentations given at the TRILL WG meeting yesterday
were updated in minor ways during the meeting while they were being
shown. These tweaked presentations have now been uploaded to the meeting
materials page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68

(In particular, the Agenda, -02 to -03, Multicast Input Link Filtering,
and Extensions presentations.)

Donald



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2M5Q8Ki012122 for <[e-mail]>; Wed, 21 Mar 2007 22:26:08 -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, 21 Mar 2007 22:26:04 -0700 (PDT)
Received: from sun.com ([129.150.20.59]) 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, 21 Mar 2007 22:26:04 -0700 (PDT)
Date: Wed, 21 Mar 2007 22:26:16 -0700
From: Radia Perlman <[e-mail]>
To: [e-mail], [e-mail], [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] Making fields in TRILL's IS-IS bigger?
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2007 05:26:23 -0000
Status: RO
Content-Length: 822

There were some fields in IS-IS that, 40 years ago or whatever, we made 
too small. We actually
can change the size of fields for TRILL, right? How badly would that 
make it to adapt an implementation
of IS-IS to TRILL if we changed the size of:

a) fragment number (to 2 bytes presumable)
b) pseudonode extra byte (to 2 bytes?)

Actually, I don't think b) needs to be done, because all that matters is 
that the pseudonode have
a unique ID, not that the first 6 bytes have to be the same as the 
system ID of the DR. So the
DR could assign the pseudonode address to be its MAC address *on that 
link*, with
a final byte of 1. And so a single byte, as it is currently, shouldn't 
be a problem.

So the only example I can think of in this (insomniacal) moment is the 
fragment number.
Are there any other examples?

Radia



Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LJE68q009562 for <[e-mail]>; Wed, 21 Mar 2007 12:14:07 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 20:14:07 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2LJE6xn032347;  Wed, 21 Mar 2007 20:14:06 +0100
Received: from [10.61.80.189] (ams3-vpn-dhcp4286.cisco.com [10.61.80.189]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LJE5lZ012507;  Wed, 21 Mar 2007 19:14:05 GMT
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2007 12:15:07 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0pre (X11/20070224)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1596; t=1174504446; x=1175368446; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Last=20Call=3A=20draft-ietf-trill-routing -reqs=20(TRILL=20Routing=0A=20Requirements=20in=20Support=20of=20RBridges) =20to=20Informational=20RFC |Sender:=20; bh=3B892n672ZPtgICZLegK45yWqBEOZzKHzokyAYiHNX0=; b=k9+nA2eDrBpnIbt+aK1znmS0X8fSd13HWbMuw7iiSniYtSbVcj9V+k2NhoH71mAjLcztsqQ4 wG0wUiBViQK5lwqiRle8qyIdPNDzNgEm33oyroqwtHPFbgrnXyuX6VJq;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail], IETF-Announce <[e-mail]>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 19:14:42 -0000
Status: RO
Content-Length: 1556

Hi Eric,

Eric Gray (LO/EUS) wrote:
>>   - "Inefficient inter-bridge connection usage". What do you 
>>     mean by this phrase?
>>     
>
>   
I guess my issue is the choice of words "inter-bridge connection usage". 
"connection" is undefined and not sure if it is the right word.
> If traffic is demonstrably required to traverse more links
> than some theoretical minimum, than link utilization is -
> by definition - less efficient than it theoretically can
> be.
>   
If this what you want to say, something along the lines of "Non-optimal 
pair-wise forwarding of unicast frames using spanning tree also results 
in inefficient usage of links" will be sufficient. However, I think that 
merely stating the lack of non-optimal pair-wise forwarding is 
sufficient to imply this and many other issues around this style.
>> What is proposed in the current solution is to run a spanning tree 
>> protocol instance per port which maybe not scalable. 
>>
>> I think something like "It's strongly desirable to minimize the
>> interaction between the bridges and Rbridges and constrain a 
>> spanning tree" is more appropriate.
>>     
>
> Yet it is difficult to imagine how this would translate to a 
> requirement that would make sense to someone evaluating the 
> acceptability of a routing protocol for the TRILL problem-space.
> Perhaps it would be simpler to omit the offending text?
>   
OK with me.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LBVj2Q008337 for <[e-mail]>; Wed, 21 Mar 2007 04:31:46 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 21 Mar 2007 19:24:12 +0800 (CST)
Received: from jys6053946 (dhcp-4009.ietf68.org [130.129.64.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 21 Mar 2007 19:24:12 +0800 (CST)
Date: Wed, 21 Mar 2007 19:23:31 +0800
From: caowayne <[e-mail]>
To: "Eric Gray (LO/EUS)" <[e-mail]>, Dinesh G Dutt <[e-mail]>, [e-mail]
Message-id: <009101c76bab$63717cb0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], IETF-Announce <[e-mail]>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL	Routing Requirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 11:32:16 -0000
Status: RO
Content-Length: 7447

----- Original Message ----- 
From: "Eric Gray (LO/EUS)" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "IETF-Announce" <[e-mail]>
Sent: Wednesday, March 21, 2007 6:48 PM
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC


> Dinesh,
> 
> Thank you for your comments.  Please see below...
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
>> Sent: Tuesday, March 20, 2007 10:33 PM
>> To: [e-mail]
>> Cc: [e-mail]; IETF-Announce
>> Subject: Re: [rbridge] Last Call: 
>> draft-ietf-trill-routing-reqs (TRILL Routing Requirements in 
>> Support of RBridges) to Informational RFC
>> 
>> I have a few comments on the document.
>> 
>> - Section 1, Bridging Limitations: The first two paragraphs are 
>> structured around the logic: because ethernet header doesn't have 
>> a TTL or a hop count, the only choice was to use spanning tree. 
>> IEEE 802.1 has defined several headers such as 802.1Q header that 
>> carries the VLAN. If they wanted to add a TTL, they could have. 
>> They picked spanning tree and said that therefore they didn't need 
>> a TTL.  To the extent this represents history, I think it is 
>> inaccurate. To the extent it attempts to explain the rationale for 
>> RBridges, it seems unnecessary. A sufficient replacement maybe 
>> along the lines of: 
>>
>> "Spanning Tree Protocol and its variants are the control protocol 
>> deployed in current 802.1D Ethernet bridges.  This protocol 
>> constructs a single tree out of a mesh of network connections. 
>> This tree eliminates usage of equal cost multipaths and results in 
>> non-optimal pair-wise forwarding."
>> 
> 
> This is a reasonable proposal for replacement text.  If there
> are no objections from the working group, or the IESG, I would
> be happy to make this change.
> 
> Thanks!
> 
>> - Section 1, Bridging Limitations: More specific comments:
>>   - "Because of the potential for severe impact from looping traffic, 
>>     many (if not most) current bridge implementations stop forwarding
>>     of traffic frames following a topology change event and restart 
>>     only after STP/RSTP is complete" is incorrect. All 802.1D bridges 
>>     allow (R/M)STP to complete before moving a port to forwarding 
>>     state. I'd remove the phrase in parentheses.
> 
> Good suggestion.  Assuming the same acceptance, I can make this
> change as well.
> 
>>   - "Inefficient inter-bridge connection usage". What do you 
>>     mean by this phrase?
> 
> I assume this is a reasonably well understood aspect of using
> a spanning tree as opposed to using shortest path routing.
> 
> It is not difficult to come up with a reasonable scenario in
> which shortest path forwarding results in 80% of the total
> link-by-link forwarding load that is generated by the same
> amount of traffic in a corresponding spanning tree scenario.
> 
> The reason why this happens is that a spanning tree may be
> constructed in which the path for some destinations will
> traverse at least one additional link, when arriving from
> some sources.  Practically speaking, unless a spanning tree 
> is constructed per-source bridge, it's easy to show that 
> this will be true for at least some source and destination 
> pairs.
> 
> Assuming the simplistic (VLAN-free) scenario that is basic
> to the "configuration-free" capability that is part of the
> chartered goals of TRILL, there would only be one spanning
> tree in a bridged network.  Hence, in this scenario, there
> would be many cases in which traffic traverses at least one
> additional link.
> 
> If traffic is demonstrably required to traverse more links
> than some theoretical minimum, than link utilization is -
> by definition - less efficient than it theoretically can
> be.
> 
>> 
>> - Section 1.2, Backward Compatibility and section 4.1: "...they 
>> terminate a bridged spanning tree, (i.e. - they do not forward 
>> BPDUs)". 
>>
>> I thought that we have not concluded the discussion on preventing 
>> loops for interconnected Bridges and RBridges based on the email 
>> thread that started a while back. Putting a decision in this 
>> section on the solution seems a little unnecessary. 
> 
> I am not sure that this text - or something like it - is unnecessary 
> from a compatibility perspective, and it may be the case that this 
> change would require a new working group last call.  However, if it 
> is acceptable to the IESG either that the change does not require a 
> new last call, or a second working group last call is needed, then I 
> would be happy to make this change as well.
> 
>> What is proposed in the current solution is to run a spanning tree 
>> protocol instance per port which maybe not scalable. 
>>
>> I think something like "It's strongly desirable to minimize the
>> interaction between the bridges and Rbridges and constrain a 
>> spanning tree" is more appropriate.
> 
> Yet it is difficult to imagine how this would translate to a 
> requirement that would make sense to someone evaluating the 
> acceptability of a routing protocol for the TRILL problem-space.
> Perhaps it would be simpler to omit the offending text?
> 
>> 
>> - Ethernet and 802 is used interchangeably. Isn't Ethernet 
>> 802.3 only ? 
>> Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or 
>> http://www.ieee802.org/3/.
>> 
>> I don't see anything on what I consider to be another 
>> important goal: to 
>> have a single protocol to compute unicast, multicast and broadcast 
>> routes. This reduces operational overhead by having to understand and 
>> debug a single protocol.
>> 
>> The IESG wrote:
>> > The IESG has received a request from the Transparent 
>> Interconnection of 
>> > Lots of Links WG (trill) to consider the following document:
>> >
>> > - 'TRILL Routing Requirements in Support of RBridges '
>> >    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
>> >
>> > The IESG plans to make a decision in the next few weeks, 
>> and solicits
>> > final comments on this action.  Please send substantive 
>> comments to the
>> > [e-mail] mailing lists by 2007-03-30. Exceptionally, 
>> > comments may be sent to [e-mail] instead. In either 
>> case, please 
>> > retain the beginning of the Subject line to allow automated sorting.
>> >
>> > The file can be obtained via
>> > 
>> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
>> eqs-02.txt
>> >
>> >
>> > IESG discussion can be tracked via
>> > 
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
>> w_id&dTag=15187&rfc_flag=0
>> >
>> > _______________________________________________
>> > rbridge mailing list
>> > [e-mail]
>> > http://mailman.postel.org/mailman/listinfo/rbridge
>> >
>> >   
>> 
>> -- 
>> We make our world significant by the courage of our questions and by 
>> the depth of our answers.                               - Carl Sagan
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>


Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LAmXeP026550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 21 Mar 2007 03:48:33 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l2LAmKCd025070; Wed, 21 Mar 2007 04:48:20 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 21 Mar 2007 05:48:19 -0500
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, 21 Mar 2007 05:48:15 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
Thread-Index: AcdrY1j8UPGPT/e8Tq+2mKPLSfHtQQAOLN3A
References: <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Mar 2007 10:48:19.0954 (UTC) FILETIME=[70802D20:01C76BA6]
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 l2LAmXeP026550
Cc: [e-mail], IETF-Announce <[e-mail]>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 10:49:18 -0000
Status: RO
Content-Length: 6675

Dinesh,

	Thank you for your comments.  Please see below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
> Sent: Tuesday, March 20, 2007 10:33 PM
> To: [e-mail]
> Cc: [e-mail]; IETF-Announce
> Subject: Re: [rbridge] Last Call: 
> draft-ietf-trill-routing-reqs (TRILL Routing Requirements in 
> Support of RBridges) to Informational RFC
> 
> I have a few comments on the document.
> 
> - Section 1, Bridging Limitations: The first two paragraphs are 
> structured around the logic: because ethernet header doesn't have 
> a TTL or a hop count, the only choice was to use spanning tree. 
> IEEE 802.1 has defined several headers such as 802.1Q header that 
> carries the VLAN. If they wanted to add a TTL, they could have. 
> They picked spanning tree and said that therefore they didn't need 
> a TTL.  To the extent this represents history, I think it is 
> inaccurate. To the extent it attempts to explain the rationale for 
> RBridges, it seems unnecessary. A sufficient replacement maybe 
> along the lines of: 
>
> "Spanning Tree Protocol and its variants are the control protocol 
> deployed in current 802.1D Ethernet bridges.  This protocol 
> constructs a single tree out of a mesh of network connections. 
> This tree eliminates usage of equal cost multipaths and results in 
> non-optimal pair-wise forwarding."
> 

This is a reasonable proposal for replacement text.  If there
are no objections from the working group, or the IESG, I would
be happy to make this change.

Thanks!

> - Section 1, Bridging Limitations: More specific comments:
>   - "Because of the potential for severe impact from looping traffic, 
>     many (if not most) current bridge implementations stop forwarding
>     of traffic frames following a topology change event and restart 
>     only after STP/RSTP is complete" is incorrect. All 802.1D bridges 
>     allow (R/M)STP to complete before moving a port to forwarding 
>     state. I'd remove the phrase in parentheses.

Good suggestion.  Assuming the same acceptance, I can make this
change as well.

>   - "Inefficient inter-bridge connection usage". What do you 
>     mean by this phrase?

I assume this is a reasonably well understood aspect of using
a spanning tree as opposed to using shortest path routing.

It is not difficult to come up with a reasonable scenario in
which shortest path forwarding results in 80% of the total
link-by-link forwarding load that is generated by the same
amount of traffic in a corresponding spanning tree scenario.

The reason why this happens is that a spanning tree may be
constructed in which the path for some destinations will
traverse at least one additional link, when arriving from
some sources.  Practically speaking, unless a spanning tree 
is constructed per-source bridge, it's easy to show that 
this will be true for at least some source and destination 
pairs.

Assuming the simplistic (VLAN-free) scenario that is basic
to the "configuration-free" capability that is part of the
chartered goals of TRILL, there would only be one spanning
tree in a bridged network.  Hence, in this scenario, there
would be many cases in which traffic traverses at least one
additional link.

If traffic is demonstrably required to traverse more links
than some theoretical minimum, than link utilization is -
by definition - less efficient than it theoretically can
be.

> 
> - Section 1.2, Backward Compatibility and section 4.1: "...they 
> terminate a bridged spanning tree, (i.e. - they do not forward 
> BPDUs)". 
>
> I thought that we have not concluded the discussion on preventing 
> loops for interconnected Bridges and RBridges based on the email 
> thread that started a while back. Putting a decision in this 
> section on the solution seems a little unnecessary. 

I am not sure that this text - or something like it - is unnecessary 
from a compatibility perspective, and it may be the case that this 
change would require a new working group last call.  However, if it 
is acceptable to the IESG either that the change does not require a 
new last call, or a second working group last call is needed, then I 
would be happy to make this change as well.

> What is proposed in the current solution is to run a spanning tree 
> protocol instance per port which maybe not scalable. 
>
> I think something like "It's strongly desirable to minimize the
> interaction between the bridges and Rbridges and constrain a 
> spanning tree" is more appropriate.

Yet it is difficult to imagine how this would translate to a 
requirement that would make sense to someone evaluating the 
acceptability of a routing protocol for the TRILL problem-space.
Perhaps it would be simpler to omit the offending text?

> 
> - Ethernet and 802 is used interchangeably. Isn't Ethernet 
> 802.3 only ? 
> Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or 
> http://www.ieee802.org/3/.
> 
> I don't see anything on what I consider to be another 
> important goal: to 
> have a single protocol to compute unicast, multicast and broadcast 
> routes. This reduces operational overhead by having to understand and 
> debug a single protocol.
> 
> The IESG wrote:
> > The IESG has received a request from the Transparent 
> Interconnection of 
> > Lots of Links WG (trill) to consider the following document:
> >
> > - 'TRILL Routing Requirements in Support of RBridges '
> >    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
> >
> > The IESG plans to make a decision in the next few weeks, 
> and solicits
> > final comments on this action.  Please send substantive 
> comments to the
> > [e-mail] mailing lists by 2007-03-30. Exceptionally, 
> > comments may be sent to [e-mail] instead. In either 
> case, please 
> > retain the beginning of the Subject line to allow automated sorting.
> >
> > The file can be obtained via
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> eqs-02.txt
> >
> >
> > IESG discussion can be tracked via
> > 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=15187&rfc_flag=0
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >   
> 
> -- 
> We make our world significant by the courage of our questions and by 
> the depth of our answers.                               - Carl Sagan
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L9qrXr009848 for <[e-mail]>; Wed, 21 Mar 2007 02:52:53 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2L9qpeG012907; Wed, 21 Mar 2007 09:52:51 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2L9qceQ308210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 02:52:40 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2007 02:52:33 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
To: "J. R. Rivers" <[e-mail]>
References: <[e-mail]> <[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]
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 09:53:13 -0000
Status: RO
Content-Length: 313

J. R. Rivers wrote:
> That seems more like a set of issues associated with access control
> management that is beyond the scope of TRILL.

The question we need to answer is whether RBridges need to support SVL, 
or whether we can say that we only do IVL. That is something that the WG 
needs to decide.

    Erik


Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L9XFkb004678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 21 Mar 2007 02:33:15 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l2L9w68G032638; Wed, 21 Mar 2007 03:58:07 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 21 Mar 2007 04:33:02 -0500
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, 21 Mar 2007 04:32:55 -0500
Message-ID: <[e-mail]>
In-Reply-To: <F98B60942429F3C001DF51B0@[10.0.0.174]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL	RoutingRequirements in Support of RBridges) to Informational RFC
Thread-Index: AcdrkMnZHwLXJBpAS9ixOUgLC+15IQAAe9VA
References: <[e-mail]><[e-mail]> <F98B60942429F3C001DF51B0@[10.0.0.174]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Harald Tveit Alvestrand" <[e-mail]>, "Silvano Gai" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Mar 2007 09:33:02.0092 (UTC) FILETIME=[EBA524C0:01C76B9B]
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 l2L9XFkb004678
Cc: [e-mail]
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL	RoutingRequirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 09:33:42 -0000
Status: RO
Content-Length: 2023

Harald,

	As it was originally chartered, the TRILL working group allowed
scope for definition of TRILL bridges that could be cheaply produced,
modulo the inclusion of a ink-state routing protocol as a complicating
factor.  It is not clear at this point that this has changed.

	Consequently, at least some of the people working on this are
thinking that a <well-known but not named here> work group switch may
very well be replaced by a TRILL capable bridge - possibly made by the
same vendor, at the same manufacturing facility.

--
Eric

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Harald Tveit 
> Alvestrand
> Sent: Wednesday, March 21, 2007 3:59 AM
> To: Silvano Gai; [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] Last Call: 
> draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in 
> Support of RBridges) to Informational RFC
> 
> 
> 
> --On 20. mars 2007 09:35 -0700 Silvano Gai 
> <[e-mail]> wrote:
> 
> > 5) Introduction - Bridging limitation. The first paragraph refers to
> > Ethernet networks used without Spanning Tree. This is 
> irrelevant, since
> > Spanning Tree is always deployed in conjunction with Ethernet. The
> > correct contrast must be between Ethernet with Spanning Tree and
> > Ethernet with TRILL. The claim of a single 
> broadcast/flooding domain is
> > incorrect since VLANs have solved this issue many years ago.
> 
> "always" is too strong, since most unmanaged bridges (intended for 
> consumers' home networks, but often dangled off the edge of corporate 
> networks as port expanders, without asking for permission) 
> don't seem to be 
> supporting Spanning Tree. However, these are not going to 
> support TRILL 
> either, so for the environments considered here, "always" is 
> probably true.
> 
>                Harald
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L9LaHa001505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 21 Mar 2007 02:21:36 -0700 (PDT)
Received: from [127.0.0.1] (c1-vpn2.isi.edu [128.9.176.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2L9LF9J020679; Wed, 21 Mar 2007 02:21:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 21 Mar 2007 02:21:04 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Enigmail-Version: 0.94.1.2.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE232F68094B1F8386A6E47FD"
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] protocol spec - change from "nonvolatile memory"
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 09:21:45 -0000
Status: RO
Content-Length: 1080

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE232F68094B1F8386A6E47FD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Silvano (et al.),

I'd like to suggest a change from:

   Once an RBridge has successfully acquired an address it SHOULD store
   it in non-volatile memory and reuse it in the case of a reboot.

to:

   Once an RBridge has successfully acquired an address it SHOULD reuse
   it in the case of a restart.

I.e., I think it's sufficient to describe the behavior desired.

Joe


--------------enigE232F68094B1F8386A6E47FD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iD8DBQFGAPkAE5f5cImnZrsRAgKQAKD6ygUIQjR50qU9syWPodeOkqrsbwCcDGuF
J3TJ2dZjpVdGX/dVEDR2o5A=
=HwHx
-----END PGP SIGNATURE-----

--------------enigE232F68094B1F8386A6E47FD--



Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L7wxn6009671 for <[e-mail]>; Wed, 21 Mar 2007 00:58:59 -0700 (PDT)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D6C925973B; Wed, 21 Mar 2007 08:58:58 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04941-04; Wed, 21 Mar 2007 08:58:53 +0100 (CET)
Received: from [192.168.1.108] (dhcp-4009.ietf68.org [130.129.64.9]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28B88259739; Wed, 21 Mar 2007 08:58:53 +0100 (CET)
Date: Wed, 21 Mar 2007 08:58:42 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Silvano Gai <[e-mail]>, [e-mail]
Message-ID: <F98B60942429F3C001DF51B0@[10.0.0.174]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.7 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL	RoutingRequirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 07:59:10 -0000
Status: RO
Content-Length: 885

--On 20. mars 2007 09:35 -0700 Silvano Gai <[e-mail]> wrote:

> 5) Introduction - Bridging limitation. The first paragraph refers to
> Ethernet networks used without Spanning Tree. This is irrelevant, since
> Spanning Tree is always deployed in conjunction with Ethernet. The
> correct contrast must be between Ethernet with Spanning Tree and
> Ethernet with TRILL. The claim of a single broadcast/flooding domain is
> incorrect since VLANs have solved this issue many years ago.

"always" is too strong, since most unmanaged bridges (intended for 
consumers' home networks, but often dangled off the edge of corporate 
networks as port expanders, without asking for permission) don't seem to be 
supporting Spanning Tree. However, these are not going to support TRILL 
either, so for the environments considered here, "always" is probably true.

               Harald



Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L2WaOC026704 for <[e-mail]>; Tue, 20 Mar 2007 19:32:37 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 03:32:37 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2L2WaMw028963;  Wed, 21 Mar 2007 03:32:36 +0100
Received: from [10.61.64.82] (ams3-vpn-dhcp82.cisco.com [10.61.64.82]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2L2WQlZ028451;  Wed, 21 Mar 2007 02:32:30 GMT
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2007 19:33:26 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0pre (X11/20070224)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3794; t=1174444356; x=1175308356; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Last=20Call=3A=20draft-ietf-trill-routing -reqs=20(TRILL=20Routing=0A=20Requirements=20in=20Support=20of=20RBridges) =20to=20Informational=20RFC |Sender:=20; bh=AjsGKDhOhMecKvZK9zqnRhTFCeCkXmLXizvBO65OSYY=; b=Kr7S9DnWTU9skuLB41DL8ajwEZCJmJxdU1Mc7Fo3Mc651LdJ9N7sFahbeFae7bqHKy6UYvF9 ZPVelcqJkOXIoh1KV7tsL0nZHTycrkx1ps31xNEIIaDtDQhYENX/Pf0S;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], IETF-Announce <[e-mail]>
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 02:33:45 -0000
Status: RO
Content-Length: 3717

I have a few comments on the document.

- Section 1, Bridging Limitations: The first two paragraphs are 
structured around the logic: because ethernet header doesn't have a TTL 
or a hop count, the only choice was to use spanning tree. IEEE 802.1 has 
defined several headers such as 802.1Q header that carries the VLAN. If 
they wanted to add a TTL, they could have. They picked spanning tree and 
said that therefore they didn't need a TTL.  To the extent this 
represents history, I think it is inaccurate. To the extent it attempts 
to explain the rationale for RBridges, it seems unnecessary. A 
sufficient replacement maybe along the lines of: "Spanning Tree Protocol 
and its variants are the control protocol deployed in current 802.1D 
Ethernet bridges. This protocol constructs a single tree out of a mesh 
of network connections. This tree eliminates usage of equal cost 
multipaths and results in non-optimal pair-wise forwarding."

- Section 1, Bridging Limitations: More specific comments:
  - "Because of the potential for severe impact from looping traffic, 
many (if not most) current bridge  
    implementations stop forwarding of traffic frames following a 
topology change event and restart only after STP/RSTP is
    complete" is incorrect. All 802.1D bridges allow (R/M)STP to 
complete before moving a port to forwarding state. I'd
    remove the phrase in parentheses.
  - "Inefficient inter-bridge connection usage". What do you mean by 
this phrase ?

- Section 1.2, Backward Compatibility and section 4.1: "...they 
terminate a bridged spanning tree, (i.e. - they do not forward BPDUs)". 
I thought that we have not concluded the discussion on preventing loops 
for interconnected Bridges and RBridges based on the email thread that 
started a while back. Putting a decision in this section on the solution 
seems a little unnecessary. What is proposed in the current solution is 
to run a spanning tree protocol instance per port which maybe not 
scalable. I think something like "It's strongly desirable to minimize 
the interaction between the bridges and Rbridges and constrain a 
spanning tree" is more appropriate.

- Ethernet and 802 is used interchangeably. Isn't Ethernet 802.3 only ? 
Look at: http://en.wikipedia.org/wiki/IEEE_802.3 or 
http://www.ieee802.org/3/.

I don't see anything on what I consider to be another important goal: to 
have a single protocol to compute unicast, multicast and broadcast 
routes. This reduces operational overhead by having to understand and 
debug a single protocol.

The IESG wrote:
> The IESG has received a request from the Transparent Interconnection of 
> Lots of Links WG (trill) to consider the following document:
>
> - 'TRILL Routing Requirements in Support of RBridges '
>    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2007-03-30. Exceptionally, 
> comments may be sent to [e-mail] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KLYdZk008754 for <[e-mail]>; Tue, 20 Mar 2007 14:34:39 -0700 (PDT)
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: Tue, 20 Mar 2007 14:34:36 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC
thread-index: AcdoFdpWI6S5xbwWQBS+xJJb9a4hygC26h0gAAi5KnAAB/bbUA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Eric Gray \(LO/EUS\)" <[e-mail]>, <[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 l2KLYdZk008754
Cc: [e-mail]
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 21:35:03 -0000
Status: RO
Content-Length: 11721

Eric,

Inline

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[e-mail]]
> Sent: Tuesday, March 20, 2007 11:31 AM
> To: Silvano Gai; [e-mail]
> Cc: [e-mail]
> Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs
> (TRILLRoutingRequirements in Support of RBridges) to Informational RFC
> 
> Silvano,
> 
> 	Thanks for posting these comments.  Please see below.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Silvano Gai
> > Sent: Tuesday, March 20, 2007 12:35 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [rbridge] Last Call:
> > draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in
> > Support of RBridges) to Informational RFC
> >
> >
> > This document has some issues that need to be corrected before it
can
> > pass an IESG last call.
> 
> I think as a strict matter of process, we don't get to say what MUST
be
> corrected before a document can pass IESG last call (if there is such
a
> thing).
> 
> Luckily, I believe this is an IETF Last Call, where the idea is that
the
> IESG is asking for our input before making _their_ decision as to what
-
> if anything - MUST be changed.
> 
> >
> > In order of importance:
> > 1) The document equates Ethernet with IEEE 802 and this is clearly
> > incorrect, since IEEE 802 includes also technologies like Token
Ring,
> > DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet
> > must be equated with IEEE 802.3
> 
> Which is historically at least as incorrect.
> 
> This comment was made during the working group last call.  Specific
> changes were made that I hoped would address this comment.

I made many comments to this document during working group last call,
some were considered, some were ignored. There was not a second WG last
call, the IESG last call was posted and I repeated the comments that
were not addressed and that I think need to be addressed. I may have
used slightly different words  in the two postings.

> 
> Why did you not earlier state specifically what part of the changes
> made were not satisfactory to you at that time?
> 

I stated very clear that IEEE 802 is a larger project that includes not
only Ethernet, but Token Ring, Token Bus, DQDB, Wireless, etc.

Ethernet is specified in IEEE 802.3.

Since you and I continue to disagree and you don't accept to replace
IEEE 802 with IEEE 802.3 I think this should be judged by an IEEE expert
in the IESG.

> >
> > 2) The document discusses Spanning Tree compatibility in section 1.2
> > where it claims that BPDUs must be terminated and in Section 4.1
where
> > the term "block" is used. This is clearly in contrast with what
> > discussed in the WG and in the base protocol spec, where BPDUs are
at
> > least processed (in one proposal) or even sourced by RBridges (in an
> > alternate proposal).
> 
> This was the terminology decided on by the working group at the time.
> 
> This comment was also made during the working group last call, and
> explanations were provided and - I believe - some small explanatory
> changes were made to the text.
> 
> Again, why did you not earlier state specifically what part of the
> changes made were not satisfactory to you at that time?
> 

I stated at that time that this text was inappropriate and the base
protocol draft contains text agreed in the WG that contradict your view.

> >
> > 3) Section 1.1 Terminology is formally incorrect since [TARCH] is
not
> an
> > approved document. It is also substantially incorrect since many
terms
> > listed are not used in this document and some are not agreed in the
> WG.
> > I propose to eliminate this section.
> 
> As a matter of process, again, this issue is addressed by listing the
> Architecture as a Normative reference.
> 
> Because the document is intended to be an informational RFC, the WG
> chairs informed me that IESG members are comfortable with pushing this
> to IETF last call ahead of its (one) normative reference.
> 
> That, again, is their prerogative.
> 
> >
> > 4) The document uses the term "will" that is not compliant with
> RFC2119.
> > In general a better definition of what is mandatory and what is
> optional
> > is important in a requirement document.
> 
> This is an informational document, proposed as an informational RFC.
> 
> This is also a requirements document, stating what is needed from any
> candidate routing protocol.  It is not an options list, or a wish
list.
> People may decide to ignore requirements in this document, and that is
> okay - because it is strictly informational.  The requirements listed
> in this document represent the things that the TRILL working group had
> agreed were needed and should be documented at the time the document
> was/is/will be published.
> 
> The choice to avoid 2119 language was - for this reason - a deliberate
> one, discussed on several occasions in the working group.  There is no
> inclusion of the "usage" of RFC 2119 terminology, nor any reference to
> RFC 2119.  Hence the word "will" can be, and is, used as it would be
> interpreted in the English language.
> 
> If you would care to provide a reasonably authoritative reference for
> English usage of the word "will" that is in conflict with any specific
> usage of the word in this document, I'd be happy to consider including
> it as a reference in this document and changing the specific instances
> you point out.
> 
> >
> > 5) Introduction - Bridging limitation. The first paragraph refers to
> > Ethernet networks used without Spanning Tree. This is irrelevant,
> > since Spanning Tree is always deployed in conjunction with Ethernet.
> 
> This follows only because:
> 
> o	you disagree with the inclusive way this document uses the term
> 	Ethernet.  Let's not conflate issues here.
> 
> 	The way the document uses the term Ethernet was explained to you
> 
> 	- and to the working group - as a result of your earlier working
> 
> 	group last call comments.
> 
> o	you exclude Ethernet deployments in small networks where small
> 	Ethernet switches _clearly_ do not use spanning tree.
> 
> o	you exclude Ethernet, and Ethernet-like, encapsulation in new,
> 	in progress, and yet to be developed technologies in making
> 	this statement.
> 
> In short, your statement that spanning tree is always used in Ethernet
> networks is correct only if you define Ethernet networks as including
> spanning tree.  Interestingly enough, I do not recall that spanning
> tree is actually defined by 802.3.
> 

That is because the work that TRILL does is really an IEEE 802.1
replacement, but still DOES NOT cover IEEE 802 as a whole.


> There was not at the time of the working group last call, nor have
> I seen any indication that there is now, a consensus to change the
> wording of this document with respect to this issue.
> 
> My earlier justification that using a less inclusive interpretation
> of "Ethernet" would mean replacing the term Ethernet with a more
> explicitly inclusive (and complex) phrase in each place where it
> occurs, still applies.
> 
> > The correct contrast must be between Ethernet with Spanning Tree and
> > Ethernet with TRILL.
> 
> This only follows if you assume that the way that Ethernet is used
> in this document is wrong.
> 
> A point has been made - more than once - that there is no absolutely
> cannonical definition of Ethernet. 

Not True. Ethernet is commonly defined as:
Digital Equipment Corporation, Intel, Xerox, The Ethernet, Version 2.0,
November 1982.

This document and the term "Ethernet" are widely referenced in IEEE
802.3 (just do a search on the PDF file). In particular TRILL uses the
Ethernet V2 encapsulation (the same used by IEEE 802.1Q) in which Length
is replaced by Type. Please see IEEE 802.3 standard.


 You might choose to decide that
> Ethernet is defined by 802.3 - in spite of the fact that Ethernet and
> 802.3 have been considered by many to be distinct for many years.  If
> you do, then you would be limiting the definition to exclude how the
> technology works with bridges, 

I never said that bridges are IEEE 802.3, Bridges are a combination of
IEEE 802.1D and IEEE 802.1Q.

-- Silvano


and you would be forcing arbitrarily
> complicated verbiage in what is essentially a relatively high-level
> document that doesn't need that degree of technical precision.  And
> you would still be wrong by some (other) definitions of Ethernet.
> 
> > The claim of a single broadcast/flooding domain is incorrect since
> > VLANs have solved this issue many years ago.
> 
> For the purposes of this document, it is not explicitly necessary -
> nor necessarily even a good idea - to dwell in too great detail on
> the ways that a domain that would be "a single broadcast/flooding
> domain" in the absence of VLANs, becomes multiply sub-setted by the
> inclusions of VLANs.
> 
> I do not recall seeing this comment during the working group last
> call.  If I had, one of the things I would have pointed out is that
> this is not explicitly an "issue" in forming requirements in this
> document, and that your taking exception to the wording - in a more
> representative context - is based on your interpretation of the
> statement (possibly in a less representative context).  Here is the
> context:
> 
> "... bridged networks consist of single broadcast/flooding domains."
> 
> One - fairly simplistic - way to look at VLANs is that the use of a
> VLAN ID allows VLAN bridges to treat the non-VLAN broadcast domain
> as having been divided into multiple logical broadcast domains, with
> each such logical broadcast domain being effectively - logically -
> a bridged network consisting of a single broadcast/flooding domain.
> 
> In this view, the statement is not incorrect - however you might not
> like it.
> 
> If you would like me to phrase this point some other way, propose an
> alternative wording, don't just say "it's wrong."
> 
> >
> > -- Silvano Gai
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
[mailto:[e-mail]]
> > On
> > > Behalf Of The IESG
> > > Sent: Friday, March 16, 2007 2:53 PM
> > > To: IETF-Announce
> > > Cc: [e-mail]
> > > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL
> > > RoutingRequirements in Support of RBridges) to Informational RFC
> > >
> > > The IESG has received a request from the Transparent
Interconnection
> > of
> > > Lots of Links WG (trill) to consider the following document:
> > >
> > > - 'TRILL Routing Requirements in Support of RBridges '
> > >    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
> > >
> > > The IESG plans to make a decision in the next few weeks,
> > and solicits
> > > final comments on this action.  Please send substantive comments
to
> > the
> > > [e-mail] mailing lists by 2007-03-30. Exceptionally,
> > > comments may be sent to [e-mail] instead. In either
> > case, please
> > > retain the beginning of the Subject line to allow automated
sorting.
> > >
> > > The file can be obtained via
> > >
> > http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> > eqs-02.txt
> > >
> > >
> > > IESG discussion can be tracked via
> > >
> > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> > w_id&dTag=
> > 15
> > > 187&rfc_flag=0
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [e-mail]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KKTcNb018599 for <[e-mail]>; Tue, 20 Mar 2007 13:29:39 -0700 (PDT)
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: Tue, 20 Mar 2007 13:29:21 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
thread-index: AcdrK10TFuxFniX1QcKAoJnSnsOimAAAvQBQ
References: <[e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "Erik Nordmark" <[e-mail]>, "Caitlin Bestler" <[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 l2KKTcNb018599
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 20:29:47 -0000
Status: RO
Content-Length: 2204

That seems more like a set of issues associated with access control
management that is beyond the scope of TRILL.

JR
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Tuesday, March 20, 2007 12:53 PM
> To: Caitlin Bestler
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> Caitlin Bestler wrote:
> 
> > It's a perfectly reasonable behavior, as long as the VID is at
> > least checked (i.e., it is an attribute, not a key field). A set
> > of RBridges that *all* used this approach would work perfectly fine.
> 
> Are you taking into account hosts that maliciously change their MAC 
> address in order to affect the bridging of packets for a host 
> that is on 
> a different VLAN?
> 
> Are you taking int account hosts that are part of multiple 
> VLANs using a 
> single NIC and single MAC address (servers often are 
> configured in such 
> ways by having the server add the 802.1Q headers and the bridge just 
> enforce that the VID is in the allowed set for that port).
> 
>     Erik
> 
> 
> 
> > The real issue is whether RBridges that will realistically tend to
> > use Independent Learning can easily accommodate some of their peers
> > doing Shared Learning, and if so, how.
> > 
> > For example, the rule could be that you can use Shared Learning as
> > long as no other RBridge can detect that you aren't using 
> Independent
> > Learning. Or Shared/Independent Learning could be a flag that each
> > RBridge advertises. Or each RBridge could advertise it's 
> VID->FID map.
> > 
> > All of these work, the question is which are justified. As much as I
> > dislike increasing the key size I can certainly see the 
> advantages to
> > maintaining a distributed database of requiring all RBridges to use
> > Independent Learning. So I'd lean toward simply standardizing on
> > Independent Learning. But any new requirement is best explicitly
> > stated, not inferred from the data descriptions.
> > 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KJrROa007931 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Tue, 20 Mar 2007 12:53:27 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.104.31]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2KJrKLY020866; Tue, 20 Mar 2007 19:53:22 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2KJrGtQ233171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 12:53:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2007 12:53:11 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
To: Caitlin Bestler <[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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 19:53:46 -0000
Status: RO
Content-Length: 1550

Caitlin Bestler wrote:

> It's a perfectly reasonable behavior, as long as the VID is at
> least checked (i.e., it is an attribute, not a key field). A set
> of RBridges that *all* used this approach would work perfectly fine.

Are you taking into account hosts that maliciously change their MAC 
address in order to affect the bridging of packets for a host that is on 
a different VLAN?

Are you taking int account hosts that are part of multiple VLANs using a 
single NIC and single MAC address (servers often are configured in such 
ways by having the server add the 802.1Q headers and the bridge just 
enforce that the VID is in the allowed set for that port).

    Erik



> The real issue is whether RBridges that will realistically tend to
> use Independent Learning can easily accommodate some of their peers
> doing Shared Learning, and if so, how.
> 
> For example, the rule could be that you can use Shared Learning as
> long as no other RBridge can detect that you aren't using Independent
> Learning. Or Shared/Independent Learning could be a flag that each
> RBridge advertises. Or each RBridge could advertise it's VID->FID map.
> 
> All of these work, the question is which are justified. As much as I
> dislike increasing the key size I can certainly see the advantages to
> maintaining a distributed database of requiring all RBridges to use
> Independent Learning. So I'd lean toward simply standardizing on
> Independent Learning. But any new requirement is best explicitly
> stated, not inferred from the data descriptions.
> 



Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KIUs0D011896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 20 Mar 2007 11:30:54 -0700 (PDT)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l2KItic8010981; Tue, 20 Mar 2007 12:55:44 -0600
Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 20 Mar 2007 13:30:41 -0500
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: Tue, 20 Mar 2007 13:30:32 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC
Thread-Index: AcdoFdpWI6S5xbwWQBS+xJJb9a4hygC26h0gAAi5KnA=
References: <[e-mail]> <[e-mail]>
From: "Eric Gray \(LO/EUS\)" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Mar 2007 18:30:41.0387 (UTC) FILETIME=[DD452BB0:01C76B1D]
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 l2KIUs0D011896
Cc: [e-mail]
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 18:31:23 -0000
Status: RO
Content-Length: 9481

Silvano,

	Thanks for posting these comments.  Please see below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Silvano Gai
> Sent: Tuesday, March 20, 2007 12:35 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] Last Call: 
> draft-ietf-trill-routing-reqs (TRILLRoutingRequirements in 
> Support of RBridges) to Informational RFC
> 
> 
> This document has some issues that need to be corrected before it can
> pass an IESG last call.

I think as a strict matter of process, we don't get to say what MUST be
corrected before a document can pass IESG last call (if there is such a
thing).

Luckily, I believe this is an IETF Last Call, where the idea is that the
IESG is asking for our input before making _their_ decision as to what -
if anything - MUST be changed.

> 
> In order of importance:
> 1) The document equates Ethernet with IEEE 802 and this is clearly
> incorrect, since IEEE 802 includes also technologies like Token Ring,
> DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet
> must be equated with IEEE 802.3

Which is historically at least as incorrect.

This comment was made during the working group last call.  Specific
changes were made that I hoped would address this comment.

Why did you not earlier state specifically what part of the changes
made were not satisfactory to you at that time?

> 
> 2) The document discusses Spanning Tree compatibility in section 1.2
> where it claims that BPDUs must be terminated and in Section 4.1 where
> the term "block" is used. This is clearly in contrast with what
> discussed in the WG and in the base protocol spec, where BPDUs are at
> least processed (in one proposal) or even sourced by RBridges (in an
> alternate proposal).

This was the terminology decided on by the working group at the time.

This comment was also made during the working group last call, and
explanations were provided and - I believe - some small explanatory
changes were made to the text.

Again, why did you not earlier state specifically what part of the 
changes made were not satisfactory to you at that time?

> 
> 3) Section 1.1 Terminology is formally incorrect since [TARCH] is not
an
> approved document. It is also substantially incorrect since many terms
> listed are not used in this document and some are not agreed in the
WG.
> I propose to eliminate this section.

As a matter of process, again, this issue is addressed by listing the
Architecture as a Normative reference.

Because the document is intended to be an informational RFC, the WG 
chairs informed me that IESG members are comfortable with pushing this
to IETF last call ahead of its (one) normative reference.

That, again, is their prerogative.

> 
> 4) The document uses the term "will" that is not compliant with
RFC2119.
> In general a better definition of what is mandatory and what is
optional
> is important in a requirement document.

This is an informational document, proposed as an informational RFC.

This is also a requirements document, stating what is needed from any
candidate routing protocol.  It is not an options list, or a wish list.
People may decide to ignore requirements in this document, and that is
okay - because it is strictly informational.  The requirements listed
in this document represent the things that the TRILL working group had
agreed were needed and should be documented at the time the document 
was/is/will be published.

The choice to avoid 2119 language was - for this reason - a deliberate
one, discussed on several occasions in the working group.  There is no
inclusion of the "usage" of RFC 2119 terminology, nor any reference to
RFC 2119.  Hence the word "will" can be, and is, used as it would be
interpreted in the English language.

If you would care to provide a reasonably authoritative reference for
English usage of the word "will" that is in conflict with any specific
usage of the word in this document, I'd be happy to consider including 
it as a reference in this document and changing the specific instances
you point out.

> 
> 5) Introduction - Bridging limitation. The first paragraph refers to
> Ethernet networks used without Spanning Tree. This is irrelevant, 
> since Spanning Tree is always deployed in conjunction with Ethernet. 

This follows only because: 

o	you disagree with the inclusive way this document uses the term 
	Ethernet.  Let's not conflate issues here.
	
	The way the document uses the term Ethernet was explained to you

	- and to the working group - as a result of your earlier working

	group last call comments.

o	you exclude Ethernet deployments in small networks where small
	Ethernet switches _clearly_ do not use spanning tree.

o	you exclude Ethernet, and Ethernet-like, encapsulation in new,
	in progress, and yet to be developed technologies in making 
	this statement.

In short, your statement that spanning tree is always used in Ethernet
networks is correct only if you define Ethernet networks as including
spanning tree.  Interestingly enough, I do not recall that spanning 
tree is actually defined by 802.3.

There was not at the time of the working group last call, nor have 
I seen any indication that there is now, a consensus to change the
wording of this document with respect to this issue. 

My earlier justification that using a less inclusive interpretation
of "Ethernet" would mean replacing the term Ethernet with a more 
explicitly inclusive (and complex) phrase in each place where it 
occurs, still applies.

> The correct contrast must be between Ethernet with Spanning Tree and
> Ethernet with TRILL. 

This only follows if you assume that the way that Ethernet is used
in this document is wrong.

A point has been made - more than once - that there is no absolutely 
cannonical definition of Ethernet.  You might choose to decide that
Ethernet is defined by 802.3 - in spite of the fact that Ethernet and
802.3 have been considered by many to be distinct for many years.  If 
you do, then you would be limiting the definition to exclude how the
technology works with bridges, and you would be forcing arbitrarily
complicated verbiage in what is essentially a relatively high-level
document that doesn't need that degree of technical precision.  And
you would still be wrong by some (other) definitions of Ethernet.

> The claim of a single broadcast/flooding domain is incorrect since 
> VLANs have solved this issue many years ago.

For the purposes of this document, it is not explicitly necessary -
nor necessarily even a good idea - to dwell in too great detail on
the ways that a domain that would be "a single broadcast/flooding
domain" in the absence of VLANs, becomes multiply sub-setted by the
inclusions of VLANs.

I do not recall seeing this comment during the working group last
call.  If I had, one of the things I would have pointed out is that
this is not explicitly an "issue" in forming requirements in this
document, and that your taking exception to the wording - in a more 
representative context - is based on your interpretation of the 
statement (possibly in a less representative context).  Here is the 
context:

"... bridged networks consist of single broadcast/flooding domains."

One - fairly simplistic - way to look at VLANs is that the use of a
VLAN ID allows VLAN bridges to treat the non-VLAN broadcast domain
as having been divided into multiple logical broadcast domains, with
each such logical broadcast domain being effectively - logically -
a bridged network consisting of a single broadcast/flooding domain.

In this view, the statement is not incorrect - however you might not
like it.

If you would like me to phrase this point some other way, propose an
alternative wording, don't just say "it's wrong."

> 
> -- Silvano Gai
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of The IESG
> > Sent: Friday, March 16, 2007 2:53 PM
> > To: IETF-Announce
> > Cc: [e-mail]
> > Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL
> > RoutingRequirements in Support of RBridges) to Informational RFC
> > 
> > The IESG has received a request from the Transparent Interconnection
> of
> > Lots of Links WG (trill) to consider the following document:
> > 
> > - 'TRILL Routing Requirements in Support of RBridges '
> >    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
> > 
> > The IESG plans to make a decision in the next few weeks, 
> and solicits
> > final comments on this action.  Please send substantive comments to
> the
> > [e-mail] mailing lists by 2007-03-30. Exceptionally,
> > comments may be sent to [e-mail] instead. In either 
> case, please
> > retain the beginning of the Subject line to allow automated sorting.
> > 
> > The file can be obtained via
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> eqs-02.txt
> > 
> > 
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=
> 15
> > 187&rfc_flag=0
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KHHXeB019693 for <[e-mail]>; Tue, 20 Mar 2007 10:17:33 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 20 Mar 2007 10:17:18 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 6EE942AF; Tue, 20 Mar 2007 10:17:18 -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 59E7B2AE; Tue, 20 Mar 2007 10:17:18 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBY75200; Tue, 20 Mar 2007 10:17:17 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 3BD3069CA3; Tue, 20 Mar 2007 10:17:17 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 20 Mar 2007 10:16:51 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAMXCd8AAKFPHYAAAaEEQ
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 6A1EC8943706110898-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 l2KHHXeB019693
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 17:17:51 -0000
Status: RO
Content-Length: 2129

Silvano Gai wrote:
> Caitlin,
> 
> inline
> 
>> -----Original Message-----
>> From: Caitlin Bestler [mailto:[e-mail]]
>> Sent: Monday, March 19, 2007 2:50 PM
>> To: Silvano Gai; Radia Perlman
>> Cc: [e-mail]; Erik Nordmark
>> Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness
>> 
>> Silvano Gai wrote:
>>> I think TRILL needs to do exactly what IEEE 802.1Q does.
>>> AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M
>>> =N. 
>>> 
>>> N is never advertised outside the bridge, and the mapping of M to N
>>> is never advertised outside the bridge. TRILL must do the same.
>>> 
>>> Learning is done on {VID, MAC-address} pairs. TRILL must do the
>>> same. 
>>> 
>> My reading of Appendix B is that Shared Learning is allowed, where
>> VID is not a key field (i.e, there is only one FID supported).
>> Appendix B details some of the problems this creates. I believe the
>> problems for RBridges are even greater than for simple Bridges. This
>> probably justifies restricting RBridges to the Independent Learning
>> model, but any such additional restriction should be explicitly
>> stated. 
> 
> I am not saying I want to restrict, I am saying that in
> bridges what triggers learning is always the reception of a
> frame that has a {VID, MAC-address} pair. The fact that the
> VID, on that particular bridge, shares the FID with other
> VIDs is what causes shared learning. But shared learning
> NEVER propagates. TRILL MUST NOT propagate shared learning.
> IT MUST always propagate {VID, MAC-address}. Recipients may
> decide to do individual or shared learning.
> 
> -- Silvano

>From a standards point of view I could see stating that all
TRILL-related protocols MUST be based on Independent Learning,
but that an RBridge MAY use Shared Learning for its local ports
when acting as a Bridge. And I suppose if you literally grafted
an RBridge as an add-on module to an existing Bridge with shared
learning it might even make sense.

Effectively, however, it is requiring RBridges to use Independent
Learning. I see that requirement as inevitable, and therefore best
stated explicitly.




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KH6kbQ016259 for <[e-mail]>; Tue, 20 Mar 2007 10:06:46 -0700 (PDT)
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: Tue, 20 Mar 2007 10:06:43 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
thread-index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAMXCd8AAKFPHYA==
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Radia Perlman" <[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 l2KH6kbQ016259
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 17:07:10 -0000
Status: RO
Content-Length: 1545

Caitlin,

inline

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]]
> Sent: Monday, March 19, 2007 2:50 PM
> To: Silvano Gai; Radia Perlman
> Cc: [e-mail]; Erik Nordmark
> Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> Silvano Gai wrote:
> > I think TRILL needs to do exactly what IEEE 802.1Q does.
> > AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M
>=N.
> >
> > N is never advertised outside the bridge, and the mapping of
> > M to N is never advertised outside the bridge. TRILL must do the
same.
> >
> > Learning is done on {VID, MAC-address} pairs. TRILL must do the
same.
> >
> My reading of Appendix B is that Shared Learning is allowed, where VID
> is not a key field (i.e, there is only one FID supported). Appendix B
> details some of the problems this creates. I believe the problems for
> RBridges are even greater than for simple Bridges. This probably
> justifies
> restricting RBridges to the Independent Learning model, but any such
> additional restriction should be explicitly stated.

I am not saying I want to restrict, I am saying that in bridges what
triggers learning is always the reception of a frame that has a {VID,
MAC-address} pair. The fact that the VID, on that particular bridge,
shares the FID with other VIDs is what causes shared learning. But
shared learning NEVER propagates. TRILL MUST NOT propagate shared
learning. IT MUST always propagate {VID, MAC-address}. Recipients may
decide to do individual or shared learning.

-- Silvano



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KGZ8Rv004982 for <[e-mail]>; Tue, 20 Mar 2007 09:35:08 -0700 (PDT)
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: Tue, 20 Mar 2007 09:35:03 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC
thread-index: AcdoFdpWI6S5xbwWQBS+xJJb9a4hygC26h0g
References: <[e-mail]>
From: "Silvano Gai" <[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 l2KGZ8Rv004982
Cc: [e-mail]
Subject: Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 16:35:57 -0000
Status: RO
Content-Length: 2952

This document has some issues that need to be corrected before it can
pass an IESG last call.

In order of importance:
1) The document equates Ethernet with IEEE 802 and this is clearly
incorrect, since IEEE 802 includes also technologies like Token Ring,
DQDB, Wireless that are clearly outside the scope of TRILL. Ethernet
must be equated with IEEE 802.3

2) The document discusses Spanning Tree compatibility in section 1.2
where it claims that BPDUs must be terminated and in Section 4.1 where
the term "block" is used. This is clearly in contrast with what
discussed in the WG and in the base protocol spec, where BPDUs are at
least processed (in one proposal) or even sourced by RBridges (in an
alternate proposal).

3) Section 1.1 Terminology is formally incorrect since [TARCH] is not an
approved document. It is also substantially incorrect since many terms
listed are not used in this document and some are not agreed in the WG.
I propose to eliminate this section.

4) The document uses the term "will" that is not compliant with RFC2119.
In general a better definition of what is mandatory and what is optional
is important in a requirement document.

5) Introduction - Bridging limitation. The first paragraph refers to
Ethernet networks used without Spanning Tree. This is irrelevant, since
Spanning Tree is always deployed in conjunction with Ethernet. The
correct contrast must be between Ethernet with Spanning Tree and
Ethernet with TRILL. The claim of a single broadcast/flooding domain is
incorrect since VLANs have solved this issue many years ago.

-- Silvano Gai



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of The IESG
> Sent: Friday, March 16, 2007 2:53 PM
> To: IETF-Announce
> Cc: [e-mail]
> Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL
> RoutingRequirements in Support of RBridges) to Informational RFC
> 
> The IESG has received a request from the Transparent Interconnection
of
> Lots of Links WG (trill) to consider the following document:
> 
> - 'TRILL Routing Requirements in Support of RBridges '
>    <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to
the
> [e-mail] mailing lists by 2007-03-30. Exceptionally,
> comments may be sent to [e-mail] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
>
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
> 
> 
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15
> 187&rfc_flag=0
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KG6TXX025902 for <[e-mail]>; Tue, 20 Mar 2007 09:06:29 -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, 20 Mar 2007 09:06:15 -0700 (PDT)
Received: from sun.com ([129.150.17.10]) 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, 20 Mar 2007 09:06:14 -0700 (PDT)
Date: Tue, 20 Mar 2007 09:06:26 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Erik Nordmark <[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]>
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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 16:06:44 -0000
Status: RO
Content-Length: 1136

Re Erik's:

 >>I don't see it being a reasonable default for RBridges.

Not just not reasonable as default, but *ever*. I'm sure we don't want 
to have a parameter
allowing RBridges to do shared learning.

Radia



Erik Nordmark wrote:

> Caitlin Bestler wrote:
>
>> My reading of Appendix B is that Shared Learning is allowed, where VID
>> is not a key field (i.e, there is only one FID supported). Appendix B
>> details some of the problems this creates. I believe the problems for
>> RBridges are even greater than for simple Bridges. This probably
>> justifies
>> restricting RBridges to the Independent Learning model, but any such
>> additional restriction should be explicitly stated.
>
>
> My understanding is is that shared learning is useless when VLANs are 
> used for isolation/security. With shared learning a host on VLAN A can 
> trivially cause a DoS attack VLAN B by just sending packets with the 
> source MAC address being the MAC address of another host on another VLAN.
>
> Thus I'd be surprised if it is used much in practice with bridges.
>
> I don't see it being a reasonable default for RBridges.
>
>    Erik




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KFipb1018540 for <[e-mail]>; Tue, 20 Mar 2007 08:44:51 -0700 (PDT)
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: Tue, 20 Mar 2007 08:44:35 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
thread-index: AcdrA2TDkMxQS/IcSE2K+shaF8GFHgAAyGsQ
References: <[e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "Erik Nordmark" <[e-mail]>, "Caitlin Bestler" <[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 l2KFipb1018540
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 15:45:10 -0000
Status: RO
Content-Length: 1513

If I'm remembering my history correctly, 3Com wanted to use this "mode"
to enable a short-cut routing mechanism (whose name escapes me now).

JR
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Tuesday, March 20, 2007 8:14 AM
> To: Caitlin Bestler
> Cc: [e-mail]; Radia Perlman
> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> Caitlin Bestler wrote:
> 
> > My reading of Appendix B is that Shared Learning is 
> allowed, where VID
> > is not a key field (i.e, there is only one FID supported). 
> Appendix B
> > details some of the problems this creates. I believe the 
> problems for
> > RBridges are even greater than for simple Bridges. This probably
> > justifies
> > restricting RBridges to the Independent Learning model, but any such
> > additional restriction should be explicitly stated.
> 
> My understanding is is that shared learning is useless when VLANs are 
> used for isolation/security. With shared learning a host on 
> VLAN A can 
> trivially cause a DoS attack VLAN B by just sending packets with the 
> source MAC address being the MAC address of another host on 
> another VLAN.
> 
> Thus I'd be surprised if it is used much in practice with bridges.
> 
> I don't see it being a reasonable default for RBridges.
> 
>     Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KFUsqE014392 for <[e-mail]>; Tue, 20 Mar 2007 08:30:54 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 20 Mar 2007 08:30:48 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CED202AE; Tue, 20 Mar 2007 08:30:48 -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 B3D392AF; Tue, 20 Mar 2007 08:30:48 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBY40126; Tue, 20 Mar 2007 08:29:57 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 8605569CA8; Tue, 20 Mar 2007 08:29:55 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 20 Mar 2007 08:29:24 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: AcdrAoIbrmi6bAfaRS27KB7+iwNJVwAAJ60w
From: "Caitlin Bestler" <[e-mail]>
To: "Erik Nordmark" <[e-mail]>
X-WSS-ID: 69E121A23706056426-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 l2KFUsqE014392
Cc: [e-mail], Radia Perlman <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 15:31:11 -0000
Status: RO
Content-Length: 1961

Erik Nordmark wrote:
> Caitlin Bestler wrote:
> 
>> My reading of Appendix B is that Shared Learning is allowed, where
>> VID is not a key field (i.e, there is only one FID supported).
>> Appendix B details some of the problems this creates. I believe the
>> problems for RBridges are even greater than for simple Bridges. This
>> probably justifies restricting RBridges to the Independent Learning
>> model, but any such additional restriction should be explicitly
>> stated. 
> 
> My understanding is is that shared learning is useless when
> VLANs are used for isolation/security. With shared learning a
> host on VLAN A can trivially cause a DoS attack VLAN B by
> just sending packets with the source MAC address being the
> MAC address of another host on another VLAN.
> 
> Thus I'd be surprised if it is used much in practice with bridges.
> 
> I don't see it being a reasonable default for RBridges.
> 
>     Erik


It's a perfectly reasonable behavior, as long as the VID is at
least checked (i.e., it is an attribute, not a key field). A set
of RBridges that *all* used this approach would work perfectly fine.

The real issue is whether RBridges that will realistically tend to
use Independent Learning can easily accommodate some of their peers
doing Shared Learning, and if so, how.

For example, the rule could be that you can use Shared Learning as
long as no other RBridge can detect that you aren't using Independent
Learning. Or Shared/Independent Learning could be a flag that each
RBridge advertises. Or each RBridge could advertise it's VID->FID map.

All of these work, the question is which are justified. As much as I
dislike increasing the key size I can certainly see the advantages to
maintaining a distributed database of requiring all RBridges to use
Independent Learning. So I'd lean toward simply standardizing on
Independent Learning. But any new requirement is best explicitly
stated, not inferred from the data descriptions.




Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KFEQJW009108 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Tue, 20 Mar 2007 08:14:26 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.108.31]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2KFELBX005413; Tue, 20 Mar 2007 15:14:21 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2KFEEeK188206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 08:14:16 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 20 Mar 2007 08:14:09 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
To: Caitlin Bestler <[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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2007 15:14:36 -0000
Status: RO
Content-Length: 868

Caitlin Bestler wrote:

> My reading of Appendix B is that Shared Learning is allowed, where VID
> is not a key field (i.e, there is only one FID supported). Appendix B
> details some of the problems this creates. I believe the problems for
> RBridges are even greater than for simple Bridges. This probably
> justifies
> restricting RBridges to the Independent Learning model, but any such
> additional restriction should be explicitly stated.

My understanding is is that shared learning is useless when VLANs are 
used for isolation/security. With shared learning a host on VLAN A can 
trivially cause a DoS attack VLAN B by just sending packets with the 
source MAC address being the MAC address of another host on another VLAN.

Thus I'd be surprised if it is used much in practice with bridges.

I don't see it being a reasonable default for RBridges.

    Erik


Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JMSVZ5018063 for <[e-mail]>; Mon, 19 Mar 2007 15:28:31 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 23:28:32 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2JMSVhs004628;  Mon, 19 Mar 2007 23:28:31 +0100
Received: from [10.61.64.140] (ams3-vpn-dhcp140.cisco.com [10.61.64.140]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2JMSTlZ022340;  Mon, 19 Mar 2007 22:28:29 GMT
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 15:29:29 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0pre (X11/20070224)
MIME-Version: 1.0
To: Radia Perlman <[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
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3016; t=1174343311; x=1175207311; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20VLAN=20Scoping=20/=20MAC=20Uniqueness |Sender:=20; bh=1ME1pliqS+73vJ447+n06OrlEAcZ1FsfYiT+/FR00yM=; b=pFSGDrlTVzyVcOdo96hmnEe5N6Y5x/9LDTdjH35xnTQDmbTeLligZSQ+a+pyMXOHJrfsc9M/ XBuy/pHu/RAJ6BmxXeock13XIOKUeLXVQksyjiaF/PKu/oLGRFz1zbMG;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2007 22:29:05 -0000
Status: RO
Content-Length: 2937

Radia,

I prefer option b as well. Just as in regular 802.1d bridges, we need to 
age out MAC addresses periodically if we don't see them. One important 
point is that we should set the default age timer to be greater than the 
default ARP cache timer to avoid flooding due to aging out a MAC entry 
but with the hosts still retaining the ARP entry.

Dinesh
Radia Perlman wrote:
> Ah. Now I understand the issue, I think. You are saying that if MAC 
> addresses are globally unique,
> an RBridge attached only to VLAN A should still monitor the endnode 
> membership of the other VLANs,
> in case one of its endnodes moves and appears elsewhere.
>
> So I think we are talking about two alternatives:
> a) have all RBridges see all endnode memberships on all VLANs
> b) have RBridges only see endnode memberships for VLANs they are 
> directly attached to.
>
> I see the disadvantages of each as:
> a) extra bandwidth and storage for having endnode membership go everywhere
> b) less timely noticing an endnode has moved to another VLAN
>
> If I understand things correctly, I much prefer b), for the following 
> reasons:
> 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by 
> pretending to be MAC addresses
>  belonging to VLAN B (so option b is safer and provides more separation 
> between VLANs)
> 2) option b) greatly lowers the burden on RBridges because they only 
> have to keep information for
> their own VLANs
> 3) option b) is likely to save bandwidth on distributing endnode information
> 4) there might be cases where an endnode might attach to multiple VLANs, 
> and the RBridges will
> panic unnecessarily
>
> Radia
>
> Caitlin Bestler wrote:
>
>   
>> The issue is not how the information is relayed, or how it is stored,
>> but who determines what information is relevant.
>>
>> If all RBridges track MAC Addresses scoped within a VLAN scope
>> then everything you suggest works perfectly fine. The only correction
>> needed would be to emphasize that this is indeed a requirement.
>>
>> But any RBridge that uses a global scope for MAC Addresses should
>> be told of new MAC detections on different VLANs because such
>> an RBridge would want to delete the old location.
>>
>> Unless the RBridge that detected the MAC address knows that all
>> other RBridges are using VLAN scoped MAC addresses they should
>> distribute the new information to *all* RBRidges, not just those on
>> the VLAN where the address was discovered.
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>  
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JMNv0v016912 for <[e-mail]>; Mon, 19 Mar 2007 15:23:57 -0700 (PDT)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2007 15:23:57 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2JMNv5C006878;  Mon, 19 Mar 2007 15:23:57 -0700
Received: from [10.61.64.140] (ams3-vpn-dhcp140.cisco.com [10.61.64.140]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2JMNtZT024730; Mon, 19 Mar 2007 22:23:56 GMT
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 15:24:56 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0pre (X11/20070224)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2060; t=1174343037; x=1175207037; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20VLAN=20Scoping=20/=20MAC=20Uniqueness |Sender:=20; bh=JAlWADRfCEyWf82+D/AhGu+c5zNb/F26oF2K8SE66mY=; b=zh7m51tmhkvbnEudPxue5kKqjdXarVvbTScdgvMW4YCITqY1IJR+pKnmjAaKFOux9Yxm93H9 jg7oshSW4oCNgxhMqQTtC4amOhh4wufey3ZBgoQzjeQJV1oUN10nRKhN;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); 
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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2007 22:24:10 -0000
Status: RO
Content-Length: 2015

Hi Caitlin,

Caitlin Bestler wrote:
> My understanding of 802.1 specifications is that the following sequence
> is acceptable behavior for a bridge:
>
> 1) VLAN 7 MAC X is seen on port 1.
> 2) Bridge learns that MAC X is on port 1 with VLAN 7.
> 3) VLAN 8 MAC X is seen on port 1.
> 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X).
>   
I don't think it happens this way. 802.1d bridges map the Vlan ID into a 
separate filtering database ID called FID and learn the MAC addresses 
along with the FID, not the VID. In independent VLAN learning, FID == 
VID whereas in shared VLAN learning, multiple VIDs map into a single 
FID. Therefore in your example above, Bridge learns MAC X on port 1, FID 
z where z is the same for VLANs 7 & 8 or it learns MAC x, FID z1 and MAC 
x, FID z2 where Vlan 7 = FID z1 and Vlan 8 = FID z2.

ARP/ND based learning is specific to TRILL and needs to decide its 
behavior. Silvano and I discuss this a bit in our presentation  on Wed.

Dinesh
> This is of course undesirable, but a livable quirk. It is best avoided by either
> ensuring that global MAC Addresses are truly unique, or ensuring that all bridges
> deployed in one subnet agree on exactly how unique a "globally unique" address is.
>
> RBridges do more than merely forward ethernet frames amongst themselves, they collaborate
> to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes
> of the shared discovery data that MAC Addresses are assumed to be unique only as scoped
> within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing
> the scope of legal behaviors that would have been available to a bridge.
>
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JLoTXq007999 for <[e-mail]>; Mon, 19 Mar 2007 14:50:29 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 19 Mar 2007 14:50:21 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C34362AF; Mon, 19 Mar 2007 14:50:21 -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 AE4412AE; Mon, 19 Mar 2007 14:50:21 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBW42097; Mon, 19 Mar 2007 14:50:17 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 82CD569CA6; Mon, 19 Mar 2007 14:50:17 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 19 Mar 2007 14:50:11 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAMXCd8A=
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 69E1DA1738G5738608-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 l2JLoTXq007999
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2007 21:51:03 -0000
Status: RO
Content-Length: 777

Silvano Gai wrote:
> I think TRILL needs to do exactly what IEEE 802.1Q does.
> AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N.
> 
> N is never advertised outside the bridge, and the mapping of
> M to N is never advertised outside the bridge. TRILL must do the same.
> 
> Learning is done on {VID, MAC-address} pairs. TRILL must do the same.
> 
My reading of Appendix B is that Shared Learning is allowed, where VID
is not a key field (i.e, there is only one FID supported). Appendix B
details some of the problems this creates. I believe the problems for
RBridges are even greater than for simple Bridges. This probably
justifies
restricting RBridges to the Independent Learning model, but any such
additional restriction should be explicitly stated.




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JKB3h5009003 for <[e-mail]>; Mon, 19 Mar 2007 13:11:04 -0700 (PDT)
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, 19 Mar 2007 12:35:51 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
thread-index: AcdqXEcPIT0gM89hSN+SBmu0vD/NZgAAQbSQ
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "J. R. Rivers" <[e-mail]>
To: "Russ White" <[e-mail]>, "Radia Perlman" <[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 l2JKB3h5009003
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2007 20:11:43 -0000
Status: RO
Content-Length: 4301

Seems like Radia's option B is a reasonable option.

Just because an RBridge has directly connected hosts on VLAN A doesn't
qualify it to understand what should (or shouldn't) be connected on VLAN
B.

There are many examples of locally assigned Ethernet addresses being
used within a subnet.  It doesn't seem like there is any fundamental
requirement for TRILL to change this.  Clearly... there needs to be a
policy for handling the same address connected to different RBridges in
the SAME VLAN.

My $0.02,

JR


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ White
> Sent: Monday, March 19, 2007 12:06 PM
> To: Radia Perlman
> Cc: [e-mail]
> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> - From an IS-IS perspective, if we do a, we only have, I 
> think, a single
> process, while if we do b, it makes more sense to do multiple 
> processes,
> right? In reality, the way the TLVs are laid out today, we 
> can advertise
> each l2 address with a vid, or not, or a group of l2 addresses with a
> single vid to indicate they are all within this vid, or some other
> various combinations.
> 
> :-)
> 
> Russ
> 
> Radia Perlman wrote:
> > Ah. Now I understand the issue, I think. You are saying that if MAC 
> > addresses are globally unique,
> > an RBridge attached only to VLAN A should still monitor the endnode 
> > membership of the other VLANs,
> > in case one of its endnodes moves and appears elsewhere.
> > 
> > So I think we are talking about two alternatives:
> > a) have all RBridges see all endnode memberships on all VLANs
> > b) have RBridges only see endnode memberships for VLANs they are 
> > directly attached to.
> > 
> > I see the disadvantages of each as:
> > a) extra bandwidth and storage for having endnode 
> membership go everywhere
> > b) less timely noticing an endnode has moved to another VLAN
> > 
> > If I understand things correctly, I much prefer b), for the 
> following 
> > reasons:
> > 1) option a offers an endnode in VLAN A the ability to 
> annoy VLAN B by 
> > pretending to be MAC addresses
> >  belonging to VLAN B (so option b is safer and provides 
> more separation 
> > between VLANs)
> > 2) option b) greatly lowers the burden on RBridges because 
> they only 
> > have to keep information for
> > their own VLANs
> > 3) option b) is likely to save bandwidth on distributing 
> endnode information
> > 4) there might be cases where an endnode might attach to 
> multiple VLANs, 
> > and the RBridges will
> > panic unnecessarily
> > 
> > Radia
> > 
> > Caitlin Bestler wrote:
> > 
> >> The issue is not how the information is relayed, or how it 
> is stored,
> >> but who determines what information is relevant.
> >>
> >> If all RBridges track MAC Addresses scoped within a VLAN scope
> >> then everything you suggest works perfectly fine. The only 
> correction
> >> needed would be to emphasize that this is indeed a requirement.
> >>
> >> But any RBridge that uses a global scope for MAC Addresses should
> >> be told of new MAC detections on different VLANs because such
> >> an RBridge would want to delete the old location.
> >>
> >> Unless the RBridge that detected the MAC address knows that all
> >> other RBridges are using VLAN scoped MAC addresses they should
> >> distribute the new information to *all* RBRidges, not just those on
> >> the VLAN where the address was discovered.
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>  
> >>
> > 
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> - --
> [e-mail] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY
> 6bS0r3gfLceCcCIUYXFR5HI=
> =F2tF
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from xmail03.myhosting.com (xmail03.myhosting.com [168.144.250.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JJ7RRu020615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 19 Mar 2007 12:07:28 -0700 (PDT)
Received: (qmail 21643 invoked from network); 19 Mar 2007 19:07:16 -0000
Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:[e-mail]@[65.190.218.139]) (envelope-sender <[e-mail]>) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for <[e-mail]>; 19 Mar 2007 19:07:16 -0000
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 15:06:24 -0400
From: Russ White <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.1
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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2007 19:08:01 -0000
Status: RO
Content-Length: 3152

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


- From an IS-IS perspective, if we do a, we only have, I think, a single
process, while if we do b, it makes more sense to do multiple processes,
right? In reality, the way the TLVs are laid out today, we can advertise
each l2 address with a vid, or not, or a group of l2 addresses with a
single vid to indicate they are all within this vid, or some other
various combinations.

:-)

Russ

Radia Perlman wrote:
> Ah. Now I understand the issue, I think. You are saying that if MAC 
> addresses are globally unique,
> an RBridge attached only to VLAN A should still monitor the endnode 
> membership of the other VLANs,
> in case one of its endnodes moves and appears elsewhere.
> 
> So I think we are talking about two alternatives:
> a) have all RBridges see all endnode memberships on all VLANs
> b) have RBridges only see endnode memberships for VLANs they are 
> directly attached to.
> 
> I see the disadvantages of each as:
> a) extra bandwidth and storage for having endnode membership go everywhere
> b) less timely noticing an endnode has moved to another VLAN
> 
> If I understand things correctly, I much prefer b), for the following 
> reasons:
> 1) option a offers an endnode in VLAN A the ability to annoy VLAN B by 
> pretending to be MAC addresses
>  belonging to VLAN B (so option b is safer and provides more separation 
> between VLANs)
> 2) option b) greatly lowers the burden on RBridges because they only 
> have to keep information for
> their own VLANs
> 3) option b) is likely to save bandwidth on distributing endnode information
> 4) there might be cases where an endnode might attach to multiple VLANs, 
> and the RBridges will
> panic unnecessarily
> 
> Radia
> 
> Caitlin Bestler wrote:
> 
>> The issue is not how the information is relayed, or how it is stored,
>> but who determines what information is relevant.
>>
>> If all RBridges track MAC Addresses scoped within a VLAN scope
>> then everything you suggest works perfectly fine. The only correction
>> needed would be to emphasize that this is indeed a requirement.
>>
>> But any RBridge that uses a global scope for MAC Addresses should
>> be told of new MAC detections on different VLANs because such
>> an RBridge would want to delete the old location.
>>
>> Unless the RBridge that detected the MAC address knows that all
>> other RBridges are using VLAN scoped MAC addresses they should
>> distribute the new information to *all* RBRidges, not just those on
>> the VLAN where the address was discovered.
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>  
>>
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

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

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

iD8DBQFF/t8wER27sUhU9OQRArzYAJ9WuW82Wcaeml5+OVEmb/OAChUO4wCg7cgY
6bS0r3gfLceCcCIUYXFR5HI=
=F2tF
-----END PGP SIGNATURE-----


Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2HJRajM003656 for <[e-mail]>; Sat, 17 Mar 2007 12:27:36 -0700 (PDT)
Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Sat, 17 Mar 2007 12:27:26 -0700
X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E03E82AF; Sat, 17 Mar 2007 12:27:25 -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 CB5332AE; Sat, 17 Mar 2007 12:27:25 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBR37306; Sat, 17 Mar 2007 12:27:25 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 5D69F69CA3; Sat, 17 Mar 2007 12:27:25 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 17 Mar 2007 12:27:23 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAEC8S3wAEbNJYAAJxr3g
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 69E29E943A44830727-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 l2HJRajM003656
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2007 19:28:00 -0000
Status: RO
Content-Length: 400

Silvano Gai wrote:
> Caitlin,
> 
> Is you problem with:
> 1) "Learning" or
> 2) "ARP/ND discovery"?
> 
> In my email I was only addressing 1), but I agree with you
> that we also need to address 2).
> 

Maybe I'm not playing spec lawyer well enough. But thinking
of how I would implement these features in a smart NIC I
simply don't see the distinction. It's all information keyed
by the L2 Index.




Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2HErbni008008 for <[e-mail]>; Sat, 17 Mar 2007 07:53:37 -0700 (PDT)
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: Sat, 17 Mar 2007 07:50:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
thread-index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAEC8S3wAEbNJYA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>, "Radia Perlman" <[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 l2HErbni008008
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2007 14:53:50 -0000
Status: RO
Content-Length: 2940

Caitlin,

Is you problem with: 
1) "Learning" or
2) "ARP/ND discovery"?

In my email I was only addressing 1), but I agree with you that we also
need to address 2).

-- Silvano

> -----Original Message-----
> From: Caitlin Bestler [mailto:[e-mail]]
> Sent: Friday, March 16, 2007 11:27 PM
> To: Silvano Gai; Radia Perlman
> Cc: [e-mail]; Erik Nordmark
> Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> 
> 
> 
> -----Original Message-----
> From: Silvano Gai [mailto:[e-mail]]
> Sent: Fri 3/16/2007 2:16 AM
> To: Radia Perlman; Caitlin Bestler
> Cc: [e-mail]; Erik Nordmark
> Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> 
> I think TRILL needs to do exactly what IEEE 802.1Q does.
> AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N.
> 
> N is never advertised outside the bridge, and the mapping of M to N is
> never advertised outside the bridge. TRILL must do the same.
> 
> Learning is done on {VID, MAC-address} pairs. TRILL must do the same.
> 
> We agreed that bridges learn from data frames and data frames are
always
> associated to a VID and RBridges learn from the per VLAN instance of
> ISIS.
> 
> Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are
> mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically
> becomes available on VLAN=9.
> 
> Now the tricky question: should the RBridge announce MAC-A on both
VLAN
> 7 and VLAN 9 or only on VLAN 7?
> 
> IMHO the correct answer is that it MUST only announce it on VLAN 7,
i.e.
> it must only announce what it has learnt from data frames, not the
> internal associations it has made. If the information was learnt on
data
> packets, it would only be learnt on VLAN 7!
> 
> If we do this we are perfectly equivalent to an IEEE 802.1Q bridge.
> 
> -- Silvano
> 
> -----End Original Message-----
> 
> 
> My understanding of 802.1 specifications is that the following
sequence
> is acceptable behavior for a bridge:
> 
> 1) VLAN 7 MAC X is seen on port 1.
> 2) Bridge learns that MAC X is on port 1 with VLAN 7.
> 3) VLAN 8 MAC X is seen on port 1.
> 4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the
prior
> information about X).
> 
> This is of course undesirable, but a livable quirk. It is best avoided
by
> either
> ensuring that global MAC Addresses are truly unique, or ensuring that
all
> bridges
> deployed in one subnet agree on exactly how unique a "globally unique"
> address is.
> 
> RBridges do more than merely forward ethernet frames amongst
themselves,
> they collaborate
> to implement a distributed ARP/ND proxy. That probably justifies
stating
> that for purposes
> of the shared discovery data that MAC Addresses are assumed to be
unique
> only as scoped
> within a VLAN, but I think we should acknowledge (and highlight) that
we
> are narrowing
> the scope of legal behaviors that would have been available to a
bridge.
> 




Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2H6R16t025252 for <[e-mail]>; Fri, 16 Mar 2007 23:27:02 -0700 (PDT)
Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 16 Mar 2007 23:26:48 -0700
X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 2B8302B0; Fri, 16 Mar 2007 23:26:48 -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 157222AF; Fri, 16 Mar 2007 23:26:48 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBQ33117; Fri, 16 Mar 2007 23:26:44 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9B60769CA4; Fri, 16 Mar 2007 23:26:44 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 Mar 2007 23:26:44 -0700
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0gAEC8S3w=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: "Silvano Gai" <[e-mail]>, "Radia Perlman" <[e-mail]>
X-WSS-ID: 69E555A23A44643839-01-01
Content-Type: text/plain; charset=iso-8859-1
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 l2H6R16t025252
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2007 06:28:47 -0000
Status: RO
Content-Length: 2372

-----Original Message-----
From: Silvano Gai [mailto:[e-mail]]
Sent: Fri 3/16/2007 2:16 AM
To: Radia Perlman; Caitlin Bestler
Cc: [e-mail]; Erik Nordmark
Subject: RE: [rbridge] VLAN Scoping / MAC Uniqueness
 

I think TRILL needs to do exactly what IEEE 802.1Q does.
AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N.

N is never advertised outside the bridge, and the mapping of M to N is
never advertised outside the bridge. TRILL must do the same.

Learning is done on {VID, MAC-address} pairs. TRILL must do the same.

We agreed that bridges learn from data frames and data frames are always
associated to a VID and RBridges learn from the per VLAN instance of
ISIS. 

Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are
mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically
becomes available on VLAN=9.

Now the tricky question: should the RBridge announce MAC-A on both VLAN
7 and VLAN 9 or only on VLAN 7?

IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e.
it must only announce what it has learnt from data frames, not the
internal associations it has made. If the information was learnt on data
packets, it would only be learnt on VLAN 7!

If we do this we are perfectly equivalent to an IEEE 802.1Q bridge.

-- Silvano

-----End Original Message-----


My understanding of 802.1 specifications is that the following sequence
is acceptable behavior for a bridge:

1) VLAN 7 MAC X is seen on port 1.
2) Bridge learns that MAC X is on port 1 with VLAN 7.
3) VLAN 8 MAC X is seen on port 1.
4) Bridge learns that MAC X is on port 1 with VLAN 8 (erasing the prior information about X).

This is of course undesirable, but a livable quirk. It is best avoided by either
ensuring that global MAC Addresses are truly unique, or ensuring that all bridges
deployed in one subnet agree on exactly how unique a "globally unique" address is.

RBridges do more than merely forward ethernet frames amongst themselves, they collaborate
to implement a distributed ARP/ND proxy. That probably justifies stating that for purposes
of the shared discovery data that MAC Addresses are assumed to be unique only as scoped
within a VLAN, but I think we should acknowledge (and highlight) that we are narrowing
the scope of legal behaviors that would have been available to a bridge.





Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2GLr19q015062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 16 Mar 2007 14:53:01 -0700 (PDT)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5A97C17697; Fri, 16 Mar 2007 21:52:56 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HSKM4-0001KO-4Q; Fri, 16 Mar 2007 17:52:56 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 16 Mar 2007 17:52:56 -0400
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL Routing Requirements in Support of RBridges) to Informational RFC
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 21:53:19 -0000
Status: RO
Content-Length: 828

The IESG has received a request from the Transparent Interconnection of 
Lots of Links WG (trill) to consider the following document:

- 'TRILL Routing Requirements in Support of RBridges '
   <draft-ietf-trill-routing-reqs-02.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2007-03-30. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15187&rfc_flag=0



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2G9GBEX002554 for <[e-mail]>; Fri, 16 Mar 2007 02:16:11 -0700 (PDT)
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: Fri, 16 Mar 2007 02:16:11 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
thread-index: Acdlncybo5fwzvmQQrmANY3oiwQKhgBu1x0g
References: <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Caitlin Bestler" <[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 l2G9GBEX002554
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 09:16:58 -0000
Status: RO
Content-Length: 5007

I think TRILL needs to do exactly what IEEE 802.1Q does.
AN IEEE 802.1Q bridge has M VIDs and N FIDs with M >= 1, N >=1, M >=N.

N is never advertised outside the bridge, and the mapping of M to N is
never advertised outside the bridge. TRILL must do the same.

Learning is done on {VID, MAC-address} pairs. TRILL must do the same.

We agreed that bridges learn from data frames and data frames are always
associated to a VID and RBridges learn from the per VLAN instance of
ISIS. 

Let's suppose that we have an RBridge with 2 VLANs (7 and 9) that are
mapped to the same FID. MAC-A is learnt on VLAN=7 and automatically
becomes available on VLAN=9.

Now the tricky question: should the RBridge announce MAC-A on both VLAN
7 and VLAN 9 or only on VLAN 7?

IMHO the correct answer is that it MUST only announce it on VLAN 7, i.e.
it must only announce what it has learnt from data frames, not the
internal associations it has made. If the information was learnt on data
packets, it would only be learnt on VLAN 7!

If we do this we are perfectly equivalent to an IEEE 802.1Q bridge.

-- Silvano


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Tuesday, March 13, 2007 11:26 AM
> To: Caitlin Bestler
> Cc: [e-mail]; Erik Nordmark
> Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
> 
> The current spec (and my understanding) is that membership of VLAN A
> would be distributed
> as link state information in IS-IS. If we include this in the link
state
> information in the core instance,
> then every RBridge has to store it all, since IS-IS flooding requires
> every RBridge to store all (the most
> recently generated from each RBridge) link state information. R1
doesn't
> just look at the link state
> information and decide what it's interested in and delete the rest. R1
> has to keep it in order for
> the reliable flooding to work.
> 
> With the way the current spec is written, endnode information is *NOT*
> distributed in the core instance.
> Instead, VLAN A information
> is distributed like a VLAN A multicast data packet, which means the
core
> RBridges distribute
> it along a tree, filtered so as not to unnecessarily go on branches
that
> don't lead to VLAN A links.
> 
> With that design, the only RBridges that would see information about
> VLAN A endnode membership are
> RBridges attached to VLAN A.
> The topology that the IS-IS instance for distributing VLAN A sees is
as
> a single hop, with all RBridges
> attached to VLAN A being neighbors.
> 
> There is a variant of this design that would have the property you are
> imagining; that all endnode information
> goes everywhere, gets seen by all RBridges, and that only RBridges in
> VLAN A have to actually store the
> information. That is to have a multicast distribution tree that sends
> things to *all* RBridges that attach to
> endnodes. This is a subtly different distribution mechanism than the
> core instance. If there are core RBridges,
> not attached to any endnodes, they would just pass the link state
> information along. And a "border" RBridge R2
> (one that does attach to endnodes) would be allowed, if it chose, to
> simply scan VLAN A information and
> then delete it, since R2 would never need to forward this link state
> ifnormation to a neighbor.
> 
> I still prefer the way the spec is now, since I think the advantage of
> noticing endnodes moving to a
> different VLAN is outweighed by the downsides (more cost to distribute
> endnode information, and
> the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN
B
> maliciously, and confusion
> when nonmaliciously an endnode resides on multiple VLANs with the same
> MAC address.
> 
> Radia
> 
> 
> 
> Caitlin Bestler wrote:
> 
> >Radia Perlman wrote:
> >
> >
> >>With IS-IS flooding, an RBridge can't simply scan the
> >>information for VLAN A and then delete it.
> >>It has to store it, since LSPs have to be flooded reliably,
> >>so each RBridge would have to keep all endnode information for all
> >>VLANs.
> >>
> >>
> >>
> >
> >I'm not following. If an RBridge is using globally scoped MAC
> >addresses, and it receives endnode information for a VLAN that
> >it does not support, the only thing I can see that it would have
> >to do is to delete any information it had on the same MAC address
> >on a different VLAN.
> >
> >It would never send to VLAN A, so why would it retain any information
> >once the contradictory data was eliminated? A deleted record can be
> >considered to be reliably delected, can't it?
> >
> >If it's knowledge of MAC Addresses is VLAN scoped then nothing
> >about VLAN A is ever relevant. That is why it is a very simple
> >solution, but one that creates an RBridge requirement for scoped
> >learning that does not apply to simple Bridges.
> >
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2G9GF3g002555 for <[e-mail]>; Fri, 16 Mar 2007 02:16:15 -0700 (PDT)
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: Fri, 16 Mar 2007 02:16:15 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees
thread-index: Acdipub/syq9ju5TR6CBdJCJFyW4/QE8Le8g
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Erik Nordmark" <[e-mail]>, "Dino Farinacci" <[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 l2G9GF3g002555
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 09:16:54 -0000
Status: RO
Content-Length: 2714

EriK,

inline

> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Friday, March 09, 2007 3:59 PM
> To: Dino Farinacci
> Cc: Silvano Gai; [e-mail]; [e-mail]
> Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge
> trees
> 
> Dino Farinacci wrote:
> 
> > The simplest example is when using multi-access links. The fact that
> > some switches use the multi-access link as an oif and others use the
> > link as an expected-incoming interface.
> >
> > So if the ones that are using the multi-access link as an oif happen
to
> > join the root through one of the other switches (which can be many
hops
> > away), then the multicast forwarding (and replication) loop occurs.
> 
> With TRILL be clearly have to be careful at the edge (the ingress and
> egress rbridges) when it comes to the relationship between 802.1D and
> designated RBridge in order to handle topology changes. In particular
> since the frames without the TRILL header header doesn't have a TTL.
> 
> But leaving that aside for a moment, the way Radia described the
> forwarding check (the "expected incoming adjacency" check), the
transit
> paths between the RBridges would act as point-to-point due to checking
> both the incoming port and the previous hop RBridge.

IMHO you can build the most sophisticated RPF check, but it will always
be based on local information. Since it is well known that the local
information of two RBridges may be temporary out of sync, due to the way
IS-IS works, the possibility of a temporary loop is concrete.

Temporary loop == Broadcast Storm

-- Silvano

> 
> It was in such a pt-pt topology that I tried to find a simple example
of
> a temporary loop.
> 
> >> Have you observed temporary IP Multicast loops? (apart from the PIM
SM
> >> ones before ASSERTS where added). What was the topology and change
> >> necessary to trigger those?
> >
> > Oh definitely, when two routers think the RP for a (*,G) are
different.
> > And this can happen when the topology is in steady state.
> >
> > And this happens due to misconfiguration or in the early days of PIM
> > when you detect one RP down, you move to another one, but others in
the
> > topology stayed with the original one. Again, in a steady-state
> > topology. The reason some thought the RP went down is because the
> > network was congested and the RP keepalives were all lost. Those
were
> > interesting times.  ;-)
> >
> > So this can happen in IS-IS as well if the not everyone is using the
> > same roots.
> 
> But AFAICT that type of loop can't happen in TRILL since we have an
> explicit designator for the tree to use in every multi-destination
data
> frame.
> 
>     Erik



Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DJ7Nqb012138 for <[e-mail]>; Tue, 13 Mar 2007 12:07:23 -0700 (PDT)
Received: by nz-out-0506.google.com with SMTP id i1so1246528nzh for <[e-mail]>; Tue, 13 Mar 2007 12:07:22 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Jsa262CYA23cTU6XtiMzE/xQZ63l7iTLfQYAtyXDNzpetAsMnaQu7/iqYHU+Y9DcoGEEyBisgCS5NGhcegGSaB1FdwwitlOkbqSc8xtiKS4eM6Cw6xYE2gB2OR/NkS6bUp9BhYEBdN0nl5XPkCE/ZSFsYWMsvU1mOEk1d8yjNlg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fDkvBuVkdp3j8sCqzNyYXAifjFrX1HPwkMeu6qW7QuAblRjVMCuMlfraUoRujVtNZtZ4MyJNxPy9jC7O7AWJkJUHH4a7IqdumAwwT2nmlnY2PJIBkMBe+qAc7l0cfRRCaKhZ4pDqYqEQisa/QYHj6gehSz+s0izTn/qtTXvS2NE=
Received: by 10.35.103.12 with SMTP id f12mr2436900pym.1173812840435; Tue, 13 Mar 2007 12:07:20 -0700 (PDT)
Received: by 10.35.51.15 with HTTP; Tue, 13 Mar 2007 12:07:20 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 13 Mar 2007 20:07:20 +0100
From: "Jose Morales Barroso" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Global MAC Addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 19:07:35 -0000
Status: RO
Content-Length: 1924

Dear colleagues:

UETS/EFR architecture uses locally administered (U/L bit = 1)
MAC addresses, "taking  advantage of interface identifiers
with universal scope", as described at:

 http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf

This technology permits to switch Ethernet frames at the physical
layer, making it unnecessary to use routing, bridging, or signaling
techniques. The Destination Address has the path information,
and does not need tables of switching, look-up or forwarding:

 http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf

Using MAC-in-MAC or SNAP, each connection support another
Ethernet domain.  In this case, the addressing will be huge, even
bigger than IPv6, making possible to build a "Global Ethernet".

You have more information in the UETS/EFR page:

 http://www.lmdata.es/uets.htm

Jose Morales
[e-mail]



Eric Gray (LO/EUS) wrote:


>> Interstingly enough, I am really sure that the IPv6 folks
>> have looked at this before.  And I am also sure that at least one
>> suggested solution has been considered.  I do not know if any (of
>> possibly many) proposals were actually adopted but, if none were,
>> it would be because the IPv6 people did not see this as a problem.
>
>AFAIK the IPv6 folks have not considered this.
>But as you pointed out, the global IPv6 addresses would still be
>globally unique since they would have different subnet prefixes.
>
> The only issue for IPv6 is that this (and host-side virtualization in
> general) means that the the semantics of the universal bit in the
> modified EUI-64 format is even weaker than before.
> But there is no protocol to date which assumes anything about the
> semantics of this bit. As RFC 4291 says:

>   The use of the universal/local bit in the Modified EUI-64 format
>   identifier is to allow development of future technology that can take
>   advantage of interface identifiers with universal scope.

>  Erik


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DIaw5Z002449 for <[e-mail]>; Tue, 13 Mar 2007 11:36:59 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 11:36:49 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 201A32AF; Tue, 13 Mar 2007 11:36:49 -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 0BA942AE; Tue, 13 Mar 2007 11:36:49 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBG66630; Tue, 13 Mar 2007 11:36:48 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id A590869CA3; Tue, 13 Mar 2007 11:36:48 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 13 Mar 2007 11:36:47 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: AcdlnRUS2fyq52ipR+ezpClQrmB6BAAADcSw
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-WSS-ID: 69E830CB38G3408583-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 l2DIaw5Z002449
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 18:37:18 -0000
Status: RO
Content-Length: 2860

Radia Perlman wrote:
> The current spec (and my understanding) is that membership of
> VLAN A would be distributed as link state information in
> IS-IS. If we include this in the link state information in
> the core instance, then every RBridge has to store it all,
> since IS-IS flooding requires every RBridge to store all (the
> most recently generated from each RBridge) link state
> information. R1 doesn't just look at the link state
> information and decide what it's interested in and delete the
> rest. R1 has to keep it in order for the reliable flooding to work.
> 
> With the way the current spec is written, endnode information
> is *NOT* distributed in the core instance.
> Instead, VLAN A information
> is distributed like a VLAN A multicast data packet, which
> means the core RBridges distribute it along a tree, filtered
> so as not to unnecessarily go on branches that don't lead to
> VLAN A links.
> 
> With that design, the only RBridges that would see
> information about VLAN A endnode membership are RBridges
> attached to VLAN A.
> The topology that the IS-IS instance for distributing VLAN A
> sees is as a single hop, with all RBridges attached to VLAN A being
> neighbors. 
> 
> There is a variant of this design that would have the
> property you are imagining; that all endnode information goes
> everywhere, gets seen by all RBridges, and that only RBridges
> in VLAN A have to actually store the information. That is to
> have a multicast distribution tree that sends things to *all*
> RBridges that attach to endnodes. This is a subtly different
> distribution mechanism than the core instance. If there are
> core RBridges, not attached to any endnodes, they would just
> pass the link state information along. And a "border" RBridge
> R2 (one that does attach to endnodes) would be allowed, if it
> chose, to simply scan VLAN A information and then delete it,
> since R2 would never need to forward this link state
> ifnormation to a neighbor.
> 
> I still prefer the way the spec is now, since I think the
> advantage of noticing endnodes moving to a different VLAN is
> outweighed by the downsides (more cost to distribute endnode
> information, and the ability for nasty behavior of an endnode
> in VLAN A to disrupt VLAN B maliciously, and confusion when
> nonmaliciously an endnode resides on multiple VLANs with the
> same MAC address.
> 
> Radia
> 

It might be sufficient to merely note that any RBridge attempting
to maintain global scoping of MAC Addresses needs to be aware that
the distribution of endnode information is optimized for per-VLAN
scoping. Because of this it MUST NOT rely on prompt notification
of migration of a MAC Address to a new VLAN on a different RBridge.

I also agree that it makes sense to optimize the wire protocol
on the assumption that typical RBridges will do per-VLAN learning.







Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DIQ1H2029228 for <[e-mail]>; Tue, 13 Mar 2007 11:26:01 -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, 13 Mar 2007 11:26:01 -0700 (PDT)
Received: from sun.com ([129.150.17.61]) 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, 13 Mar 2007 11:26:01 -0700 (PDT)
Date: Tue, 13 Mar 2007 11:26:11 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Caitlin Bestler <[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]
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 18:26:41 -0000
Status: RO
Content-Length: 3328

The current spec (and my understanding) is that membership of VLAN A 
would be distributed
as link state information in IS-IS. If we include this in the link state 
information in the core instance,
then every RBridge has to store it all, since IS-IS flooding requires 
every RBridge to store all (the most
recently generated from each RBridge) link state information. R1 doesn't 
just look at the link state
information and decide what it's interested in and delete the rest. R1 
has to keep it in order for
the reliable flooding to work.

With the way the current spec is written, endnode information is *NOT* 
distributed in the core instance.
Instead, VLAN A information
is distributed like a VLAN A multicast data packet, which means the core 
RBridges distribute
it along a tree, filtered so as not to unnecessarily go on branches that 
don't lead to VLAN A links.

With that design, the only RBridges that would see information about 
VLAN A endnode membership are
RBridges attached to VLAN A.
The topology that the IS-IS instance for distributing VLAN A sees is as 
a single hop, with all RBridges
attached to VLAN A being neighbors.

There is a variant of this design that would have the property you are 
imagining; that all endnode information
goes everywhere, gets seen by all RBridges, and that only RBridges in 
VLAN A have to actually store the
information. That is to have a multicast distribution tree that sends 
things to *all* RBridges that attach to
endnodes. This is a subtly different distribution mechanism than the 
core instance. If there are core RBridges,
not attached to any endnodes, they would just pass the link state 
information along. And a "border" RBridge R2
(one that does attach to endnodes) would be allowed, if it chose, to 
simply scan VLAN A information and
then delete it, since R2 would never need to forward this link state 
ifnormation to a neighbor.

I still prefer the way the spec is now, since I think the advantage of 
noticing endnodes moving to a
different VLAN is outweighed by the downsides (more cost to distribute 
endnode information, and
the ability for nasty behavior of an endnode in VLAN A to disrupt VLAN B 
maliciously, and confusion
when nonmaliciously an endnode resides on multiple VLANs with the same 
MAC address.

Radia



Caitlin Bestler wrote:

>Radia Perlman wrote:
>  
>
>>With IS-IS flooding, an RBridge can't simply scan the
>>information for VLAN A and then delete it.
>>It has to store it, since LSPs have to be flooded reliably,
>>so each RBridge would have to keep all endnode information for all
>>VLANs. 
>>
>>    
>>
>
>I'm not following. If an RBridge is using globally scoped MAC
>addresses, and it receives endnode information for a VLAN that
>it does not support, the only thing I can see that it would have
>to do is to delete any information it had on the same MAC address
>on a different VLAN.
>
>It would never send to VLAN A, so why would it retain any information
>once the contradictory data was eliminated? A deleted record can be
>considered to be reliably delected, can't it?
>
>If it's knowledge of MAC Addresses is VLAN scoped then nothing
>about VLAN A is ever relevant. That is why it is a very simple
>solution, but one that creates an RBridge requirement for scoped
>learning that does not apply to simple Bridges.
>
>  
>



Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DHxqWI020724 for <[e-mail]>; Tue, 13 Mar 2007 10:59:53 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 10:59:41 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 20ED52B0; Tue, 13 Mar 2007 10:59:41 -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 0CB2A2AF; Tue, 13 Mar 2007 10:59:41 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBG55493; Tue, 13 Mar 2007 10:59:40 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 445D469CA3; Tue, 13 Mar 2007 10:59:40 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 13 Mar 2007 10:59:38 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: AcdlmLV46rixuFdCT4OMcSimkHFYIgAAB64g
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
X-WSS-ID: 69E839073703311508-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 l2DHxqWI020724
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 18:00:06 -0000
Status: RO
Content-Length: 971

Radia Perlman wrote:
> With IS-IS flooding, an RBridge can't simply scan the
> information for VLAN A and then delete it.
> It has to store it, since LSPs have to be flooded reliably,
> so each RBridge would have to keep all endnode information for all
> VLANs. 
> 

I'm not following. If an RBridge is using globally scoped MAC
addresses, and it receives endnode information for a VLAN that
it does not support, the only thing I can see that it would have
to do is to delete any information it had on the same MAC address
on a different VLAN.

It would never send to VLAN A, so why would it retain any information
once the contradictory data was eliminated? A deleted record can be
considered to be reliably delected, can't it?

If it's knowledge of MAC Addresses is VLAN scoped then nothing
about VLAN A is ever relevant. That is why it is a very simple
solution, but one that creates an RBridge requirement for scoped
learning that does not apply to simple Bridges.




Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DHsbIR019230 for <[e-mail]>; Tue, 13 Mar 2007 10:54:37 -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, 13 Mar 2007 10:54:37 -0700 (PDT)
Received: from sun.com ([129.150.17.61]) 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, 13 Mar 2007 10:54:36 -0700 (PDT)
Date: Tue, 13 Mar 2007 10:54:47 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Caitlin Bestler <[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]
Cc: [e-mail], Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 17:55:33 -0000
Status: RO
Content-Length: 1064

With IS-IS flooding, an RBridge can't simply scan the information for 
VLAN A and then delete it.
It has to store it, since LSPs have to be flooded reliably, so each 
RBridge would have to keep all
endnode information for all VLANs.

Radia

Caitlin Bestler wrote:

>Radia Perlman wrote:
>
>  
>
>>The advantage of this is that flooding of endnode information 
>>for VLAN A need not be stored by any RBridges except those
>>that attach to VLAN A.
>>    
>>
>
>That line leapt out at me on re-read.
>
>*If* we are going to allow RBridges to have the traditional
>bridge option of using scoped or global MAC address learning,
>then we do indeed have to flood endnode information about 
>VLAN A. This is not so that RBridges that are not part of
>VLAN A can *store* the new endnode information, it is so
>they can *delete* contradictory information.
>
>Alternatively, if we explicitly require scoped learning,
>then any RBridge that is not part of VLAN A cannot have
>contradictory information. Then there would be no need
>to flood endnode advertisements.
>
>
>  
>



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DHem5c015049 for <[e-mail]>; Tue, 13 Mar 2007 10:40: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]; Tue, 13 Mar 2007 10:40:33 -0700 (PDT)
Received: from sun.com ([129.150.17.61]) 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, 13 Mar 2007 10:40:33 -0700 (PDT)
Date: Tue, 13 Mar 2007 10:40:44 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Caitlin Bestler <[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]>
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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 17:41:35 -0000
Status: RO
Content-Length: 2147

Ah. Now I understand the issue, I think. You are saying that if MAC 
addresses are globally unique,
an RBridge attached only to VLAN A should still monitor the endnode 
membership of the other VLANs,
in case one of its endnodes moves and appears elsewhere.

So I think we are talking about two alternatives:
a) have all RBridges see all endnode memberships on all VLANs
b) have RBridges only see endnode memberships for VLANs they are 
directly attached to.

I see the disadvantages of each as:
a) extra bandwidth and storage for having endnode membership go everywhere
b) less timely noticing an endnode has moved to another VLAN

If I understand things correctly, I much prefer b), for the following 
reasons:
1) option a offers an endnode in VLAN A the ability to annoy VLAN B by 
pretending to be MAC addresses
 belonging to VLAN B (so option b is safer and provides more separation 
between VLANs)
2) option b) greatly lowers the burden on RBridges because they only 
have to keep information for
their own VLANs
3) option b) is likely to save bandwidth on distributing endnode information
4) there might be cases where an endnode might attach to multiple VLANs, 
and the RBridges will
panic unnecessarily

Radia

Caitlin Bestler wrote:

>The issue is not how the information is relayed, or how it is stored,
>but who determines what information is relevant.
>
>If all RBridges track MAC Addresses scoped within a VLAN scope
>then everything you suggest works perfectly fine. The only correction
>needed would be to emphasize that this is indeed a requirement.
>
>But any RBridge that uses a global scope for MAC Addresses should
>be told of new MAC detections on different VLANs because such
>an RBridge would want to delete the old location.
>
>Unless the RBridge that detected the MAC address knows that all
>other RBridges are using VLAN scoped MAC addresses they should
>distribute the new information to *all* RBRidges, not just those on
>the VLAN where the address was discovered.
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DHbLX1014368 for <[e-mail]>; Tue, 13 Mar 2007 10:37:21 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 10:37:12 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0320C2AF; Tue, 13 Mar 2007 10:37:12 -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 E343E2AE; Tue, 13 Mar 2007 10:37:11 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBG48751; Tue, 13 Mar 2007 10:37:11 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 7B1FC69CA4; Tue, 13 Mar 2007 10:37:11 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 13 Mar 2007 10:37:09 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: Acdk+LVrBIIH880YR26Db9fsV9Es6AAnO53Q
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Erik Nordmark" <[e-mail]>
X-WSS-ID: 69E83EC238G3384691-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 l2DHbLX1014368
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 17:37:42 -0000
Status: RO
Content-Length: 759

Radia Perlman wrote:

> The advantage of this is that flooding of endnode information 
> for VLAN A need not be stored by any RBridges except those
> that attach to VLAN A.

That line leapt out at me on re-read.

*If* we are going to allow RBridges to have the traditional
bridge option of using scoped or global MAC address learning,
then we do indeed have to flood endnode information about 
VLAN A. This is not so that RBridges that are not part of
VLAN A can *store* the new endnode information, it is so
they can *delete* contradictory information.

Alternatively, if we explicitly require scoped learning,
then any RBridge that is not part of VLAN A cannot have
contradictory information. Then there would be no need
to flood endnode advertisements.





Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2DEOGu8019801 for <[e-mail]>; Tue, 13 Mar 2007 07:24:16 -0700 (PDT)
Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 13 Mar 2007 07:23:55 -0700
X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BCFA72AF; Tue, 13 Mar 2007 07:23: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 AA0DC2AE for <[e-mail]>; Tue, 13 Mar 2007 07:23:55 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBF87896; Tue, 13 Mar 2007 07:23:55 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 5354069CA3 for <[e-mail]>; Tue, 13 Mar 2007 07:23:55 -0700 ( PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 13 Mar 2007 07:23:55 -0700
Message-ID: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: AcdlezsOxEEaK+OlRIOYX1kZQWtosA==
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail]
X-WSS-ID: 69E86C713703221989-01-01
Content-Type: text/plain; charset=iso-8859-1
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 l2DEOGu8019801
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 14:24:25 -0000
Status: RO
Content-Length: 737

The issue is not how the information is relayed, or how it is stored,
but who determines what information is relevant.

If all RBridges track MAC Addresses scoped within a VLAN scope
then everything you suggest works perfectly fine. The only correction
needed would be to emphasize that this is indeed a requirement.

But any RBridge that uses a global scope for MAC Addresses should
be told of new MAC detections on different VLANs because such
an RBridge would want to delete the old location.

Unless the RBridge that detected the MAC address knows that all
other RBridges are using VLAN scoped MAC addresses they should
distribute the new information to *all* RBRidges, not just those on
the VLAN where the address was discovered.




Received: from correo12.acens.net (correo12.acens.net [217.116.0.112]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2D9NhLw001534 for <[e-mail]>; Tue, 13 Mar 2007 02:23:44 -0700 (PDT)
Received: (qmail 10799 invoked from network); 13 Mar 2007 09:23:36 -0000
Received: from unknown (HELO [10.0.0.41]) (jmb.lmdata.es@[213.98.12.218]) (envelope-sender <[e-mail]>) by correo12.acens.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 13 Mar 2007 09:23:36 -0000
Message-ID: <[e-mail]>
Date: Tue, 13 Mar 2007 10:23:35 +0100
From: Jose Morales Barroso <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Content-Type: text/html; 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] Global MAC Addresses
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 09:24:27 -0000
Status: RO
Content-Length: 3107

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear colleagues:<br>
<br>
UETS/EFR architecture uses locally administered MAC addresses (U/L bit
= 1), <br>
as you can see at:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf">http://www.lmdata.es/uets/draft/uets-efr-addressing.pdf</a><br>
<br>
This technology permits to switch Ethernet frames directly at the
physical layer, <br>
making it unnecessary to use routing, bridging, or signaling
techniques. <br>
The Destination Address has the routing information, and does not need
tables<br>
of switching, look-up or forwarding, as described in:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf">http://www.lmdata.es/uets/draft/uets-efr-scenario-wwn.pdf</a><br>
<br>
<br>
Using MAC-in-MAC or SNAP, each connection will support another Ethernet
domain.<br>
In this case, the addressing will be huge, even bigger than IPv6,
making possible<br>
to build a "Global Ethernet".<br>
<br>
Jose Morales<br>
<br>
<br>
<blockquote type="cite">
  <div class="moz-text-plain" wrap="true" graphical-quote="true"
 style="font-size: 12px;" lang="x-western">
  <pre wrap="">Eric Gray (LO/EUS) wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap=""><span class="moz-txt-citetags">&gt; </span>	Interstingly enough, I am really sure that the IPv6 folks 
<span class="moz-txt-citetags">&gt; </span>have looked at this before.  And I am also sure that at least one
<span class="moz-txt-citetags">&gt; </span>suggested solution has been considered.  I do not know if any (of
<span class="moz-txt-citetags">&gt; </span>possibly many) proposals were actually adopted but, if none were,
<span class="moz-txt-citetags">&gt; </span>it would be because the IPv6 people did not see this as a problem.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
AFAIK the IPv6 folks have not considered this.
But as you pointed out, the global IPv6 addresses would still be 
globally unique since they would have different subnet prefixes.

The only issue for IPv6 is that this (and host-side virtualization in 
general) means that the the semantics of the universal bit in the 
modified EUI-64 format is even weaker than before.
But there is no protocol to date which assumes anything about the 
semantics of this bit. As RFC 4291 says:

    The use of the universal/local bit in the Modified EUI-64 format
    identifier is to allow development of future technology that can take
    advantage of interface identifiers with universal scope.

   Erik


_______________________________________________
rbridge mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
<a class="moz-txt-link-freetext"
 href="http://mailman.postel.org/mailman/listinfo/rbridge">http://mailman.postel.org/mailman/listinfo/rbridge</a>

  </pre>
  </div>
</blockquote>
</body>
</html>


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2D1ZLjn011251 for <[e-mail]>; Mon, 12 Mar 2007 18:35:21 -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, 12 Mar 2007 18:35:21 -0700 (PDT)
Received: from sun.com ([129.150.17.226]) 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, 12 Mar 2007 18:35:21 -0700 (PDT)
Date: Mon, 12 Mar 2007 18:35:32 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Caitlin Bestler <[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]
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2007 01:35:34 -0000
Status: RO
Content-Length: 2563

I'm not sure I understand what you're saying. But I think the issue is 
how link state information is distributed.

The core instance link state information is flooded to all RBridges, but 
transmitted hop by hop. That means
every RBridge, including core RBridges that do not attach to any VLANs, 
have to store this information,
in addition to forwarding it, in case it needs to be retransmitted to a 
neighbor, or transmitted to a new
neighbor that might come up later.

As the spec currently is, the endnode information is multicast. So R1, 
attached to VLAN A, just multicasts
a single copy of its VLAN A information, and it gets distributed by the 
core like any VLAN A multicast
data packet. It magically gets received just by RBridges attached to 
VLAN A. Only RBridges actually
attached to VLAN A need to store this information. It is not sent 
reliably neighbor-to-neighbor. Only
R1 has to ensure that all the relevant RBridges have received the link 
state information about VLAN A.
THe intervening RBridges just forward it and forget it.

So as I said, you could get rid of running the per-instance IS-IS 
hellos, by just listing, in the core
instance LSP, which VLANs you attach to. There really isn't anything 
that the per-VLAN instance
of the hello protocol
needs to know that isn't already in the core instance link state 
information, so we could eliminate running
4000 Hello and Designated RBridge elections.

However, the per-VLAN link state information (listing the endnodes) is 
potentially large enough that
I believe it is useful to avoid having non-VLAN-A RBridges keep track of 
the VLAN A endnodes (and
VLAN A IP groups and multicast routers).

And if we are using multicast to distribute, I don't see how R1 can 
choose which RBridges to send the
information to, or to format it differently depending on the recipient.

For as many as possible of these sorts of things that are OK to do
either this way or that way, I think we should choose,
rather than making it a parameter.

Radia





Caitlin Bestler wrote:

>One suggestion that I think is adequate:
>
>RBridge Hello messages would be from the core instance
>and sent to core instance. It would list the VLAN IDs
>and whether it maintained a single destination database
>or a per VLAN database.
>
>In the latter case, other RBridges would only forward
>relevant advertisements to RBridges that advertised the
>relevant VLAN. An RBridge using an unscoped database
>would be send all address advertisements.
>
>Alternately, we could explicitly require per VLAN scoping.
>
>
>
>  
>



Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2CN0rN7003701 for <[e-mail]>; Mon, 12 Mar 2007 16:00:53 -0700 (PDT)
Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 12 Mar 2007 16:00:39 -0700
X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9C3D02AF; Mon, 12 Mar 2007 16:00:39 -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 886102AE; Mon, 12 Mar 2007 16:00:39 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBE00120; Mon, 12 Mar 2007 16:00:39 -0700 (PDT)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id DC12A69CE6; Mon, 12 Mar 2007 16:00:38 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 12 Mar 2007 16:00:25 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: Acdk+LVrBIIH880YR26Db9fsV9Es6AAAOS4A
From: "Caitlin Bestler" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, "Erik Nordmark" <[e-mail]>
X-WSS-ID: 69EB041D3A42807922-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 l2CN0rN7003701
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2007 23:01:26 -0000
Status: RO
Content-Length: 501

One suggestion that I think is adequate:

RBridge Hello messages would be from the core instance
and sent to core instance. It would list the VLAN IDs
and whether it maintained a single destination database
or a per VLAN database.

In the latter case, other RBridges would only forward
relevant advertisements to RBridges that advertised the
relevant VLAN. An RBridge using an unscoped database
would be send all address advertisements.

Alternately, we could explicitly require per VLAN scoping.






Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2CMnQ7w000814 for <[e-mail]>; Mon, 12 Mar 2007 15:49:26 -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, 12 Mar 2007 15:49:26 -0700 (PDT)
Received: from sun.com ([129.150.17.226]) 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, 12 Mar 2007 15:49:26 -0700 (PDT)
Date: Mon, 12 Mar 2007 15:49:36 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Erik Nordmark <[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]>
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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2007 22:50:06 -0000
Status: RO
Content-Length: 3087

Yes. There are three ways of sending per-VLAN endnode information:

a) a single instance of IS-IS for both "core" information and "endnode" 
information. Endnode
information would be marked as (VLAN ID, {set of endnodes}).
RBridges that are
not in VLAN A would need to store the VLAN A endnode information, and 
all endnode information would
go to all parts of the campus

b) two instances of  IS-IS: one for core information (which RBridges are 
connected to which other
RBridges, and which VLANs are attached to which RBridges), and one for 
endnode information. Not
sure what advantage/disadvantage this has over a), since all link state 
information would go to all RBridges.

c) n+1 instance of IS-IS, where n is the number of VLANs that are in 
use. Each RBridge R1 would run
k+1 instances of IS-IS; the core instance, and one for each of the k 
VLANs that R1 is attached to.
The advantage of this is that flooding of endnode information for VLAN A 
need not be stored by
any RBridges except those that attach to VLAN A. Also, because the core 
instance enables flooding
of VLAN multicast just to links that are interested (RBridges that are 
attached to VLAN A), there is
further optimization because this information does not need to traverse 
all the links in the campus; just
those needed to get the packet from the RBridge that originates the LSP 
for VLAN A endnode
information to the RBridges that attach to VLAN A.

I prefer c). I don't think there is that much overhead to running n 
instances. It's really like separating
the endnode information into distinct LSPs. Except for...the Hello 
Protocol. If all RBridges are connected
to 4000 VLANs, then they'd all be sending 4000 Hellos, one for each 
instance. The core instance Hellos
are a bit different -- they only go to direct neighbors. But the VLAN 
instances get flooded by the core
to all links throughout the campus attached to that VLAN.

We could eliminate the hello protocol for the per-VLAN instance of 
IS-IS, since there's enough information
in the core instance for all VLAN A RBridges to know about each other 
and decide which should be
Designated (for sending out CSNPs).

Radia

Erik Nordmark wrote:

> [e-mail] wrote:
>
>> I don't agree that we have to explicitly advertise which VLAN a MAC 
>> address belongs to, because
>> each VLAN runs its own instance of IS-IS in which endnodes are 
>> announced. This could be looked
>> at as implicitly advertising the VLAN. In other words, the endnode 
>> information is announced in
>> an instance of IS-IS distinguished by having an inner VLAN tag (I 
>> think that's how we differentiate it).
>> Core RBridges forward it like a multicast packet for that VLAN. Only 
>> border RBridges of that VLAN actually
>> store the information.
>
>
> That is true if you are required to have N IS-IS VLAN instances when 
> there are N VLANs in use.
>
> I don't know if that is overkill when all the RBridges are all part of 
> all N VLANs - basically when it is just different subsets of 
> stations/hosts that make up the different VLANs.
>
>    Erik




Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2CLiVfl015053 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Mon, 12 Mar 2007 14:44:31 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.56.144]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2CLiQje017513; Mon, 12 Mar 2007 21:44:30 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2CLiJSX616878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2007 14:44:20 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 12 Mar 2007 14:44:19 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
To: [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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2007 21:45:00 -0000
Status: RO
Content-Length: 853

[e-mail] wrote:
> I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because
> each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked
> at as implicitly advertising the VLAN. In other words, the endnode information is announced in
> an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it).
> Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually
> store the information.

That is true if you are required to have N IS-IS VLAN instances when 
there are N VLANs in use.

I don't know if that is overkill when all the RBridges are all part of 
all N VLANs - basically when it is just different subsets of 
stations/hosts that make up the different VLANs.

    Erik


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2C1PiFw011801 for <[e-mail]>; Sun, 11 Mar 2007 18:25:45 -0700 (PDT)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Sun, 11 Mar 2007 18:25:35 -0700
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CB2202B0; Sun, 11 Mar 2007 18:25:35 -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 B3E3D2AF; Sun, 11 Mar 2007 18:25:35 -0700 (PDT)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FAV79499; Sun, 11 Mar 2007 17:25:35 -0800 (PST)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id E456F69CA3; Sun, 11 Mar 2007 18:25:34 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 11 Mar 2007 18:25:32 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [rbridge] VLAN Scoping / MAC Uniqueness
Thread-Index: AcdjrnJMrZRHmmgsQWqSEGjRcof4hgAk/ztg
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail], "Erik Nordmark" <[e-mail]>
X-WSS-ID: 69EA738538G2547193-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 l2C1PiFw011801
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2007 01:27:02 -0000
Status: RO
Content-Length: 2413

[e-mail] wrote:
> I don't agree that we have to explicitly advertise which VLAN
> a MAC address belongs to, because each VLAN runs its own
> instance of IS-IS in which endnodes are announced. This could
> be looked at as implicitly advertising the VLAN. In other
> words, the endnode information is announced in an instance of
> IS-IS distinguished by having an inner VLAN tag (I think
> that's how we differentiate it).
> Core RBridges forward it like a multicast packet for that
> VLAN. Only border RBridges of that VLAN actually store the
> information. 
> 
> Radia
> 

VLAN tagging the endnode announcement assumes that the 
announcement is only relevant within the VLAN. That still
leaves the following scenario:

	RBridge I participates in VLANs R and S.
	It uses a single (VLAN independent) MAC learning database.
	It believes the MAC X is on a local port for VLAN R.

	RBridge J participates in VLANs S and T.
	It uses a single (VLAN independent) MAC learning database.
	
	RBridge K participates in VLAN T
	It detects MAC X on a local port for VLAN T.

It would share that information with RBridge J, but not RBridge I.
RBRidge J can now receive contradictory information from I and K.

This is avoided if RBridge K does not presume which RBridges 
need this informaton, or if RBridge I advertises itself as
wanting information for all VLANs (that is, it is a member
of VLAN T, but only for purposes of getting endnode announcements).

As for the more general problem, obviously any CRED which
has varying concepts on the scope over which a MAC address
is unique is going to have potential problems. But most of
that problem is well outside of TRILL's scope. 

The issue that is within TRILL's scope is ensuring that 
endnode announcements are distributed everywhere that
the information is needed.

The prior drafts explicitly assumed that information about
MAC Address X was not relevant to any RBridge that was not
in the same VLAN. This is only a valid assumption if port
learning is being done on a per VLAN basis.

The current drafts do not have this problem, because they
merely state that distribution might be limited based upon
VLAN (which would be appropriate if the RBridges are known
to have compatible scoping concepts).

The language could be more explicit, but to be realistic,
network administrators would generally avoid allowing
this problem to exist in the first place.




Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2B7PSwt021973 for <[e-mail]>; Sat, 10 Mar 2007 23:25:28 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) 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]; Sat, 10 Mar 2007 23:25:15 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.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]; Sat, 10 Mar 2007 23:25:14 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [142.131.243.242]) by mail-srv.sfvic.sunlabs.com (mshttpd); Sat, 10 Mar 2007 23:25:14 -0800
Date: Sat, 10 Mar 2007 23:25:14 -0800
From: [e-mail]
To: Erik Nordmark <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 11 Mar 2007 07:26:05 -0000
Status: RO
Content-Length: 2326

I don't agree that we have to explicitly advertise which VLAN a MAC address belongs to, because
each VLAN runs its own instance of IS-IS in which endnodes are announced. This could be looked
at as implicitly advertising the VLAN. In other words, the endnode information is announced in
an instance of IS-IS distinguished by having an inner VLAN tag (I think that's how we differentiate it).
Core RBridges forward it like a multicast packet for that VLAN. Only border RBridges of that VLAN actually
store the information.

Radia

----- Original Message -----
From: Erik Nordmark <[e-mail]>
Date: Friday, March 9, 2007 4:11 pm
Subject: Re: [rbridge] VLAN Scoping / MAC Uniqueness

> Caitlin Bestler wrote:
> 
> > This suggests three options:
> > 
> > 	1) Require all RBridges to scope on a per-VLAN basis.
> >            The only real flaw in this is that it is a RBridge
> >            requirement that does not apply to conventional bridges.
> > 
> > 	2) Allow all RBridges to have whatever scoping rules they
> >            want, but require that all updates go to all RBridgges.
> >            Each RBridge can judge for itself it the information is
> >            relevant to it, and organize that data however it wants.
> > 
> > 	3) Punt: require the network adminstrator to ensure that naming
> >            scopes enforced by RBRidges are "consistent" and provide
> >            only text-based suggestions on how to achieve this.
> 
> I didn't see a conclusion on this discussion.
> 
> I think 802.1D mandates that bridges be capable of doing learning 
> independently for each VLAN (what is called IVL). Thus mandating 
> the 
> same for RBridges (option 1 above) seems natural.
> 
> I think this means that the link state routing protocol needs to be 
> able 
> to carry <VLAN tag, L2 address> in the LSAs instead of just <L2 
> address>. If that is correct then we should clarify this in the 
> routing 
> requirements. They currently say
>    o  layer 2 addresses of nodes within the domain which have
>       transmitted frames but have not transmitted ARP or ND replies
> and that would need to be the tuple of VLAN tag and L2 address.
> 
>    Erik
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2A0BVuA004200 for <[e-mail]>; Fri, 9 Mar 2007 16:11:31 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2A0BUmH013916; Sat, 10 Mar 2007 00:11:30 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2A0BS8i191360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 16:11:29 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2007 16:11:25 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
To: Caitlin Bestler <[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] VLAN Scoping / MAC Uniqueness
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 10 Mar 2007 00:12:01 -0000
Status: RO
Content-Length: 1364

Caitlin Bestler wrote:

> This suggests three options:
> 
> 	1) Require all RBridges to scope on a per-VLAN basis.
> 	   The only real flaw in this is that it is a RBridge
> 	   requirement that does not apply to conventional bridges.
> 
> 	2) Allow all RBridges to have whatever scoping rules they
> 	   want, but require that all updates go to all RBridgges.
> 	   Each RBridge can judge for itself it the information is
> 	   relevant to it, and organize that data however it wants.
> 
> 	3) Punt: require the network adminstrator to ensure that naming
> 	   scopes enforced by RBRidges are "consistent" and provide
> 	   only text-based suggestions on how to achieve this.

I didn't see a conclusion on this discussion.

I think 802.1D mandates that bridges be capable of doing learning 
independently for each VLAN (what is called IVL). Thus mandating the 
same for RBridges (option 1 above) seems natural.

I think this means that the link state routing protocol needs to be able 
to carry <VLAN tag, L2 address> in the LSAs instead of just <L2 
address>. If that is correct then we should clarify this in the routing 
requirements. They currently say
    o  layer 2 addresses of nodes within the domain which have
       transmitted frames but have not transmitted ARP or ND replies
and that would need to be the tuple of VLAN tag and L2 address.

    Erik


Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2A06KbS002923 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Fri, 9 Mar 2007 16:06:20 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.104.31]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2A06DBM029521; Sat, 10 Mar 2007 00:06:17 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2A06EPQ189892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 16:06:15 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2007 16:06:11 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
To: "Eric Gray (LO/EUS)" <[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] Global MAC Addresses
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 10 Mar 2007 00:06:27 -0000
Status: RO
Content-Length: 1055

Eric Gray (LO/EUS) wrote:

> 	Interstingly enough, I am really sure that the IPv6 folks 
> have looked at this before.  And I am also sure that at least one
> suggested solution has been considered.  I do not know if any (of
> possibly many) proposals were actually adopted but, if none were,
> it would be because the IPv6 people did not see this as a problem.

AFAIK the IPv6 folks have not considered this.
But as you pointed out, the global IPv6 addresses would still be 
globally unique since they would have different subnet prefixes.

The only issue for IPv6 is that this (and host-side virtualization in 
general) means that the the semantics of the universal bit in the 
modified EUI-64 format is even weaker than before.
But there is no protocol to date which assumes anything about the 
semantics of this bit. As RFC 4291 says:

    The use of the universal/local bit in the Modified EUI-64 format
    identifier is to allow development of future technology that can take
    advantage of interface identifiers with universal scope.

   Erik




Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29NwwSY001263 for <[e-mail]>; Fri, 9 Mar 2007 15:58:58 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.106.105]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29Nwvx8002937; Fri, 9 Mar 2007 23:58:57 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l29NwuBk186171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 15:58:56 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2007 15:58:42 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
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]> <[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]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2007 23:59:35 -0000
Status: RO
Content-Length: 2023

Dino Farinacci wrote:

> The simplest example is when using multi-access links. The fact that 
> some switches use the multi-access link as an oif and others use the 
> link as an expected-incoming interface.
> 
> So if the ones that are using the multi-access link as an oif happen to 
> join the root through one of the other switches (which can be many hops 
> away), then the multicast forwarding (and replication) loop occurs.

With TRILL be clearly have to be careful at the edge (the ingress and 
egress rbridges) when it comes to the relationship between 802.1D and 
designated RBridge in order to handle topology changes. In particular 
since the frames without the TRILL header header doesn't have a TTL.

But leaving that aside for a moment, the way Radia described the 
forwarding check (the "expected incoming adjacency" check), the transit 
paths between the RBridges would act as point-to-point due to checking 
both the incoming port and the previous hop RBridge.

It was in such a pt-pt topology that I tried to find a simple example of 
a temporary loop.

>> Have you observed temporary IP Multicast loops? (apart from the PIM SM 
>> ones before ASSERTS where added). What was the topology and change 
>> necessary to trigger those?
> 
> Oh definitely, when two routers think the RP for a (*,G) are different. 
> And this can happen when the topology is in steady state.
> 
> And this happens due to misconfiguration or in the early days of PIM 
> when you detect one RP down, you move to another one, but others in the 
> topology stayed with the original one. Again, in a steady-state 
> topology. The reason some thought the RP went down is because the 
> network was congested and the RP keepalives were all lost. Those were 
> interesting times.  ;-)
> 
> So this can happen in IS-IS as well if the not everyone is using the 
> same roots.

But AFAICT that type of loop can't happen in TRILL since we have an 
explicit designator for the tree to use in every multi-destination data 
frame.

    Erik


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29Na4BC024800 for <[e-mail]>; Fri, 9 Mar 2007 15:36:04 -0800 (PST)
Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2007 15:36:04 -0800
X-IronPort-AV: i="4.14,268,1170662400";  d="scan'208"; a="119715557:sNHT45711342"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l29Na4nj001280;  Fri, 9 Mar 2007 15:36:04 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l29NZsxb002843; Fri, 9 Mar 2007 23:36:00 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 9 Mar 2007 15:35:59 -0800
Received: from [10.253.200.34] ([10.21.81.164]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 9 Mar 2007 15:35:59 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <[e-mail]>
Date: Fri, 9 Mar 2007 15:36:03 -0800
To: Erik Nordmark <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 09 Mar 2007 23:35:59.0603 (UTC) FILETIME=[B13BDC30:01C762A3]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1628; t=1173483364; x=1174347364; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dino=20Farinacci=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=nHM4UA0KwpbCsRQQZ6HHE0zb+Tef9OLNC8IubgvxjyY=; b=GuSNCC+ZkbKaNC3rV+GqQ7+GUQLokO4grlBjk6+nNj0Jsbs/6RiE+xjO7yB3I5WGBbdHQ3p0 YnYqB7CvBKkNmbINNz5iX6X8RxBLZpFrfZGt6DKDvXGQmDRjG+umpTGj;
Authentication-Results: sj-dkim-5; header.From=[e-mail]; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2007 23:36:32 -0000
Status: RO
Content-Length: 1593

> I'm trying to draw an example topology where a change causes a  
> transient multicast loop (with an "expected incoming adjacency"  
> check) and I can't  find one. Unicast is sooo much easier ;-)

The simplest example is when using multi-access links. The fact that  
some switches use the multi-access link as an oif and others use the  
link as an expected-incoming interface.

So if the ones that are using the multi-access link as an oif happen  
to join the root through one of the other switches (which can be many  
hops away), then the multicast forwarding (and replication) loop occurs.

This only happens when the link state database is not in sync among  
the switches involved because each one thinks the root is located on  
a different path while still consider the same location of the  
receivers.

> Have you observed temporary IP Multicast loops? (apart from the PIM  
> SM ones before ASSERTS where added). What was the topology and  
> change necessary to trigger those?

Oh definitely, when two routers think the RP for a (*,G) are  
different. And this can happen when the topology is in steady state.

And this happens due to misconfiguration or in the early days of PIM  
when you detect one RP down, you move to another one, but others in  
the topology stayed with the original one. Again, in a steady-state  
topology. The reason some thought the RP went down is because the  
network was congested and the RP keepalives were all lost. Those were  
interesting times.  ;-)

So this can happen in IS-IS as well if the not everyone is using the  
same roots.

Dino


Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29Mc0PP011160 for <[e-mail]>; Fri, 9 Mar 2007 14:38:00 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.228.31]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29Mbxun013929; Fri, 9 Mar 2007 22:37:59 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l29MbwdA174717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 14:37:58 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 09 Mar 2007 14:37:58 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
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]>
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], [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2007 22:38:24 -0000
Status: RO
Content-Length: 673

Dino Farinacci wrote:
>> Will you also agree with me that this technique is useful for  
>> network in
>> a steady state, but does not prevent temporary loops when there is a
>> topology change?
> 
> I agree there will be transient multicast packet looping when there  
> are topology changes.

Dino,

I'm trying to draw an example topology where a change causes a transient 
multicast loop (with an "expected incoming adjacency" check) and I can't 
  find one. Unicast is sooo much easier ;-)

Have you observed temporary IP Multicast loops? (apart from the PIM SM 
ones before ASSERTS where added). What was the topology and change 
necessary to trigger those?

    Erik


Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29LCPjR017483 for <[e-mail]>; Fri, 9 Mar 2007 13:12:25 -0800 (PST)
Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 09 Mar 2007 13:12:13 -0800
X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 030B72B0; Fri, 9 Mar 2007 13:12:13 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id E3F122AF for <[e-mail]>; Fri, 9 Mar 2007 13:12:12 -0800 (PST)
Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FAP22606; Fri, 9 Mar 2007 13:12:12 -0800 (PST)
Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 4A28869CA4 for <[e-mail]>; Fri, 9 Mar 2007 13:12:12 -0800 ( PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 9 Mar 2007 13:12:11 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: NITS RE: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt
Thread-Index: AcdhxouSEzY9fPumQjKKH6czZxJ+LwAxxu4Q
From: "Caitlin Bestler" <[e-mail]>
To: [e-mail]
X-WSS-ID: 69EF122738G1388067-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 l29LCPjR017483
Subject: [rbridge] NITS RE: I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2007 21:12:56 -0000
Status: RO
Content-Length: 441

The definition of "CRED" in section 2.2 fails to clarify
where the "D" comes from.

	o  CRED: Cooperating RBridges and Encapsulation Tunnels - a 
      topological construct consisting of a set of cooperating 
      RBridges, and the forwarding tunnels connecting them.

The CFT-RDT table is not given a distinct long name. This is
especially apparent when looking at the headers 3.2.1 and 3.2.2,
which differ only by the short names.








Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28MY8oA018134 for <[e-mail]>; Thu, 8 Mar 2007 14:34:08 -0800 (PST)
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2007 14:34:08 -0800
X-IronPort-AV: i="4.14,264,1170662400";  d="scan'208"; a="765971593:sNHT50213356"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l28MY7lC025736;  Thu, 8 Mar 2007 14:34:07 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l28MY11r023981; Thu, 8 Mar 2007 22:34:07 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 14:34:00 -0800
Received: from [171.71.57.36] ([171.71.57.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 14:34:00 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <[e-mail]>
Date: Thu, 8 Mar 2007 14:34:05 -0800
To: "Silvano Gai" <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 Mar 2007 22:34:00.0291 (UTC) FILETIME=[DDF02330:01C761D1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=277; t=1173393247; x=1174257247; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dino=20Farinacci=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=RejDwJa7iI6h4z1u+OQRmLi+P8lOwcnkMP3nvD4P8WU=; b=il7dX3xtGLz/ozZFV3UDnqFOVTYhUZm3zpcPIgkLFLKU+c952wpGX6DCZzf6BOSBS1xwebth kRVrs7umFdsAjjhODTRw7b1NrGHm8DZLx3B+YxKBe9Ci9ndueycSramT;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 22:34:35 -0000
Status: RO
Content-Length: 268

> Will you also agree with me that this technique is useful for  
> network in
> a steady state, but does not prevent temporary loops when there is a
> topology change?

I agree there will be transient multicast packet looping when there  
are topology changes.

Dino


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28M14Dc009773 for <[e-mail]>; Thu, 8 Mar 2007 14:01:04 -0800 (PST)
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: Thu, 8 Mar 2007 14:01:00 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees
thread-index: AcdhvGLm6W/ZqgQPShy0sUq5zITDOQAEJQkg
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Dino Farinacci" <[e-mail]>, <[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 l28M14Dc009773
Cc: [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 22:01:25 -0000
Status: RO
Content-Length: 1038

I am glad you agree ;-)

Will you also agree with me that this technique is useful for network in
a steady state, but does not prevent temporary loops when there is a
topology change?

-- Silvano 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Dino Farinacci
> Sent: Thursday, March 08, 2007 11:49 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge
> trees
> 
> > There is an open question, however, which is whether the "expected
> > incoming interface" check should be
> > SHOULD, MAY or MUST for checking not just port, but neighbor. The
> > downside is the extra 6-byte
> > check, as you point out. The upside is less likely to have bizarre
> > temporary loops. I'd vote for
> > MUST actually.
> 
> I definitely agree with MUST.
> 
> Dino
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge



Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28Ko8lb022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 8 Mar 2007 12:50:09 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D7405176C7; Thu,  8 Mar 2007 20:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYp-0007H7-JE; Thu, 08 Mar 2007 15:50:03 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 08 Mar 2007 15:50:03 -0500
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-02.txt
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 20:50:23 -0000
Status: RO
Content-Length: 3764

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: The Architecture of an RBridge Solution to TRILL
	Author(s)	: E. Gray
	Filename	: draft-ietf-trill-rbridge-arch-02.txt
	Pages		: 35
	Date		: 2007-3-8
	
RBridges are link layer (L2) devices that use routing protocols 
        as a control plane. They combine several of the benefits of the 
        link layer with network layer routing benefits. RBridges use 
        existing link state routing (without requiring configuration) to 
        improve RBridge to RBridge aggregate throughput. RBridges also 
        provide support for IP multicast and IP address resolution 
        optimizations. They are intended to be applicable to similar L2 
        network sizes as conventional bridges and are intended to be 
        backward compatible with those bridges as both ingress/egress 
        and transit. They also support VLANs (although this generally 
        requires configuration) and otherwise attempt to retain as much 
        'plug and play' as is already available in existing bridges. 
        This document proposes an RBridge system as a solution to the 
        TRILL problem. It also defines the RBridge architecture, defines 
        its terminology, and describes basic components and desired 
        behavior. One or more separate documents specify the protocols 
        and mechanisms that satisfy the architecture presented herein.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-arch-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-rbridge-arch-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-arch-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-arch-02.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart--



Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28Jn1hL007962 for <[e-mail]>; Thu, 8 Mar 2007 11:49:01 -0800 (PST)
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2007 11:49:01 -0800
X-IronPort-AV: i="4.14,264,1170662400";  d="scan'208"; a="364702245:sNHT56643876"
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 l28Jn1sB002487;  Thu, 8 Mar 2007 11:49:01 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l28Jn1a3028331; Thu, 8 Mar 2007 19:49:01 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 11:49:00 -0800
Received: from [171.71.55.98] ([171.71.55.98]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 11:49:00 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <[e-mail]>
Date: Thu, 8 Mar 2007 11:49:04 -0800
To: [e-mail]
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 Mar 2007 19:49:00.0481 (UTC) FILETIME=[D1310310:01C761BA]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=378; t=1173383341; x=1174247341; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dino=20Farinacci=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=ln0kn5O/6ItCxbSGbwAyGPQcYdz+gi1T6AoSGEOdwO8=; b=WwuDHhJM9JAk0CaVOdwbqhN18HREXDSeCh6KI7dmqjTJPxMnz4JM/NcoZAxjNAm99aGW+JXZ JeSnk62EHKpJ7UEhKnDYbgV6Pg2CfZZ1fwE+sH31ByEEsEGKMJtXvOn7;
Authentication-Results: sj-dkim-6; header.From=[e-mail]; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 19:49:24 -0000
Status: RO
Content-Length: 367

> There is an open question, however, which is whether the "expected  
> incoming interface" check should be
> SHOULD, MAY or MUST for checking not just port, but neighbor. The  
> downside is the extra 6-byte
> check, as you point out. The upside is less likely to have bizarre  
> temporary loops. I'd vote for
> MUST actually.

I definitely agree with MUST.

Dino


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28Iru3i023415 for <[e-mail]>; Thu, 8 Mar 2007 10:53:57 -0800 (PST)
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, 08 Mar 2007 10:53:56 -0800 (PST)
Received: from [129.145.154.55] 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, 08 Mar 2007 10:53:56 -0800 (PST)
Date: Thu, 08 Mar 2007 10:53:55 -0800
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]> <[e-mail]> <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060629
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 18:54:24 -0000
Status: RO
Content-Length: 4278

Yup. The bottom line, for those only skimming, is that you and I are not 
disagreeing
about anything.

And the action item from this thread is that the extra announcement 
"these are the trees I will specify" should go
into IS-IS, in the core instance LSP.

Also, in the protocol spec, it we should update the forwarding/filtering 
rules to include
"allowed ingress RBridges on this adjacency/port", and make sure the 
filtering rules really
do specify what you and I said, in different words.

There is an open question, however, which is whether the "expected 
incoming interface" check should be
SHOULD, MAY or MUST for checking not just port, but neighbor. The 
downside is the extra 6-byte
check, as you point out. The upside is less likely to have bizarre 
temporary loops. I'd vote for
MUST actually.

Radia



Dino Farinacci wrote On 03/08/07 10:20,:

>>We're not talking about G's here, as in specific multicast  
>>destination addresses. We're talking
>>about
>>a) Distinct distribution trees: computed by using the link state  
>>database to compute a shortest path
>>tree from the named Root
>>b) ingress RBridges, for filtering based on "expected incoming  
>>interface (adjacency) check"
>>    
>>
>
>Yes, I understand that. But the state storage cost here is more in  
>control-plane memory which is less of a concern than forwarding-plane  
>memory. That is why I spoke up.
>
>  
>
>>(Note: when you say "interface" do you mean what I refer to as  
>>"adjacency" (which is a (port, neighbor) pair),
>>    
>>
>
>I meant port, but if you want to do a last-hop neighbor incoming  
>check then you have to do a 6-byte compare and are required to have  
>the last-hop MAC address in the frame. I know the frame formats have  
>been changing, so not sure that the last-hop MAC address is still in  
>the frame (I'm behind on TRILL reading).
>
>  
>
>>or do you mean "port"? -- I'll assume you mean "adjacency", and  
>>therefore I'll use "interface" because I
>>never really liked the word "adjacency" --- too many syllables, and  
>>it's a word I never tend to use in
>>ordinary conversation.
>>    
>>
>
>Right, adjacency tends to be more unicast centric and means  
>downstream. We are talking about upstream interfaces here (closer to  
>the source and not closer towards the destination).
>
>  
>
>>Anyway...where G's come in (as well as VLANs), is further filtering  
>>information on each interface in the
>>named tree.
>>    
>>
>
>Right.
>
>  
>
>>So the rules are, if  R3 receives a multicast packet on interface  
>>i, with named tree=R2, and ingress RBridge=R1,
>>then:
>>
>>if R1 is not on the expected source list for interface i, then the  
>>packet is dropped
>>    
>>
>
>Right, said another way if R1 is not the last-hop device on the  
>shortest path from R1 to R3, the packet is dropped.
>
>  
>
>>passing that check, for each interface other than i, in tree R2,  
>>filtering is done based on whether the VLAN
>>    
>>
>
>Yes. But I mentioned this before. The oif-list for the G is populated  
>based on the receivers downstream. So you actually filter by default  
>and only the ports in the oif-list get packets sent out on.
>
>I know why you say filtered, because you are describing a broadcast  
>tree which contains all links in the topology and the membership tree  
>is typically a subset of those links.
>
>Doesn't matter, just terms. I think we agree on the concept.
>
>  
>
>>specified in the inner frame can be reached downstream on that  
>>interface, and for IP multicast group G, whether
>>either IP multicast routers, or receivers for G are reachable  
>>downstream on that interface.
>>    
>>
>
>Right.
>
>But just to reiterate my point, when a packet comes into an rBridge,  
>in fast switching mode, an entry like this exists to be forwarded on  
>if the DA is G:
>
>     (*,G), incoming-interface: port i, oif-list: port j, k, l
>
>So as you say if the packet came in on port i, the packet gets  
>replicated out
>ports j,k,l. If the packet comes in on any other port, it is dropped.
>
>What I describe above could be implemented in a fast hardware  
>implementation.
>
>Dino
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28IKb2Q015363 for <[e-mail]>; Thu, 8 Mar 2007 10:20:37 -0800 (PST)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2007 10:20:35 -0800
X-IronPort-AV: i="4.14,264,1170662400";  d="scan'208"; a="119276010:sNHT47950209"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l28IKYSe031365;  Thu, 8 Mar 2007 10:20:34 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l28IKUe3015219; Thu, 8 Mar 2007 18:20:34 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 10:20:34 -0800
Received: from [10.253.144.98] ([10.21.82.142]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 10:20:34 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <[e-mail]>
Date: Thu, 8 Mar 2007 10:20:36 -0800
To: Radia Perlman <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 Mar 2007 18:20:34.0174 (UTC) FILETIME=[7662D1E0:01C761AE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3192; t=1173378035; x=1174242035; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dino=20Farinacci=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=PpCys0nt6Vtepypcd9uAxCPA7oWTx0QjnRf89eIbfLE=; b=dESXXEUoFPzAnxic97Zu7z5bRqyt4/yVYKMuT2A24J0b/s1+S+AwxV3SrDhkDjI/4mR+d9Dm qQHH7rahmjYP1PpVPuHf0lEbLRwuh8ApquJ8RNNNjVepDxiczpOm6FaI;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 18:20:53 -0000
Status: RO
Content-Length: 3110

> We're not talking about G's here, as in specific multicast  
> destination addresses. We're talking
> about
> a) Distinct distribution trees: computed by using the link state  
> database to compute a shortest path
> tree from the named Root
> b) ingress RBridges, for filtering based on "expected incoming  
> interface (adjacency) check"

Yes, I understand that. But the state storage cost here is more in  
control-plane memory which is less of a concern than forwarding-plane  
memory. That is why I spoke up.

> (Note: when you say "interface" do you mean what I refer to as  
> "adjacency" (which is a (port, neighbor) pair),

I meant port, but if you want to do a last-hop neighbor incoming  
check then you have to do a 6-byte compare and are required to have  
the last-hop MAC address in the frame. I know the frame formats have  
been changing, so not sure that the last-hop MAC address is still in  
the frame (I'm behind on TRILL reading).

> or do you mean "port"? -- I'll assume you mean "adjacency", and  
> therefore I'll use "interface" because I
> never really liked the word "adjacency" --- too many syllables, and  
> it's a word I never tend to use in
> ordinary conversation.

Right, adjacency tends to be more unicast centric and means  
downstream. We are talking about upstream interfaces here (closer to  
the source and not closer towards the destination).

> Anyway...where G's come in (as well as VLANs), is further filtering  
> information on each interface in the
> named tree.

Right.

> So the rules are, if  R3 receives a multicast packet on interface  
> i, with named tree=R2, and ingress RBridge=R1,
> then:
>
> if R1 is not on the expected source list for interface i, then the  
> packet is dropped

Right, said another way if R1 is not the last-hop device on the  
shortest path from R1 to R3, the packet is dropped.

> passing that check, for each interface other than i, in tree R2,  
> filtering is done based on whether the VLAN

Yes. But I mentioned this before. The oif-list for the G is populated  
based on the receivers downstream. So you actually filter by default  
and only the ports in the oif-list get packets sent out on.

I know why you say filtered, because you are describing a broadcast  
tree which contains all links in the topology and the membership tree  
is typically a subset of those links.

Doesn't matter, just terms. I think we agree on the concept.

> specified in the inner frame can be reached downstream on that  
> interface, and for IP multicast group G, whether
> either IP multicast routers, or receivers for G are reachable  
> downstream on that interface.

Right.

But just to reiterate my point, when a packet comes into an rBridge,  
in fast switching mode, an entry like this exists to be forwarded on  
if the DA is G:

     (*,G), incoming-interface: port i, oif-list: port j, k, l

So as you say if the packet came in on port i, the packet gets  
replicated out
ports j,k,l. If the packet comes in on any other port, it is dropped.

What I describe above could be implemented in a fast hardware  
implementation.

Dino


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28HvOmD009223 for <[e-mail]>; Thu, 8 Mar 2007 09:57:24 -0800 (PST)
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, 08 Mar 2007 09:57:24 -0800 (PST)
Received: from sun.com ([129.150.17.32]) 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, 08 Mar 2007 09:57:24 -0800 (PST)
Date: Thu, 08 Mar 2007 09:57:31 -0800
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=ISO-8859-1; 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] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 17:57:56 -0000
Status: RO
Content-Length: 2054

We're not talking about G's here, as in specific multicast destination 
addresses. We're talking
about
a) Distinct distribution trees: computed by using the link state 
database to compute a shortest path
tree from the named Root
b) ingress RBridges, for filtering based on "expected incoming interface 
(adjacency) check"

(Note: when you say "interface" do you mean what I refer to as 
"adjacency" (which is a (port, neighbor) pair),
or do you mean "port"? -- I'll assume you mean "adjacency", and 
therefore I'll use "interface" because I
never really liked the word "adjacency" --- too many syllables, and it's 
a word I never tend to use in
ordinary conversation.

Anyway...where G's come in (as well as VLANs), is further filtering 
information on each interface in the
named tree.

So the rules are, if  R3 receives a multicast packet on interface i, 
with named tree=R2, and ingress RBridge=R1,
then:

if R1 is not on the expected source list for interface i, then the 
packet is dropped

passing that check, for each interface other than i, in tree R2, 
filtering is done based on whether the VLAN
specified in the inner frame can be reached downstream on that 
interface, and for IP multicast group G, whether
either IP multicast routers, or receivers for G are reachable downstream 
on that interface.

Radia

Dino Farinacci wrote:

>
> The dominate state in the forwarding plane is number of group  
> entries, regardless of he number of roots. The forwarding plane  
> forwards on (*,G) entries, so that is the state volume we want to  
> keep an eye on.
>
>> The default is "compute a tree based on me" and "I will always choose
>> tree rooted as me", which would result in (# of trees) state. The only
>> RPF state at R2, for tree R1,
>> is to put R1 onto the adjacency from which frames
>> from R1 should arrive, and the null set on the other adjacencies in
>> the R1 tree.
>
>
> This doesn't make sense to me. You want to choose one root for a  
> particular (*,G) entry and all rBridges use the same root for this  
> entry.
>
> Dino




Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28HW2iB002567 for <[e-mail]>; Thu, 8 Mar 2007 09:32:02 -0800 (PST)
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2007 09:31:54 -0800
X-IronPort-AV: i="4.14,264,1170662400";  d="scan'208"; a="469331336:sNHT46401144"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l28HVs70001357;  Thu, 8 Mar 2007 09:31:54 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l28HViaT009204; Thu, 8 Mar 2007 17:31:54 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 09:31:51 -0800
Received: from [10.253.144.98] ([10.21.82.142]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 8 Mar 2007 09:31:50 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <[e-mail]>
Date: Thu, 8 Mar 2007 09:31:54 -0800
To: [e-mail]
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 Mar 2007 17:31:50.0799 (UTC) FILETIME=[A7EB31F0:01C761A7]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1178; t=1173375114; x=1174239114; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dino=20Farinacci=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=MIxi4jdRw/nDOEmJWzdTPMaAS/h15KYUESgXPBtXNlg=; b=gAsmh8uSB7Br0LFJttZhErwWz3XHuSzznvcukxKxMMTHrSf7oSzZmQM1CkwMHx0Py0KSYvTD PSJV/aHJceW789TMKOWlYOOy/hXmTafNhbl62jjjTp8l+tiAIjckafn9;
Authentication-Results: sj-dkim-8; header.From=[e-mail]; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 17:32:30 -0000
Status: RO
Content-Length: 1147

> As for terminology, I don't care. Is there a better term than "RPF  
> check"?

It it not an RPF check, because as you and Sanjay described it, the  
best-path from an rBridge to a receiver is on the forward path.

So an appropriate and less misleading term is "the expected incoming  
interface check".

> And as you observed, the reason for having R1 announce the set of  
> trees
> it will select is to avoid having (# of trees) * (# of RBridges)  
> RPF state.

The dominate state in the forwarding plane is number of group  
entries, regardless of he number of roots. The forwarding plane  
forwards on (*,G) entries, so that is the state volume we want to  
keep an eye on.

> The default is "compute a tree based on me" and "I will always choose
> tree rooted as me", which would result in (# of trees) state. The only
> RPF state at R2, for tree R1,
> is to put R1 onto the adjacency from which frames
> from R1 should arrive, and the null set on the other adjacencies in
> the R1 tree.

This doesn't make sense to me. You want to choose one root for a  
particular (*,G) entry and all rBridges use the same root for this  
entry.

Dino


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l28GTiHl013737 for <[e-mail]>; Thu, 8 Mar 2007 08:29:44 -0800 (PST)
Received: from sml-sfvt3a.sfvic.sunlabs.com ([152.70.2.254]) 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, 08 Mar 2007 08:29:44 -0800 (PST)
Received: from sunlabs.com ([152.70.2.254]) by mail-srv.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, 08 Mar 2007 08:29:43 -0800 (PST)
Received: from [152.70.2.164] (Forwarded-For: [66.126.243.35]) by mail-srv.sfvic.sunlabs.com (mshttpd); Thu, 08 Mar 2007 08:29:43 -0800
Date: Thu, 08 Mar 2007 08:29:43 -0800
From: [e-mail]
To: "Sanjay Sane (sanjays)" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.1 HotFix 0.02 (built Aug 25 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 16:30:25 -0000
Status: RO
Content-Length: 4388

Sanjay,

We are agreeing on the technical details.

As for terminology, I don't care. Is there a better term than "RPF check"?

And as you observed, the reason for having R1 announce the set of trees
it will select is to avoid having (# of trees) * (# of RBridges) RPF state.

The default is "compute a tree based on me" and "I will always choose
tree rooted as me", which would result in (# of trees) state. The only
RPF state at R2, for tree R1,
is to put R1 onto the adjacency from which frames
from R1 should arrive, and the null set on the other adjacencies in
the R1 tree.

The only reasons R1 should choose a tree other than itself are:

a) R1 is configured to decline being a tree root, in order to cut down
on the number of trees RBridges need to compute, in which case R1 will,
in most cases,
be configured to just announce one tree, and always select that one

b) R1 is sourcing some high volume multicast sources, in which case
R1 is likely to be configured to choose perhaps 2, maybe 3, but not
"lots of" different trees.

So with this announcement of which trees R1 will choose when ingressing
packets, it greatly simplifies RPF state.

Radia

----- Original Message -----
From: "Sanjay Sane (sanjays)" <[e-mail]>
Date: Wednesday, March 7, 2007 11:19 pm
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees

> 
> What every rbridge wants to do is -- 
> for every rbridge Rx that could use tree R1, 
> On this tree R1, find which is the interface that leads me towards Rx,
> or leads Rx towards me.
> Multicast packets ingressed from Rx, and using tree R1, should be
> allowed to come in only on this interface. 
> 
> The RPF state per interface could potentially be 
> #ofswitches * #oftrees
> 
> By announcing this field, are you just trying to reduce the RPF 
> state ? 
> 
> btw, should we use the term "RPF" to denote what's being checked here?
> What we're really checking is whether the ingress rbridge is really
> forwarding as per a given R1 tree. 
> 
> -Sanjay
> 
> 
> -----Original Message-----
> From: [e-mail] [[e-mail]] On
> Behalf Of Radia Perlman
> Sent: Wednesday, March 07, 2007 6:18 PM
> To: [e-mail]
> Subject: [rbridge] How to do RPF checks for bidirectional RBridge 
> trees
> It isn't totally obvious how to do RPF (reverse path forwarding) 
> checksto make multicast forwarding safer, when we're doing 
> bidirectional trees
> (ingress is R1, but R1 chooses tree root R2).
> 
> So after thinking about it, I think this is how it would work, and it
> introduces a new field that would be nice to add to the core instance
> IS-IS LSP. The field is "I promise to only choose the following set of
> RBridges to be tree roots". The only reasons for R1 to choose a
> distribution tree rooted on an RBridge other than itself are:
> 
> a) R1 is configured not to ask to be a tree root (so that RBridges 
> don'thave to calculate as many trees)
> 
> b) R1 wants to multipath multicast originating on its attached links.
> 
> The reason for having R1 preannounce is to simplify creating an RPF
> database associated with each tree.
> 
> If tree R1 is used if and only if R1 is the ingress for the data, then
> the RPF tree for tree R1 would look like this, at some RBridge R in 
> thecore:
> 
> for each "adjacency" (neighbor/port): one of the following: not in 
> tree,in-port, or out-port. The RPF check would discard any incoming 
> data for
> tree R1 except on the in-port.
> 
> However, if R1 chooses R2 as the root of the multicast tree, then the
> RPF database associated with the tree R2, at some core RBridge R looks
> like this:
> 
> Let S be the set of RBridges that have announced, in their LSPs, that
> they might choose R2 as the tree for multicast traffic they are 
> sourcinginto the campus.
> 
> R keeps, for tree R2, and for each adjacency, {set of RBridges that 
> areplausible ingress RBridges for packets received on that adjacency}.
> 
> The set union of all of those will be S.
> 
> I hope that's correct, and that I've explained it clearly....
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 



Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l287JLpO009149 for <[e-mail]>; Wed, 7 Mar 2007 23:19:21 -0800 (PST)
Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2007 23:19:21 -0800
X-IronPort-AV: i="4.14,263,1170662400";  d="scan'208"; a="46488593:sNHT60593526"
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 l287JKXp004961;  Wed, 7 Mar 2007 23:19:20 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l287JKxR010186; Thu, 8 Mar 2007 07:19:20 GMT
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 7 Mar 2007 23:19:20 -0800
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, 7 Mar 2007 23:19:23 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] How to do RPF checks for bidirectional RBridge trees
Thread-Index: AcdhKkY4Dt6+4fFfTE6Tk3HJ8iVSOAAIth1A
From: "Sanjay Sane \(sanjays\)" <[e-mail]>
To: "Radia Perlman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 08 Mar 2007 07:19:20.0425 (UTC) FILETIME=[16FD2590:01C76152]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2819; t=1173338360; x=1174202360; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Sanjay=20Sane=20\(sanjays\)=22=20<[e-mail]> |Subject:=20RE=3A=20[rbridge]=20How=20to=20do=20RPF=20checks=20for=20bidi rectional=20RBridge=20trees |Sender:=20; bh=j/3/YerqSpa/62l4/hTTDXQfDaTUuoucfptkZKaZCU0=; b=MCXUjLS2VQ2G3I+PFFcX9fOx0b3tdXcs45OGFOXdHXTR98eHN6lAH1xAP/nay82vUJ/dMYHO JpbhBLr5YVC+6E6ykrz/TlVlGEYCuqaNn81yV+hP5k8bWZKXiz0VZULq;
Authentication-Results: sj-dkim-6; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); 
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 l287JLpO009149
Subject: Re: [rbridge] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 07:19:54 -0000
Status: RO
Content-Length: 2732

What every rbridge wants to do is -- 
for every rbridge Rx that could use tree R1, 
On this tree R1, find which is the interface that leads me towards Rx,
or leads Rx towards me.
Multicast packets ingressed from Rx, and using tree R1, should be
allowed to come in only on this interface. 

The RPF state per interface could potentially be 
#ofswitches * #oftrees

By announcing this field, are you just trying to reduce the RPF state ? 

btw, should we use the term "RPF" to denote what's being checked here?
What we're really checking is whether the ingress rbridge is really
forwarding as per a given R1 tree. 

-Sanjay
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Radia Perlman
Sent: Wednesday, March 07, 2007 6:18 PM
To: [e-mail]
Subject: [rbridge] How to do RPF checks for bidirectional RBridge trees

It isn't totally obvious how to do RPF (reverse path forwarding) checks
to make multicast forwarding safer, when we're doing bidirectional trees
(ingress is R1, but R1 chooses tree root R2).

So after thinking about it, I think this is how it would work, and it
introduces a new field that would be nice to add to the core instance
IS-IS LSP. The field is "I promise to only choose the following set of
RBridges to be tree roots". The only reasons for R1 to choose a
distribution tree rooted on an RBridge other than itself are:

a) R1 is configured not to ask to be a tree root (so that RBridges don't
have to calculate as many trees)

b) R1 wants to multipath multicast originating on its attached links.

The reason for having R1 preannounce is to simplify creating an RPF
database associated with each tree.

If tree R1 is used if and only if R1 is the ingress for the data, then
the RPF tree for tree R1 would look like this, at some RBridge R in the
core:

for each "adjacency" (neighbor/port): one of the following: not in tree,
in-port, or out-port. The RPF check would discard any incoming data for
tree R1 except on the in-port.

However, if R1 chooses R2 as the root of the multicast tree, then the
RPF database associated with the tree R2, at some core RBridge R looks
like this:

Let S be the set of RBridges that have announced, in their LSPs, that
they might choose R2 as the tree for multicast traffic they are sourcing
into the campus.

R keeps, for tree R2, and for each adjacency, {set of RBridges that are
plausible ingress RBridges for packets received on that adjacency}.

The set union of all of those will be S.

I hope that's correct, and that I've explained it clearly....

Radia

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l282Hgkg007499 for <[e-mail]>; Wed, 7 Mar 2007 18:17:43 -0800 (PST)
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, 07 Mar 2007 18:17:42 -0800 (PST)
Received: from sun.com ([129.150.18.109]) 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, 07 Mar 2007 18:17:42 -0800 (PST)
Date: Wed, 07 Mar 2007 18:17:50 -0800
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] How to do RPF checks for bidirectional RBridge trees
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 02:18:13 -0000
Status: RO
Content-Length: 1723

It isn't totally obvious how to do RPF (reverse path forwarding) checks 
to make multicast forwarding safer, when we're doing bidirectional trees 
(ingress is R1, but R1 chooses tree root R2).

So after thinking about it, I think this is how it would work, and it
introduces a new field that would be nice to add to the core instance 
IS-IS LSP. The field is "I promise to only choose the following set of 
RBridges to be tree roots". The only reasons for R1 to choose a 
distribution tree rooted on an RBridge other than itself are:

a) R1 is configured not to ask to be a tree root (so that RBridges don't 
have to calculate as many trees)

b) R1 wants to multipath multicast originating on its attached links.

The reason for having R1 preannounce is to simplify creating an RPF 
database associated with each tree.

If tree R1 is used if and only if R1 is the ingress for the data, then 
the RPF tree for tree R1 would look like this, at some RBridge R in the 
core:

for each "adjacency" (neighbor/port): one of the following: not in tree, 
in-port, or out-port. The RPF check would discard any incoming data for 
tree R1 except on the in-port.

However, if R1 chooses R2 as the root of the multicast tree, then the 
RPF database associated with the tree R2, at some core RBridge R looks 
like this:

Let S be the set of RBridges that have announced, in their LSPs, that 
they might choose R2 as the tree for multicast traffic they are sourcing 
into the campus.

R keeps, for tree R2, and for each adjacency, {set of RBridges that are 
plausible ingress RBridges for packets received on that adjacency}.

The set union of all of those will be S.

I hope that's correct, and that I've explained it clearly....

Radia



Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l27IwIiQ021029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Wed, 7 Mar 2007 10:58:18 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.224.130]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l27IwDc1011234 for <[e-mail]>; Wed, 7 Mar 2007 18:58:17 GMT
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l27IwDj7607098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 10:58:13 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2007 10:58:13 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 1.5.0.5 (X11/20060911)
MIME-Version: 1.0
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: [rbridge] Draft meeting agenda
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 18:58:24 -0000
Status: RO
Content-Length: 91

The draft agenda is at
http://www3.ietf.org/proceedings/07mar/agenda/trill.txt

    Erik



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l271ZMVT009236 for <[e-mail]>; Tue, 6 Mar 2007 17:35:22 -0800 (PST)
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, 06 Mar 2007 17:35:18 -0800 (PST)
Received: from [129.145.154.55] 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, 06 Mar 2007 17:35:18 -0800 (PST)
Date: Tue, 06 Mar 2007 17:35:17 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Phanidhar Koganti <[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 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060629
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] RBridge Ingress Address
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 01:35:53 -0000
Status: RO
Content-Length: 5122

There were various arguments about that as well. Personally, I think 
it's reasonable either way,
and actually there might be a reason for some endnodes to be learned one 
way and others another.
For instance, for access points in which endnodes enroll, it is likely 
better to send around announcements
in IS-IS.

Some of the arguments, again, off the top of my head, for why it's good 
to announce at least some of the endnodes

a) sometimes it is clear when an endnode is no longer there (for 
instance, the access point finds out) in
which case it's advantageous to tell everyone

b) for IP nodes, it is possible for the RBridge to ping its attached 
endnodes to make sure they really are there.
Perhaps only in response to seeing some other RBridge announce an 
attached endnode.

c) in general only the egress RBridge will find out about S. If lots of 
people talk to S, then that traffic will
be flooded, unless S's RBridge announces where S is.

d) there might be a node that only occasionally talks and lots of nodes 
send it data, in which case traffic
to it will often be flooded.

e) I think some implementors were telling me that they didn't want to 
have to learn from decapsulated
traffic.

f) we probably do want to announce (layer 3, layer 2) pairs based on 
ARP/ND replies, so as to not require
flooding ARP/ND queries. If most nodes are IP nodes, then that would 
mean most (if not all) would be
advertised anyway.

One reason I was happy the WG wanted to put in ingress RBridge as well 
as egress RBridge was
because of the possibility of implicitly learning some of the endnodes.


Radia



Phanidhar Koganti wrote On 03/06/07 17:13,:

>Radia,
>
>Thanks for the response.
>
>In you point c) if can learn end node addresses from the data-path
>then why are we not doing it? Wouldn't it be a more scalable solution
>for the control plane (ISIS). 
>
>Thanks
>Phanidhar Koganti
>Brocade
>408 333 5455
>
>-----Original Message-----
>From: Radia Perlman [mailto:[e-mail]] 
>Sent: Tuesday, March 06, 2007 1:50 PM
>To: Phanidhar Koganti
>Cc: [e-mail]
>Subject: Re: [rbridge] RBridge Ingress Address
>
>You've really kind of answered your own question. Originally the shim 
>header only
>had a single RBridge nickname. For unicast it was "egress". For 
>multicast it was
>"ingress". Everything is engineering tradeoffs.  There's seldom a "right
>
>answer",
>but often two perfectly reasonable choices, and we don't want the WG 
>agonizing forever,
>se we seem to have chosen having both ingress and egress.
>
>The cost of having both ingress and
>egress is an extra 4 bytes.
>
>The advantages of having both are:
>a) some IEEE things (like BCN -- congestion notification) require 
>knowing where something
>came from, so could use "ingress RBridge"
>b) tunneling usually has both source and destination, so it's "more
>natural"
>c) we might at some point choose, as you suggested, to learn some or all
>
>of the endnodes
>based on decapsulated traffic (so only the egress RBridge would learn 
>the mapping between
>the source MAC and the ingress RBridge)
>d) for multicast, it allows multipathing by having the ingress RBridge 
>R1 choose a different
>tree (not the one rooted at R1), for distributing the multicast frame
>e) for multicast, it allows configuring things to compute fewer trees, 
>because instead of
>requiring all RBridges to compute a tree rooted at every ingress, 
>RBridges can request
>that they not be tree Roots. (except the RBridges with lowest IS-IS ID 
>-- that one has to be the
>root of a tree so that there is always at least one tree all the 
>RBridges compute).
>
>There might have been other reasons, but these are the ones I could 
>remember off the top of my head.
>
>Radia
>
>
>
>Phanidhar Koganti wrote On 03/06/07 12:45,:
>
>  
>
>>Hi,
>>
>>Went through the below draft briefly and had a basic question. Bear
>>    
>>
>with
>  
>
>>me if this has already been answered on the list
>>
>>http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0
>>    
>>
>3
>  
>
>>.txt
>>
>>For Known DA
>>
>> Trill.EgressRBridgesAddress = egress RBRIDGE; 
>> Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>>
>>For Unknown DA / Multicast Traffic
>>
>> Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution
>>Tree
>> Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>>
>>In both the above cases the unicast forwarding and the distribution
>>    
>>
>tree
>  
>
>>to use is conveyed using "Trill.EgressRBridgesAddress". 
>>
>>My question is where does the "Trill.IngressRBridgesAddress" play a
>>role?
>>
>>
>>My second question is
>>
>>Learning of L2 end-node addresses are done using ISIS TLVs, why can't
>>    
>>
>we
>  
>
>>learn from the data-path similar to 802.1D/Q? 
>>(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address)
>>
>>In such a case there would be use for the
>>    
>>
>"Trill.IngressRBridgesAddress"
>  
>
>>Thanks
>>Phanidhar Koganti
>>Brocade
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://mailman.postel.org/mailman/listinfo/rbridge
>> 
>>
>>    
>>


Received: from mx10.brocade.com (mail.brocade.com [66.243.153.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l271DWiI004174 for <[e-mail]>; Tue, 6 Mar 2007 17:13:32 -0800 (PST)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 06 Mar 2007 17:13:32 -0800
X-IronPort-AV: i="4.14,255,1170662400"; d="scan'208"; a="5959785:sNHT21314027"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with SMTP id 0F63E238394; Tue,  6 Mar 2007 17:13:26 -0800 (PST)
Received: from hq-exch-2.corp.brocade.com ([10.3.8.22]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Mar 2007 17:13:31 -0800
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: Tue, 6 Mar 2007 17:13:31 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] RBridge Ingress Address
Thread-Index: AcdgOXICMgN3ApUISqWbcX12A6tYrQAHA5gA
From: "Phanidhar Koganti" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 07 Mar 2007 01:13:31.0815 (UTC) FILETIME=[D22F4B70:01C76055]
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 l271DWiI004174
Cc: [e-mail]
Subject: Re: [rbridge] RBridge Ingress Address
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 01:14:30 -0000
Status: RO
Content-Length: 3262

Radia,

Thanks for the response.

In you point c) if can learn end node addresses from the data-path
then why are we not doing it? Wouldn't it be a more scalable solution
for the control plane (ISIS). 

Thanks
Phanidhar Koganti
Brocade
408 333 5455

-----Original Message-----
From: Radia Perlman [mailto:[e-mail]] 
Sent: Tuesday, March 06, 2007 1:50 PM
To: Phanidhar Koganti
Cc: [e-mail]
Subject: Re: [rbridge] RBridge Ingress Address

You've really kind of answered your own question. Originally the shim 
header only
had a single RBridge nickname. For unicast it was "egress". For 
multicast it was
"ingress". Everything is engineering tradeoffs.  There's seldom a "right

answer",
but often two perfectly reasonable choices, and we don't want the WG 
agonizing forever,
se we seem to have chosen having both ingress and egress.

The cost of having both ingress and
egress is an extra 4 bytes.

The advantages of having both are:
a) some IEEE things (like BCN -- congestion notification) require 
knowing where something
came from, so could use "ingress RBridge"
b) tunneling usually has both source and destination, so it's "more
natural"
c) we might at some point choose, as you suggested, to learn some or all

of the endnodes
based on decapsulated traffic (so only the egress RBridge would learn 
the mapping between
the source MAC and the ingress RBridge)
d) for multicast, it allows multipathing by having the ingress RBridge 
R1 choose a different
tree (not the one rooted at R1), for distributing the multicast frame
e) for multicast, it allows configuring things to compute fewer trees, 
because instead of
requiring all RBridges to compute a tree rooted at every ingress, 
RBridges can request
that they not be tree Roots. (except the RBridges with lowest IS-IS ID 
-- that one has to be the
root of a tree so that there is always at least one tree all the 
RBridges compute).

There might have been other reasons, but these are the ones I could 
remember off the top of my head.

Radia



Phanidhar Koganti wrote On 03/06/07 12:45,:

>Hi,
>
>Went through the below draft briefly and had a basic question. Bear
with
>me if this has already been answered on the list
>
>http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-0
3
>.txt
>
>For Known DA
>
>  Trill.EgressRBridgesAddress = egress RBRIDGE; 
>  Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>
>For Unknown DA / Multicast Traffic
>
>  Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution
>Tree
>  Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>
>In both the above cases the unicast forwarding and the distribution
tree
>to use is conveyed using "Trill.EgressRBridgesAddress". 
>
>My question is where does the "Trill.IngressRBridgesAddress" play a
>role?
>
>
>My second question is
>
>Learning of L2 end-node addresses are done using ISIS TLVs, why can't
we
>learn from the data-path similar to 802.1D/Q? 
>(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address)
>
>In such a case there would be use for the
"Trill.IngressRBridgesAddress"
>
>Thanks
>Phanidhar Koganti
>Brocade
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l26LoTY0015803 for <[e-mail]>; Tue, 6 Mar 2007 13:50:29 -0800 (PST)
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, 06 Mar 2007 13:50:17 -0800 (PST)
Received: from [129.145.154.55] 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, 06 Mar 2007 13:50:17 -0800 (PST)
Date: Tue, 06 Mar 2007 13:50:11 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Phanidhar Koganti <[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]>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20060629
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] RBridge Ingress Address
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 21:51:00 -0000
Status: RO
Content-Length: 2800

You've really kind of answered your own question. Originally the shim 
header only
had a single RBridge nickname. For unicast it was "egress". For 
multicast it was
"ingress". Everything is engineering tradeoffs.  There's seldom a "right 
answer",
but often two perfectly reasonable choices, and we don't want the WG 
agonizing forever,
se we seem to have chosen having both ingress and egress.

The cost of having both ingress and
egress is an extra 4 bytes.

The advantages of having both are:
a) some IEEE things (like BCN -- congestion notification) require 
knowing where something
came from, so could use "ingress RBridge"
b) tunneling usually has both source and destination, so it's "more natural"
c) we might at some point choose, as you suggested, to learn some or all 
of the endnodes
based on decapsulated traffic (so only the egress RBridge would learn 
the mapping between
the source MAC and the ingress RBridge)
d) for multicast, it allows multipathing by having the ingress RBridge 
R1 choose a different
tree (not the one rooted at R1), for distributing the multicast frame
e) for multicast, it allows configuring things to compute fewer trees, 
because instead of
requiring all RBridges to compute a tree rooted at every ingress, 
RBridges can request
that they not be tree Roots. (except the RBridges with lowest IS-IS ID 
-- that one has to be the
root of a tree so that there is always at least one tree all the 
RBridges compute).

There might have been other reasons, but these are the ones I could 
remember off the top of my head.

Radia



Phanidhar Koganti wrote On 03/06/07 12:45,:

>Hi,
>
>Went through the below draft briefly and had a basic question. Bear with
>me if this has already been answered on the list
>
>http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
>.txt
>
>For Known DA
>
>  Trill.EgressRBridgesAddress = egress RBRIDGE; 
>  Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>
>For Unknown DA / Multicast Traffic
>
>  Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution
>Tree
>  Trill.IngressRBridgesAddress = ingress RBRIDGE; 
>
>In both the above cases the unicast forwarding and the distribution tree
>to use is conveyed using "Trill.EgressRBridgesAddress". 
>
>My question is where does the "Trill.IngressRBridgesAddress" play a
>role?
>
>
>My second question is
>
>Learning of L2 end-node addresses are done using ISIS TLVs, why can't we
>learn from the data-path similar to 802.1D/Q? 
>(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address)
>
>In such a case there would be use for the "Trill.IngressRBridgesAddress"
>
>Thanks
>Phanidhar Koganti
>Brocade
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>


Received: from mx20.brocade.com (mx20.brocade.com [66.243.153.19]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l26KjAfJ028747 for <[e-mail]>; Tue, 6 Mar 2007 12:45:10 -0800 (PST)
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 06 Mar 2007 12:45:10 -0800
X-IronPort-AV: i="4.14,255,1170662400"; d="scan'208"; a="7267116:sNHT17235246"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with SMTP id B2603238398 for <[e-mail]>; Tue,  6 Mar 2007 12:45:04 -0800 (PST)
Received: from hq-exch-2.corp.brocade.com ([10.3.8.22]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Mar 2007 12:45:10 -0800
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: Tue, 6 Mar 2007 12:45:09 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RBridge Ingress Address
Thread-Index: Acc6g4j0kMFoZDvXTQOgWkSr53zkxglq85Qw
From: "Phanidhar Koganti" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 06 Mar 2007 20:45:10.0291 (UTC) FILETIME=[54EDB630:01C76030]
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 l26KjAfJ028747
Subject: [rbridge] RBridge Ingress Address
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 20:45:44 -0000
Status: RO
Content-Length: 1003

Hi,

Went through the below draft briefly and had a basic question. Bear with
me if this has already been answered on the list

http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt

For Known DA

  Trill.EgressRBridgesAddress = egress RBRIDGE; 
  Trill.IngressRBridgesAddress = ingress RBRIDGE; 

For Unknown DA / Multicast Traffic

  Trill.EgressRBridgesAddress = ingress RBRIDGE // Default Distribution
Tree
  Trill.IngressRBridgesAddress = ingress RBRIDGE; 

In both the above cases the unicast forwarding and the distribution tree
to use is conveyed using "Trill.EgressRBridgesAddress". 

My question is where does the "Trill.IngressRBridgesAddress" play a
role?


My second question is

Learning of L2 end-node addresses are done using ISIS TLVs, why can't we
learn from the data-path similar to 802.1D/Q? 
(Trill.IngressRBridgeAddress <-> Inner SRC MAC Address)

In such a case there would be use for the "Trill.IngressRBridgesAddress"

Thanks
Phanidhar Koganti
Brocade



Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l25No6LW018108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 5 Mar 2007 15:50:06 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B2248177E4; Mon,  5 Mar 2007 23:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOMwM-0000yJ-EL; Mon, 05 Mar 2007 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 05 Mar 2007 18:50:02 -0500
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-03.txt
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://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2007 23:50:31 -0000
Status: RO
Content-Length: 3123

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: RBridges: Base Protocol Specification
	Author(s)	: R. Perlman, et al.
	Filename	: draft-ietf-trill-rbridge-protocol-03.txt
	Pages		: 36
	Date		: 2007-3-5
	
RBridges allow for optimal pair-wise forwarding with zero 
   configuration, safe forwarding even during periods of temporary 
   loops, and the ability to cut down on ARP/ND and IP multicast 
   traffic. They achieve these goals by replacing the Spanning Tree 
   protocol with IS-IS.  

   The design also supports VLANs, and allows forwarding tables to be 
   based on RBridge destinations (rather than endnode destinations), 
   which allows internal forwarding tables to be substantially smaller 
   than in conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-protocol-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-rbridge-protocol-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart--