Subject: [rbridge] TRILL Header Format

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 30 Apr 2007 09:06:27 -0700

The purpose of the following message is to converge on the final
structure of the TRILL header.

The format proposed in:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-03
.txt
has been stable for a while. This message only describes the
differences.

At the last IETF Donald proposed to support a single extension header
containing multiple extensions.

After some discussion two solutions seem possible. Please express your
preference by replying to this email.

-- Silvano

Solution 1
==========

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      | V |M|RSD|EH-length| Hop Count |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Ingress RBridge Nickname     |  Egress RBridge Nickname      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:
- RSD (2 bits) is reserved
- EH-Length (5 bits) is the extension header length, expressed in units
of in 4 bytes words.

If EH-length is zero there is no extension header;
else, the extensions follow immediately after the Egress Rbridge
Nickname field, and the total length of all the extensions is as
indicated by the EH-length field, expressed in units of 4-byte words.

This solution allows 128 bytes of extensions.

Solution 2
==========

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      |  V  |M|S| RSD |   Hop Count   |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    RSD        |   EH-length   |  Inner IEEE 802.1Q/S tag      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Ingress RBridge Nickname     |  Egress RBridge Nickname      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and Priority)
into the TRILL header. The Inner 1Q/1S tag is no longer present in the
inner frame.

This simplifies the parsing for the core RBridges. On the other hand the
Ingress/Egress Rbridges need to do slightly more work. 

This has more reserved space. Since the inner 1Q/1S tag is removed from
the frame (4 bytes), it uses the same overall space of solution 1.

The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).

The EH-length is 8 bits, with a granularity of 2 bytes it allows up to
512 bytes of extensions.

The Hop Count can grow to 8 bits.

A word of caution
=================

Extensions are very appealing, but their practical deployment has been
very limited. Often Router and Switches are not able to process in HW
frames with extensions and they send them to SW.

Example with Solution 1
======================= 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               Outer Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Outer Destination MAC Address | Outer Source MAC Address      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Outer Source MAC Address                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = TRILL             | V |M|RSD|EH-length| Hop Count |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Ingress RBridge Nickname     |  Egress RBridge Nickname      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Inner Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Inner Destination MAC Address | InnerSource MAC Address       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    Inner Source MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                 Original Ethernet Payload                     | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           New FCS                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
             TRILL Encapsulation over Ethernet with Solution 1

Example with Solution 2
=======================

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |               Outer Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Outer Destination MAC Address | Outer Source MAC Address      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   Outer Source MAC Address                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Ethertype = TRILL             |  V  |M|S| RSD |   Hop Count   |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    RSD        |   EH-length   |  UP |C|    Inner VID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Ingress RBridge Nickname     |  Egress RBridge Nickname      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Inner Destination MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Inner Destination MAC Address | InnerSource MAC Address       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    Inner Source MAC Address                   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                 Original Ethernet Payload                     | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           New FCS                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
               TRILL Encapsulation over Ethernet with Solution 2

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 30 Apr 2007 12:18:59 -0700

Two small corrections. In the second format, we really don't need any 
indication of .1Q/.1S. The tag that is to be added at the egress port 
maybe different from the tag that we received at the ingress port and is 
part of the port logic. For example, the frame may have come in with a 
.1Q tag and may go out a port that accepts no tagging at all.

Given that we don't need to carry any indication of .1Q/.1S in the TRILL 
header, I suggest that we also define the field "Inner 802.1Q/S tag" to 
be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and call 
it DE (drop eligibility). This way if RBridges along the way can choose 
to set the DE bit in the inner header, instead of treating it as an 
opaque field.

Dinesh
Silvano Gai wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> 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

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 30 Apr 2007 12:21:06 -0700

I agree with these two changes

-- Silvano

> -----Original Message-----
> From: Dinesh G Dutt [mailto:ddutt at cisco.com]
> Sent: Monday, April 30, 2007 12:19 PM
> To: Silvano Gai
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] TRILL Header Format
> 
> >       |
|
> >       |
|
> >       |                           New FCS
|
> >       |
|
> >       |
|
> >       |                           New FCS
|
> >                TRILL Encapsulation over Ethernet with Solution 2

Content-class: urn:content-classes:message
Date: Mon, 30 Apr 2007 12:21:06 -0700
From: "Silvano Gai" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header Format
Status: RO
Content-Length: 7889

I agree with these two changes

-- Silvano

> -----Original Message-----
> From: Dinesh G Dutt [mailto:[email-masked]]
> Sent: Monday, April 30, 2007 12:19 PM
> To: Silvano Gai
> Cc: [email-masked]
> Subject: Re: [rbridge] TRILL Header Format
> 
> >       |
|
> >       |
|
> >       |                           New FCS
|
> >       |
|
> >       |
|
> >       |                           New FCS
|
> > [email-masked]

Date: Mon, 30 Apr 2007 12:18:59 -0700
From: Dinesh G Dutt <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Header Format
Status: RO
Content-Length: 8195

Dinesh
Silvano Gai wrote:
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 30 Apr 2007 09:06:27 -0700
From: "Silvano Gai" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Header Format
Status: RO
Content-Length: 6878

The format proposed in:

-- Silvano

Solution 1
==========

Where:

Solution 2
==========

A word of caution
=================

Example with Solution 1
======================= 

Example with Solution 2
=======================

Content-class: urn:content-classes:message
Date: Thu, 26 Apr 2007 12:41:26 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 2074

[email-masked] wrote:
> Hi Eric,
> 
> There are IESG members who will be intent on assuring that
> Rbridges are manageable and have reasonable provisions for
> security and I tend to agree with them. See below at @@@.
> 

That's valid, and we can provide security guidance even before
deployment (although Eric raised a valid point on the exact
wording of that advice).

My main concern is that we do allow multiple methods of
achieving the goal of only accepting RBridge encapsulated
traffic on ports where it is reasonable for a known RBridge
to have sent them.

Specifically, as part of its overall RBridge/Bridge functionality,
an RBridge MAY already have anti-spoofing protections that guard
against ANY frame arriving on a port that is inconsistent with
the source address of the frame. Further, I believe it is a safe
statement that any network middlebox is always free to choose
not to associate with other network elements when the local
configuration indicates that it would be unsafe or against
administrative policy to do so.

Therefore, without needing to add something to the protocol
specifications, I believe an RBridge could already be configured
with instructions that amount to "join NO RBRidge-collective
that claims to have RBridges on port X", or "port X support
is limited to at most N MAC addresses, none of which may be
an RBridge", or even "only the following MAC addresses are
supported on port x".

That implies that a totally safe method of controlling where
RBridges can exist could be implemented with all of the
*additional* security checking being done during RBridge
discovery. *Existing* per-frame anti-spoofing techniques
would not need to be enhanced, no matter how slightly.
Shifting from MUST to SHOULD does't really solve the
problem. I would argue that an RBridge SHOULD NOT perform
per-frame security checks that are completely redundant.
If the per-frame checks are generalize anti-spoofing checks
then there is an equivalent security measure in place then
there is no point in also doing redundant per-frame checks.

Content-class: urn:content-classes:message
Date: Thu, 26 Apr 2007 13:39:28 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 10499

Donald,

	Specific excerpts from your response below:

@@@ I don't buy that we have to deploy Rbridges and have experience
before we specify some basic security provisions.

	Good, because I ain't sellin' it.

	For control plane activities, we have 4 things to consider
	(and address) in the interactions between RBridges:

	1.  IS-IS (as extended) interactions - presumably we will not
	    define new security mechanisms (in TRILL) that apply more
	    generally to IS-IS.
	2.  Bridge control interactions - we WILL NOT define security
	    mechanisms that apply to this general area, whatever the
	    IESG may, or may not, feel about existing L2 exposures.
	3.  Merged bridging and IS-IS interactions that introduce new
	    vulnerabilities not encountered previously.
	4.  Other vulnerabilities introduced in RBridge interactions
	    not specifically related to either bridging or IS-IS.

	It cannot be over-emphasized that it is only in interactions
	between RBridges that any of these things become relevant in
	defining RBridge control protocol specifications, including
	those relating to security.

	Items 3 and 4 above are the areas where we will need to say
	something directly about security - both what the risks are 
	and how we feel they might be addressed.  But what we say is 
	likely to be largely based on a SWAG - except where we may 
	have experience in interactions between multiple RBridges, 
	built by multiple RBridge vendors.  To think otherwise, is - 
	IMO - overly optimistic.

	Hence, what we say should be said with this in mind; i.e. -
	we need to state what we think the issues will be, but also
	acknowledge that the list is likely to be incomplete. AND we
	need to propose mechanisms that address at least those parts
	of any specific security solution that are related to how a
	set of RBridges need to interact with each other in dealing
	with the issues we know about.  

	There is nothing in any of this that implies we should not
	define "basic security provisions."

@@@ I don't think the Architecture draft needs many details. 
    Nor do all the details necessarily have to be in a successor
    to the current protocol specification as there could be a 
    separate document on management.

	Agree.

@@@ I think that if we want to get it approved for publication,
    the Architecture document will have to say what protocol we
    expect to be used to manage RBridges, e.g., SNMP, and may 
    have to say how we expect them to be configured, e.g., via 
    a TRILL MIB.

	Possibly, but I believe it is safe to say that this is a 
	new requirement of architecture documents, assuming it is
	a requirement even now.  I don't know - off hand - of a 
	single architecture document in the RFC database right 
	now that addresses this aspect of a device or solution 
	architecture.

	I looked at a number of them, just to make sure I hadn't
	missed out on this aspect in existing architecture RFCs,
	and found exactly one single example of an architecture
	RFC that says anything specific about how a protocol is
	going to be managed.

	The ones I looked at included at least a dozen of the 
	most recent RFCs on architecture.  The exception was RFC
	4655 - which has an experimental "manageability section" 
	and includes an operational model explicitly based on use
	of a network management system.

	That RFC does not mention SNMP, but it does state that 
	there must be a (one or more) management MIB(s) for 
	managing the system that architecture defines.

	The inclusion of manageability considerations is based on 
	an "experiment" that is currently in Internet Draft form,
	and that (currently) addresses PCE documents only.

	I believe that there is no requirement for us to include
	such a section (at present) and that doing so requires a
	consensus from the working group (to include that same
	section in all working group documents).

	Hence, I am inclined to believe that any IESG member who
	proposes to make this a major issue is simply being a tad
	on the capricious side...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 11:15 PM
> To: Eric Gray (LO/EUS); [email-masked]
> Subject: RE: [rbridge] Rbridge port security
> Importance: High
> 
> Hi Eric,
> 
> There are IESG members who will be intent on assuring that 
> Rbridges are
> manageable and have reasonable provisions for security and I tend to
> agree with them. See below at @@@.
> 
> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 11:33 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] Rbridge port security
> 
> Donald,
> 
> 	I can't say that I understand why.  Is there nothing along
> the same lines in any of the IS-IS specifications?  If there is 
> not, why are we expected to make statements about IS-IS security
> that are likely to apply to a more general problem?  If there is,
> cannot we simply refer to that?
> 
> @@@ IS-IS might be the biggest component an RBridge but it is 
> not all of
> it. The concern will be with the management and security of Rbridges,
> not just of their IS-IS component.
> 
> @@@ Looks like the IS-IS MIB is in RFC 4444. It's probably pretty
> thorough. At least the RFC is over 100 pages :-) If it covers this
> point, of course we could just reference it. Looks like 802.1 bridge
> MIBs are in RFC 4188 and RFC 4363. If someone is familiar with these
> MIBs, or is willing to read them and comment on their applicability to
> TRILL, I think that would be very useful for this working group.
> 
> 	While I tend to agree that there should be a general way to
> manage devices to accomplish identical results - rather than ask
> each vendor to come up with their own and all users/operators to
> deal with the associated complexity.  But, as Silvano indicated,
> this may not be done the same way for each vendor and - more
> importantly - we are not in an experiential position to guess (at
> this point) what way is the best way to handle this particular
> set of security issues...
> 
> @@@ I don't buy that we have to deploy Rbridges and have experience
> before we specify some basic security provisions.
> 
> @@@ I think that if we want to get it approved for publication, the
> Architecture document will have to say what protocol we expect to be
> used to manage RBridges, e.g., SNMP, and may have to say how we expect
> them to be configured, e.g., via a TRILL MIB. We already have at least
> one new per-Rbridge configuration variable, called RequestTree in
> protocol draft -03.
> 
> @@@ I don't think the Architecture draft needs many details. 
> Nor do all
> the details necessarily have to be in a successor to the current
> protocol specification as there could be a separate document on
> management.
> 
> @@@ Thanks,
> @@@ Donald
> 
> Thanks!
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:[email-masked]] 
> > Sent: Wednesday, April 25, 2007 11:15 AM
> > To: Eric Gray (LO/EUS); [email-masked]
> > Subject: RE: [rbridge] Rbridge port security
> > Importance: High
> > 
> > Eric,
> > 
> > Sure, we don't want to get too bogged down in details. On the other
> > hand, while some of the IESG comments on the routing requirements
> > document seem to be based on a misunderstanding of the 
> purpose of that
> > document, I still feel that security and management will both be a
> > primary concerns for the architecture and protocol documents.
> > 
> > Our charter requirement of "zero or minimal" configuration is 
> > helpful in
> > motivating a default configuration for Rbridges which has security
> > weaknesses that parallel those of unmanaged bridges. However, 
> > I think we
> > are going to have to say something about management and 
> provide for a
> > standard way to configure Rbridges to provide at least the suggested
> > ability to not run IS-IS on selected ports.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Sent: Wednesday, April 25, 2007 10:09 AM
> > To: Eastlake III Donald-LDE008; [email-masked]
> > Subject: RE: [rbridge] Rbridge port security
> > 
> > Donald,
> > 
> > 	In the past, it has not been necessary to explicitly state
> > this sort of thing, except in some general way.  Otherwise, it is
> > easy to get snarled up in phraseology around things like "RBridge
> > enabled ports" and so on.
> > 
> > 	As an historical example (I am sure there are others), the
> > concept of global label spaces in MPLS is intended to be similarly
> > constrained.
> > 
> > 	To a certain extent, we don't want to get wrapped up around 
> > an axle in trying to tell people how to build good implementations
> > - our focus should be on interoperable implementations, right?
> > 
> > Thanks!
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Eastlake III 
> > > Donald-LDE008
> > > Sent: Friday, April 20, 2007 3:53 PM
> > > To: [email-masked]
> > > Subject: [rbridge] Rbridge port security
> > > 
> > > Hi,
> > > 
> > > I'm continuing to work through the comments on our first 
> > > document to hit
> > > the IESG, the routing requirements document.
> > > 
> > > Based on these, I would say that we have to add a per port 
> > > configuration
> > > variable for Rbridges that indicates there are no Rbridges 
> > > connected via
> > > that port. The effect would be that any TRILL frames 
> > arriving on that
> > > port would be assumed to be forged and would be discarded. 
> > This would
> > > include frames claiming to be core or per-VLAN IS-IS messages 
> > > as well as
> > > messages that claim to be TRILL encapsulated frames. Of 
> > > course, the zero
> > > configuration default would be to accept TRILL frames on 
> all ports.
> > > 
> > > Unless there is some objection, this will be added to the protocol
> > > specification and should probably be mentioned in the architecture
> > > document.
> > > 
> > > Thanks,
> > > Donald
> > > 
> > > [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 26 Apr 2007 13:26:12 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2619

Anoop,

	There are (at least) two possible interpretations of what 
is meant by "multi-pathing."

	One is the sort of multipathing that is roughly analogous
to either link-bundling (at L2) or ECMP (usually for L3 routing).

	The other is the sort that has to do with the more general
form of "load-sharing" - i.e. - simply trying to ensure that all
possible links are being used, roughly at some proportional ratio
relative to their capacities.  This form of multi-pathing is not
dependent on multiple-path use for essentially the same traffic
(i.e. - as defined by edge-to-edge unidirectional forwarding).

	I believe that many people (especially those who are not 
completely up to speed on - for example - MSTP) are thinking of
the second form of "multi-pathing" when they refer to this term.
When using MSTP, there are no unused links and load-sharing is
a natural consequence of the assignment of VIDs on the basis of
separate spanning tree instances.

	As you may know, there are problems that must be addressed 
in using the first form of multi-pathing scheme if we need to be
able to maintain forwarding symmetry on an end-point pair basis.  
These difficulties are reduced by using a hierarchical (tunneled) 
overlay with RBridges, but they are not eliminated...

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Tuesday, April 24, 2007 9:14 PM
> To: J. R. Rivers; Caitlin Bestler; Silvano Gai; Eric Gray 
> (LO/EUS); Radia Perlman; [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of J. R. Rivers
> > Sent: Tuesday, April 03, 2007 3:47 PM
> > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> > Perlman; [email-masked]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > I would have thought that RBridges are "better bridges" 
> > because they allow multi-pathing at layer 2 creating 
> > significantly more available bandwidth and with a deployment 
> > cost/complexity relatively close to
> > 802.1 bridges.
> 
> Is TRILL going to solve the multipathing problem?
> 
> From
> http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-r
> eqs-02.txt
>    However, support for multi-pathing is potentially 
> problematic and is 
>    assumed - in this document - to be a non-goal.  Multi-path 
> forwarding
>    has the potential to confound the bridge learning process.
> 
> Anoop
> 

Content-class: urn:content-classes:message
Date: Thu, 26 Apr 2007 13:18:20 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 974

Radia,

	I started to reply to Anoop, but decided to hold of
because this is a complicated discussion and there are more
than enough of those going around.

	The issue is that not all of us mean the same thing
when we say "multi-pathing."  I guess I will fire of my 
response to Anoop after all...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 11:58 PM
> To: Anoop Ghanwani
> Cc: J. R. Rivers; Caitlin Bestler; Silvano Gai; Eric Gray 
> (LO/EUS); [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> Anoop Ghanwani wrote:
> > Is TRILL going to solve the multipathing problem?
> Multipathing comes "for free" because of using layer 3 routing 
> technology. Whatever
> capabilities IS-IS has for routing to a destination can be used for 
> routing to the
> egress RBridge.
> 
> So the answer is yes.
> 
> Radia
> 

Date: Wed, 25 Apr 2007 20:57:36 -0700
From: Radia Perlman <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 289

Anoop Ghanwani wrote:
> Is TRILL going to solve the multipathing problem?
Multipathing comes "for free" because of using layer 3 routing 
technology. Whatever
capabilities IS-IS has for routing to a destination can be used for 
routing to the
egress RBridge.

So the answer is yes.

Radia

Content-class: urn:content-classes:message
Date: Wed, 25 Apr 2007 23:14:48 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 5817

Hi Eric,

There are IESG members who will be intent on assuring that Rbridges are
manageable and have reasonable provisions for security and I tend to
agree with them. See below at @@@.

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 11:33 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Rbridge port security

Donald,

	I can't say that I understand why.  Is there nothing along
the same lines in any of the IS-IS specifications?  If there is 
not, why are we expected to make statements about IS-IS security
that are likely to apply to a more general problem?  If there is,
cannot we simply refer to that?

@@@ IS-IS might be the biggest component an RBridge but it is not all of
it. The concern will be with the management and security of Rbridges,
not just of their IS-IS component.

@@@ Looks like the IS-IS MIB is in RFC 4444. It's probably pretty
thorough. At least the RFC is over 100 pages :-) If it covers this
point, of course we could just reference it. Looks like 802.1 bridge
MIBs are in RFC 4188 and RFC 4363. If someone is familiar with these
MIBs, or is willing to read them and comment on their applicability to
TRILL, I think that would be very useful for this working group.

	While I tend to agree that there should be a general way to
manage devices to accomplish identical results - rather than ask
each vendor to come up with their own and all users/operators to
deal with the associated complexity.  But, as Silvano indicated,
this may not be done the same way for each vendor and - more
importantly - we are not in an experiential position to guess (at
this point) what way is the best way to handle this particular
set of security issues...

@@@ I don't buy that we have to deploy Rbridges and have experience
before we specify some basic security provisions.

@@@ I think that if we want to get it approved for publication, the
Architecture document will have to say what protocol we expect to be
used to manage RBridges, e.g., SNMP, and may have to say how we expect
them to be configured, e.g., via a TRILL MIB. We already have at least
one new per-Rbridge configuration variable, called RequestTree in
protocol draft -03.

@@@ I don't think the Architecture draft needs many details. Nor do all
the details necessarily have to be in a successor to the current
protocol specification as there could be a separate document on
management.

@@@ Thanks,
@@@ Donald

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 11:15 AM
> To: Eric Gray (LO/EUS); [email-masked]
> Subject: RE: [rbridge] Rbridge port security
> Importance: High
> 
> Eric,
> 
> Sure, we don't want to get too bogged down in details. On the other
> hand, while some of the IESG comments on the routing requirements
> document seem to be based on a misunderstanding of the purpose of that
> document, I still feel that security and management will both be a
> primary concerns for the architecture and protocol documents.
> 
> Our charter requirement of "zero or minimal" configuration is 
> helpful in
> motivating a default configuration for Rbridges which has security
> weaknesses that parallel those of unmanaged bridges. However, 
> I think we
> are going to have to say something about management and provide for a
> standard way to configure Rbridges to provide at least the suggested
> ability to not run IS-IS on selected ports.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 10:09 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] Rbridge port security
> 
> Donald,
> 
> 	In the past, it has not been necessary to explicitly state
> this sort of thing, except in some general way.  Otherwise, it is
> easy to get snarled up in phraseology around things like "RBridge
> enabled ports" and so on.
> 
> 	As an historical example (I am sure there are others), the
> concept of global label spaces in MPLS is intended to be similarly
> constrained.
> 
> 	To a certain extent, we don't want to get wrapped up around 
> an axle in trying to tell people how to build good implementations
> - our focus should be on interoperable implementations, right?
> 
> Thanks!
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Friday, April 20, 2007 3:53 PM
> > To: [email-masked]
> > Subject: [rbridge] Rbridge port security
> > 
> > Hi,
> > 
> > I'm continuing to work through the comments on our first 
> > document to hit
> > the IESG, the routing requirements document.
> > 
> > Based on these, I would say that we have to add a per port 
> > configuration
> > variable for Rbridges that indicates there are no Rbridges 
> > connected via
> > that port. The effect would be that any TRILL frames 
> arriving on that
> > port would be assumed to be forged and would be discarded. 
> This would
> > include frames claiming to be core or per-VLAN IS-IS messages 
> > as well as
> > messages that claim to be TRILL encapsulated frames. Of 
> > course, the zero
> > configuration default would be to accept TRILL frames on all ports.
> > 
> > Unless there is some objection, this will be added to the protocol
> > specification and should probably be mentioned in the architecture
> > document.
> > 
> > Thanks,
> > Donald
> > 
> > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 25 Apr 2007 10:32:43 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 4097

Donald,

	I can't say that I understand why.  Is there nothing along
the same lines in any of the IS-IS specifications?  If there is 
not, why are we expected to make statements about IS-IS security
that are likely to apply to a more general problem?  If there is,
cannot we simply refer to that?

	While I tend to agree that there should be a general way to
manage devices to accomplish identical results - rather than ask
each vendor to come up with their own and all users/operators to
deal with the associated complexity.  But, as Silvano indicated,
this may not be done the same way for each vendor and - more
importantly - we are not in an experiential position to guess (at
this point) what way is the best way to handle this particular
set of security issues...

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 11:15 AM
> To: Eric Gray (LO/EUS); [email-masked]
> Subject: RE: [rbridge] Rbridge port security
> Importance: High
> 
> Eric,
> 
> Sure, we don't want to get too bogged down in details. On the other
> hand, while some of the IESG comments on the routing requirements
> document seem to be based on a misunderstanding of the purpose of that
> document, I still feel that security and management will both be a
> primary concerns for the architecture and protocol documents.
> 
> Our charter requirement of "zero or minimal" configuration is 
> helpful in
> motivating a default configuration for Rbridges which has security
> weaknesses that parallel those of unmanaged bridges. However, 
> I think we
> are going to have to say something about management and provide for a
> standard way to configure Rbridges to provide at least the suggested
> ability to not run IS-IS on selected ports.
> 
> Donald
> 
> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 10:09 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: [rbridge] Rbridge port security
> 
> Donald,
> 
> 	In the past, it has not been necessary to explicitly state
> this sort of thing, except in some general way.  Otherwise, it is
> easy to get snarled up in phraseology around thinsg like "RBridge
> enabled ports" and so on.
> 
> 	As an historical example (I am sure there are others), the
> concept of global label spaces in MPLS is intended to be similarly
> constrained.
> 
> 	To a certain extent, we don't want to get wrapped up around 
> an axle in trying to tell people how to build good implementations
> - our focus should be on interoperable implementations, right?
> 
> Thanks!
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Friday, April 20, 2007 3:53 PM
> > To: [email-masked]
> > Subject: [rbridge] Rbridge port security
> > 
> > Hi,
> > 
> > I'm continuing to work through the comments on our first 
> > document to hit
> > the IESG, the routing requirements document.
> > 
> > Based on these, I would say that we have to add a per port 
> > configuration
> > variable for Rbridges that indicates there are no Rbridges 
> > connected via
> > that port. The effect would be that any TRILL frames 
> arriving on that
> > port would be assumed to be forged and would be discarded. 
> This would
> > include frames claiming to be core or per-VLAN IS-IS messages 
> > as well as
> > messages that claim to be TRILL encapsulated frames. Of 
> > course, the zero
> > configuration default would be to accept TRILL frames on all ports.
> > 
> > Unless there is some objection, this will be added to the protocol
> > specification and should probably be mentioned in the architecture
> > document.
> > 
> > Thanks,
> > Donald
> > 
> > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 25 Apr 2007 11:14:57 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 2832

Eric,

Sure, we don't want to get too bogged down in details. On the other
hand, while some of the IESG comments on the routing requirements
document seem to be based on a misunderstanding of the purpose of that
document, I still feel that security and management will both be a
primary concerns for the architecture and protocol documents.

Our charter requirement of "zero or minimal" configuration is helpful in
motivating a default configuration for Rbridges which has security
weaknesses that parallel those of unmanaged bridges. However, I think we
are going to have to say something about management and provide for a
standard way to configure Rbridges to provide at least the suggested
ability to not run IS-IS on selected ports.

Donald

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 10:09 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Rbridge port security

Donald,

	In the past, it has not been necessary to explicitly state
this sort of thing, except in some general way.  Otherwise, it is
easy to get snarled up in phraseology around thinsg like "RBridge
enabled ports" and so on.

	As an historical example (I am sure there are others), the
concept of global label spaces in MPLS is intended to be similarly
constrained.

	To a certain extent, we don't want to get wrapped up around 
an axle in trying to tell people how to build good implementations
- our focus should be on interoperable implementations, right?

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, April 20, 2007 3:53 PM
> To: [email-masked]
> Subject: [rbridge] Rbridge port security
> 
> Hi,
> 
> I'm continuing to work through the comments on our first 
> document to hit
> the IESG, the routing requirements document.
> 
> Based on these, I would say that we have to add a per port 
> configuration
> variable for Rbridges that indicates there are no Rbridges 
> connected via
> that port. The effect would be that any TRILL frames arriving on that
> port would be assumed to be forged and would be discarded. This would
> include frames claiming to be core or per-VLAN IS-IS messages 
> as well as
> messages that claim to be TRILL encapsulated frames. Of 
> course, the zero
> configuration default would be to accept TRILL frames on all ports.
> 
> Unless there is some objection, this will be added to the protocol
> specification and should probably be mentioned in the architecture
> document.
> 
> Thanks,
> Donald
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 25 Apr 2007 07:51:08 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 2671

I agree with Eric, I am not sure I want to specify a specific port
configuration variable for this particular case.

Products will implement this through a potentially more complex scheme
that may include trusted/non-trusted ports/VLANs, authentications, ACLs,
etc.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, April 25, 2007 7:09 AM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] Rbridge port security
> 
> Donald,
> 
> 	In the past, it has not been necessary to explicitly state
> this sort of thing, except in some general way.  Otherwise, it is
> easy to get snarled up in phraseology around thinsg like "RBridge
> enabled ports" and so on.
> 
> 	As an historical example (I am sure there are others), the
> concept of global label spaces in MPLS is intended to be similarly
> constrained.
> 
> 	To a certain extent, we don't want to get wrapped up around
> an axle in trying to tell people how to build good implementations
> - our focus should be on interoperable implementations, right?
> 
> Thanks!
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Eastlake III
> > Donald-LDE008
> > Sent: Friday, April 20, 2007 3:53 PM
> > To: [email-masked]
> > Subject: [rbridge] Rbridge port security
> >
> > Hi,
> >
> > I'm continuing to work through the comments on our first
> > document to hit
> > the IESG, the routing requirements document.
> >
> > Based on these, I would say that we have to add a per port
> > configuration
> > variable for Rbridges that indicates there are no Rbridges
> > connected via
> > that port. The effect would be that any TRILL frames arriving on
that
> > port would be assumed to be forged and would be discarded. This
would
> > include frames claiming to be core or per-VLAN IS-IS messages
> > as well as
> > messages that claim to be TRILL encapsulated frames. Of
> > course, the zero
> > configuration default would be to accept TRILL frames on all ports.
> >
> > Unless there is some objection, this will be added to the protocol
> > specification and should probably be mentioned in the architecture
> > document.
> >
> > Thanks,
> > Donald
> >
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 25 Apr 2007 09:09:19 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 1862

Donald,

	In the past, it has not been necessary to explicitly state
this sort of thing, except in some general way.  Otherwise, it is
easy to get snarled up in phraseology around thinsg like "RBridge
enabled ports" and so on.

	As an historical example (I am sure there are others), the
concept of global label spaces in MPLS is intended to be similarly
constrained.

	To a certain extent, we don't want to get wrapped up around 
an axle in trying to tell people how to build good implementations
- our focus should be on interoperable implementations, right?

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, April 20, 2007 3:53 PM
> To: [email-masked]
> Subject: [rbridge] Rbridge port security
> 
> Hi,
> 
> I'm continuing to work through the comments on our first 
> document to hit
> the IESG, the routing requirements document.
> 
> Based on these, I would say that we have to add a per port 
> configuration
> variable for Rbridges that indicates there are no Rbridges 
> connected via
> that port. The effect would be that any TRILL frames arriving on that
> port would be assumed to be forged and would be discarded. This would
> include frames claiming to be core or per-VLAN IS-IS messages 
> as well as
> messages that claim to be TRILL encapsulated frames. Of 
> course, the zero
> configuration default would be to accept TRILL frames on all ports.
> 
> Unless there is some objection, this will be added to the protocol
> specification and should probably be mentioned in the architecture
> document.
> 
> Thanks,
> Donald
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 25 Apr 2007 08:57:49 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 1109

Caitlin,

	We need to be careful at this point about what we claim
to know will work...  :-)

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> Sent: Monday, April 23, 2007 12:13 PM
> To: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] Rbridge port security
> 
> Eastlake III Donald-LDE008 wrote:
> 
> > 
> > @@@ I would have no problems with using "SHOULD" for the
> > default of running the core IS-IS and most of this, with an
> > example of an exception being a special purpose device where
> > you have additional knowledge.
> > 
> > @@@ Thanks,
> > @@@ Donald
> 
> I could even see a requirement that there MUST be a method
> that once enabled can ensure that no RBridge enapsulated
> will be accepted via RBridge-disabled ports, and that two
> mechanisms known to achieve this are...
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 24 Apr 2007 18:14:18 -0700
From: "Anoop Ghanwani" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 916

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of J. R. Rivers
> Sent: Tuesday, April 03, 2007 3:47 PM
> To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> I would have thought that RBridges are "better bridges" 
> because they allow multi-pathing at layer 2 creating 
> significantly more available bandwidth and with a deployment 
> cost/complexity relatively close to
> 802.1 bridges.

Is TRILL going to solve the multipathing problem?

From
http://www.ietf.org/internet-drafts/draft-ietf-trill-routing-reqs-02.txt
   However, support for multi-pathing is potentially problematic and is 
   assumed - in this document - to be a non-goal.  Multi-path forwarding
   has the potential to confound the bridge learning process.

Anoop

Content-class: urn:content-classes:message
Date: Mon, 23 Apr 2007 09:12:38 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 502

Eastlake III Donald-LDE008 wrote:

> 
> @@@ I would have no problems with using "SHOULD" for the
> default of running the core IS-IS and most of this, with an
> example of an exception being a special purpose device where
> you have additional knowledge.
> 
> @@@ Thanks,
> @@@ Donald

I could even see a requirement that there MUST be a method
that once enabled can ensure that no RBridge enapsulated
will be accepted via RBridge-disabled ports, and that two
mechanisms known to achieve this are...

Content-class: urn:content-classes:message
Date: Sat, 21 Apr 2007 16:49:08 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 5144

Hi Caitlin,

See below at @@@ 

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 4:22 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Rbridge port security

[email-masked] wrote:
> Hi,
> 
> I'm continuing to work through the comments on our first
> document to hit the IESG, the routing requirements document.
> 
> Based on these, I would say that we have to add a per port
> configuration variable for Rbridges that indicates there are
> no Rbridges connected via that port. The effect would be that
> any TRILL frames arriving on that port would be assumed to be
> forged and would be discarded. This would include frames
> claiming to be core or per-VLAN IS-IS messages as well as
> messages that claim to be TRILL encapsulated frames. Of
> course, the zero configuration default would be to accept TRILL
> frames on all ports. 

@@@ My message should have also said that IS-IS messages are not
emitted. (It does not need to say that TRILL encapsulated messages are
not emitted since an RBridge should never do that if it has not detected
any Rbridges out that port and it can't detect them if it doesn't
receive and emit IS-IS Hellos.) Probably the better way to say all this
is that it doesn't run the core IS-IS instance on that port.

> Unless there is some objection, this will be added to the
> protocol specification and should probably be mentioned in the
> architecture document. 
> 
> Thanks,
> Donald

Two questions:

Would the default be that a port was allowed to have
RBridge encapsulated traffic on it? Given the zero-
configuration intent I think that default needs to
be made explicit.

@@@ Sure. The default has to be such that Rbridges will provide their
intended service.

Secondly, does this really need to be a per-frame check
that is specific to RBridge traffic?

Wouldn't the following be sufficient?

	An implementation MAY have configuration constraints
	on the results of RBridge discovery. Possible examples
	could include "discovered topology MUST be a subset of
	the pre-configured topology", "all discovered RBridges
	MUST be no more than 2 hops from X", "at most N RBridges",
	etc.

		And it SHOULD/MUST include the ability to configure
		ports that do not lead to other RBridges.

	Each RBridge MAY/SHOULD drop frames allegedly from other 
	RBRidges where the ingress port is inconsistent with the
	discovered topology.

That would make the RBridge specific logic pertain only during
RBridge discovery, and then allow generic "acceptable ingress
port" logic to apply rather than an RBridge specific rule.

@@@ I assume by "ingress port" in the two paragraphs above you mean the
port on which the Rbridge receives the frame, not the TRILL ingress,
which is where a frame gets encapsulated. I would agree that it is also
reasonable to drop frames received on a port which the Rbridge believes
has no other Rbridges attached to it even if Rbridge discovery isn't
configured off for that port.

If a given bridge already has anti-spoofing features it wouldn't
make much sense to require additional RBridge specific checks.

@@@ Well, a bridge isn't an Rbridge and I wasn't proposing to make any
changes in bridges.

@@@ I believe that bridges sometimes have a per port "anti-spoofing"
feature which could be expressed as controlling whether or not *STP runs
on that port (i.e., whether it discards any received BPDUs and does not
emit any for that port). But such a feature would do nothing to protect
against forged TRILL messages. One way or another you have to either
expand the "anti-spoofing feature" configuration or add an additional
"anti-spoofing feature" which is Rbridge specific. Also, bridges don't
encapsulate or modify native frames so it really wouldn't make any sense
to say you want to block bridged frames but Rbridges do encapsulate
native frames so it is reasonable to block such "Rbridged" frames on
ports which are not supposed to have any Rbridges attached to them.

@@@ I think the best way to think of the feature I am talking about is
controlling whether or not the core instance of IS-IS runs on a port.
And to satisfy the eventual security and management considerations
review of our protocol draft, there will have to be some standard way to
configure this, presumably via SNMP and a standard MIB.

For an example, an RBridge built into a piece of equipment could
indeed know that its internal "ports" have no RBridges on them.
But it might know that because it knows the MAC address associated
with each of those ports. It can easily enforce that they are not
RBridges during discovery, and it can easily enforce that the only
traffic originating on those ports have the correct MAC address.
Given those checks, I see no need for such an implementation to
dynamically block RBridge encapsulated frames from originating
on the internal ports.

@@@ I would have no problems with using "SHOULD" for the default of
running the core IS-IS and most of this, with an example of an exception
being a special purpose device where you have additional knowledge.

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Fri, 20 Apr 2007 13:22:02 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Rbridge port security
Status: RO
Content-Length: 2727

[email-masked] wrote:
> Hi,
> 
> I'm continuing to work through the comments on our first
> document to hit the IESG, the routing requirements document.
> 
> Based on these, I would say that we have to add a per port
> configuration variable for Rbridges that indicates there are
> no Rbridges connected via that port. The effect would be that
> any TRILL frames arriving on that port would be assumed to be
> forged and would be discarded. This would include frames
> claiming to be core or per-VLAN IS-IS messages as well as
> messages that claim to be TRILL encapsulated frames. Of
> course, the zero configuration default would be to accept TRILL
> frames on all ports. 
> 
> Unless there is some objection, this will be added to the
> protocol specification and should probably be mentioned in the
> architecture document. 
> 
> Thanks,
> Donald
> 
> [email-masked]

Two questions:

Would the default be that a port was allowed to have
RBridge encapsulated traffic on it? Given the zero-
configuration intent I think that default needs to
be made explicit.

Secondly, does this really need to be a per-frame check
that is specific to RBridge traffic?

Wouldn't the following be sufficient?

	An implementation MAY have configuration constraints
	on the results of RBridge discovery. Possible examples
	could include "discovered topology MUST be a subset of
	the pre-configured topoloty", "all discovered RBridges
	MUST be no more than 2 hops from X", "at most N RBridges",
	etc.

		And it SHOULD/MUST include the ability to configure
		ports that do not lead to other RBridges.

	Each RBridge MAY/SHOULD drop frames allegedly from other 
	RBRidges where the ingress port is inconsistent with the
	discovered topology.

That would make the RBridge specific logic pertain only during
RBridge discovery, and then allow generic "acceptable ingress
port" logic to apply rather than an RBridge specific rule.

If a given bridge already has anti-spoofing features it wouldn't
make much sense to require additional RBridge specific checks.

For an example, an RBridge built into a piece of equipment could
indeed know that its internal "ports" have no RBridges on them.
But it might know that because it knows the MAC address associated
with each of those ports. It can easily enforce that they are not
RBridges during discovery, and it can easily enforce that the only
traffic originating on those ports have the correct MAC address.
Given those checks, I see no need for such an implementation to
dynamically block RBridge encapsulated frames from originating
on the internal ports.

Content-class: urn:content-classes:message
Date: Fri, 20 Apr 2007 15:53:12 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Rbridge port security
Status: RO
Content-Length: 786

Hi,

I'm continuing to work through the comments on our first document to hit
the IESG, the routing requirements document.

Based on these, I would say that we have to add a per port configuration
variable for Rbridges that indicates there are no Rbridges connected via
that port. The effect would be that any TRILL frames arriving on that
port would be assumed to be forged and would be discarded. This would
include frames claiming to be core or per-VLAN IS-IS messages as well as
messages that claim to be TRILL encapsulated frames. Of course, the zero
configuration default would be to accept TRILL frames on all ports.

Unless there is some objection, this will be added to the protocol
specification and should probably be mentioned in the architecture
document.

Thanks,
Donald

Date: Fri, 20 Apr 2007 12:03:16 -0700 (PDT)
From: Gary H <[email-masked]>
To: [email-masked]
Subject: [rbridge] Frame format for 802.1ah MAC-in-MAC?
Status: RO
Content-Length: 15847

--0-149186721-1177095796=:74056
Content-Type: text/plain; charset=ascii

Hello All:

    I am looking at 802.1ah draft 3.4 and I see that section 9.5 clearly defines the Service Instance Tag but I do not see anywhere in the spec that clearly defines the format of the Backbone VLAN Tag (aka Service VLAN Tag). I do see someone posted their interpretation of the frame format back in December (see below). Is this still what people expect to be the final frame format?

Below is my stab at putting into words what is described from the post in Decemeber. Please ignire the values I put in for MAC addresses.

Backbone VLAN Tag
Backbone Destination MAC (hex) = 12:34:56:00:00:01
Backbone Source MAC (hex) = 12:34:56:00:00:02
EtherType (hex) = 8100
Backbone VLAN Tag (hex) = 0101 (user defined)
EtherType (hex) = 88a8
Instance VLAN Tag
Priority (bits) = 000
Drop Eligible (bit) = 0
Res1 (bits) = 00
Res2 (bits) = 00
Service ID (bits) = 000000000000000000000000
Customer Tag
Customer Destination MAC (hex) = ab:cd:ef:00:00:11
Customer Source MAC (hex) = ab:cd:ef:00:00:12
Ethertype (hex) = 88b5
                         
        |      1        |       2       |       3       |       4       |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -2 |                               |                               |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +  2 |                Backbone Destination Address         [B-DA]    |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  6 |                Backbone Source Address              [B-SA]    |    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 |                               |   .1ad Ethertype    [B-TAG]   |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14 |  .1ad B-TAG TCI/VID           |   .1ah Ethertype    [   ]     |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+ 18 |               .1ah I-TAG TCI/SID                    [ - ]     |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+ 22 |           
     Customer Destination Address         [ A ]     |    +                               +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+ 26 |                               |                     [   ]     |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     [   ]     + 30 |                Customer Source Address              [   ]     |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[   ]-+-+-+ 34 |  Encap Ethertype              |                     [   ]    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                  .1ah I-TAG TCI    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    | P/DE  |R1 |R2 |                     I-SID                     |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Thanks,
Gary

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-149186721-1177095796=:74056
Content-Type: text/html; charset=ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>Hello All:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; I am looking at 802.1ah draft 3.4 and I see that section 9.5 clearly defines the Service Instance Tag but I do not see anywhere in the spec that clearly defines the format of the Backbone&nbsp;VLAN Tag (aka Service VLAN Tag). I do see someone posted their interpretation of the frame format back in December (see below). Is this still what people expect to be the final frame format?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Below is my stab at putting into words what is described from the post in Decemeber. Please ignire the values I put in for MAC addresses.</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone VLAN Tag<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone Destination MAC (hex) = 12:34:56:00:00:01<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone Source MAC (hex) = 12:34:56:00:00:02<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">EtherType (hex) = 8100<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Backbone VLAN Tag (hex) = 0101 (user defined)</SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">EtherType (hex) = 88a8<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Instance VLAN Tag<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Priority (bits) = 000<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Drop Eligible (bit) = 0<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Res1 (bits) = 00<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Res2 (bits) = 00<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Service ID (bits) = 000000000000000000000000<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Customer Tag<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Customer Destination MAC (hex) = ab:cd:ef:00:00:11<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Customer Source MAC (hex) = ab:cd:ef:00:00:12<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt 1in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Ethertype (hex) = 88b5<o:p></o:p></SPAN></P></DIV>
<DIV><FONT size=2><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
<DIV><PRE><o:p><FONT size=2><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN><o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>1<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>2<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>3<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>4<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp; </SPAN><o:p></o:p></PRE><PRE><SPAN style="mso-spacerun:
 yes">&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE> -2 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>+<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp; </SPAN>2 |<SPAN
 style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Backbone Destination Address<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[B-DA]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp; </SPAN>6 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Backbone Source Address<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[B-SA]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+<SPAN style="mso-spacerun:
 yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE> 10 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>.1ad Ethertype<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>[B-TAG]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE> 14 |<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>.1ad B-TAG TCI/VID<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>.1ah Ethertype<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+<o:p></o:p></PRE><PRE> 18 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>.1ah I-TAG TCI/SID<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[ - ]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+<o:p></o:p></PRE><PRE> 22 |<SPAN style="mso-spacerun:
 yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Customer Destination Address<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[ A ]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+<o:p></o:p></PRE><PRE> 26 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun:
 yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>+<o:p></o:p></PRE><PRE> 30 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Customer Source Address<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;
 </SPAN>]<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>]-+-+-+<o:p></o:p></PRE><PRE> 34 |<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>Encap Ethertype<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>[<SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>]<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE><o:p>&nbsp;</o:p></PRE><PRE><o:p>&nbsp;</o:p></PRE><PRE><SPAN style="mso-spacerun:
 yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>.1ah I-TAG TCI<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>| P/DE<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>|R1 |R2 |<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>I-SID<SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>|<o:p></o:p></PRE><PRE><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;
 </SPAN>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></PRE><P class=MsoNormal style="MARGIN: 0in 0in 0pt"><o:p><FONT face="Times New Roman" size=3>&nbsp;</FONT></o:p></P></FONT></o:p></PRE></DIV>
<DIV>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt">Thanks,</P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt">Gary</P>&nbsp;</DIV></div><br>

      <hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out
<a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a>
</body></html>
--0-149186721-1177095796=:74056--

Content-class: urn:content-classes:message
Date: Thu, 19 Apr 2007 09:13:45 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Proposal for making per-VLAN instance optional (to listento)
Status: RO
Content-Length: 8248

Radia,

	I think you are making this too hard.  Please see
my comments below.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, April 17, 2007 3:38 PM
> To: [email-masked]
> Subject: [rbridge] Proposal for making per-VLAN instance 
> optional (to listento)
> 
> First an explanation of the issue:
> 
> Some people have expressed a scalability concern: that if 
> there are many more endnodes (that the Designated RBridge
> R1 knows about) than ones that are talking to endnodes on
> Designated RBridge R2's link, there is no reason for R2 to 
> know about all those other endnodes, and the traffic to 
> keep R2 informed about R1's endnodes' comings and goings
> might be a concern.

A picture right about here would be extremely useful.

> 
> TRILL will work if some RBridges decide they want to learn
> endnode locations from decapsulated traffic rather than
> from the per-VLAN instance in which the Designated RBridge
> announces its attached endnodes. (and other RBridges learn
> from the per-VLAN instance).

This is true.  Is it worth the price to other RBridges (in
terms of option complexity) to support this?

> 
> So it is OK to make *learning* from the IS-IS endnode 
> announcements optional. 

I am unsure that this follows.  When you say "it is ok", you
are apparently referring to the fact that it will work.  That
is not the same as "it is okay" (acceptable), IMO.

> R2 could learn only from the source MAC address of frames
> it decapsulates onto its link, even if other RBridges are 
> learning from the IS-IS endnode announcements.

There are (at least) three ways in which this impacts the way 
other RBridges are required to behave:

1) it now becomes an issue for either configuration (yech!)
   or negotiation in protocol to determine which of two 
   kinds of behavior will apply;
2) this might occur in one of three ways -
   a) on the basis of peer-adjacency - in which case a peer
      will need to decide whether or not to propagate IS-IS
      end-node announcements on a per-peer basis,
   b) on the basis of domain-wide policy that applies to all
	RBridges in a campus, or
   c) some complicated combination of both;
3) all RBridges are likely to have to endure a greater load
   of unicast flooding as a result of information not kept
   by the "lame-duck" implementations that simply do not
   want to receive (or retain) IS-IS endnode announcements.

> 
> But we can't make *advertising* attached endnodes optional, 
> because if there's any RBridge R3 that does NOT want to 
> learn from decapsulated traffic, and wants to learn from 
> IS-IS announcements, then if all the other RBridges stop 
> advertising, then R3 will flood everything.

This is but one issue with making the decision on a basis 
of peer adjacencies.  Another is that - in a deployment
where the majority of edge RBridges elect not to receive
such announcements, the core RBridges (in environments
where there is actually a real distinction between "core"
and "edge" RBridges) should be configured not to receive
them either.  Otherwise, the edge RBridges will originate
a lot of announcement traffic that will then be dropped
rather than being propagated.

But, of course, if the core RBridges are configured not to
receive these announcements, then your problem arises.  I
assume that we're not suggesting that all RBridges MUST 
support this "old-style" learning, so even when the ones
that do not are a minority, they still need to receive the
endnode announcements.

> 
> So--you ask--why don't we *only* learn from decapsulated 
> data traffic?

Not my question at all.

Learning from decapsulation is a flagrant layer violation,
and - as such - is either too risky, or too restrictive in
future developments.

With that caveat, if you want to do it, more power to you.

> 
> The reasons are as follows:
> a) some people have said that router products don't like 
>    to learn from the data plane; they want to forward
>    traffic without thinking very hard, and want to do
>    the work of updating forwarding tables based on control
>    traffic
> b) there are some layer 2 technologies in which endnodes
>    enroll, and being able to announce these attached 
>    endnodes is nice because it is definitive 
>    -- you know when they attach, you know when they go away 
>    -- it's more secure than learning from data, since anyone
>       can send data with any source address and cause 
>       disruption. 
>
> The IS-IS announcement can even modify how definitive the 
> attached endnode is 
>    "it enrolled" 
>    "it enrolled cryptographically" 
>    "I learned it just because I heard a data packet with 
>     that as source address"
>
> c) the per-VLAN IS-IS endnode announcements also announce the
>    layer 3/layer 2 correspondence to facilitate proxy ARP/ND
>    (though that could probably be learned from decapsulated
>    data traffic as well).

This last point assumes a behavior that - IMO - should be 
included, but is not (AFAIK) included in the current WG 
consensus.

> 
> ***********************
> OK, now the proposal:
> 
> One suggestion of course is to eliminate the per-VLAN IS-IS
> instance, and make everyone learn from data traffic. I don't
> have strong opinions on that, but we should make sure the
> people doing router products can cope with this, and that 
> we don't care about the other potential advantages of
> advertising endnodes with IS-IS.
> 
> But I think we can have a compromise that will make both 
> sides happy.
> 
> The idea is to have RB1 announce, in its core instance, 
> whether it wants to learn from IS-IS endnode announcements. 
> If any RBridge in VLAN A wants to learn from endnode
> announcements, then all the RBridges in VLAN A MUST send
> IS-IS endnode announcements.
> 
> But if *all* the RBridges in VLAN A say they don't want them, 
> then the VLAN A endnode announcements stop.
> 
> Even if there are endnodes announcements in VLAN A, it is 
> optional for an RBridge whether it wants to learn from data
> or from the announcements, or from some combination of the
> two (like perhaps it will only learn from endnode 
> announcements which are definitive, or that it will learn
> from endnode announcements, but if it runs out of room to
> store them, it will fall back on learning from data).
> 
> We could even have core RBridges filter IS-IS endnode 
> announcements for VLAN A to only deliver them to RBridges
> in VLAN A that say that want to learn from them.
> 
> ***************
> What do people think?

As I said above, I think you are making this too hard.

As with bridges before them, all RBridges may eventually
have to deal with memory (scale) limitations by purging 
their least-used, or least recently refreshed "filter"
information.

This implies two choices in implementation: 

1) optimize for the IS-IS approach by designing both for
   large and expandable memory capacity to minimize the
   need for purging and (potentially) having to re-learn 
2) optimize for the data-learning approach, save on cost 
   of memory at a cost of increased forwarding complexity

Clearly if the IS-IS endnode announcements are sent to all
RBridges in a campus, then any that are unable to retain
the information (because of their optimization choices) 
will be able to either ignore them, or purge their DBs
according to whatever local policy applies to their own
implementation.

The only time the IS-IS endnode announcement traffic is 
likely to be a problem is if all RBridges are ignoring
them.  Since this will be an exclusive property of those
RBridges that only use "old-style" learning, I assume it
will be possible to configure those same RBridges not to
send IS-IS announcements in the event that a specific
deployment scenario does not require them.

This places the (minimal) additional complexity in those
RBridges that choose to learn without any impact at all
on those that choose to use IS-IS endnode announcements.

> Radia
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 18 Apr 2007 07:45:44 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Proposal for making per-VLAN instance optional (to listen to)
Status: RO
Content-Length: 365

The proposal strikes me as a reasonable compromise that ensures
interoperability
while allowing specific implementations to optimize as they see best for
their
target deployment.

Assuming both this and the VLAN-sharing ideas make it into the next
draft,
it might be worth noting than RBridges using the VLAN-sharing concept
will
need the IS-IS advertisements.

Date: Tue, 17 Apr 2007 12:37:50 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Proposal for making per-VLAN instance optional (to listen to)
Status: RO
Content-Length: 3678

First an explanation of the issue:

Some people have expressed a scalability concern: that if there are many 
more endnodes
(that the Designated RBridge R1 knows about) than ones that are talking 
to endnodes
on Designated RBridge R2's link, there is no reason for R2 to know about 
all those other
endnodes, and the traffic to keep R2 informed about R1's endnodes' 
comings and goings
might be a concern.

TRILL will work if some RBridges decide they want to learn endnode 
locations from
decapsulated traffic rather than from the per-VLAN instance in which the 
Designated RBridge
announces its attached endnodes. (and other RBridges learn from the 
per-VLAN instance).

So it is OK to make *learning* from the IS-IS endnode announcements 
optional. R2
could learn only from the source MAC address of frames it decapsulates 
onto its link, even
if other RBridges are learning from the IS-IS endnode announcements.

But we can't make *advertising* attached endnodes optional, because if 
there's any RBridge R3
that does NOT want to learn from decapsulated traffic, and wants to 
learn from IS-IS announcements, then if all the other RBridges stop 
advertising, then R3 will flood everything.

So--you ask--why don't we *only* learn from decapsulated data traffic?

The reasons are as follows:
a) some people have said that router products don't like to learn from 
the data plane; they
want to forward traffic without thinking very hard, and want to do the 
work of updating
forwarding tables based on control traffic
b) there are some layer 2 technologies in which endnodes enroll, and 
being able to announce
these attached endnodes is nice because it is definitive -- you know 
when they attach,
you know when they go away -- it's more secure than learning from data, 
since anyone
can send data with any source address and cause disruption. The IS-IS 
announcement
can even modify how definitive the attached endnode is "it enrolled" "it 
enrolled
cryptographically" "I learned it just because I heard a data packet with 
that as source
address"
c) the per-VLAN IS-IS endnode announcements also announce the layer 
3/layer 2
correspondence to facilitate proxy ARP/ND (though that could probably be 
learned
from decapsulated data traffic as well).

***********************
OK, now the proposal:

One suggestion of course is to eliminate the per-VLAN IS-IS instance, 
and make
everyone learn from data traffic. I don't have strong opinions on that, 
but we should
make sure the people doing router products can cope with this, and that 
we don't
care about the other potential advantages of advertising endnodes with 
IS-IS.

But I think we can have a compromise that will make both sides happy.

The idea is to have RB1 announce, in its core instance, whether it wants 
to learn
from IS-IS endnode announcements. If any RBridge in VLAN A wants to learn
from endnode announcements, then all the RBridges in VLAN A MUST send
IS-IS endnode announcements.

But if *all* the RBridges in VLAN A say they don't want them, then the 
VLAN A
endnode announcements stop.

Even if there are endnodes announcements in VLAN A, it is optional for 
an RBridge
whether it wants to learn from data or from the announcements, or from some
combination of the two (like perhaps it will only learn from endnode 
announcements
which are definitive, or that it will learn from endnode announcements, 
but if
it runs out of room to store them, it will fall back on learning from data).

We could even have core RBridges filter IS-IS endnode announcements for 
VLAN A
to only deliver them to RBridges in VLAN A that say that want to learn 
from them.

***************
What do people think?

Radia

Date: Mon, 09 Apr 2007 13:36:24 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN proposal
Status: RO
Content-Length: 1211

Actually, with IS-IS, R1 can't delete information from R2's LSP If R1 is 
not interesting in it.
Anyone participating in the flooding of R1's LSP must keep R1's LSP 
intact. Someone
downstream might be interested in that information. Even once R1's 
neighbors acknowledge
they've received R2's LSP, R1 must still retain the information in case 
one of R1's neighbors
goes down and loses state.

With the per-VLAN instance of IS-IS, since the topology is a single hop, 
R1 would
never need to forward R2's LSP to anyone else, so in theory R1 could ignore
R2's endnode announcements.

Radia

Caitlin Bestler wrote:
> Radia Perlman wrote:
>
>   
>> I'd suggest the TRILL spec just say that you SHOULD put the
>> information into the core instance of IS-IS if you are
>> configured, and not say anything about what any RBridge would
>> do with the information.
>>
>>     
> The TRILL spec would merely add the information to the RBridge
> discovery data. It could explicitly state that any RBridge could
> choose to not retain information that it would have no use of.
>
> The same would apply to the additional attribute in the endnode
> discovery. If it's not relevant to you, discard or ignore it.
>
>
>
>   

Content-class: urn:content-classes:message
Date: Mon, 9 Apr 2007 13:18:07 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN proposal
Status: RO
Content-Length: 560

Radia Perlman wrote:

> 
> I'd suggest the TRILL spec just say that you SHOULD put the
> information into the core instance of IS-IS if you are
> configured, and not say anything about what any RBridge would
> do with the information.
> 
The TRILL spec would merely add the information to the RBridge
discovery data. It could explicitly state that any RBridge could
choose to not retain information that it would have no use of.

The same would apply to the additional attribute in the endnode
discovery. If it's not relevant to you, discard or ignore it.

Date: Mon, 09 Apr 2007 12:19:34 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN proposal
Status: RO
Content-Length: 8458

Yes.! Thanks, Caitlin.

This seems like the right way to go. It offers the best part of both the 
proposals
I wrote up earlier, without the disadvantages or either, and it's simple.

a) only the RBridges attached to a VLAN in the group need to know about 
the VLAN group
b) packets don't get duplicated

And it accomplishes this by having RBridges that are in the VLAN group 
pretend to be in all
the relevant other VLANs. This way they receive multicasts, including 
IS-IS endnode announcements, for all the VLANs they should be receiving.

To say it in other words,

a) There is a VLAN group consisting of {Z=primary, A, B, C, D}

b) An RBridge is configured to know about this group iff it attaches to 
a link in one of
those VLANs

c) "Core RBridges" (by which I mean those that are forwarding packets 
that are already
encapsulated) forward a multicast frame tagged with a VLAN in that group 
exactly as
it would have without there being a VLAN group

d) For an RBridge RB1 that attaches to one of the VLANs in the group:

   . If RB1 is attached to a secondary VLAN, say VLAN C, RB1 claims, in 
its core instance
     of IS-IS, that RB1 is actually attached to both VLAN C and VLAN Z. 
This causes
     multicast packets tagged with VLAN C or VLAN Z to get delivered to RB1.

   . If RB1 is attached to the primary VLAN Z, the RB1 claims, in its 
core instance of
     IS-IS, to also be connected to VLANs A, B, C, and D. That way RB1 
will receive
     any multicast packet tagged with any of the VLANs in the group

e) The per-VLAN instance of IS-IS in which endnode membership is announced
is not changed; there is still one for A, one for B, one for C, one for 
D, and one for Z.
Because RB1, in Z, has announced it is part of A, B, C, and D as well, 
RB1 will receive
endnode announcements for all of the VLANs A, B, C, and D

f) If RB1 receives, from endnode S in VLAN Z, a unicast for destination 
D, RB1 checks to
find D in its endnode databases for all of the VLANs in the group (Z, A, 
B, C, and D). If
it finds D in VLAN C, with egress RBridge RB2, then RB1 encapsulates the 
packet with
inner VLAN tag Z (the source's VLAN), and specifies egress RBridge=RB2.

RB2 receives this unicast for D, and forwards it to D even though the 
frame is marked
as VLAN=Z, and D is in VLAN C. RB2 removes the VLAN tag, changes it to C, or
leaves it as Z, whatever is appropriate, and presumably RB2 is 
configured to know which
of these three is appropriate for the outgoing port.

If RB1 cannot find D in any of the endnode tables for {Z, A, B, C, or 
D}, then RB1
floods the packet tagged with VLAN=Z (the source's VLAN).

g) If any rbridge RB1 receives a multicast packet from a source in any
VLAN, whether that VLAN is part of a group or not, RB1 floods the packet 
tagged
with the source's VLAN

**********
One thing I'd like to add is for RBridges that are part of a group to 
announce the group
in their core instance. Core RBridges would ignore this. It would not 
change their behavior, so
there is no disadvantage (other than a trivial amount of space in the 
core instance LSP).
The advantages are:
a) perhaps one could avoid configuring every RBridge, and an RBridge 
could be willing
to take the word of another RBridge what the VLAN groupings should be
b) at the very least, it would be a good debugging tool, and a way of 
detecting misconfiguration

I'd suggest the TRILL spec just say that you SHOULD put the information 
into the core
instance of IS-IS if you are configured, and not say anything about what 
any RBridge would
do with the information.

**********
So -- what do people think about this?

Radia

Caitlin Bestler wrote:
> This is a proposal on how to support "shared VLANs" and resolve the
> whole MAC/IP uniqueness question. It avoids the incosistencies of
> simply assuming that MAC and IP addresses are always scoped by VLANs,
> but does so without requiring any action from any RBridge that is not
> directly involved in a "VLAN Group".
>
> By default the per-VLAN IS-IS instances are totally independent from
> each
>  other. There is no presumed correlation between identicial MAC or IP
> addresses when they are in different VLAN instances.
>
> However, RBridges MAY offer the capability of recognized groups of VLANs
> that represent a single unique namespace for both MAC and IP addresses
> and
> where there is a primary or shared VLAN that is accessible from all of
> the
> other VLANs in the group.
>
> For example, a VLAN group might consist of {Z,A,B,C,D} where Z is the
> designated primary VLAN. Endnodes in VLAN A would be capable of sending
> ethernet frames within VLAN A, and to VLAN Z. Endnodes in VLAN B could
> send to {Z,B}, those in C to {Z,C} and those in D to {Z,D}. While
> endnodes
> in the shared or primary VLAN (Z) would be able to send to all VLANs in
> the
> group {Z,A,B,C,D}.
>
> The impact on the RBridge protocol is that RBridges which support a
> VLAN Group would have more information in the  IS-IS instances for
> the VLAN Group. Specifically:
>
> 	Endnodes that are part of the primary VLAN (Z) would be
> represented
> 	in the IS-IS instances for the entire group {A,B,C,D,Z}.
>
> 	Endnodes that are part of a non-primary VLAN (for example, A)
> would
> 	also be represented in the instance for the group's primary VLAN
> (Z).
>
> RBridge ingress behavior is essentially unchanged. The exception is that
> a frame being attempted from one non-primary VLAN (A) to another
> non-primary
> VLAN (B) can be short-circuited at the source. Because of the sharing
> between
> the IS-IS instances within the VLAN Group the ingress RBridge MAY
> recognize
> that the destination is unreachable, whereas without this information it
>
> would merely be unknown (it would also be unreachable, but the ingress
> RBridge would not have known that).
>
> For RBridges supporting VLAN Groups, egress behavior is enhanced to
> allow
> an endnode that otherwise would have been considered to be just the
> primary
> to also be part of all VLANs in the group, and for an endnode that
> otherwise
> would have been part of any non-primary VLAN in the group to also be
> part
> of the group's primary VLAN.
>
> This option requires no supporting action from any RBridge that is not
> part of
> the VLAN group. The additional information need only be retained in
> IS-IS
> instances that are part of a VLAN Group. No RBridge is required to
> support
> VLAN Groups.
>
> The only required enhancement to RBridge protocols is that the endnode
> discovery
> advertisement needs to explicitly indicate the VLAN associated with the
> discovered
> endnode. It may also be desirable for each the RBridge discovery
> advertisement to
> explicitly list any VLAN Group that the RBridge is part of.
>
> All RBridges that are part of a VLAN Group MUST have the same list of
> member VLANs
> for the VLAN Group.
>
> All RBridges that are part of a VLAN Group MUST participate directly in
> the group's
> primary VLAN ('Z' in the example), and MUST maintain a VLAN Z IS-IS
> instance.
>
> Endnode discoveries by any RBridge within a VLAN Group MUST be
> distributed via the
> group's primary VLAN.
>
> When an RBridge receives an endnode discovery advertisement for and
> endnode that
> belongs to the primary VLAN it MUST include that information within each
> IS-IS
> instance that it maintains for the entire VLAN Group. It MUST enforce
> any consistency
> rules that are relevant according to that VLAN Group's rules, for
> example discovery of
> an IP Address within one VLAN might require removal from another VLAN.
>
> Consistency rules of this type reflect the rules of that VLAN Group. The
> RBridge protocol 
> neither requires nor forbids such VLAN Group specific rules.
>
> When an RBridge receives an endnode discovery advertisement for a
> non-primary VLAN, the
> endode is only added to the receiving RBRidge's IS-IS instance for the
> group's primary
> VLAN (Z). The receiving RBridge would also remove any endnode record
> that was inconsistent
> with the new information, such as the same MAC or IP address having a
> conflicting meaning,
> from other VLAN IS-IS instances.
>
> Determination as to whether an entry is "conflicting"  is based upon the
> rules of the
> VLAN Group, and is not part of the RBridge protocol specificatins.
>
>
>
>
>
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 9 Apr 2007 11:03:35 -0700
From: "Caitlin Bestler" <[email-masked]>
To: [email-masked]
Subject: [rbridge] Shared VLAN proposal
Status: RO
Content-Length: 4425

This is a proposal on how to support "shared VLANs" and resolve the
whole MAC/IP uniqueness question. It avoids the incosistencies of
simply assuming that MAC and IP addresses are always scoped by VLANs,
but does so without requiring any action from any RBridge that is not
directly involved in a "VLAN Group".

By default the per-VLAN IS-IS instances are totally independent from
each
 other. There is no presumed correlation between identicial MAC or IP
addresses when they are in different VLAN instances.

However, RBridges MAY offer the capability of recognized groups of VLANs
that represent a single unique namespace for both MAC and IP addresses
and
where there is a primary or shared VLAN that is accessible from all of
the
other VLANs in the group.

For example, a VLAN group might consist of {Z,A,B,C,D} where Z is the
designated primary VLAN. Endnodes in VLAN A would be capable of sending
ethernet frames within VLAN A, and to VLAN Z. Endnodes in VLAN B could
send to {Z,B}, those in C to {Z,C} and those in D to {Z,D}. While
endnodes
in the shared or primary VLAN (Z) would be able to send to all VLANs in
the
group {Z,A,B,C,D}.

The impact on the RBridge protocol is that RBridges which support a
VLAN Group would have more information in the  IS-IS instances for
the VLAN Group. Specifically:

	Endnodes that are part of the primary VLAN (Z) would be
represented
	in the IS-IS instances for the entire group {A,B,C,D,Z}.

	Endnodes that are part of a non-primary VLAN (for example, A)
would
	also be represented in the instance for the group's primary VLAN
(Z).

RBridge ingress behavior is essentially unchanged. The exception is that
a frame being attempted from one non-primary VLAN (A) to another
non-primary
VLAN (B) can be short-circuited at the source. Because of the sharing
between
the IS-IS instances within the VLAN Group the ingress RBridge MAY
recognize
that the destination is unreachable, whereas without this information it

would merely be unknown (it would also be unreachable, but the ingress
RBridge would not have known that).

For RBridges supporting VLAN Groups, egress behavior is enhanced to
allow
an endnode that otherwise would have been considered to be just the
primary
to also be part of all VLANs in the group, and for an endnode that
otherwise
would have been part of any non-primary VLAN in the group to also be
part
of the group's primary VLAN.

This option requires no supporting action from any RBridge that is not
part of
the VLAN group. The additional information need only be retained in
IS-IS
instances that are part of a VLAN Group. No RBridge is required to
support
VLAN Groups.

The only required enhancement to RBridge protocols is that the endnode
discovery
advertisement needs to explicitly indicate the VLAN associated with the
discovered
endnode. It may also be desirable for each the RBridge discovery
advertisement to
explicitly list any VLAN Group that the RBridge is part of.

All RBridges that are part of a VLAN Group MUST have the same list of
member VLANs
for the VLAN Group.

All RBridges that are part of a VLAN Group MUST participate directly in
the group's
primary VLAN ('Z' in the example), and MUST maintain a VLAN Z IS-IS
instance.

Endnode discoveries by any RBridge within a VLAN Group MUST be
distributed via the
group's primary VLAN.

When an RBridge receives an endnode discovery advertisement for and
endnode that
belongs to the primary VLAN it MUST include that information within each
IS-IS
instance that it maintains for the entire VLAN Group. It MUST enforce
any consistency
rules that are relevant according to that VLAN Group's rules, for
example discovery of
an IP Address within one VLAN might require removal from another VLAN.

Consistency rules of this type reflect the rules of that VLAN Group. The
RBridge protocol 
neither requires nor forbids such VLAN Group specific rules.

When an RBridge receives an endnode discovery advertisement for a
non-primary VLAN, the
endode is only added to the receiving RBRidge's IS-IS instance for the
group's primary
VLAN (Z). The receiving RBridge would also remove any endnode record
that was inconsistent
with the new information, such as the same MAC or IP address having a
conflicting meaning,
from other VLAN IS-IS instances.

Determination as to whether an entry is "conflicting"  is based upon the
rules of the
VLAN Group, and is not part of the RBridge protocol specificatins.

Content-class: urn:content-classes:message
Date: Mon, 9 Apr 2007 11:54:07 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Some routine changes to the specifications draft
Status: RO
Content-Length: 1443

Unless there is some objection, the following changes, which I hope will
be non-controversial, will be made in the specification draft:

(1) There are no IANA Considerations for the reserved bits in the shim
or for version number values. I suggest that both require a Standards
Action as modified by RFC 4020.

(2) The draft currently says nothing about the reserved bits. Typical
IETF language would be "must be zero on transmission and are ignored on
receipt". But, thinking about it, I'm not so sure that's right in this
case. Zero on transmit is fine but, of the seven reserved bits, perhaps
some of them should be ignored and some should cause the frame to be
dropped if they are non-zero and the receiving Rbridge does not know
that they means. Of course, I'm only talking about what the
specification would say about unallocated bits. We may, in completing
the specification, give a specific meaning of some of those bits
currently labeled as reserved in which case we can say what we like
about their setting on transmission and interpretation on receipt and
the generic language would only apply to remaining reserved bits.

(3) Also, if versions are going to actually be useful in an incremental
deployment scenario, I think it would be useful for Rbridges to know
what version is supported by another RBridge they are talking to. This
could be easily accomplished by adding that information to the core link
state.

Thanks,
Donald

Date: Wed, 04 Apr 2007 21:37:10 -0700
From: Erik Nordmark <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Prague minutes
Status: RO
Content-Length: 439

Eastlake III Donald-LDE008 wrote:
> Minutes of the Prague TRILL meeting have been uploaded to the 68th IETF
> Meeting Materials page:
> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68

Please send any corrections to the minutes to the co-chairs or the list
including any issues with the consensus to use "nickname" to describe
the short designators of the RBridges that are in
the TRILL header.

    Erik & Donald

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 23:48:58 -0400
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Prague minutes
Status: RO
Content-Length: 186

Minutes of the Prague TRILL meeting have been uploaded to the 68th IETF
Meeting Materials page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 09:47:57 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 9859

I don't disagree... I couldn't make the connection between this and
proxy ARP/ND.

JR

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 9:07 AM
> To: J. R. Rivers
> Cc: [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> 
> JR,
> 
> 	Just to be precise, in the working group discussions, we have
> been making a very strong distinction between multicast and broadcast.
> 
> 	I agree that - in an environment where multicast is a large
> factor (where large means something like more than 1% of the total
> injected traffic), the traffic associated with ARP is way down in 
> the noise.  However, if any effective form of multicast optimization 
> is implemented, the impact of potentially looping multicast can be 
> scoped to affected VLANs (and possibly even to multicast "listeners") 
> by techniques other than TTL (such as queue management that provides 
> effective isolation of logical interfaces, or hard upper limits on 
> total multicast traffic, for instance).
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 11:26 AM
> > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > Importance: High
> > 
> > 
> > Sorry I must have mis-stated my point.  It seems that if ARP 
> > is the bulk
> > of your multicast traffic, then optimizing it doesn't seem like much
> > return-on-investment.  If other multicast comprises the bulk, then
> > optimizing ARP doesn't seem to provide much return-on-investment.
> > 
> > JR
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > Sent: Wednesday, April 04, 2007 7:38 AM
> > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> > > Perlman; [email-masked]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals)
> > > 
> > > It doesn't.  However, you mentioned IP multicast as 
> another area of
> > > concern... 
> > > 
> > > Thanks!
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson  
> > > 
> > > > -----Original Message-----
> > > > From: J. R. Rivers [mailto:[email-masked]] 
> > > > Sent: Wednesday, April 04, 2007 10:36 AM
> > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > > > Perlman; [email-masked]
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals)
> > > > Importance: High
> > > > 
> > > > 
> > > > Why does ARP/ND equate to IP multicast optimization?
> > > > 
> > > > JR
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > > > Sent: Wednesday, April 04, 2007 7:34 AM
> > > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> > > > > Perlman; [email-masked]
> > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > alternative proposals)
> > > > > 
> > > > > JR,
> > > > > 
> > > > > 	I agree.  However, I believe we (as a working 
> > group) have
> > > > > already
> > > > > agreed that the IP multicast optimization is essential.  
> > > > > Also, it is my
> > > > > point (and it is certainly arguable) that perhaps TRILL 
> > > > should not be
> > > > > targetting the general applications of L2 where other forms 
> > > > > of L2 bcast
> > > > > are likely to be a significant factor - but should instead 
> > > > > focus on the
> > > > > applications of L2 specific to IP only (or IP dominant) 
> > networks.
> > > > > 
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: J. R. Rivers [mailto:[email-masked]] 
> > > > > > Sent: Wednesday, April 04, 2007 9:58 AM
> > > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > > > > > Perlman; [email-masked]
> > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > > alternative proposals)
> > > > > > Importance: High
> > > > > > 
> > > > > > 
> > > > > > It seems that if ARP is the bulk of your 
> > > > > broadcast/multicast, then you
> > > > > > don't really need a very efficient broadcast/multicast 
> > > > > > mechanism.  Some
> > > > > > networks can be characterized as you've stated; 
> > > however, there are
> > > > > > others that use L2/IP multicast in a substantial fashion.
> > > > > > 
> > > > > > JR
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > > > > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> > > > > > > Perlman; [email-masked]
> > > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > > > alternative proposals)
> > > > > > > 
> > > > > > > Silvano,
> > > > > > > 
> > > > > > > 	Where IP (v4 or v6) is the exclusive higher 
> > > > layer in a specific
> > > > > > > network deployment, it is likely that ARP is one of the 
> > > > > most common 
> > > > > > > forms of broadcast traffic that may occur.  As we've 
> > > > > > > previously agreed 
> > > > > > > that broadcast traffic is of particular concern in 
> > TRILL, the 
> > > > > > > potential
> > > > > > > to drastically reduce (or possibly eliminate) common 
> > > > > > broadcast traffic
> > > > > > > should be considered a worth-while objective.
> > > > > > > 
> > > > > > > --
> > > > > > > Eric Gray
> > > > > > > Principal Engineer
> > > > > > > Ericsson  
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Silvano Gai [mailto:[email-masked]] 
> > > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray 
> > > (LO/EUS); Radia 
> > > > > > > > Perlman; [email-masked]
> > > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > > > > alternative proposals)
> > > > > > > > Importance: High
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Do we have any quantitatively data about the need of 
> > > > > ARP/ND proxy?
> > > > > > > > 
> > > > > > > > With an ARP cache of 30 minutes, typical in hosts 
> > > today, even 
> > > > > > > > with a 100
> > > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. 
> > Since not 
> > > > > > > > all the hosts
> > > > > > > > talk with each other, it is more typically like 
> 5 ARP/sec.
> > > > > > > > 
> > > > > > > > The ARP/ND cache on the RBridge must be significantly 
> > > > > > > shorter than 30
> > > > > > > > minutes to not increase the amount of obsolete 
> > information.
> > > > > > > > 
> > > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 
> > 100 K hosts 
> > > > > > > per VLAN?
> > > > > > > > 
> > > > > > > > Is this the big optimization for which we care 
> to create 
> > > > > > > corner cases
> > > > > > > > and potential incompatibilities?
> > > > > > > > 
> > > > > > > > -- Silvano
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); 
> > > > > > Radia Perlman;
> > > > > > > > > [email-masked]
> > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: J. R. Rivers 
> [mailto:[email-masked]]
> > > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray 
> > > > (LO/EUS); Radia
> > > > > > > > > > Perlman; [email-masked]
> > > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > > > > alternative proposals
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > snip...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > At the minimum we need to ensure that all 
> > > > > RBridges have the
> > > > > > > > > > > information that would enable them to 
> > efficiently and
> > > > > > > > > > reliably act as
> > > > > > > > > > > an ARP/ND proxy.
> > > > > > > > > >
> > > > > > > > > > It depends on how you define the requirements 
> > of ARP/ND
> > > > > > > > > > proxy.  I have seen this general mechanism 
> > used in many
> > > > > > > > > > contexts... only one of which is covered by 
> > an IETF RFC
> > > > > > > > > > (AFAIK).  Bridges in their basic definition don't 
> > > > > have ARP/ND
> > > > > > > > > > proxy.  Only bridges that subsume some type of 
> > > IP related
> > > > > > > > > > functionality contain these.
> > > > > > > > > >
> > > > > > > > > > If an RBridge "looks and smells" like a bridge, 
> > > > > then there is
> > > > > > > > > > natural traffic separation between VLANs, and 
> > > this allows
> > > > > > > > > > systems companies to view RBridges as "better 
> > bridges".
> > > > > > > > > >
> > > > > > > > > > JR
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > 
> > > > > > > > > The reason RBridges are "better bridges" is that they
> > > > > > > > > deal with the issues of large subnets far better than
> > > > > > > > > bridges do.
> > > > > > > > > 
> > > > > > > > > Efficient distribution of ARP/ND information is also
> > > > > > > > > an issue where a "better bridge" is needed to scale
> > > > > > > > > to larger subnets efficiently.
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 09:30:21 -0700
From: "Silvano Gai" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Eric Gray \(LO/EUS\)" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 8677

Let me try to summarize what I learnt from the replies to my message. 

ARP/ND optimization:
1) it is not justified by a bandwidth issue;
2) it is not justified by a latency issue;
3) may help reduce the problem with the broadcast storm, but the problem
is really IP multicast. Solution like the one proposed by Radia at the
last IETF address both IP multicast and ARP; therefore there is no need
for a special ARP/ND solution;
4) it introduces corner cases.

Why do we want to do ARP/ND optimization in the first version of TRILL?

I restate my proposal: let's drop it by the first version of TRILL and
deal with it later, in a separate document.

-- Silvano

> -----Original Message-----
> From: J. R. Rivers
> Sent: Wednesday, April 04, 2007 8:26 AM
> To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia Perlman;
> [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative
> proposals)
> 
> 
> Sorry I must have mis-stated my point.  It seems that if ARP is the
bulk
> of your multicast traffic, then optimizing it doesn't seem like much
> return-on-investment.  If other multicast comprises the bulk, then
> optimizing ARP doesn't seem to provide much return-on-investment.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > Sent: Wednesday, April 04, 2007 7:38 AM
> > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > alternative proposals)
> >
> > It doesn't.  However, you mentioned IP multicast as another area of
> > concern...
> >
> > Thanks!
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:[email-masked]]
> > > Sent: Wednesday, April 04, 2007 10:36 AM
> > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia
> > > Perlman; [email-masked]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > alternative proposals)
> > > Importance: High
> > >
> > >
> > > Why does ARP/ND equate to IP multicast optimization?
> > >
> > > JR
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > Sent: Wednesday, April 04, 2007 7:34 AM
> > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia
> > > > Perlman; [email-masked]
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > alternative proposals)
> > > >
> > > > JR,
> > > >
> > > > 	I agree.  However, I believe we (as a working group)
have
> > > > already
> > > > agreed that the IP multicast optimization is essential.
> > > > Also, it is my
> > > > point (and it is certainly arguable) that perhaps TRILL
> > > should not be
> > > > targetting the general applications of L2 where other forms
> > > > of L2 bcast
> > > > are likely to be a significant factor - but should instead
> > > > focus on the
> > > > applications of L2 specific to IP only (or IP dominant)
networks.
> > > >
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson
> > > >
> > > > > -----Original Message-----
> > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > Sent: Wednesday, April 04, 2007 9:58 AM
> > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia
> > > > > Perlman; [email-masked]
> > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > > alternative proposals)
> > > > > Importance: High
> > > > >
> > > > >
> > > > > It seems that if ARP is the bulk of your
> > > > broadcast/multicast, then you
> > > > > don't really need a very efficient broadcast/multicast
> > > > > mechanism.  Some
> > > > > networks can be characterized as you've stated;
> > however, there are
> > > > > others that use L2/IP multicast in a substantial fashion.
> > > > >
> > > > > JR
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]]
> > > > > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia
> > > > > > Perlman; [email-masked]
> > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > > > alternative proposals)
> > > > > >
> > > > > > Silvano,
> > > > > >
> > > > > > 	Where IP (v4 or v6) is the exclusive higher
> > > layer in a specific
> > > > > > network deployment, it is likely that ARP is one of the
> > > > most common
> > > > > > forms of broadcast traffic that may occur.  As we've
> > > > > > previously agreed
> > > > > > that broadcast traffic is of particular concern in TRILL,
the
> > > > > > potential
> > > > > > to drastically reduce (or possibly eliminate) common
> > > > > broadcast traffic
> > > > > > should be considered a worth-while objective.
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Silvano Gai [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray
> > (LO/EUS); Radia
> > > > > > > Perlman; [email-masked]
> > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > > > > alternative proposals)
> > > > > > > Importance: High
> > > > > > >
> > > > > > >
> > > > > > > Do we have any quantitatively data about the need of
> > > > ARP/ND proxy?
> > > > > > >
> > > > > > > With an ARP cache of 30 minutes, typical in hosts
> > today, even
> > > > > > > with a 100
> > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not
> > > > > > > all the hosts
> > > > > > > talk with each other, it is more typically like 5 ARP/sec.
> > > > > > >
> > > > > > > The ARP/ND cache on the RBridge must be significantly
> > > > > > shorter than 30
> > > > > > > minutes to not increase the amount of obsolete
information.
> > > > > > >
> > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K
hosts
> > > > > > per VLAN?
> > > > > > >
> > > > > > > Is this the big optimization for which we care to create
> > > > > > corner cases
> > > > > > > and potential incompatibilities?
> > > > > > >
> > > > > > > -- Silvano
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS);
> > > > > Radia Perlman;
> > > > > > > > [email-masked]
> > > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > > alternative proposals
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray
> > > (LO/EUS); Radia
> > > > > > > > > Perlman; [email-masked]
> > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN"
> > > > alternative proposals
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > snip...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > At the minimum we need to ensure that all
> > > > RBridges have the
> > > > > > > > > > information that would enable them to efficiently
and
> > > > > > > > > reliably act as
> > > > > > > > > > an ARP/ND proxy.
> > > > > > > > >
> > > > > > > > > It depends on how you define the requirements of
ARP/ND
> > > > > > > > > proxy.  I have seen this general mechanism used in
many
> > > > > > > > > contexts... only one of which is covered by an IETF
RFC
> > > > > > > > > (AFAIK).  Bridges in their basic definition don't
> > > > have ARP/ND
> > > > > > > > > proxy.  Only bridges that subsume some type of
> > IP related
> > > > > > > > > functionality contain these.
> > > > > > > > >
> > > > > > > > > If an RBridge "looks and smells" like a bridge,
> > > > then there is
> > > > > > > > > natural traffic separation between VLANs, and
> > this allows
> > > > > > > > > systems companies to view RBridges as "better
bridges".
> > > > > > > > >
> > > > > > > > > JR
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > The reason RBridges are "better bridges" is that they
> > > > > > > > deal with the issues of large subnets far better than
> > > > > > > > bridges do.
> > > > > > > >
> > > > > > > > Efficient distribution of ARP/ND information is also
> > > > > > > > an issue where a "better bridge" is needed to scale
> > > > > > > > to larger subnets efficiently.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 11:06:42 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 8979

JR,

	Just to be precise, in the working group discussions, we have
been making a very strong distinction between multicast and broadcast.

	I agree that - in an environment where multicast is a large
factor (where large means something like more than 1% of the total
injected traffic), the traffic associated with ARP is way down in 
the noise.  However, if any effective form of multicast optimization 
is implemented, the impact of potentially looping multicast can be 
scoped to affected VLANs (and possibly even to multicast "listeners") 
by techniques other than TTL (such as queue management that provides 
effective isolation of logical interfaces, or hard upper limits on 
total multicast traffic, for instance).

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 11:26 AM
> To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> Importance: High
> 
> 
> Sorry I must have mis-stated my point.  It seems that if ARP 
> is the bulk
> of your multicast traffic, then optimizing it doesn't seem like much
> return-on-investment.  If other multicast comprises the bulk, then
> optimizing ARP doesn't seem to provide much return-on-investment.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 7:38 AM
> > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > 
> > It doesn't.  However, you mentioned IP multicast as another area of
> > concern... 
> > 
> > Thanks!
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:[email-masked]] 
> > > Sent: Wednesday, April 04, 2007 10:36 AM
> > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > > Perlman; [email-masked]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals)
> > > Importance: High
> > > 
> > > 
> > > Why does ARP/ND equate to IP multicast optimization?
> > > 
> > > JR
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > > Sent: Wednesday, April 04, 2007 7:34 AM
> > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> > > > Perlman; [email-masked]
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals)
> > > > 
> > > > JR,
> > > > 
> > > > 	I agree.  However, I believe we (as a working 
> group) have
> > > > already
> > > > agreed that the IP multicast optimization is essential.  
> > > > Also, it is my
> > > > point (and it is certainly arguable) that perhaps TRILL 
> > > should not be
> > > > targetting the general applications of L2 where other forms 
> > > > of L2 bcast
> > > > are likely to be a significant factor - but should instead 
> > > > focus on the
> > > > applications of L2 specific to IP only (or IP dominant) 
> networks.
> > > > 
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson  
> > > > 
> > > > > -----Original Message-----
> > > > > From: J. R. Rivers [mailto:[email-masked]] 
> > > > > Sent: Wednesday, April 04, 2007 9:58 AM
> > > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > > > > Perlman; [email-masked]
> > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > alternative proposals)
> > > > > Importance: High
> > > > > 
> > > > > 
> > > > > It seems that if ARP is the bulk of your 
> > > > broadcast/multicast, then you
> > > > > don't really need a very efficient broadcast/multicast 
> > > > > mechanism.  Some
> > > > > networks can be characterized as you've stated; 
> > however, there are
> > > > > others that use L2/IP multicast in a substantial fashion.
> > > > > 
> > > > > JR
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > > > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> > > > > > Perlman; [email-masked]
> > > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > > alternative proposals)
> > > > > > 
> > > > > > Silvano,
> > > > > > 
> > > > > > 	Where IP (v4 or v6) is the exclusive higher 
> > > layer in a specific
> > > > > > network deployment, it is likely that ARP is one of the 
> > > > most common 
> > > > > > forms of broadcast traffic that may occur.  As we've 
> > > > > > previously agreed 
> > > > > > that broadcast traffic is of particular concern in 
> TRILL, the 
> > > > > > potential
> > > > > > to drastically reduce (or possibly eliminate) common 
> > > > > broadcast traffic
> > > > > > should be considered a worth-while objective.
> > > > > > 
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson  
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Silvano Gai [mailto:[email-masked]] 
> > > > > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray 
> > (LO/EUS); Radia 
> > > > > > > Perlman; [email-masked]
> > > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > > > alternative proposals)
> > > > > > > Importance: High
> > > > > > > 
> > > > > > > 
> > > > > > > Do we have any quantitatively data about the need of 
> > > > ARP/ND proxy?
> > > > > > > 
> > > > > > > With an ARP cache of 30 minutes, typical in hosts 
> > today, even 
> > > > > > > with a 100
> > > > > > > K hosts in a VLAN we get at most 55 ARP seconds. 
> Since not 
> > > > > > > all the hosts
> > > > > > > talk with each other, it is more typically like 5 ARP/sec.
> > > > > > > 
> > > > > > > The ARP/ND cache on the RBridge must be significantly 
> > > > > > shorter than 30
> > > > > > > minutes to not increase the amount of obsolete 
> information.
> > > > > > > 
> > > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 
> 100 K hosts 
> > > > > > per VLAN?
> > > > > > > 
> > > > > > > Is this the big optimization for which we care to create 
> > > > > > corner cases
> > > > > > > and potential incompatibilities?
> > > > > > > 
> > > > > > > -- Silvano
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); 
> > > > > Radia Perlman;
> > > > > > > > [email-masked]
> > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray 
> > > (LO/EUS); Radia
> > > > > > > > > Perlman; [email-masked]
> > > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > snip...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > At the minimum we need to ensure that all 
> > > > RBridges have the
> > > > > > > > > > information that would enable them to 
> efficiently and
> > > > > > > > > reliably act as
> > > > > > > > > > an ARP/ND proxy.
> > > > > > > > >
> > > > > > > > > It depends on how you define the requirements 
> of ARP/ND
> > > > > > > > > proxy.  I have seen this general mechanism 
> used in many
> > > > > > > > > contexts... only one of which is covered by 
> an IETF RFC
> > > > > > > > > (AFAIK).  Bridges in their basic definition don't 
> > > > have ARP/ND
> > > > > > > > > proxy.  Only bridges that subsume some type of 
> > IP related
> > > > > > > > > functionality contain these.
> > > > > > > > >
> > > > > > > > > If an RBridge "looks and smells" like a bridge, 
> > > > then there is
> > > > > > > > > natural traffic separation between VLANs, and 
> > this allows
> > > > > > > > > systems companies to view RBridges as "better 
> bridges".
> > > > > > > > >
> > > > > > > > > JR
> > > > > > > > >
> > > > > > > > >
> > > > > > > > 
> > > > > > > > The reason RBridges are "better bridges" is that they
> > > > > > > > deal with the issues of large subnets far better than
> > > > > > > > bridges do.
> > > > > > > > 
> > > > > > > > Efficient distribution of ARP/ND information is also
> > > > > > > > an issue where a "better bridge" is needed to scale
> > > > > > > > to larger subnets efficiently.
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 08:26:12 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 7416

Sorry I must have mis-stated my point.  It seems that if ARP is the bulk
of your multicast traffic, then optimizing it doesn't seem like much
return-on-investment.  If other multicast comprises the bulk, then
optimizing ARP doesn't seem to provide much return-on-investment.

JR

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 7:38 AM
> To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> 
> It doesn't.  However, you mentioned IP multicast as another area of
> concern... 
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 10:36 AM
> > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > Importance: High
> > 
> > 
> > Why does ARP/ND equate to IP multicast optimization?
> > 
> > JR
> >  
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > Sent: Wednesday, April 04, 2007 7:34 AM
> > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> > > Perlman; [email-masked]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals)
> > > 
> > > JR,
> > > 
> > > 	I agree.  However, I believe we (as a working group) have
> > > already
> > > agreed that the IP multicast optimization is essential.  
> > > Also, it is my
> > > point (and it is certainly arguable) that perhaps TRILL 
> > should not be
> > > targetting the general applications of L2 where other forms 
> > > of L2 bcast
> > > are likely to be a significant factor - but should instead 
> > > focus on the
> > > applications of L2 specific to IP only (or IP dominant) networks.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson  
> > > 
> > > > -----Original Message-----
> > > > From: J. R. Rivers [mailto:[email-masked]] 
> > > > Sent: Wednesday, April 04, 2007 9:58 AM
> > > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > > > Perlman; [email-masked]
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals)
> > > > Importance: High
> > > > 
> > > > 
> > > > It seems that if ARP is the bulk of your 
> > > broadcast/multicast, then you
> > > > don't really need a very efficient broadcast/multicast 
> > > > mechanism.  Some
> > > > networks can be characterized as you've stated; 
> however, there are
> > > > others that use L2/IP multicast in a substantial fashion.
> > > > 
> > > > JR
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> > > > > Perlman; [email-masked]
> > > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > alternative proposals)
> > > > > 
> > > > > Silvano,
> > > > > 
> > > > > 	Where IP (v4 or v6) is the exclusive higher 
> > layer in a specific
> > > > > network deployment, it is likely that ARP is one of the 
> > > most common 
> > > > > forms of broadcast traffic that may occur.  As we've 
> > > > > previously agreed 
> > > > > that broadcast traffic is of particular concern in TRILL, the 
> > > > > potential
> > > > > to drastically reduce (or possibly eliminate) common 
> > > > broadcast traffic
> > > > > should be considered a worth-while objective.
> > > > > 
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Silvano Gai [mailto:[email-masked]] 
> > > > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray 
> (LO/EUS); Radia 
> > > > > > Perlman; [email-masked]
> > > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > > alternative proposals)
> > > > > > Importance: High
> > > > > > 
> > > > > > 
> > > > > > Do we have any quantitatively data about the need of 
> > > ARP/ND proxy?
> > > > > > 
> > > > > > With an ARP cache of 30 minutes, typical in hosts 
> today, even 
> > > > > > with a 100
> > > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not 
> > > > > > all the hosts
> > > > > > talk with each other, it is more typically like 5 ARP/sec.
> > > > > > 
> > > > > > The ARP/ND cache on the RBridge must be significantly 
> > > > > shorter than 30
> > > > > > minutes to not increase the amount of obsolete information.
> > > > > > 
> > > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts 
> > > > > per VLAN?
> > > > > > 
> > > > > > Is this the big optimization for which we care to create 
> > > > > corner cases
> > > > > > and potential incompatibilities?
> > > > > > 
> > > > > > -- Silvano
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); 
> > > > Radia Perlman;
> > > > > > > [email-masked]
> > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > alternative proposals
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray 
> > (LO/EUS); Radia
> > > > > > > > Perlman; [email-masked]
> > > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals
> > > > > > > >
> > > > > > > >
> > > > > > > > snip...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > At the minimum we need to ensure that all 
> > > RBridges have the
> > > > > > > > > information that would enable them to efficiently and
> > > > > > > > reliably act as
> > > > > > > > > an ARP/ND proxy.
> > > > > > > >
> > > > > > > > It depends on how you define the requirements of ARP/ND
> > > > > > > > proxy.  I have seen this general mechanism used in many
> > > > > > > > contexts... only one of which is covered by an IETF RFC
> > > > > > > > (AFAIK).  Bridges in their basic definition don't 
> > > have ARP/ND
> > > > > > > > proxy.  Only bridges that subsume some type of 
> IP related
> > > > > > > > functionality contain these.
> > > > > > > >
> > > > > > > > If an RBridge "looks and smells" like a bridge, 
> > > then there is
> > > > > > > > natural traffic separation between VLANs, and 
> this allows
> > > > > > > > systems companies to view RBridges as "better bridges".
> > > > > > > >
> > > > > > > > JR
> > > > > > > >
> > > > > > > >
> > > > > > > 
> > > > > > > The reason RBridges are "better bridges" is that they
> > > > > > > deal with the issues of large subnets far better than
> > > > > > > bridges do.
> > > > > > > 
> > > > > > > Efficient distribution of ARP/ND information is also
> > > > > > > an issue where a "better bridge" is needed to scale
> > > > > > > to larger subnets efficiently.
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 09:38:17 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 6428

It doesn't.  However, you mentioned IP multicast as another area of
concern... 

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 10:36 AM
> To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> Importance: High
> 
> 
> Why does ARP/ND equate to IP multicast optimization?
> 
> JR
>  
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 7:34 AM
> > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > 
> > JR,
> > 
> > 	I agree.  However, I believe we (as a working group) have
> > already
> > agreed that the IP multicast optimization is essential.  
> > Also, it is my
> > point (and it is certainly arguable) that perhaps TRILL 
> should not be
> > targetting the general applications of L2 where other forms 
> > of L2 bcast
> > are likely to be a significant factor - but should instead 
> > focus on the
> > applications of L2 specific to IP only (or IP dominant) networks.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:[email-masked]] 
> > > Sent: Wednesday, April 04, 2007 9:58 AM
> > > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > > Perlman; [email-masked]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals)
> > > Importance: High
> > > 
> > > 
> > > It seems that if ARP is the bulk of your 
> > broadcast/multicast, then you
> > > don't really need a very efficient broadcast/multicast 
> > > mechanism.  Some
> > > networks can be characterized as you've stated; however, there are
> > > others that use L2/IP multicast in a substantial fashion.
> > > 
> > > JR
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> > > > Perlman; [email-masked]
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals)
> > > > 
> > > > Silvano,
> > > > 
> > > > 	Where IP (v4 or v6) is the exclusive higher 
> layer in a specific
> > > > network deployment, it is likely that ARP is one of the 
> > most common 
> > > > forms of broadcast traffic that may occur.  As we've 
> > > > previously agreed 
> > > > that broadcast traffic is of particular concern in TRILL, the 
> > > > potential
> > > > to drastically reduce (or possibly eliminate) common 
> > > broadcast traffic
> > > > should be considered a worth-while objective.
> > > > 
> > > > --
> > > > Eric Gray
> > > > Principal Engineer
> > > > Ericsson  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Silvano Gai [mailto:[email-masked]] 
> > > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> > > > > Perlman; [email-masked]
> > > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > > alternative proposals)
> > > > > Importance: High
> > > > > 
> > > > > 
> > > > > Do we have any quantitatively data about the need of 
> > ARP/ND proxy?
> > > > > 
> > > > > With an ARP cache of 30 minutes, typical in hosts today, even 
> > > > > with a 100
> > > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not 
> > > > > all the hosts
> > > > > talk with each other, it is more typically like 5 ARP/sec.
> > > > > 
> > > > > The ARP/ND cache on the RBridge must be significantly 
> > > > shorter than 30
> > > > > minutes to not increase the amount of obsolete information.
> > > > > 
> > > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts 
> > > > per VLAN?
> > > > > 
> > > > > Is this the big optimization for which we care to create 
> > > > corner cases
> > > > > and potential incompatibilities?
> > > > > 
> > > > > -- Silvano
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); 
> > > Radia Perlman;
> > > > > > [email-masked]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray 
> (LO/EUS); Radia
> > > > > > > Perlman; [email-masked]
> > > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> > alternative proposals
> > > > > > >
> > > > > > >
> > > > > > > snip...
> > > > > > > >
> > > > > > > >
> > > > > > > > At the minimum we need to ensure that all 
> > RBridges have the
> > > > > > > > information that would enable them to efficiently and
> > > > > > > reliably act as
> > > > > > > > an ARP/ND proxy.
> > > > > > >
> > > > > > > It depends on how you define the requirements of ARP/ND
> > > > > > > proxy.  I have seen this general mechanism used in many
> > > > > > > contexts... only one of which is covered by an IETF RFC
> > > > > > > (AFAIK).  Bridges in their basic definition don't 
> > have ARP/ND
> > > > > > > proxy.  Only bridges that subsume some type of IP related
> > > > > > > functionality contain these.
> > > > > > >
> > > > > > > If an RBridge "looks and smells" like a bridge, 
> > then there is
> > > > > > > natural traffic separation between VLANs, and this allows
> > > > > > > systems companies to view RBridges as "better bridges".
> > > > > > >
> > > > > > > JR
> > > > > > >
> > > > > > >
> > > > > > 
> > > > > > The reason RBridges are "better bridges" is that they
> > > > > > deal with the issues of large subnets far better than
> > > > > > bridges do.
> > > > > > 
> > > > > > Efficient distribution of ARP/ND information is also
> > > > > > an issue where a "better bridge" is needed to scale
> > > > > > to larger subnets efficiently.
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 07:36:01 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 5616

Why does ARP/ND equate to IP multicast optimization?

JR

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 7:34 AM
> To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> 
> JR,
> 
> 	I agree.  However, I believe we (as a working group) have
> already
> agreed that the IP multicast optimization is essential.  
> Also, it is my
> point (and it is certainly arguable) that perhaps TRILL should not be
> targetting the general applications of L2 where other forms 
> of L2 bcast
> are likely to be a significant factor - but should instead 
> focus on the
> applications of L2 specific to IP only (or IP dominant) networks.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 9:58 AM
> > To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > Importance: High
> > 
> > 
> > It seems that if ARP is the bulk of your 
> broadcast/multicast, then you
> > don't really need a very efficient broadcast/multicast 
> > mechanism.  Some
> > networks can be characterized as you've stated; however, there are
> > others that use L2/IP multicast in a substantial fashion.
> > 
> > JR
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > > Sent: Wednesday, April 04, 2007 6:14 AM
> > > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> > > Perlman; [email-masked]
> > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals)
> > > 
> > > Silvano,
> > > 
> > > 	Where IP (v4 or v6) is the exclusive higher layer in a specific
> > > network deployment, it is likely that ARP is one of the 
> most common 
> > > forms of broadcast traffic that may occur.  As we've 
> > > previously agreed 
> > > that broadcast traffic is of particular concern in TRILL, the 
> > > potential
> > > to drastically reduce (or possibly eliminate) common 
> > broadcast traffic
> > > should be considered a worth-while objective.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson  
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [mailto:[email-masked]] 
> > > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> > > > Perlman; [email-masked]
> > > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > > alternative proposals)
> > > > Importance: High
> > > > 
> > > > 
> > > > Do we have any quantitatively data about the need of 
> ARP/ND proxy?
> > > > 
> > > > With an ARP cache of 30 minutes, typical in hosts today, even 
> > > > with a 100
> > > > K hosts in a VLAN we get at most 55 ARP seconds. Since not 
> > > > all the hosts
> > > > talk with each other, it is more typically like 5 ARP/sec.
> > > > 
> > > > The ARP/ND cache on the RBridge must be significantly 
> > > shorter than 30
> > > > minutes to not increase the amount of obsolete information.
> > > > 
> > > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts 
> > > per VLAN?
> > > > 
> > > > Is this the big optimization for which we care to create 
> > > corner cases
> > > > and potential incompatibilities?
> > > > 
> > > > -- Silvano
> > > > 
> > > > > -----Original Message-----
> > > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); 
> > Radia Perlman;
> > > > > [email-masked]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > > 
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia
> > > > > > Perlman; [email-masked]
> > > > > > Subject: RE: [rbridge] Two "shared VLAN" 
> alternative proposals
> > > > > >
> > > > > >
> > > > > > snip...
> > > > > > >
> > > > > > >
> > > > > > > At the minimum we need to ensure that all 
> RBridges have the
> > > > > > > information that would enable them to efficiently and
> > > > > > reliably act as
> > > > > > > an ARP/ND proxy.
> > > > > >
> > > > > > It depends on how you define the requirements of ARP/ND
> > > > > > proxy.  I have seen this general mechanism used in many
> > > > > > contexts... only one of which is covered by an IETF RFC
> > > > > > (AFAIK).  Bridges in their basic definition don't 
> have ARP/ND
> > > > > > proxy.  Only bridges that subsume some type of IP related
> > > > > > functionality contain these.
> > > > > >
> > > > > > If an RBridge "looks and smells" like a bridge, 
> then there is
> > > > > > natural traffic separation between VLANs, and this allows
> > > > > > systems companies to view RBridges as "better bridges".
> > > > > >
> > > > > > JR
> > > > > >
> > > > > >
> > > > > 
> > > > > The reason RBridges are "better bridges" is that they
> > > > > deal with the issues of large subnets far better than
> > > > > bridges do.
> > > > > 
> > > > > Efficient distribution of ARP/ND information is also
> > > > > an issue where a "better bridge" is needed to scale
> > > > > to larger subnets efficiently.
> > > > 
> > > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 09:33:46 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 4932

JR,

	I agree.  However, I believe we (as a working group) have
already
agreed that the IP multicast optimization is essential.  Also, it is my
point (and it is certainly arguable) that perhaps TRILL should not be
targetting the general applications of L2 where other forms of L2 bcast
are likely to be a significant factor - but should instead focus on the
applications of L2 specific to IP only (or IP dominant) networks.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 9:58 AM
> To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> Importance: High
> 
> 
> It seems that if ARP is the bulk of your broadcast/multicast, then you
> don't really need a very efficient broadcast/multicast 
> mechanism.  Some
> networks can be characterized as you've stated; however, there are
> others that use L2/IP multicast in a substantial fashion.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 6:14 AM
> > To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> > Perlman; [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > 
> > Silvano,
> > 
> > 	Where IP (v4 or v6) is the exclusive higher layer in a specific
> > network deployment, it is likely that ARP is one of the most common 
> > forms of broadcast traffic that may occur.  As we've 
> > previously agreed 
> > that broadcast traffic is of particular concern in TRILL, the 
> > potential
> > to drastically reduce (or possibly eliminate) common 
> broadcast traffic
> > should be considered a worth-while objective.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[email-masked]] 
> > > Sent: Tuesday, April 03, 2007 7:22 PM
> > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> > > Perlman; [email-masked]
> > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > > alternative proposals)
> > > Importance: High
> > > 
> > > 
> > > Do we have any quantitatively data about the need of ARP/ND proxy?
> > > 
> > > With an ARP cache of 30 minutes, typical in hosts today, even 
> > > with a 100
> > > K hosts in a VLAN we get at most 55 ARP seconds. Since not 
> > > all the hosts
> > > talk with each other, it is more typically like 5 ARP/sec.
> > > 
> > > The ARP/ND cache on the RBridge must be significantly 
> > shorter than 30
> > > minutes to not increase the amount of obsolete information.
> > > 
> > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts 
> > per VLAN?
> > > 
> > > Is this the big optimization for which we care to create 
> > corner cases
> > > and potential incompatibilities?
> > > 
> > > -- Silvano
> > > 
> > > > -----Original Message-----
> > > > From: Caitlin Bestler [mailto:[email-masked]]
> > > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); 
> Radia Perlman;
> > > > [email-masked]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia
> > > > > Perlman; [email-masked]
> > > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > > >
> > > > >
> > > > > snip...
> > > > > >
> > > > > >
> > > > > > At the minimum we need to ensure that all RBridges have the
> > > > > > information that would enable them to efficiently and
> > > > > reliably act as
> > > > > > an ARP/ND proxy.
> > > > >
> > > > > It depends on how you define the requirements of ARP/ND
> > > > > proxy.  I have seen this general mechanism used in many
> > > > > contexts... only one of which is covered by an IETF RFC
> > > > > (AFAIK).  Bridges in their basic definition don't have ARP/ND
> > > > > proxy.  Only bridges that subsume some type of IP related
> > > > > functionality contain these.
> > > > >
> > > > > If an RBridge "looks and smells" like a bridge, then there is
> > > > > natural traffic separation between VLANs, and this allows
> > > > > systems companies to view RBridges as "better bridges".
> > > > >
> > > > > JR
> > > > >
> > > > >
> > > > 
> > > > The reason RBridges are "better bridges" is that they
> > > > deal with the issues of large subnets far better than
> > > > bridges do.
> > > > 
> > > > Efficient distribution of ARP/ND information is also
> > > > an issue where a "better bridge" is needed to scale
> > > > to larger subnets efficiently.
> > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 06:57:48 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 3895

It seems that if ARP is the bulk of your broadcast/multicast, then you
don't really need a very efficient broadcast/multicast mechanism.  Some
networks can be characterized as you've stated; however, there are
others that use L2/IP multicast in a substantial fashion.

JR

> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 6:14 AM
> To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> 
> Silvano,
> 
> 	Where IP (v4 or v6) is the exclusive higher layer in a specific
> network deployment, it is likely that ARP is one of the most common 
> forms of broadcast traffic that may occur.  As we've 
> previously agreed 
> that broadcast traffic is of particular concern in TRILL, the 
> potential
> to drastically reduce (or possibly eliminate) common broadcast traffic
> should be considered a worth-while objective.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[email-masked]] 
> > Sent: Tuesday, April 03, 2007 7:22 PM
> > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> > Perlman; [email-masked]
> > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > Importance: High
> > 
> > 
> > Do we have any quantitatively data about the need of ARP/ND proxy?
> > 
> > With an ARP cache of 30 minutes, typical in hosts today, even 
> > with a 100
> > K hosts in a VLAN we get at most 55 ARP seconds. Since not 
> > all the hosts
> > talk with each other, it is more typically like 5 ARP/sec.
> > 
> > The ARP/ND cache on the RBridge must be significantly 
> shorter than 30
> > minutes to not increase the amount of obsolete information.
> > 
> > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts 
> per VLAN?
> > 
> > Is this the big optimization for which we care to create 
> corner cases
> > and potential incompatibilities?
> > 
> > -- Silvano
> > 
> > > -----Original Message-----
> > > From: Caitlin Bestler [mailto:[email-masked]]
> > > Sent: Tuesday, April 03, 2007 3:38 PM
> > > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman;
> > > [email-masked]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: J. R. Rivers [mailto:[email-masked]]
> > > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia
> > > > Perlman; [email-masked]
> > > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > >
> > > >
> > > > snip...
> > > > >
> > > > >
> > > > > At the minimum we need to ensure that all RBridges have the
> > > > > information that would enable them to efficiently and
> > > > reliably act as
> > > > > an ARP/ND proxy.
> > > >
> > > > It depends on how you define the requirements of ARP/ND
> > > > proxy.  I have seen this general mechanism used in many
> > > > contexts... only one of which is covered by an IETF RFC
> > > > (AFAIK).  Bridges in their basic definition don't have ARP/ND
> > > > proxy.  Only bridges that subsume some type of IP related
> > > > functionality contain these.
> > > >
> > > > If an RBridge "looks and smells" like a bridge, then there is
> > > > natural traffic separation between VLANs, and this allows
> > > > systems companies to view RBridges as "better bridges".
> > > >
> > > > JR
> > > >
> > > >
> > > 
> > > The reason RBridges are "better bridges" is that they
> > > deal with the issues of large subnets far better than
> > > bridges do.
> > > 
> > > Efficient distribution of ARP/ND information is also
> > > an issue where a "better bridge" is needed to scale
> > > to larger subnets efficiently.
> > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 08:13:37 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 3114

Silvano,

	Where IP (v4 or v6) is the exclusive higher layer in a specific
network deployment, it is likely that ARP is one of the most common 
forms of broadcast traffic that may occur.  As we've previously agreed 
that broadcast traffic is of particular concern in TRILL, the potential
to drastically reduce (or possibly eliminate) common broadcast traffic
should be considered a worth-while objective.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 7:22 PM
> To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> Importance: High
> 
> 
> Do we have any quantitatively data about the need of ARP/ND proxy?
> 
> With an ARP cache of 30 minutes, typical in hosts today, even 
> with a 100
> K hosts in a VLAN we get at most 55 ARP seconds. Since not 
> all the hosts
> talk with each other, it is more typically like 5 ARP/sec.
> 
> The ARP/ND cache on the RBridge must be significantly shorter than 30
> minutes to not increase the amount of obsolete information.
> 
> Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN?
> 
> Is this the big optimization for which we care to create corner cases
> and potential incompatibilities?
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Caitlin Bestler [mailto:[email-masked]]
> > Sent: Tuesday, April 03, 2007 3:38 PM
> > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman;
> > [email-masked]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:[email-masked]]
> > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia
> > > Perlman; [email-masked]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > >
> > >
> > > snip...
> > > >
> > > >
> > > > At the minimum we need to ensure that all RBridges have the
> > > > information that would enable them to efficiently and
> > > reliably act as
> > > > an ARP/ND proxy.
> > >
> > > It depends on how you define the requirements of ARP/ND
> > > proxy.  I have seen this general mechanism used in many
> > > contexts... only one of which is covered by an IETF RFC
> > > (AFAIK).  Bridges in their basic definition don't have ARP/ND
> > > proxy.  Only bridges that subsume some type of IP related
> > > functionality contain these.
> > >
> > > If an RBridge "looks and smells" like a bridge, then there is
> > > natural traffic separation between VLANs, and this allows
> > > systems companies to view RBridges as "better bridges".
> > >
> > > JR
> > >
> > >
> > 
> > The reason RBridges are "better bridges" is that they
> > deal with the issues of large subnets far better than
> > bridges do.
> > 
> > Efficient distribution of ARP/ND information is also
> > an issue where a "better bridge" is needed to scale
> > to larger subnets efficiently.
> 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 08:06:14 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 2663

Silvano,

	It's possible that Caitlin made a mis-statement.  The impact of
a larger propagation radius is in the number of branches that usually
is implied by such an increase.  More branches, more risks of looping 
broadcast and/or multicast traffic, hence more impetus to reduce both.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 7:48 PM
> To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> Importance: High
> 
> 
> I am surprised,
> in ARP the dominant time is the software processing on the two nodes
> that goes through a classical interrupt moderation technique 
> and exceed
> multiple milliseconds. The Rbridge latency is probably 1 to 10
> microseconds, so even if you have 100 hops, it is still negligible.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: Caitlin Bestler [mailto:[email-masked]]
> > Sent: Tuesday, April 03, 2007 4:37 PM
> > To: Silvano Gai; J. R. Rivers; Eric Gray (LO/EUS); Radia Perlman;
> > [email-masked]
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative
> > proposals)
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Sent: Tuesday, April 03, 2007 4:22 PM
> > > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia
> > > Perlman; [email-masked]
> > > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > alternative proposals)
> > >
> > >
> > > Do we have any quantitatively data about the need of ARP/ND proxy?
> > >
> > > With an ARP cache of 30 minutes, typical in hosts today, even
> > > with a 100 K hosts in a VLAN we get at most 55 ARP seconds.
> > > Since not all the hosts talk with each other, it is more
> > > typically like 5 ARP/sec.
> > >
> > > The ARP/ND cache on the RBridge must be significantly shorter
> > > than 30 minutes to not increase the amount of obsolete 
> information.
> > >
> > > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per
> VLAN?
> > >
> > > Is this the big optimization for which we care to create
> > > corner cases and potential incompatibilities?
> > >
> > 
> > The ARP/ND transaction rate is not the critical issue.
> > 
> > The more critical issue is the end-to-end latency of a transaction
> > that requires doing an ARP/ND first. As the subnet gets larger,
> > and the number of "L2 Hops" increases, that answer gets worse
> > unless you implement a distributed ARP/ND proxy service.
> > 
> > 
> > 
> 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 07:16:05 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2366

And you would be correct.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 6:47 PM
> To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> I would have thought that RBridges are "better bridges" because they
> allow multi-pathing at layer 2 creating significantly more available
> bandwidth and with a deployment cost/complexity relatively close to
> 802.1 bridges.
> 
> JR
> 
> > -----Original Message-----
> > From: Caitlin Bestler [mailto:[email-masked]] 
> > Sent: Tuesday, April 03, 2007 3:38 PM
> > To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia 
> > Perlman; [email-masked]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:[email-masked]] 
> > > Sent: Tuesday, April 03, 2007 3:31 PM
> > > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> > > Perlman; [email-masked]
> > > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > > 
> > > 
> > > snip... 
> > > > 
> > > > 
> > > > At the minimum we need to ensure that all RBridges have the 
> > > > information that would enable them to efficiently and 
> > > reliably act as 
> > > > an ARP/ND proxy.
> > > 
> > > It depends on how you define the requirements of ARP/ND 
> > > proxy.  I have seen this general mechanism used in many 
> > > contexts... only one of which is covered by an IETF RFC 
> > > (AFAIK).  Bridges in their basic definition don't have ARP/ND 
> > > proxy.  Only bridges that subsume some type of IP related 
> > > functionality contain these.
> > > 
> > > If an RBridge "looks and smells" like a bridge, then there is 
> > > natural traffic separation between VLANs, and this allows 
> > > systems companies to view RBridges as "better bridges". 
> > > 
> > > JR
> > > 
> > > 
> > 
> > The reason RBridges are "better bridges" is that they
> > deal with the issues of large subnets far better than
> > bridges do.
> > 
> > Efficient distribution of ARP/ND information is also
> > an issue where a "better bridge" is needed to scale
> > to larger subnets efficiently.
> > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 07:14:59 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2762

JR,

	I agree that "natural traffic separation between VLANs" is a 
requirement.

	This, however, does not mean that an ARP/ND optimization within
the separate VLANs is in any way unnatural.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 6:31 PM
> To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
> 
> snip... 
> > 
> > 
> > At the minimum we need to ensure that all RBridges have 
> > the information that would enable them to efficiently
> > and reliably act as an ARP/ND proxy.
> 
> It depends on how you define the requirements of ARP/ND proxy.  I have
> seen this general mechanism used in many contexts... only one of which
> is covered by an IETF RFC (AFAIK).  Bridges in their basic definition
> don't have ARP/ND proxy.  Only bridges that subsume some type of IP
> related functionality contain these.
> 
> If an RBridge "looks and smells" like a bridge, then there is natural
> traffic separation between VLANs, and this allows systems companies to
> view RBridges as "better bridges". 
> 
> JR
> 
> 
> > 
> > By the very nature of a proxy it is hard to state that
> > it MUST do anything. Any proxy will have a limit on the
> > information that it can cache, and can therefore fail
> > to act as a proxy on some occassions. So anything that
> > is a proxy function strikes me as inherently a SHOULD
> > at most.
> > 
> > That said, all of the arguments on why an RBridge is
> > valuable also imply that proxying ARP/ND is a vital
> > part of the RBridge's functionality.
> > 
> > In particular, I believe that the trends towards
> > server virtualization and physically more compact
> > servers both will lead to an increase in the logical
> > size of IP subnets. That makes the role of ARP/ND
> > proxying more important, and makes it all the more
> > desirable not to routinely run these queries from
> > one end of the CRED to the other important.
> > 
> > In a virtualization context I also think it makes
> > for more sense for each Virtual Machine to be able
> > to obtain the ARP/ND info for host X when it needs
> > it without having *each* of them having to do an
> > end-to-end query or forcing each of them to hear
> > every ARP response so that each virtual machine
> > can maintain its own ARP table in parallel.
> > The RBridge is simply in the ideal position to
> > perform a highly optimized ARP/ND proxy role.
> > 
> > 
> > 
> > [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 4 Apr 2007 07:11:46 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 4109

I agree with all of the reasons Caitlin states below and would add two
more reasons for including ARP/ND as at least a capability:

1) One particular attribute of this work is the use of TTL as a loop
   mitigation technique; an obvious aspect of this approach is its
   total inadequacy in addressing loops in pt-2-mp traffic - hence it
   is imperative that anything that can be done to reduce both the 
   absolute quantity, and the number of paths involved, in pt-2-mp
   traffic is considered to be very important.
2) The TRILL solution - coming as it does from the IETF community -
   needs to be specific to applications of IP (v4 or v6) and therefore
   needs to consider optimization for such applications of primary
   concern.

I would further clarify one of Caitlin's points by saying that it is
pointless to consider defining ARP/ND for later inclusion if we have
not included the basic capabilities in the protocol.  Specifically,
if we have not included the data structures and behaviors necessary
to ensure the distribution of information required to support ARP/ND,
then subsequent work to add these basic capabilities will introduce
potential compatibility issues and limitations.

What all of this seems to mean is that we should define how ARP/ND 
information could be distributed aqnd what information we know has
to be included.  Then we may leave the specification of what to do
with that information to a later date.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 6:06 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman; [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> Importance: High
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Silvano Gai
> > Sent: Tuesday, April 03, 2007 8:16 AM
> > To: Eric Gray (LO/EUS); Radia Perlman; [email-masked]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > Eric,
> > 
> > I will go one step further and say that the basic TRILL 
> > protocol should not specify an ARP/ND proxy function.
> > 
> > As the discussion as pointed out, ARP/ND proxy is more a 
> > product feature that depends on how the box are packaged. 
> > IMHO RBridges will be packaged with additional router, NAT, 
> > firewall functionalities. If and where proxy ARP will be 
> > implemented will vary.
> > 
> > After the last call on the base protocol, we can always 
> > resume the work and deal with Proxy ARP/ND in a separate document.
> > 
> > -- Silvano
> > 
> 
> At the minimum we need to ensure that all RBridges have 
> the information that would enable them to efficiently
> and reliably act as an ARP/ND proxy.
> 
> By the very nature of a proxy it is hard to state that
> it MUST do anything. Any proxy will have a limit on the
> information that it can cache, and can therefore fail
> to act as a proxy on some occassions. So anything that
> is a proxy function strikes me as inherently a SHOULD
> at most.
> 
> That said, all of the arguments on why an RBridge is
> valuable also imply that proxying ARP/ND is a vital
> part of the RBridge's functionality.
> 
> In particular, I believe that the trends towards
> server virtualization and physically more compact
> servers both will lead to an increase in the logical
> size of IP subnets. That makes the role of ARP/ND
> proxying more important, and makes it all the more
> desirable not to routinely run these queries from
> one end of the CRED to the other important.
> 
> In a virtualization context I also think it makes
> for more sense for each Virtual Machine to be able
> to obtain the ARP/ND info for host X when it needs
> it without having *each* of them having to do an
> end-to-end query or forcing each of them to hear
> every ARP response so that each virtual machine
> can maintain its own ARP table in parallel.
> The RBridge is simply in the ideal position to
> perform a highly optimized ARP/ND proxy role.
> 
> 
> 

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 16:48:16 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 1890

I am surprised,
in ARP the dominant time is the software processing on the two nodes
that goes through a classical interrupt moderation technique and exceed
multiple milliseconds. The Rbridge latency is probably 1 to 10
microseconds, so even if you have 100 hops, it is still negligible.

-- Silvano

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2007 4:37 PM
> To: Silvano Gai; J. R. Rivers; Eric Gray (LO/EUS); Radia Perlman;
> [email-masked]
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" alternative
> proposals)
> 
> 
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[email-masked]]
> > Sent: Tuesday, April 03, 2007 4:22 PM
> > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia
> > Perlman; [email-masked]
> > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > alternative proposals)
> >
> >
> > Do we have any quantitatively data about the need of ARP/ND proxy?
> >
> > With an ARP cache of 30 minutes, typical in hosts today, even
> > with a 100 K hosts in a VLAN we get at most 55 ARP seconds.
> > Since not all the hosts talk with each other, it is more
> > typically like 5 ARP/sec.
> >
> > The ARP/ND cache on the RBridge must be significantly shorter
> > than 30 minutes to not increase the amount of obsolete information.
> >
> > Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per
VLAN?
> >
> > Is this the big optimization for which we care to create
> > corner cases and potential incompatibilities?
> >
> 
> The ARP/ND transaction rate is not the critical issue.
> 
> The more critical issue is the end-to-end latency of a transaction
> that requires doing an ARP/ND first. As the subnet gets larger,
> and the number of "L2 Hops" increases, that answer gets worse
> unless you implement a distributed ARP/ND proxy service.
> 
> 
> 

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 16:36:47 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 1232

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 4:22 PM
> To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> 
> 
> Do we have any quantitatively data about the need of ARP/ND proxy?
> 
> With an ARP cache of 30 minutes, typical in hosts today, even 
> with a 100 K hosts in a VLAN we get at most 55 ARP seconds. 
> Since not all the hosts talk with each other, it is more 
> typically like 5 ARP/sec.
> 
> The ARP/ND cache on the RBridge must be significantly shorter 
> than 30 minutes to not increase the amount of obsolete information.
> 
> Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN?
> 
> Is this the big optimization for which we care to create 
> corner cases and potential incompatibilities?
> 

The ARP/ND transaction rate is not the critical issue.

The more critical issue is the end-to-end latency of a transaction
that requires doing an ARP/ND first. As the subnet gets larger,
and the number of "L2 Hops" increases, that answer gets worse
unless you implement a distributed ARP/ND proxy service.

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 16:22:23 -0700
From: "Silvano Gai" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
Status: RO
Content-Length: 2207

Do we have any quantitatively data about the need of ARP/ND proxy?

With an ARP cache of 30 minutes, typical in hosts today, even with a 100
K hosts in a VLAN we get at most 55 ARP seconds. Since not all the hosts
talk with each other, it is more typically like 5 ARP/sec.

The ARP/ND cache on the RBridge must be significantly shorter than 30
minutes to not increase the amount of obsolete information.

Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN?

Is this the big optimization for which we care to create corner cases
and potential incompatibilities?

-- Silvano

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2007 3:38 PM
> To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman;
> [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:[email-masked]]
> > Sent: Tuesday, April 03, 2007 3:31 PM
> > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia
> > Perlman; [email-masked]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> >
> >
> > snip...
> > >
> > >
> > > At the minimum we need to ensure that all RBridges have the
> > > information that would enable them to efficiently and
> > reliably act as
> > > an ARP/ND proxy.
> >
> > It depends on how you define the requirements of ARP/ND
> > proxy.  I have seen this general mechanism used in many
> > contexts... only one of which is covered by an IETF RFC
> > (AFAIK).  Bridges in their basic definition don't have ARP/ND
> > proxy.  Only bridges that subsume some type of IP related
> > functionality contain these.
> >
> > If an RBridge "looks and smells" like a bridge, then there is
> > natural traffic separation between VLANs, and this allows
> > systems companies to view RBridges as "better bridges".
> >
> > JR
> >
> >
> 
> The reason RBridges are "better bridges" is that they
> deal with the issues of large subnets far better than
> bridges do.
> 
> Efficient distribution of ARP/ND information is also
> an issue where a "better bridge" is needed to scale
> to larger subnets efficiently.

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 15:46:42 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 1872

I would have thought that RBridges are "better bridges" because they
allow multi-pathing at layer 2 creating significantly more available
bandwidth and with a deployment cost/complexity relatively close to
802.1 bridges.

JR

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 3:38 PM
> To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
>  
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:[email-masked]] 
> > Sent: Tuesday, April 03, 2007 3:31 PM
> > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> > Perlman; [email-masked]
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > 
> > snip... 
> > > 
> > > 
> > > At the minimum we need to ensure that all RBridges have the 
> > > information that would enable them to efficiently and 
> > reliably act as 
> > > an ARP/ND proxy.
> > 
> > It depends on how you define the requirements of ARP/ND 
> > proxy.  I have seen this general mechanism used in many 
> > contexts... only one of which is covered by an IETF RFC 
> > (AFAIK).  Bridges in their basic definition don't have ARP/ND 
> > proxy.  Only bridges that subsume some type of IP related 
> > functionality contain these.
> > 
> > If an RBridge "looks and smells" like a bridge, then there is 
> > natural traffic separation between VLANs, and this allows 
> > systems companies to view RBridges as "better bridges". 
> > 
> > JR
> > 
> > 
> 
> The reason RBridges are "better bridges" is that they
> deal with the issues of large subnets far better than
> bridges do.
> 
> Efficient distribution of ARP/ND information is also
> an issue where a "better bridge" is needed to scale
> to larger subnets efficiently.
> 
> 

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 15:38:00 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 1277

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 3:31 PM
> To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia 
> Perlman; [email-masked]
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> snip... 
> > 
> > 
> > At the minimum we need to ensure that all RBridges have the 
> > information that would enable them to efficiently and 
> reliably act as 
> > an ARP/ND proxy.
> 
> It depends on how you define the requirements of ARP/ND 
> proxy.  I have seen this general mechanism used in many 
> contexts... only one of which is covered by an IETF RFC 
> (AFAIK).  Bridges in their basic definition don't have ARP/ND 
> proxy.  Only bridges that subsume some type of IP related 
> functionality contain these.
> 
> If an RBridge "looks and smells" like a bridge, then there is 
> natural traffic separation between VLANs, and this allows 
> systems companies to view RBridges as "better bridges". 
> 
> JR
> 
> 

The reason RBridges are "better bridges" is that they
deal with the issues of large subnets far better than
bridges do.

Efficient distribution of ARP/ND information is also
an issue where a "better bridge" is needed to scale
to larger subnets efficiently.

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 15:31:18 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2101

snip... 
> 
> 
> At the minimum we need to ensure that all RBridges have 
> the information that would enable them to efficiently
> and reliably act as an ARP/ND proxy.

It depends on how you define the requirements of ARP/ND proxy.  I have
seen this general mechanism used in many contexts... only one of which
is covered by an IETF RFC (AFAIK).  Bridges in their basic definition
don't have ARP/ND proxy.  Only bridges that subsume some type of IP
related functionality contain these.

If an RBridge "looks and smells" like a bridge, then there is natural
traffic separation between VLANs, and this allows systems companies to
view RBridges as "better bridges". 

JR

> 
> By the very nature of a proxy it is hard to state that
> it MUST do anything. Any proxy will have a limit on the
> information that it can cache, and can therefore fail
> to act as a proxy on some occassions. So anything that
> is a proxy function strikes me as inherently a SHOULD
> at most.
> 
> That said, all of the arguments on why an RBridge is
> valuable also imply that proxying ARP/ND is a vital
> part of the RBridge's functionality.
> 
> In particular, I believe that the trends towards
> server virtualization and physically more compact
> servers both will lead to an increase in the logical
> size of IP subnets. That makes the role of ARP/ND
> proxying more important, and makes it all the more
> desirable not to routinely run these queries from
> one end of the CRED to the other important.
> 
> In a virtualization context I also think it makes
> for more sense for each Virtual Machine to be able
> to obtain the ARP/ND info for host X when it needs
> it without having *each* of them having to do an
> end-to-end query or forcing each of them to hear
> every ARP response so that each virtual machine
> can maintain its own ARP table in parallel.
> The RBridge is simply in the ideal position to
> perform a highly optimized ARP/ND proxy role.
> 
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 15:06:19 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2213

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Silvano Gai
> Sent: Tuesday, April 03, 2007 8:16 AM
> To: Eric Gray (LO/EUS); Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> Eric,
> 
> I will go one step further and say that the basic TRILL 
> protocol should not specify an ARP/ND proxy function.
> 
> As the discussion as pointed out, ARP/ND proxy is more a 
> product feature that depends on how the box are packaged. 
> IMHO RBridges will be packaged with additional router, NAT, 
> firewall functionalities. If and where proxy ARP will be 
> implemented will vary.
> 
> After the last call on the base protocol, we can always 
> resume the work and deal with Proxy ARP/ND in a separate document.
> 
> -- Silvano
> 

At the minimum we need to ensure that all RBridges have 
the information that would enable them to efficiently
and reliably act as an ARP/ND proxy.

By the very nature of a proxy it is hard to state that
it MUST do anything. Any proxy will have a limit on the
information that it can cache, and can therefore fail
to act as a proxy on some occassions. So anything that
is a proxy function strikes me as inherently a SHOULD
at most.

That said, all of the arguments on why an RBridge is
valuable also imply that proxying ARP/ND is a vital
part of the RBridge's functionality.

In particular, I believe that the trends towards
server virtualization and physically more compact
servers both will lead to an increase in the logical
size of IP subnets. That makes the role of ARP/ND
proxying more important, and makes it all the more
desirable not to routinely run these queries from
one end of the CRED to the other important.

In a virtualization context I also think it makes
for more sense for each Virtual Machine to be able
to obtain the ARP/ND info for host X when it needs
it without having *each* of them having to do an
end-to-end query or forcing each of them to hear
every ARP response so that each virtual machine
can maintain its own ARP table in parallel.
The RBridge is simply in the ideal position to
perform a highly optimized ARP/ND proxy role.

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 16:17:11 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Back to "what is the problem" for SVL/private VLAN/proxyARP stuff
Status: RO
Content-Length: 3342

Radia,

	I don't understand why you're asking this question.

	It is - believe it or not - sufficient to say "we're doing
it that way because we like to, and we can."

	Trying to analyze the specific problem that might, or might
not, be solved by using a specific technology is a mistake when
the technology is being used and nobody is especially interested 
in hearing how their problems might be solved a different way.

	I understand your frustration, but I don't see how getting
a grip on the problem is going to make any difference in what we
end up doing - so why waste our time on that particular subject?

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, April 03, 2007 3:23 PM
> To: [email-masked]
> Subject: [rbridge] Back to "what is the problem" for 
> SVL/private VLAN/proxyARP stuff
> 
> I think the reason we are all so confused is that we 
> (especially me) do 
> not understand what problem
> we are solving. I wrote up in a previous note what I interpreted the 
> problem to be. Let's be
> really tangible about it. I'll start. Correct me if you disagree. But 
> don't use reference to other solutions
> or specs. It *can't* be that hard to actually describe it, 
> rather than 
> reference a spec, and without
> being explicit people won't realize when they are thinking of 
> different 
> things.
> 
> So...is this the problem?
> 
> a) IP address block that has to be subdivided willy-nilly 
> (not in clean 
> sub-prefixes) among 4 customers
> 
> b) desire separation of the customers. I'd like this 
> expanded. Why? Is 
> it because of not wanting
> to bother customer B with A's traffic, or that A doesn't want 
> B to see 
> A's traffic? Or both maybe.
> Do we know what these applications are?
> 
> c) we want these communities to share some service node, say a DHCP 
> server or an IP router
> 
> d) we don't want modify the IP router to do anything special 
> (I suspect 
> this is not really true, and that
> the solutions people have in mind do require the IP router to 
> know about 
> this), or not much special
> 
> e) (I'm throwing this one in). We don't want to have to configure 
> anything (RBridges or IP routers) to know
> static mapping of IP addresses or MAC addresses to VLANs. The only 
> configuration will be that an
> RBridge (or bridge) will be configured to say "this set of 
> ports of mine 
> are VLAN A, this set are VLAN B, ..."
> and it's by the tagging of packets transmitted from the port 
> that other 
> nodes learn which MAC addresses
> (or which IP addresses) are in which VLAN
> 
> f) we want an IP endnode E_a in VLAN A to talk to an IP node 
> E_b in VLAN 
> B by being forwarded through the IP router. E_a and E_b are 
> vanilla IP 
> nodes and think they should be talking directly since they 
> are in the same
> IP address block.
> 
> g) maybe there are applications other than IP that want to have some 
> sort of service node see all
> the traffic from all the VLANs, and be able to talk to all the VLANs, 
> but not have the VLANs talk to each
> other. Is this true?
> 
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 16:03:29 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2149

Caitlin,

	I think this is incorrect.  There is little reason to have VLAN 
separation if you are planning to share all information irrespective
of VLAN membership.

	Plus, the example you seem to be referring to does not
necessarily
require the level of information sharing you assume.  There is nothing 
intrinsic in the fact that a IP address is discovered on VLAN B when it 
was earlier discovered on VLAN A that would indicate that the host has
necessarily moved from one to the other.  This could only happen in the
shared IP address space case, but it could happen either because a host 
moves, or because it has presence in both VLANs (as might be the case 
if it was a server, for example).

	Hence I fail to see how it is helpful to share that information.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> Sent: Tuesday, April 03, 2007 2:30 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
>  
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[email-masked]] 
> > Sent: Tuesday, April 03, 2007 11:25 AM
> > To: Caitlin Bestler
> > Cc: Joel M. Halpern; [email-masked]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> > 
> > It that's all that's needed (letting RBridges in Z know about 
> > membership of A, B, C, and D), then that would work by having 
> > RBridge RB1, which is only attached to, say, Z, advertise in 
> > its core IS-IS instance that it actually is also attached to 
> > A, B, C, and D. That way
> > RB1 will receive the endnode
> > advertisements of A, B, C, and D as well as Z.
> > 
> > Radia
> > 
> 
> If you are in {Z,A} you need to know about endnodes in B
> because of the shared address space problem, but you do
> not want B's traffic. It is *only* the endnode advertisements
> that you want added.
> 
> 
> 
> [email-masked]

Date: Tue, 03 Apr 2007 12:22:34 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Back to "what is the problem" for SVL/private VLAN/proxy ARP stuff
Status: RO
Content-Length: 2100

I think the reason we are all so confused is that we (especially me) do 
not understand what problem
we are solving. I wrote up in a previous note what I interpreted the 
problem to be. Let's be
really tangible about it. I'll start. Correct me if you disagree. But 
don't use reference to other solutions
or specs. It *can't* be that hard to actually describe it, rather than 
reference a spec, and without
being explicit people won't realize when they are thinking of different 
things.

So...is this the problem?

a) IP address block that has to be subdivided willy-nilly (not in clean 
sub-prefixes) among 4 customers

b) desire separation of the customers. I'd like this expanded. Why? Is 
it because of not wanting
to bother customer B with A's traffic, or that A doesn't want B to see 
A's traffic? Or both maybe.
Do we know what these applications are?

c) we want these communities to share some service node, say a DHCP 
server or an IP router

d) we don't want modify the IP router to do anything special (I suspect 
this is not really true, and that
the solutions people have in mind do require the IP router to know about 
this), or not much special

e) (I'm throwing this one in). We don't want to have to configure 
anything (RBridges or IP routers) to know
static mapping of IP addresses or MAC addresses to VLANs. The only 
configuration will be that an
RBridge (or bridge) will be configured to say "this set of ports of mine 
are VLAN A, this set are VLAN B, ..."
and it's by the tagging of packets transmitted from the port that other 
nodes learn which MAC addresses
(or which IP addresses) are in which VLAN

f) we want an IP endnode E_a in VLAN A to talk to an IP node E_b in VLAN 
B by being forwarded through the IP router. E_a and E_b are vanilla IP 
nodes and think they should be talking directly since they are in the same
IP address block.

g) maybe there are applications other than IP that want to have some 
sort of service node see all
the traffic from all the VLANs, and be able to talk to all the VLANs, 
but not have the VLANs talk to each
other. Is this true?

Date: Tue, 03 Apr 2007 11:45:23 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 922

Re: Caitlin's comment below

Really? The problem, as explained to me by some subset of the people, 
was that the IP router R
would be on the primary VLAN (in this case, Z), and so R needs to 
receive at least some broadcasts from
the secondaries -- the ARP/ND queries, for example.

It seemed to me that VLAN Z traffic (unicast or multicast) has to be 
legally accepted by all links
in Z, A, B, C, and D. And that VLAN A traffic (unicast or multicast) has 
to be legally accepted by all
links in A and Z.

There might be some applications that only want to stay within VLAN A. 
But how are RBridges to
know which are supposed to go to Z and which aren't supposed to go to Z?

Radia

Caitlin Bestler wrote:

>
>If you are in {Z,A} you need to know about endnodes in B
>because of the shared address space problem, but you do
>not want B's traffic. It is *only* the endnode advertisements
>that you want added.
>
>
>  
>

Date: Tue, 03 Apr 2007 14:43:53 -0400
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 3294

I don't follow the connection.

At 01:28 PM 4/3/2007, Caitlin Bestler wrote:
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> > Sent: Tuesday, April 03, 2007 10:04 AM
> > To: [email-masked]
> > Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> >
> > I think we can take the description a step further.
> >
> > As long as we do not insist that all special cases must be
> > solved optimally, it seems that this particular case, as
> > described, can be solved with no modification to the protocol
> > just by special behavior of the RBridge at the router.  Given
> > that it is a special case, and that it can be solved
> > externally to the protocol, it would seem to make sense for
> > the protocol not to solve this problem.
> >
> > We do not normally specify what additional features, outside
> > of the spec, an implementation may or may not perform.
> > Hence, the most we might consider doing for this is an
> > infromational appendix that describes how this particular
> > case is solved.  (And remember, we can not describe how to
> > solve all the possible special cases.)
> >
>
>What started this whole line of discussion was that the protocol
>specification at the time explicitly stated that end node discovery
>was only shared with the VLAN. That leads to problems when RBridges
>that are not part of VLAN A need to know of a discovery in VLAN A
>because it implies removal of conflicting key addresses (IP or MAC)
>in their own data structures.

Discover that MAC address X is on VLAN B should not always imply 
removal of MAC address X from VLAN A.  A device may use the same 
address on multiple VLANs.  I understand that there are cases where 
such sharing of information may be necessary.
But those cases have nothing to do with the situation of a router 
unknowingly serving several VLANs all within the same subnet.  In 
fact, as far as I can tell, that scenario is best dealt with if the 
routers MAC address is permitted to appear in several different VLANs 
simultaneously.

>So, the specification could merely state that RBridges MAY
>communicate endnode discovery with other RBridges for whatever
>reasons. It could even cite shared IP subnets as an example
>of a special feature that specific RBridges MAY chose to
>support.

The problem of proper removal of stale information (either because of 
exclusive VLAN usage where the end station is not permitted to be on 
several VLANs, or because of physical movement, is generally best 
addressed by explicit and direct support, if it is desired.  Trying 
to have unspecified behavior produce consistent result just doesn't work.
However, it also does not seem to be related to the scenario as 
described in Radia's email and the IEEE spec.  There is no change in 
what VLAN can be used to reach any given MAC address in those situations.

>That might make sense if we adopt the "it's not a general problem
>that should be handled by the default zereo configuration solution"
>approach.

the grouping of VLANs (whether for an end-RBridge support or for 
Radia's proposal 1 advertisement, or any other approach) is clearly 
not going to supported by the zero-configuration case.  It can't be.

Yours,
Joel

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 11:29:36 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 838

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 11:25 AM
> To: Caitlin Bestler
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> It that's all that's needed (letting RBridges in Z know about 
> membership of A, B, C, and D), then that would work by having 
> RBridge RB1, which is only attached to, say, Z, advertise in 
> its core IS-IS instance that it actually is also attached to 
> A, B, C, and D. That way
> RB1 will receive the endnode
> advertisements of A, B, C, and D as well as Z.
> 
> Radia
> 

If you are in {Z,A} you need to know about endnodes in B
because of the shared address space problem, but you do
not want B's traffic. It is *only* the endnode advertisements
that you want added.

Date: Tue, 03 Apr 2007 11:25:25 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2423

It that's all that's needed (letting RBridges in Z know about membership 
of A, B, C, and D), then
that would work by having RBridge RB1, which is only attached to, say, 
Z, advertise in its core IS-IS
instance that it actually is also attached to A, B, C, and D. That way 
RB1 will receive the endnode
advertisements of A, B, C, and D as well as Z.

Radia

Caitlin Bestler wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>Sent: Tuesday, April 03, 2007 10:04 AM
>>To: [email-masked]
>>Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
>>
>>I think we can take the description a step further.
>>
>>As long as we do not insist that all special cases must be 
>>solved optimally, it seems that this particular case, as 
>>described, can be solved with no modification to the protocol 
>>just by special behavior of the RBridge at the router.  Given 
>>that it is a special case, and that it can be solved 
>>externally to the protocol, it would seem to make sense for 
>>the protocol not to solve this problem.
>>
>>We do not normally specify what additional features, outside 
>>of the spec, an implementation may or may not perform.  
>>Hence, the most we might consider doing for this is an 
>>infromational appendix that describes how this particular 
>>case is solved.  (And remember, we can not describe how to 
>>solve all the possible special cases.)
>>
>>    
>>
>
>What started this whole line of discussion was that the protocol
>specification at the time explicitly stated that end node discovery
>was only shared with the VLAN. That leads to problems when RBridges
>that are not part of VLAN A need to know of a discovery in VLAN A
>because it implies removal of conflicting key addresses (IP or MAC)
>in their own data structures.
>
>So, the specification could merely state that RBridges MAY
>communicate endnode discovery with other RBridges for whatever
>reasons. It could even cite shared IP subnets as an example
>of a special feature that specific RBridges MAY chose to
>support.
>
>That might make sense if we adopt the "it's not a general problem
>that should be handled by the default zereo configuration solution"
>approach.
>
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 10:28:06 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 1852

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 03, 2007 10:04 AM
> To: [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> I think we can take the description a step further.
> 
> As long as we do not insist that all special cases must be 
> solved optimally, it seems that this particular case, as 
> described, can be solved with no modification to the protocol 
> just by special behavior of the RBridge at the router.  Given 
> that it is a special case, and that it can be solved 
> externally to the protocol, it would seem to make sense for 
> the protocol not to solve this problem.
> 
> We do not normally specify what additional features, outside 
> of the spec, an implementation may or may not perform.  
> Hence, the most we might consider doing for this is an 
> infromational appendix that describes how this particular 
> case is solved.  (And remember, we can not describe how to 
> solve all the possible special cases.)
> 

What started this whole line of discussion was that the protocol
specification at the time explicitly stated that end node discovery
was only shared with the VLAN. That leads to problems when RBridges
that are not part of VLAN A need to know of a discovery in VLAN A
because it implies removal of conflicting key addresses (IP or MAC)
in their own data structures.

So, the specification could merely state that RBridges MAY
communicate endnode discovery with other RBridges for whatever
reasons. It could even cite shared IP subnets as an example
of a special feature that specific RBridges MAY chose to
support.

That might make sense if we adopt the "it's not a general problem
that should be handled by the default zereo configuration solution"
approach.

Date: Tue, 03 Apr 2007 13:04:15 -0400
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2152

I think we can take the description a step further.

As long as we do not insist that all special cases must be solved 
optimally, it seems that this particular case, as described, can be 
solved with no modification to the protocol just by special behavior 
of the RBridge at the router.  Given that it is a special case, and 
that it can be solved externally to the protocol, it would seem to 
make sense for the protocol not to solve this problem.

We do not normally specify what additional features, outside of the 
spec, an implementation may or may not perform.  Hence, the most we 
might consider doing for this is an infromational appendix that 
describes how this particular case is solved.  (And remember, we can 
not describe how to solve all the possible special cases.)

Yours,
Joel M. Halpern

At 11:46 AM 4/3/2007, Caitlin Bestler wrote:
>But I do agree with Radia that there are two essential ways
>to solve this:
>
>         Extend the information collected during RBridge discovery
>         so that this problem will be taken care of automatically.
>
>         or, require the RBridges that have this special problem
>         to solve it amongs themselves and leave everyone else
>         out of it.
>
>With the first method you retain zero configuration for
>this feature by advertising VLAN groupings that require
>what would otherwise be excessive distribution of endnode
>discovery announcements. What Radia proposed works, but
>alternate approaches are possible if there is something
>inherently wrong about explicitly exporing FID info.
>
>With the second method you would be explicitly configuring
>each RBridge within the group with the additional export
>rules. Zero configuration is lost for those RBridges, but
>kept simpler for most RBridges.
>
>But unless I'm missing something, the only special action
>required is to ensure that when a group of VLANs share an
>IP subnet that all Proxy ARP tables that reference the
>shared IP subnet will be told of new discoveries.
>
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 08:46:13 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 2195

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, April 03, 2007 6:08 AM
> To: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> Radia,
> 
> 	I imagine there are many more ways to answer this 
> question than the three alternatives you've offered as examples.
> 
> 	I would answer this way:
> 
> .	neither approach is required to solve the problem, hence I
> 	suggest we concentrate on not breaking solutions that work
> 	now;
> 
> 	And:
> 
> .	Here is a better option - we specify that an RBridge may be
> 	configured to provide an inter-VLAN proxy ARP service in a
> 	manner that is compatible with similar services offered at
> 	present and the mechanisms and potential protocols needed
> 	to accomplish this are out of scope for TRILL.
> 

I think this may be a good approach. The only RBridge related
problem with inter-VLAN quasi-routing that has been identified
is an artifact of the ARP Proxy functionality. It makes sense
to fix it there.

But I do agree with Radia that there are two essential ways
to solve this:

	Extend the information collected during RBridge discovery
	so that this problem will be taken care of automatically.

	or, require the RBridges that have this special problem
	to solve it amongs themselves and leave everyone else
	out of it.

With the first method you retain zero configuration for
this feature by advertising VLAN groupings that require
what would otherwise be excessive distribution of endnode
discovery announcements. What Radia proposed works, but
alternate approaches are possible if there is something
inherently wrong about explicitly exporing FID info.

With the second method you would be explicitly configuring
each RBridge within the group with the additional export
rules. Zero configuration is lost for those RBridges, but
kept simpler for most RBridges.

But unless I'm missing something, the only special action
required is to ensure that when a group of VLANs share an
IP subnet that all Proxy ARP tables that reference the 
shared IP subnet will be told of new discoveries.

Date: Tue, 03 Apr 2007 08:27:36 -0700
From: Dinesh G Dutt <[email-masked]>
To: "J. R. Rivers" <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should	wecare?
Status: RO
Content-Length: 17060

I can't agree more. The entire ARP/ND optimization defocusses from the 
main strengths of TRILL: equal cost multipathing and shortest path 
forwarding at L2. I had suggested that we move the ARP/ND optimization 
section out of the base protocol spec into a separate document that can 
be addressed separately. I'd like to reiterate that suggestion.

BTW, Private VLANs was *only an* example of why shared VLAN learning is 
needed. During the meeting, we (Silvano and I) raised a list of open 
items and SVL was one of them. People questioned the need for this 
functionality and Ali Sajassi and I stated one example of its use. 
Focussing on how it works and attempting to solve what Private VLAN does 
outside of supporting SVL is an overkill, at least for the initial 
versions.

Dinesh
J. R. Rivers wrote:
>  
> These are issues that are commonly dealt with today when routers (either
> stand alone or "merged L3 switches") face this situation today.  I
> suggest focusing TRILL on retaining compatibility with today's
> expectations rather than altering them in any way.
>
> JR
>
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Eric Gray (LO/EUS)
>> Sent: Monday, April 02, 2007 1:50 PM
>> To: Radia Perlman
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
>> why should wecare?
>>
>> Radia,
>>
>> 	There is an interesting problem that might arise out of
>> a router receiving VLAN tagged frames without being aware that
>> they are tagged.  
>>
>> 	A router is a MAC termination point - i.e. - it is an 
>> end-station at the MAC layer.  But it is also a forwarding
>> device.  Hence the slack that might apply to a host receiving
>> a MAC frame with "stuff" in the header it doesn't understand,
>> shouldn't be allowed for a router.
>>
>> 	Also, many routers do understand that it is possible to
>> have the same IP subnet connected to multiple logical interfaces.
>> That was where the original "Bridging Router" (or BRouter) came
>> from.
>>
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson  
>>
>>     
>>> -----Original Message-----
>>> From: Radia Perlman [mailto:[email-masked]] 
>>> Sent: Monday, April 02, 2007 4:10 PM
>>> To: Eric Gray (LO/EUS)
>>> Cc: [email-masked]
>>> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
>>> why should we care?
>>> Importance: High
>>>
>>> My understanding is that shared VLANs assume
>>> IP routers are not aware of VLANs.
>>>
>>> My understanding is that the way it would work if the IP 
>>> router R *was* 
>>> aware of
>>> VLANs, is that R would treat the link as 4 separate links (by using 
>>> VLANs), and then the IP addresses
>>> on the 4 different links (VLANs A, B, C, and D) would have to have 
>>> different IP prefixes.
>>>
>>> So therefore, I am assuming that the IP router is not 
>>> supposed to know 
>>> that the link is subdivided into VLANs.
>>>
>>> So my understanding of the problem in this case is:
>>>
>>> a) single IP address block shared by different communities
>>> b) desire to isolate these communities from layer 2 
>>>       
>> broadcast traffic 
>>     
>>> from each other
>>> c) desire to share some services (like DHCP and IP 
>>>       
>> routers), without 
>>     
>>> those services being aware
>>> that the communities are separate
>>>
>>> As for my question about proxy ARP, to further add
>>> to the confusion -- some people are assuming the 
>>> bridge/RBridge will be 
>>> doing
>>> the proxy ARP, and some others are assuming the router is.
>>>
>>> And actually, after talking offline with Joel Halpern, I'll 
>>> send another 
>>> note with two different proposals
>>> (one just a cleanup of what I originally wrote, and the other a 
>>> different approach) for solving
>>> that vaguely stated problem.
>>>
>>> Radia
>>>
>>>
>>>
>>>
>>>
>>> Eric Gray (LO/EUS) wrote:
>>>
>>>       
>>>> Radia,
>>>>
>>>> 	Let me try to re-state your explanation to see if I understand 
>>>> it...
>>>>
>>>> 	You believe that the problem that shared VLAN learning is used
>>>> to solve is conservation of IP addresses used in a single 
>>>>         
>> IP subnet, 
>>     
>>>> and that it is necessary to use shared VLAN learning to 
>>>>         
>> keep routers 
>>     
>>>> (in the subnet) from having to re-learn MAC+IP 
>>>>         
>> associations across a
>>     
>>>> set of VLANs in that same IP subnet, is that correct?
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Eric Gray
>>>> Principal Engineer
>>>> Ericsson  
>>>>
>>>>  
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: [email-masked] 
>>>>> [mailto:[email-masked]] On Behalf Of Radia Perlman
>>>>> Sent: Thursday, March 29, 2007 2:56 AM
>>>>> To: [email-masked]
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> [email-masked]
>> [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 08:16:03 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 7270

Eric,

I will go one step further and say that the basic TRILL protocol should
not specify an ARP/ND proxy function.

As the discussion as pointed out, ARP/ND proxy is more a product feature
that depends on how the box are packaged. IMHO RBridges will be packaged
with additional router, NAT, firewall functionalities. If and where
proxy ARP will be implemented will vary.

After the last call on the base protocol, we can always resume the work
and deal with Proxy ARP/ND in a separate document.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, April 03, 2007 6:08 AM
> To: Radia Perlman; [email-masked]
> Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
> 
> Radia,
> 
> 	I imagine there are many more ways to answer this question
> than the three alternatives you've offered as examples.
> 
> 	I would answer this way:
> 
> .	neither approach is required to solve the problem, hence I
> 	suggest we concentrate on not breaking solutions that work
> 	now;
> 
> 	And:
> 
> .	Here is a better option - we specify that an RBridge may be
> 	configured to provide an inter-VLAN proxy ARP service in a
> 	manner that is compatible with similar services offered at
> 	present and the mechanisms and potential protocols needed
> 	to accomplish this are out of scope for TRILL.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Monday, April 02, 2007 7:00 PM
> > To: [email-masked]
> > Subject: [rbridge] Two "shared VLAN" alternative proposals
> >
> > Based on the thread, and some off-list communication with
> > Joel Halpern
> > and others, I now
> > would like to propose two concrete solutions.
> >
> > I'd like people to make comments like
> > . "either of them is fine, but I prefer this one because..."
> > . "neither of them solve the problem. The problem is ..."
> > . "here is a better option .. xxxxxxxxx"
> >
> >
> > Option 1: Making groupings known to all the RBridges
> > (slightly revised
> > from my original proposal)
> > --------------------------------------------------------------
> > ------------------------------------
> >
> > a) Make a group of VLANs {Z, A, B, C, D}, where VLAN Z is the
> > "primary" and
> > {A, B, C, D} are "secondaries".  All RBridges learn about
> > this grouping
> > because
> > at least one RBridge RB1 has been configured to know these 5 VLANs
> > belong in a group,
> > and RB1 announces this grouping in its core IS-IS instance.
> >
> > A frame tagged with VLAN Z (say an ARP request
> > from the IP router) goes to all the links in all the VLANs in
> > the group
> > (i.e., Z, A, B, C, and D). While
> > in the core, the inner VLAN tag is Z. When an RBridge
> > decapsulates onto
> > a VLAN A link, it changes the
> > VLAN tag to A in order to forward it (or removes the VLAN tag).
> >
> > RBridges in the core do optimal filtering of VLAN-tagged packets,
> > so that something tagged VLAN D goes to D and Z, something
> > marked Z goes
> > to Z, A, B, C, and D, and
> > something marked F (not in a group) goes just to F. And the
> > distribution
> > tree gets filtered as early
> > as possible, by some core RBridge that notices no downstream
> > link leads
> > to any of the VLANs in the
> > set it is supposed to be delivering to.
> >
> > There will still be separate per-VLAN instances of  Z, A, B,
> > C, and D.
> > These are not combined.
> > RBridges that only claim to be attached to VLAN Z, will also
> > participate
> > in the per-VLAN IS-IS
> > instances of A, B, C, and D, in that they will recieve and store the
> > link state announcements about endnodes
> > in those VLANs.
> >
> > If two different RBridges announce different groupings, say RB1
> > announces {Z, A, B, C, D} and
> > RB2 announces {Z, A, E}, then we log an error, but core RBridges
> > treat the group as the set union, i.e. {Z, A, B, C, D, E}, for the
> > purpose of filtering multicasts tagged with
> > any of those VLAN tags.
> >
> > Option 2: Groupings only known to RBridges at the edge
> > involved in these
> > groupings
> > --------------------------------------------------------------
> > -----------------------
> >
> > b) Only RBridges associated with these groupings know
> > anything about the
> > grouping. So going with
> > our original example, an IP router is shared by VLANs A, B, C, and
D,
> > and is assigned to VLAN Z.
> > The IP router is not aware of any of this, and assumes
> > everything is one
> > IP subnet. RBridges
> > attached to IP nodes in any of the VLANs {Z, A, B, C, D}
> > *are* aware of
> > this grouping.
> >
> > Suppose the IP router is
> > attached to RBridge RB1. The IP router does an ARP request. RB1
knows
> > that something from
> > the IP router is supposed to go to
> > VLANs Z, A, B, C, and D, so RB1 duplicates the packet (in
> > this case, the
> > ARP request),
> > creating 5 packets, and transmits one
> > into the cloud tagged as VLAN Z, one as VLAN A, one as VLAN B, one
as
> > VLAN C, one as VLAN D.
> > In the IP router issues a unicast packet to MAC address M,
> > RB1 looks in
> > its endnode tables
> > for VLAN Z, VLAN A, VLAN B, VLAN C, and VLAN D. If RB1 finds
> > M, say in
> > VLAN B,
> > RB1 tags the packet as "VLAN B", and sends it to the egress
> > RBridge that
> > announced attachment to M
> > in VLAN B. I assume that RB1 stops when it finds M, and if M is in
> > multiple of these tables, too bad.
> > RB1 sends it to the first one it finds.
> >
> > For an RBridge RB2 attached to a "secondary VLAN", say C, the
> > same thing
> > happens.
> > Multicasts from C get duplicated so RB2 sends two copies, one marked
> > "VLAN C", and one marked "VLAN Z".
> > For unicast, RB2 sees if it can find the MAC address in its C
> > table or Z
> > table, and if it does, unicasts it
> > to the egress RBridge (marking the VLAN tag according to the table
in
> > which it found the destination,
> > or leaving it as C; I think either one will work).
> >
> > But if RB2 does *not* find the destination in any of the
> > endnode tables,
> > RB2 creates two copies of the packet, one
> > marked VLAN Z, one marked VLAN B, and multicasts each one.
> >
> > ********************************************************
> > Pros and cons of these two proposals
> >
> > Proposal a) is more optimal since packets to the group do not
> > need to be
> > duplicated,
> > and furthermore get filtered in the core. However, it
> > requires adding an
> > announcement
> > into the core IS-IS instance of what the VLAN groupings are, and
some
> > thought as
> > to what to do if different RBridges announce different groupings.
> >
> > Proposal b) adds less complexity to the basic RBridge spec. Since no
> > sharing of
> > grouping information is done, misconfiguration will not be
detectable.
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 08:05:36 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "J. R. Rivers" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why shouldwecare?
Status: RO
Content-Length: 17454

I completely agree

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Tuesday, April 03, 2007 4:23 AM
> To: J. R. Rivers; Radia Perlman; [email-masked]
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why
> shouldwecare?
> 
> JR,
> 
> 	I agree.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:[email-masked]]
> > Sent: Monday, April 02, 2007 6:52 PM
> > To: Eric Gray (LO/EUS); Radia Perlman; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [rbridge] Shared VLAN learning: What is it and
> > why should wecare?
> > Importance: High
> >
> >
> > These are issues that are commonly dealt with today when
> > routers (either
> > stand alone or "merged L3 switches") face this situation today.  I
> > suggest focusing TRILL on retaining compatibility with today's
> > expectations rather than altering them in any way.
> >
> > JR
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Eric Gray
(LO/EUS)
> > > Sent: Monday, April 02, 2007 1:50 PM
> > > To: Radia Perlman
> > > Cc: [email-masked]
> > > Subject: Re: [rbridge] Shared VLAN learning: What is it and
> > > why should wecare?
> > >
> > > Radia,
> > >
> > > 	There is an interesting problem that might arise out of
> > > a router receiving VLAN tagged frames without being aware that
> > > they are tagged.
> > >
> > > 	A router is a MAC termination point - i.e. - it is an
> > > end-station at the MAC layer.  But it is also a forwarding
> > > device.  Hence the slack that might apply to a host receiving
> > > a MAC frame with "stuff" in the header it doesn't understand,
> > > shouldn't be allowed for a router.
> > >
> > > 	Also, many routers do understand that it is possible to
> > > have the same IP subnet connected to multiple logical interfaces.
> > > That was where the original "Bridging Router" (or BRouter) came
> > > from.
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Radia Perlman [mailto:[email-masked]]
> > > > Sent: Monday, April 02, 2007 4:10 PM
> > > > To: Eric Gray (LO/EUS)
> > > > Cc: [email-masked]
> > > > Subject: Re: [rbridge] Shared VLAN learning: What is it and
> > > > why should we care?
> > > > Importance: High
> > > >
> > > > My understanding is that shared VLANs assume
> > > > IP routers are not aware of VLANs.
> > > >
> > > > My understanding is that the way it would work if the IP
> > > > router R *was*
> > > > aware of
> > > > VLANs, is that R would treat the link as 4 separate links
> > (by using
> > > > VLANs), and then the IP addresses
> > > > on the 4 different links (VLANs A, B, C, and D) would
> > have to have
> > > > different IP prefixes.
> > > >
> > > > So therefore, I am assuming that the IP router is not
> > > > supposed to know
> > > > that the link is subdivided into VLANs.
> > > >
> > > > So my understanding of the problem in this case is:
> > > >
> > > > a) single IP address block shared by different communities
> > > > b) desire to isolate these communities from layer 2
> > > broadcast traffic
> > > > from each other
> > > > c) desire to share some services (like DHCP and IP
> > > routers), without
> > > > those services being aware
> > > > that the communities are separate
> > > >
> > > > As for my question about proxy ARP, to further add
> > > > to the confusion -- some people are assuming the
> > > > bridge/RBridge will be
> > > > doing
> > > > the proxy ARP, and some others are assuming the router is.
> > > >
> > > > And actually, after talking offline with Joel Halpern, I'll
> > > > send another
> > > > note with two different proposals
> > > > (one just a cleanup of what I originally wrote, and the other a
> > > > different approach) for solving
> > > > that vaguely stated problem.
> > > >
> > > > Radia
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Eric Gray (LO/EUS) wrote:
> > > >
> > > > >Radia,
> > > > >
> > > > >	Let me try to re-state your explanation to see if I
understand
> > > > >it...
> > > > >
> > > > >	You believe that the problem that shared VLAN learning
is used
> > > > >to solve is conservation of IP addresses used in a single
> > > IP subnet,
> > > > >and that it is necessary to use shared VLAN learning to
> > > keep routers
> > > > >(in the subnet) from having to re-learn MAC+IP
> > > associations across a
> > > > >set of VLANs in that same IP subnet, is that correct?
> > > > >
> > > > >Thanks!
> > > > >
> > > > >--
> > > > >Eric Gray
> > > > >Principal Engineer
> > > > >Ericsson
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: [email-masked]
> > > > >>[mailto:[email-masked]] On Behalf Of Radia Perlman
> > > > >>Sent: Thursday, March 29, 2007 2:56 AM
> > > > >>To: [email-masked]
> > > > >>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
> > > > >>
> > > > >>
> > > > >>
> > > > >>[email-masked]
> > > [email-masked]
> [email-masked]

Date: Tue, 3 Apr 2007 08:50:16 -0500
From: "Dale W. Carder" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we	care?
Reply-To: [email-masked]
Status: RO
Content-Length: 568

Thus spake Eric Gray (LO/EUS) ([email-masked]) on Tue, Apr 03, 2007 at 08:25:38AM -0500:
> cover several of the issues.  Silvano said:
> 
> "Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs.  In 
>  figure B-4 assume a router instead of the Server."
> 
> I don't think I am at liberty to disclose publicly how you 
> can get direct access to that publication, but you can.  See
> your local IEEE people to find out how...

They are now free to download after a 6 month period after
initial release:

http://standards.ieee.org/getieee802/802.1.html

Dale

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 08:25:38 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 1434

Russ,

	Silvano provided a reference for a diagram that does
cover several of the issues.  Silvano said:

"Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs.  In 
 figure B-4 assume a router instead of the Server."

I don't think I am at liberty to disclose publicly how you 
can get direct access to that publication, but you can.  See
your local IEEE people to find out how...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Tuesday, April 03, 2007 8:58 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Argh! I'm really confused.
> 
> Could we have a network diagram posted someplace on a web site? I'm
> finding this hard to follow from text descriptions.... ??
> 
> :-)
> 
> Russ
> 
> - --
> [email-masked] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGEk9zER27sUhU9OQRAs00AJwLav8FeqJ59QvW9/jGuyaCw9Pn8ACdFqFn
> CLWoXE/tUZ9ouCsFEhdTOqU=
> =e8Vh
> -----END PGP SIGNATURE-----
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 08:17:59 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 1717

Russ,

	I'm with you on that, but I doubt that a single diagram
would suffice to describe the many different things that people
are talking about.  Trying to come up with a single diagram to 
include all of the issues would result in a diagram too complex
to be useful in most cases.

	You may have seen the simplistic one I provided to show 
the potential problems that might arise from using inter-VLAN
Proxy ARP with RBridges - if one does not take into account a
real-world possibility that this may be done already using the
techniques that are deployed today.  But does that one serve
to illustrate the other problems discussed in this thread?  I
think not...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Tuesday, April 03, 2007 8:58 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Argh! I'm really confused.
> 
> Could we have a network diagram posted someplace on a web site? I'm
> finding this hard to follow from text descriptions.... ??
> 
> :-)
> 
> Russ
> 
> - --
> [email-masked] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGEk9zER27sUhU9OQRAs00AJwLav8FeqJ59QvW9/jGuyaCw9Pn8ACdFqFn
> CLWoXE/tUZ9ouCsFEhdTOqU=
> =e8Vh
> -----END PGP SIGNATURE-----
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 08:07:42 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 6056

Radia,

	I imagine there are many more ways to answer this question
than the three alternatives you've offered as examples.

	I would answer this way:

.	neither approach is required to solve the problem, hence I
	suggest we concentrate on not breaking solutions that work
	now;

	And:

.	Here is a better option - we specify that an RBridge may be
	configured to provide an inter-VLAN proxy ARP service in a
	manner that is compatible with similar services offered at
	present and the mechanisms and potential protocols needed
	to accomplish this are out of scope for TRILL.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Monday, April 02, 2007 7:00 PM
> To: [email-masked]
> Subject: [rbridge] Two "shared VLAN" alternative proposals
> 
> Based on the thread, and some off-list communication with 
> Joel Halpern 
> and others, I now
> would like to propose two concrete solutions.
> 
> I'd like people to make comments like
> . "either of them is fine, but I prefer this one because..."
> . "neither of them solve the problem. The problem is ..."
> . "here is a better option .. xxxxxxxxx"
> 
> 
> Option 1: Making groupings known to all the RBridges 
> (slightly revised 
> from my original proposal)
> --------------------------------------------------------------
> ------------------------------------
> 
> a) Make a group of VLANs {Z, A, B, C, D}, where VLAN Z is the 
> "primary" and
> {A, B, C, D} are "secondaries".  All RBridges learn about 
> this grouping 
> because
> at least one RBridge RB1 has been configured to know these 5 VLANs 
> belong in a group,
> and RB1 announces this grouping in its core IS-IS instance.
> 
> A frame tagged with VLAN Z (say an ARP request
> from the IP router) goes to all the links in all the VLANs in 
> the group 
> (i.e., Z, A, B, C, and D). While
> in the core, the inner VLAN tag is Z. When an RBridge 
> decapsulates onto 
> a VLAN A link, it changes the
> VLAN tag to A in order to forward it (or removes the VLAN tag).
> 
> RBridges in the core do optimal filtering of VLAN-tagged packets,
> so that something tagged VLAN D goes to D and Z, something 
> marked Z goes 
> to Z, A, B, C, and D, and
> something marked F (not in a group) goes just to F. And the 
> distribution 
> tree gets filtered as early
> as possible, by some core RBridge that notices no downstream 
> link leads 
> to any of the VLANs in the
> set it is supposed to be delivering to.
> 
> There will still be separate per-VLAN instances of  Z, A, B, 
> C, and D. 
> These are not combined.
> RBridges that only claim to be attached to VLAN Z, will also 
> participate 
> in the per-VLAN IS-IS
> instances of A, B, C, and D, in that they will recieve and store the 
> link state announcements about endnodes
> in those VLANs.
> 
> If two different RBridges announce different groupings, say RB1 
> announces {Z, A, B, C, D} and
> RB2 announces {Z, A, E}, then we log an error, but core RBridges
> treat the group as the set union, i.e. {Z, A, B, C, D, E}, for the 
> purpose of filtering multicasts tagged with
> any of those VLAN tags.
> 
> Option 2: Groupings only known to RBridges at the edge 
> involved in these 
> groupings
> --------------------------------------------------------------
> -----------------------
> 
> b) Only RBridges associated with these groupings know 
> anything about the 
> grouping. So going with
> our original example, an IP router is shared by VLANs A, B, C, and D, 
> and is assigned to VLAN Z.
> The IP router is not aware of any of this, and assumes 
> everything is one 
> IP subnet. RBridges
> attached to IP nodes in any of the VLANs {Z, A, B, C, D} 
> *are* aware of 
> this grouping.
> 
> Suppose the IP router is
> attached to RBridge RB1. The IP router does an ARP request. RB1 knows 
> that something from
> the IP router is supposed to go to
> VLANs Z, A, B, C, and D, so RB1 duplicates the packet (in 
> this case, the 
> ARP request),
> creating 5 packets, and transmits one
> into the cloud tagged as VLAN Z, one as VLAN A, one as VLAN B, one as 
> VLAN C, one as VLAN D.
> In the IP router issues a unicast packet to MAC address M, 
> RB1 looks in 
> its endnode tables
> for VLAN Z, VLAN A, VLAN B, VLAN C, and VLAN D. If RB1 finds 
> M, say in 
> VLAN B,
> RB1 tags the packet as "VLAN B", and sends it to the egress 
> RBridge that 
> announced attachment to M
> in VLAN B. I assume that RB1 stops when it finds M, and if M is in 
> multiple of these tables, too bad.
> RB1 sends it to the first one it finds.
> 
> For an RBridge RB2 attached to a "secondary VLAN", say C, the 
> same thing 
> happens.
> Multicasts from C get duplicated so RB2 sends two copies, one marked 
> "VLAN C", and one marked "VLAN Z".
> For unicast, RB2 sees if it can find the MAC address in its C 
> table or Z 
> table, and if it does, unicasts it
> to the egress RBridge (marking the VLAN tag according to the table in 
> which it found the destination,
> or leaving it as C; I think either one will work).
> 
> But if RB2 does *not* find the destination in any of the 
> endnode tables, 
> RB2 creates two copies of the packet, one
> marked VLAN Z, one marked VLAN B, and multicasts each one.
> 
> ********************************************************
> Pros and cons of these two proposals
> 
> Proposal a) is more optimal since packets to the group do not 
> need to be 
> duplicated,
> and furthermore get filtered in the core. However, it 
> requires adding an 
> announcement
> into the core IS-IS instance of what the VLAN groupings are, and some 
> thought as
> to what to do if different RBridges announce different groupings.
> 
> Proposal b) adds less complexity to the basic RBridge spec. Since no 
> sharing of
> grouping information is done, misconfiguration will not be detectable.
> 
> [email-masked]

Date: Tue, 03 Apr 2007 08:58:27 -0400
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 507

> Argh! I'm really confused.

Could we have a network diagram posted someplace on a web site? I'm
finding this hard to follow from text descriptions.... ??

:-)

Russ

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

Content-class: urn:content-classes:message
Date: Tue, 3 Apr 2007 06:22:45 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "J. R. Rivers" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 16197

JR,

	I agree.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 6:52 PM
> To: Eric Gray (LO/EUS); Radia Perlman; [email-masked]
> Cc: [email-masked]
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> Importance: High
> 
>  
> These are issues that are commonly dealt with today when 
> routers (either
> stand alone or "merged L3 switches") face this situation today.  I
> suggest focusing TRILL on retaining compatibility with today's
> expectations rather than altering them in any way.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eric Gray (LO/EUS)
> > Sent: Monday, April 02, 2007 1:50 PM
> > To: Radia Perlman
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> > why should wecare?
> > 
> > Radia,
> > 
> > 	There is an interesting problem that might arise out of
> > a router receiving VLAN tagged frames without being aware that
> > they are tagged.  
> > 
> > 	A router is a MAC termination point - i.e. - it is an 
> > end-station at the MAC layer.  But it is also a forwarding
> > device.  Hence the slack that might apply to a host receiving
> > a MAC frame with "stuff" in the header it doesn't understand,
> > shouldn't be allowed for a router.
> > 
> > 	Also, many routers do understand that it is possible to
> > have the same IP subnet connected to multiple logical interfaces.
> > That was where the original "Bridging Router" (or BRouter) came
> > from.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:[email-masked]] 
> > > Sent: Monday, April 02, 2007 4:10 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [email-masked]
> > > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> > > why should we care?
> > > Importance: High
> > > 
> > > My understanding is that shared VLANs assume
> > > IP routers are not aware of VLANs.
> > > 
> > > My understanding is that the way it would work if the IP 
> > > router R *was* 
> > > aware of
> > > VLANs, is that R would treat the link as 4 separate links 
> (by using 
> > > VLANs), and then the IP addresses
> > > on the 4 different links (VLANs A, B, C, and D) would 
> have to have 
> > > different IP prefixes.
> > > 
> > > So therefore, I am assuming that the IP router is not 
> > > supposed to know 
> > > that the link is subdivided into VLANs.
> > > 
> > > So my understanding of the problem in this case is:
> > > 
> > > a) single IP address block shared by different communities
> > > b) desire to isolate these communities from layer 2 
> > broadcast traffic 
> > > from each other
> > > c) desire to share some services (like DHCP and IP 
> > routers), without 
> > > those services being aware
> > > that the communities are separate
> > > 
> > > As for my question about proxy ARP, to further add
> > > to the confusion -- some people are assuming the 
> > > bridge/RBridge will be 
> > > doing
> > > the proxy ARP, and some others are assuming the router is.
> > > 
> > > And actually, after talking offline with Joel Halpern, I'll 
> > > send another 
> > > note with two different proposals
> > > (one just a cleanup of what I originally wrote, and the other a 
> > > different approach) for solving
> > > that vaguely stated problem.
> > > 
> > > Radia
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Eric Gray (LO/EUS) wrote:
> > > 
> > > >Radia,
> > > >
> > > >	Let me try to re-state your explanation to see if I understand 
> > > >it...
> > > >
> > > >	You believe that the problem that shared VLAN learning is used
> > > >to solve is conservation of IP addresses used in a single 
> > IP subnet, 
> > > >and that it is necessary to use shared VLAN learning to 
> > keep routers 
> > > >(in the subnet) from having to re-learn MAC+IP 
> > associations across a
> > > >set of VLANs in that same IP subnet, is that correct?
> > > >
> > > >Thanks!
> > > >
> > > >--
> > > >Eric Gray
> > > >Principal Engineer
> > > >Ericsson  
> > > >
> > > >  
> > > >
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]] On Behalf Of Radia Perlman
> > > >>Sent: Thursday, March 29, 2007 2:56 AM
> > > >>To: [email-masked]
> > > >>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
> > > >>
> > > >>
> > > >>
> > > >>[email-masked]
> > [email-masked]

Date: Mon, 02 Apr 2007 16:00:20 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Two "shared VLAN" alternative proposals
Status: RO
Content-Length: 4722

Based on the thread, and some off-list communication with Joel Halpern 
and others, I now
would like to propose two concrete solutions.

I'd like people to make comments like
. "either of them is fine, but I prefer this one because..."
. "neither of them solve the problem. The problem is ..."
. "here is a better option .. xxxxxxxxx"

Option 1: Making groupings known to all the RBridges (slightly revised 
from my original proposal)
--------------------------------------------------------------------------------------------------

a) Make a group of VLANs {Z, A, B, C, D}, where VLAN Z is the "primary" and
{A, B, C, D} are "secondaries".  All RBridges learn about this grouping 
because
at least one RBridge RB1 has been configured to know these 5 VLANs 
belong in a group,
and RB1 announces this grouping in its core IS-IS instance.

A frame tagged with VLAN Z (say an ARP request
from the IP router) goes to all the links in all the VLANs in the group 
(i.e., Z, A, B, C, and D). While
in the core, the inner VLAN tag is Z. When an RBridge decapsulates onto 
a VLAN A link, it changes the
VLAN tag to A in order to forward it (or removes the VLAN tag).

RBridges in the core do optimal filtering of VLAN-tagged packets,
so that something tagged VLAN D goes to D and Z, something marked Z goes 
to Z, A, B, C, and D, and
something marked F (not in a group) goes just to F. And the distribution 
tree gets filtered as early
as possible, by some core RBridge that notices no downstream link leads 
to any of the VLANs in the
set it is supposed to be delivering to.

There will still be separate per-VLAN instances of  Z, A, B, C, and D. 
These are not combined.
RBridges that only claim to be attached to VLAN Z, will also participate 
in the per-VLAN IS-IS
instances of A, B, C, and D, in that they will recieve and store the 
link state announcements about endnodes
in those VLANs.

If two different RBridges announce different groupings, say RB1 
announces {Z, A, B, C, D} and
RB2 announces {Z, A, E}, then we log an error, but core RBridges
treat the group as the set union, i.e. {Z, A, B, C, D, E}, for the 
purpose of filtering multicasts tagged with
any of those VLAN tags.

Option 2: Groupings only known to RBridges at the edge involved in these 
groupings
-------------------------------------------------------------------------------------

b) Only RBridges associated with these groupings know anything about the 
grouping. So going with
our original example, an IP router is shared by VLANs A, B, C, and D, 
and is assigned to VLAN Z.
The IP router is not aware of any of this, and assumes everything is one 
IP subnet. RBridges
attached to IP nodes in any of the VLANs {Z, A, B, C, D} *are* aware of 
this grouping.

Suppose the IP router is
attached to RBridge RB1. The IP router does an ARP request. RB1 knows 
that something from
the IP router is supposed to go to
VLANs Z, A, B, C, and D, so RB1 duplicates the packet (in this case, the 
ARP request),
creating 5 packets, and transmits one
into the cloud tagged as VLAN Z, one as VLAN A, one as VLAN B, one as 
VLAN C, one as VLAN D.
In the IP router issues a unicast packet to MAC address M, RB1 looks in 
its endnode tables
for VLAN Z, VLAN A, VLAN B, VLAN C, and VLAN D. If RB1 finds M, say in 
VLAN B,
RB1 tags the packet as "VLAN B", and sends it to the egress RBridge that 
announced attachment to M
in VLAN B. I assume that RB1 stops when it finds M, and if M is in 
multiple of these tables, too bad.
RB1 sends it to the first one it finds.

For an RBridge RB2 attached to a "secondary VLAN", say C, the same thing 
happens.
Multicasts from C get duplicated so RB2 sends two copies, one marked 
"VLAN C", and one marked "VLAN Z".
For unicast, RB2 sees if it can find the MAC address in its C table or Z 
table, and if it does, unicasts it
to the egress RBridge (marking the VLAN tag according to the table in 
which it found the destination,
or leaving it as C; I think either one will work).

But if RB2 does *not* find the destination in any of the endnode tables, 
RB2 creates two copies of the packet, one
marked VLAN Z, one marked VLAN B, and multicasts each one.

********************************************************
Pros and cons of these two proposals

Proposal a) is more optimal since packets to the group do not need to be 
duplicated,
and furthermore get filtered in the core. However, it requires adding an 
announcement
into the core IS-IS instance of what the VLAN groupings are, and some 
thought as
to what to do if different RBridges announce different groupings.

Proposal b) adds less complexity to the basic RBridge spec. Since no 
sharing of
grouping information is done, misconfiguration will not be detectable.

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 15:51:42 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 14916

These are issues that are commonly dealt with today when routers (either
stand alone or "merged L3 switches") face this situation today.  I
suggest focusing TRILL on retaining compatibility with today's
expectations rather than altering them in any way.

JR

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Gray (LO/EUS)
> Sent: Monday, April 02, 2007 1:50 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> 
> Radia,
> 
> 	There is an interesting problem that might arise out of
> a router receiving VLAN tagged frames without being aware that
> they are tagged.  
> 
> 	A router is a MAC termination point - i.e. - it is an 
> end-station at the MAC layer.  But it is also a forwarding
> device.  Hence the slack that might apply to a host receiving
> a MAC frame with "stuff" in the header it doesn't understand,
> shouldn't be allowed for a router.
> 
> 	Also, many routers do understand that it is possible to
> have the same IP subnet connected to multiple logical interfaces.
> That was where the original "Bridging Router" (or BRouter) came
> from.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[email-masked]] 
> > Sent: Monday, April 02, 2007 4:10 PM
> > To: Eric Gray (LO/EUS)
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> > why should we care?
> > Importance: High
> > 
> > My understanding is that shared VLANs assume
> > IP routers are not aware of VLANs.
> > 
> > My understanding is that the way it would work if the IP 
> > router R *was* 
> > aware of
> > VLANs, is that R would treat the link as 4 separate links (by using 
> > VLANs), and then the IP addresses
> > on the 4 different links (VLANs A, B, C, and D) would have to have 
> > different IP prefixes.
> > 
> > So therefore, I am assuming that the IP router is not 
> > supposed to know 
> > that the link is subdivided into VLANs.
> > 
> > So my understanding of the problem in this case is:
> > 
> > a) single IP address block shared by different communities
> > b) desire to isolate these communities from layer 2 
> broadcast traffic 
> > from each other
> > c) desire to share some services (like DHCP and IP 
> routers), without 
> > those services being aware
> > that the communities are separate
> > 
> > As for my question about proxy ARP, to further add
> > to the confusion -- some people are assuming the 
> > bridge/RBridge will be 
> > doing
> > the proxy ARP, and some others are assuming the router is.
> > 
> > And actually, after talking offline with Joel Halpern, I'll 
> > send another 
> > note with two different proposals
> > (one just a cleanup of what I originally wrote, and the other a 
> > different approach) for solving
> > that vaguely stated problem.
> > 
> > Radia
> > 
> > 
> > 
> > 
> > 
> > Eric Gray (LO/EUS) wrote:
> > 
> > >Radia,
> > >
> > >	Let me try to re-state your explanation to see if I understand 
> > >it...
> > >
> > >	You believe that the problem that shared VLAN learning is used
> > >to solve is conservation of IP addresses used in a single 
> IP subnet, 
> > >and that it is necessary to use shared VLAN learning to 
> keep routers 
> > >(in the subnet) from having to re-learn MAC+IP 
> associations across a
> > >set of VLANs in that same IP subnet, is that correct?
> > >
> > >Thanks!
> > >
> > >--
> > >Eric Gray
> > >Principal Engineer
> > >Ericsson  
> > >
> > >  
> > >
> > >>-----Original Message-----
> > >>From: [email-masked] 
> > >>[mailto:[email-masked]] On Behalf Of Radia Perlman
> > >>Sent: Thursday, March 29, 2007 2:56 AM
> > >>To: [email-masked]
> > >>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
> > >>
> > >>
> > >>
> > >>[email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 17:15:09 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 5510

Caitlin,

	I'm not sure who you're addressing this to, but I'll take a
crack at answering it.  Please see below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 5:37 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia Perlman
> Cc: [email-masked]
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> Importance: High
> 
> [email-masked] wrote:
> > Eric,
> > 
> >> -----Original Message-----
> >> From: [email-masked] 
> [mailto:[email-masked]]
> >> On Behalf Of Eric Gray (LO/EUS) Sent: Monday, April 02, 
> 2007 1:50 PM
> >> To: Radia Perlman
> >> Cc: [email-masked]
> >> Subject: Re: [rbridge] Shared VLAN learning: What is it and why
> >> should wecare? 
> >> 
> >> Radia,
> >> 
> >> 	There is an interesting problem that might arise out of a router
> >> receiving VLAN tagged frames without being aware that they are
> >> tagged. 
> >> 
> > 
> > This is not the case, unless there is a misconfiguration. A
> > Router has a
> > concept of an interface (e.g. eth0, the Ethernet port) and of
> > sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to
> > sub-interfaces. When a frame arrive the VID (VLAN ID), 
> either explicit
> > or implicit, is used to select a sub-interface. The
> > sub-interface has an
> > IP address and a netmask.
> > 
> > -- Silvano
> > 
> > 
> 
> If you review the email I cited previously, and then do some googling,
> you'll see that assigning each VLAN a recognizable IP subnet is merely
> the predominant technique -- it is not the only one, and it is not a
> requirement.
> 
> Do you agree that when a router connects to multiple VLANs that share
> an IP subnet that having the RBridge generate a Proxied ARP response
> to the *same* IP address on each VLAN is a problem that needs to
> be solved?

I agree.  However, solving it may be simply requiring that
implementations
are configurable to avoid the pathological consequences of this
situation.

Since this would be the case today with existing VLAN aware devices, I
am
not sure what we (TRILL) needs to say or whether or not it even makes
any
sense for us to say anything.

It is usually not necessary to specify that implementers should not
build
broken implementations.

> 
> How do you prevent the incorrect Proxied ARP response without sharing
> the endnode discovery over the truly relevant span, rather than just
> within the VLAN?

So, here's my take:

o	If SVL is in use, then it is usually necessary that all of the
bridges
	have a consistent view of which VLANS are shared (this is
independent 
	of a specific FID <-> VID mapping except that the same VIDs
SHOULD be
	mapped to a single locally determined FID in all bridges in a
given
	deployment).
o	This would typically be a matter of configuration, although it
is 
	possible that configration tools may be used to help ensure that
a
	consistent picture is "shared" among bridges.
o	Existence of VLANs in a deployment typically means configuration
is
	required to make the VLANs work (hence this is not strictly a
_new_ 
	requirement to steer us away from the plug-and-play objective).
o	Whether SVL, or IVL, is used - if IP-MAC binding information is
only
	distributed where appropriate (based on VID) at each RBridge,
then
	it is difficult for me to see how incorrect proxied ARP
responses 
	would occur.
o	Even if all IP-MAC binding information was distributed to all
RBridges,
	as long as this information is scoped by the designated RBridge
in any
	ARP responses it might provide (by relevant VID in the request),
then
	it is still difficult to see how incorrect proxied ARP responses

	might occur.

> 
> This is a more pressing issue than just Shared vs. Independent
Learning.
> Mandating that all RBridges use Independent Learning is undesirable to
> the extent that specifications should be minimalistic and impose as
> few constraints as possible. But realistically I doubt that Shared
> Learning is really desirable for RBridges.

Okay.  Do I get to say "I told you so" when you get aroud to eating that
opinion?  :-)

> 
> The shared IP subnet issue, however, has nothing to do with RBridges.
> Forbidding sharing of IP subnets across VLANs would be considerably
> more drastic, and presumably outside the WG's scope. For one thing
> it would directly contradict RFC 3069:
> 
>    The VLAN [802.1Q] aggregation technique described in this document
>    provides a mechanism by which hosts that reside within the same
>    physical switched infrastructure, but separate virtual broadcast
>    domains, may be addressed from the same IPv4 subnet and may share a
>    common default gateway IPv4 address.
> 
> ...
> 
> 
>    Essentially, what occurs is that each sub-VLAN (customer) remains
>    within a separate broadcast domain.  One or more sub-VLANs belong
>    to a super-VLAN, and utilize the default gateway IP address of the
>    super-VLAN.  Hosts within the sub-VLANs are numbered out of IP
>    subnets associated with the super-VLAN, and their IP subnet masking
>    information reflects that of the super-VLAN subnet.

I think we should avoid the "super-VLAN" concept.  What you seem to
be talking about is IP subnets, rather than VLAN aggregation.

> 
>    If desired, the super-VLAN router performs functions similar to
>    Proxy ARP to enable communication between hosts that are members
>    of different sub-VLANs.
> 
> 

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 16:51:50 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 18372

Silvano,

	Possibly this was meant as a reply to a different message?

	If you look at the text below, one of my early paragraphs
(the one that starts "In one case, there may be a VLAN aware bridge 
between the IP router and the 4 VLANs ...") is nearly identical to
the illustration you describe.  So, I think we can assume we're at
least talking about the same thing.

	Which leaves me wondering what your point is...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 5:45 PM
> To: Eric Gray (LO/EUS); Radia Perlman
> Cc: [email-masked]
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> 
> 
> Eric,
> 
> Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs.
> In figure B-4 assume a router instead of the Server.
> As you can see the link between the router and the Bridge is untagged.
> Being the link untagged the router will have a single sub-interface
> associated to a single IP subnet.
> 
> Nonetheless it will be on the Red, Blue and Purple Asymmetric 
> (Private)
> VLANs. The frames received by the router will be legal IP frames.
> 
> I don't know if we are in agreement, but this is the most pertinent
> example I am able to come out with.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Monday, April 02, 2007 2:08 PM
> > To: Radia Perlman
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should
> > wecare?
> > 
> > Radia,
> > 
> > 	WRT your quiz question:
> > 
> > 	To expand on Sanjay's earlier reply (assuming I've understood
> > your questions correctly), you've assumed an essentially broken IP
> > subnet configuration.  That doesn't mean that it wouldn't work with
> > today's devices, but it does mean that it is not working the way I
> > believe you have described it.
> > 
> > 	Sanjay is correct about ARP as a function of the IP router.  A
> > "smart bridge" may incorporate enough of the routing 
> function to help
> > out in this scenario, but is not a standards defined implementation
> > if it does.  There is a fairly long list of caveats that must apply
> > in that case, and this is not an area we want to explore - unless it
> > turns out to be the case that someone does this incorrectly and we
> > find that we need to be compatible with the incorrect 
> implementation.
> > 
> > 	In one case, there may be a VLAN aware bridge between the IP
> > router and the 4 VLANs you describe.  In implementations, this VLAN
> > aware bridge may actually be co-located with the IP router.  In this
> > case, the VLAN aware bridge may very well forward un-tagged 
> frames to
> > and from the (potentially co-located) IP router, across one 
> (possibly
> > logical) link, allowing the router to enjoy simplified ARP learning.
> > This VLAN aware bridge then provides the VLAN translation 
> function to
> > allow proper forwarding of data within the subnet.
> > 
> > 	Note that - in this case - the VLAN aware bridge is translating
> > untagged frames into tagged frames (and vice versa), but is 
> not doing
> > the similar translation (one tag to another) between distinct tagged
> > VLANs.  That function must be done by a router - hence the router is
> > supposed to handle ARP responses and associate IP-to-MAC so 
> that it is
> > in the forwarding path (much as Sanjay described).
> > 
> > 	Because you're assuming over-lapping assignments of IP
> > addresses,
> > this scenario causes problems for a standards defined IP router
> because
> > it will see all of the subnet-local IP destinations as 
> being part of a
> > single IP subnet, and will - most likely - try to force the 
> senders in
> > the IP sub-network to send directly to destination MAC 
> addresses - via
> > ARP responses (assuming single subnet) and IP re-directs.
> > 
> > 	As you probably realize, that situation would be pathological.
> > 
> > 	This situation arises in real networks, and has been addressed
> > in real implementations.  One approach blurs the distinction between
> > the VLAN aware bridging and standard routing functions.
> > 
> > 	For the co-located case, this is not hard: the router sees more
> > than one VLAN on a single physical interface, but is configured (or
> > learns) that these multiple logical interfaces are all part of the
> same
> > IP subnet.  In this case, the router is required to bridge 
> between the
> > multiple logical interfaces that are part of a single logical IP
> subnet.
> > 
> > 	An implementation may instantiate a VLAN-aware bridging instance
> > 
> > to handle this role.  In this case, the boundary between 
> bridging and
> > routing becomes blurred because the same physical device is involved
> > in both - making the handling of ARP and appropriate VLAN forwarding
> > work because the router can carefully choose which role it 
> assumes in
> > dealing with ARP and forwarding of traffic.  If this takes 
> place in a
> > single device, it is possible to avoid many of the caveats 
> that would
> > apply if this particular form of cheating was distributed.
> > 
> > 	In the non-colocated case, a bit more work is required to make
> > the scenario functional and a number of caveats cannot be completely
> > avoided.  For example, if there is exactly one VLAN aware bridge in
> > the local IP-subnet, it is possible for that bridge to "proxy" ARP
> > responses (as if it were a router) and forward frames between VLANs.
> > If there are multiple VLAN aware bridges, then it should be possible
> > to configure them so that only one of them performs this function.
> > A more complex configuration is possible, but such a 
> configuration is
> > workable only if there is no potential forwarding path 
> (including any
> > possible failure mode) which results in multiple VLAN ID 
> translations
> > - and forwarding - between multiple VLAN aware bridges, in a loop.
> > 
> > 	For RBridges, the situation we need to avoid is as shown below:
> > 
> >                  Host Group-P
> >                     A
> >                     |
> >              _____VLAN-A______
> >             |                 |
> >             V                 V
> >    R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host
> >                                                             Group Q
> > 
> > 	If both the RBridges and the VLAN aware Bridge (VAB) are doing
> > Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is
> > possible for frames to be forwarded consistently back and forth
> between
> > the RBridge CRED/Campus and VAB.  Moreover, it is possible 
> for a host
> > in group P in this diagram, to get a copy of each frame each time it
> > goes around.
> > 
> > 	Still another alternative is that IP addresses are not assigned
> > as you suggest, and VLAN tags are used simply to share physical link
> > resources - while maintaining IP address space separation.  Many of
> > the router vendors today (I believe) would claim that the 
> alternative
> > is pathological...
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > > Sent: Thursday, March 29, 2007 2:56 AM
> > > To: [email-masked]
> > > 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
> > >
> > >
> > >
> > > [email-masked]
> > [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 14:44:41 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 16645

Eric,

Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs.
In figure B-4 assume a router instead of the Server.
As you can see the link between the router and the Bridge is untagged.
Being the link untagged the router will have a single sub-interface
associated to a single IP subnet.

Nonetheless it will be on the Red, Blue and Purple Asymmetric (Private)
VLANs. The frames received by the router will be legal IP frames.

I don't know if we are in agreement, but this is the most pertinent
example I am able to come out with.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Monday, April 02, 2007 2:08 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
> wecare?
> 
> Radia,
> 
> 	WRT your quiz question:
> 
> 	To expand on Sanjay's earlier reply (assuming I've understood
> your questions correctly), you've assumed an essentially broken IP
> subnet configuration.  That doesn't mean that it wouldn't work with
> today's devices, but it does mean that it is not working the way I
> believe you have described it.
> 
> 	Sanjay is correct about ARP as a function of the IP router.  A
> "smart bridge" may incorporate enough of the routing function to help
> out in this scenario, but is not a standards defined implementation
> if it does.  There is a fairly long list of caveats that must apply
> in that case, and this is not an area we want to explore - unless it
> turns out to be the case that someone does this incorrectly and we
> find that we need to be compatible with the incorrect implementation.
> 
> 	In one case, there may be a VLAN aware bridge between the IP
> router and the 4 VLANs you describe.  In implementations, this VLAN
> aware bridge may actually be co-located with the IP router.  In this
> case, the VLAN aware bridge may very well forward un-tagged frames to
> and from the (potentially co-located) IP router, across one (possibly
> logical) link, allowing the router to enjoy simplified ARP learning.
> This VLAN aware bridge then provides the VLAN translation function to
> allow proper forwarding of data within the subnet.
> 
> 	Note that - in this case - the VLAN aware bridge is translating
> untagged frames into tagged frames (and vice versa), but is not doing
> the similar translation (one tag to another) between distinct tagged
> VLANs.  That function must be done by a router - hence the router is
> supposed to handle ARP responses and associate IP-to-MAC so that it is
> in the forwarding path (much as Sanjay described).
> 
> 	Because you're assuming over-lapping assignments of IP
> addresses,
> this scenario causes problems for a standards defined IP router
because
> it will see all of the subnet-local IP destinations as being part of a
> single IP subnet, and will - most likely - try to force the senders in
> the IP sub-network to send directly to destination MAC addresses - via
> ARP responses (assuming single subnet) and IP re-directs.
> 
> 	As you probably realize, that situation would be pathological.
> 
> 	This situation arises in real networks, and has been addressed
> in real implementations.  One approach blurs the distinction between
> the VLAN aware bridging and standard routing functions.
> 
> 	For the co-located case, this is not hard: the router sees more
> than one VLAN on a single physical interface, but is configured (or
> learns) that these multiple logical interfaces are all part of the
same
> IP subnet.  In this case, the router is required to bridge between the
> multiple logical interfaces that are part of a single logical IP
subnet.
> 
> 	An implementation may instantiate a VLAN-aware bridging instance
> 
> to handle this role.  In this case, the boundary between bridging and
> routing becomes blurred because the same physical device is involved
> in both - making the handling of ARP and appropriate VLAN forwarding
> work because the router can carefully choose which role it assumes in
> dealing with ARP and forwarding of traffic.  If this takes place in a
> single device, it is possible to avoid many of the caveats that would
> apply if this particular form of cheating was distributed.
> 
> 	In the non-colocated case, a bit more work is required to make
> the scenario functional and a number of caveats cannot be completely
> avoided.  For example, if there is exactly one VLAN aware bridge in
> the local IP-subnet, it is possible for that bridge to "proxy" ARP
> responses (as if it were a router) and forward frames between VLANs.
> If there are multiple VLAN aware bridges, then it should be possible
> to configure them so that only one of them performs this function.
> A more complex configuration is possible, but such a configuration is
> workable only if there is no potential forwarding path (including any
> possible failure mode) which results in multiple VLAN ID translations
> - and forwarding - between multiple VLAN aware bridges, in a loop.
> 
> 	For RBridges, the situation we need to avoid is as shown below:
> 
>                  Host Group-P
>                     A
>                     |
>              _____VLAN-A______
>             |                 |
>             V                 V
>    R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host
>                                                             Group Q
> 
> 	If both the RBridges and the VLAN aware Bridge (VAB) are doing
> Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is
> possible for frames to be forwarded consistently back and forth
between
> the RBridge CRED/Campus and VAB.  Moreover, it is possible for a host
> in group P in this diagram, to get a copy of each frame each time it
> goes around.
> 
> 	Still another alternative is that IP addresses are not assigned
> as you suggest, and VLAN tags are used simply to share physical link
> resources - while maintaining IP address space separation.  Many of
> the router vendors today (I believe) would claim that the alternative
> is pathological...
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Thursday, March 29, 2007 2:56 AM
> > To: [email-masked]
> > 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
> >
> >
> >
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 14:37:29 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 2988

[email-masked] wrote:
> Eric,
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Eric Gray (LO/EUS) Sent: Monday, April 02, 2007 1:50 PM
>> To: Radia Perlman
>> Cc: [email-masked]
>> Subject: Re: [rbridge] Shared VLAN learning: What is it and why
>> should wecare? 
>> 
>> Radia,
>> 
>> 	There is an interesting problem that might arise out of a router
>> receiving VLAN tagged frames without being aware that they are
>> tagged. 
>> 
> 
> This is not the case, unless there is a misconfiguration. A
> Router has a
> concept of an interface (e.g. eth0, the Ethernet port) and of
> sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to
> sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit
> or implicit, is used to select a sub-interface. The
> sub-interface has an
> IP address and a netmask.
> 
> -- Silvano
> 
> 

If you review the email I cited previously, and then do some googling,
you'll see that assigning each VLAN a recognizable IP subnet is merely
the predominant technique -- it is not the only one, and it is not a
requirement.

Do you agree that when a router connects to multiple VLANs that share
an IP subnet that having the RBridge generate a Proxied ARP response
to the *same* IP address on each VLAN is a problem that needs to
be solved?

How do you prevent the incorrect Proxied ARP response without sharing
the endnode discovery over the truly relevant span, rather than just
within the VLAN?

This is a more pressing issue than just Shared vs. Independent Learning.
Mandating that all RBridges use Independent Learning is undesirable to
the extent that specifications should be minimalistic and impose as
few constraints as possible. But realistically I doubt that Shared
Learning is really desirable for RBridges.

The shared IP subnet issue, however, has nothing to do with RBridges.
Forbidding sharing of IP subnets across VLANs would be considerably
more drastic, and presumably outside the WG's scope. For one thing
it would directly contradict RFC 3069:

   The VLAN [802.1Q] aggregation technique described in this document
   provides a mechanism by which hosts that reside within the same
   physical switched infrastructure, but separate virtual broadcast
   domains, may be addressed from the same IPv4 subnet and may share a
   common default gateway IPv4 address.

...

   Essentially, what occurs is that each sub-VLAN (customer) remains
   within a separate broadcast domain.  One or more sub-VLANs belong to
   a super-VLAN, and utilize the default gateway IP address of the
   super-VLAN.  Hosts within the sub-VLANs are numbered out of IP
   subnets associated with the super-VLAN, and their IP subnet masking
   information reflects that of the super-VLAN subnet.

   If desired, the super-VLAN router performs functions similar to Proxy
   ARP to enable communication between hosts that are members of
   different sub-VLANs.

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 16:15:35 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 16638

Silvano,

	Uhhhh, yes, but that makes the router aware of VLANs - doesn't
it?

	Getting back to Radia's statement (below) - "So therefore, I
(Radia)
am assuming that the IP router is not supposed to know that the link is 
subdivided into VLANs."

	I think you need to review the order of the dialog.  I was
pointing
out that Radia's assumption of router ignorance of VIDs would be a
problem.
You apparently would argue that routers are not ignorant of VIDs.

	So, unless I am misunderstanding you, I believe we are in
agreement.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 5:06 PM
> To: Eric Gray (LO/EUS); Radia Perlman
> Cc: [email-masked]
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> Importance: High
> 
> Eric,
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Monday, April 02, 2007 1:50 PM
> > To: Radia Perlman
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should
> > wecare?
> > 
> > Radia,
> > 
> > 	There is an interesting problem that might arise out of
> > a router receiving VLAN tagged frames without being aware that
> > they are tagged.
> > 
> 
> This is not the case, unless there is a misconfiguration. A 
> Router has a
> concept of an interface (e.g. eth0, the Ethernet port) and of
> sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to
> sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit
> or implicit, is used to select a sub-interface. The 
> sub-interface has an
> IP address and a netmask.
> 
> -- Silvano
> 
> 
> > 	A router is a MAC termination point - i.e. - it is an
> > end-station at the MAC layer.  But it is also a forwarding
> > device.  Hence the slack that might apply to a host receiving
> > a MAC frame with "stuff" in the header it doesn't understand,
> > shouldn't be allowed for a router.
> > 
> > 	Also, many routers do understand that it is possible to
> > have the same IP subnet connected to multiple logical interfaces.
> > That was where the original "Bridging Router" (or BRouter) came
> > from.
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:[email-masked]]
> > > Sent: Monday, April 02, 2007 4:10 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: [email-masked]
> > > Subject: Re: [rbridge] Shared VLAN learning: What is it and
> > > why should we care?
> > > Importance: High
> > >
> > > My understanding is that shared VLANs assume
> > > IP routers are not aware of VLANs.
> > >
> > > My understanding is that the way it would work if the IP
> > > router R *was*
> > > aware of
> > > VLANs, is that R would treat the link as 4 separate links 
> (by using
> > > VLANs), and then the IP addresses
> > > on the 4 different links (VLANs A, B, C, and D) would have to have
> > > different IP prefixes.
> > >
> > > So therefore, I am assuming that the IP router is not
> > > supposed to know
> > > that the link is subdivided into VLANs.
> > >
> > > So my understanding of the problem in this case is:
> > >
> > > a) single IP address block shared by different communities
> > > b) desire to isolate these communities from layer 2 broadcast
> traffic
> > > from each other
> > > c) desire to share some services (like DHCP and IP 
> routers), without
> > > those services being aware
> > > that the communities are separate
> > >
> > > As for my question about proxy ARP, to further add
> > > to the confusion -- some people are assuming the
> > > bridge/RBridge will be
> > > doing
> > > the proxy ARP, and some others are assuming the router is.
> > >
> > > And actually, after talking offline with Joel Halpern, I'll
> > > send another
> > > note with two different proposals
> > > (one just a cleanup of what I originally wrote, and the other a
> > > different approach) for solving
> > > that vaguely stated problem.
> > >
> > > Radia
> > >
> > >
> > >
> > >
> > >
> > > Eric Gray (LO/EUS) wrote:
> > >
> > > >Radia,
> > > >
> > > >	Let me try to re-state your explanation to see if I understand
> > > >it...
> > > >
> > > >	You believe that the problem that shared VLAN learning is used
> > > >to solve is conservation of IP addresses used in a single IP
> subnet,
> > > >and that it is necessary to use shared VLAN learning to keep
> routers
> > > >(in the subnet) from having to re-learn MAC+IP 
> associations across
> a
> > > >set of VLANs in that same IP subnet, is that correct?
> > > >
> > > >Thanks!
> > > >
> > > >--
> > > >Eric Gray
> > > >Principal Engineer
> > > >Ericsson
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > >>[mailto:[email-masked]] On Behalf Of Radia Perlman
> > > >>Sent: Thursday, March 29, 2007 2:56 AM
> > > >>To: [email-masked]
> > > >>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
> > > >>
> > > >>
> > > >>
> > > >>[email-masked]
> > [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 16:08:23 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 15029

Radia,

	WRT your quiz question:

	To expand on Sanjay's earlier reply (assuming I've understood 
your questions correctly), you've assumed an essentially broken IP
subnet configuration.  That doesn't mean that it wouldn't work with
today's devices, but it does mean that it is not working the way I
believe you have described it.

	Sanjay is correct about ARP as a function of the IP router.  A
"smart bridge" may incorporate enough of the routing function to help
out in this scenario, but is not a standards defined implementation
if it does.  There is a fairly long list of caveats that must apply 
in that case, and this is not an area we want to explore - unless it
turns out to be the case that someone does this incorrectly and we
find that we need to be compatible with the incorrect implementation.

	In one case, there may be a VLAN aware bridge between the IP
router and the 4 VLANs you describe.  In implementations, this VLAN
aware bridge may actually be co-located with the IP router.  In this
case, the VLAN aware bridge may very well forward un-tagged frames to
and from the (potentially co-located) IP router, across one (possibly
logical) link, allowing the router to enjoy simplified ARP learning.
This VLAN aware bridge then provides the VLAN translation function to
allow proper forwarding of data within the subnet.

	Note that - in this case - the VLAN aware bridge is translating
untagged frames into tagged frames (and vice versa), but is not doing
the similar translation (one tag to another) between distinct tagged
VLANs.  That function must be done by a router - hence the router is
supposed to handle ARP responses and associate IP-to-MAC so that it is 
in the forwarding path (much as Sanjay described).

	Because you're assuming over-lapping assignments of IP
addresses,
this scenario causes problems for a standards defined IP router because 
it will see all of the subnet-local IP destinations as being part of a
single IP subnet, and will - most likely - try to force the senders in 
the IP sub-network to send directly to destination MAC addresses - via
ARP responses (assuming single subnet) and IP re-directs.

	As you probably realize, that situation would be pathological.

	This situation arises in real networks, and has been addressed
in real implementations.  One approach blurs the distinction between 
the VLAN aware bridging and standard routing functions.  

	For the co-located case, this is not hard: the router sees more
than one VLAN on a single physical interface, but is configured (or
learns) that these multiple logical interfaces are all part of the same
IP subnet.  In this case, the router is required to bridge between the
multiple logical interfaces that are part of a single logical IP subnet.

	An implementation may instantiate a VLAN-aware bridging instance

to handle this role.  In this case, the boundary between bridging and
routing becomes blurred because the same physical device is involved
in both - making the handling of ARP and appropriate VLAN forwarding 
work because the router can carefully choose which role it assumes in
dealing with ARP and forwarding of traffic.  If this takes place in a
single device, it is possible to avoid many of the caveats that would
apply if this particular form of cheating was distributed.

	In the non-colocated case, a bit more work is required to make
the scenario functional and a number of caveats cannot be completely
avoided.  For example, if there is exactly one VLAN aware bridge in
the local IP-subnet, it is possible for that bridge to "proxy" ARP
responses (as if it were a router) and forward frames between VLANs.
If there are multiple VLAN aware bridges, then it should be possible 
to configure them so that only one of them performs this function.
A more complex configuration is possible, but such a configuration is
workable only if there is no potential forwarding path (including any
possible failure mode) which results in multiple VLAN ID translations
- and forwarding - between multiple VLAN aware bridges, in a loop.

	For RBridges, the situation we need to avoid is as shown below:

                 Host Group-P
                    A
                    |
             _____VLAN-A______
            |                 |
            V                 V
   R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host
                                                            Group Q

	If both the RBridges and the VLAN aware Bridge (VAB) are doing
Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is 
possible for frames to be forwarded consistently back and forth between
the RBridge CRED/Campus and VAB.  Moreover, it is possible for a host
in group P in this diagram, to get a copy of each frame each time it
goes around.

	Still another alternative is that IP addresses are not assigned
as you suggest, and VLAN tags are used simply to share physical link
resources - while maintaining IP address space separation.  Many of
the router vendors today (I believe) would claim that the alternative
is pathological...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, March 29, 2007 2:56 AM
> To: [email-masked]
> 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
> 
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 14:05:47 -0700
From: "Silvano Gai" <[email-masked]>
To: "Eric Gray \(LO/EUS\)" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should wecare?
Status: RO
Content-Length: 14852

Eric,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Monday, April 02, 2007 1:50 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
> wecare?
> 
> Radia,
> 
> 	There is an interesting problem that might arise out of
> a router receiving VLAN tagged frames without being aware that
> they are tagged.
> 

This is not the case, unless there is a misconfiguration. A Router has a
concept of an interface (e.g. eth0, the Ethernet port) and of
sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to
sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit
or implicit, is used to select a sub-interface. The sub-interface has an
IP address and a netmask.

-- Silvano

> 	A router is a MAC termination point - i.e. - it is an
> end-station at the MAC layer.  But it is also a forwarding
> device.  Hence the slack that might apply to a host receiving
> a MAC frame with "stuff" in the header it doesn't understand,
> shouldn't be allowed for a router.
> 
> 	Also, many routers do understand that it is possible to
> have the same IP subnet connected to multiple logical interfaces.
> That was where the original "Bridging Router" (or BRouter) came
> from.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson
> 
> > -----Original Message-----
> > From: Radia Perlman [mailto:[email-masked]]
> > Sent: Monday, April 02, 2007 4:10 PM
> > To: Eric Gray (LO/EUS)
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and
> > why should we care?
> > Importance: High
> >
> > My understanding is that shared VLANs assume
> > IP routers are not aware of VLANs.
> >
> > My understanding is that the way it would work if the IP
> > router R *was*
> > aware of
> > VLANs, is that R would treat the link as 4 separate links (by using
> > VLANs), and then the IP addresses
> > on the 4 different links (VLANs A, B, C, and D) would have to have
> > different IP prefixes.
> >
> > So therefore, I am assuming that the IP router is not
> > supposed to know
> > that the link is subdivided into VLANs.
> >
> > So my understanding of the problem in this case is:
> >
> > a) single IP address block shared by different communities
> > b) desire to isolate these communities from layer 2 broadcast
traffic
> > from each other
> > c) desire to share some services (like DHCP and IP routers), without
> > those services being aware
> > that the communities are separate
> >
> > As for my question about proxy ARP, to further add
> > to the confusion -- some people are assuming the
> > bridge/RBridge will be
> > doing
> > the proxy ARP, and some others are assuming the router is.
> >
> > And actually, after talking offline with Joel Halpern, I'll
> > send another
> > note with two different proposals
> > (one just a cleanup of what I originally wrote, and the other a
> > different approach) for solving
> > that vaguely stated problem.
> >
> > Radia
> >
> >
> >
> >
> >
> > Eric Gray (LO/EUS) wrote:
> >
> > >Radia,
> > >
> > >	Let me try to re-state your explanation to see if I understand
> > >it...
> > >
> > >	You believe that the problem that shared VLAN learning is used
> > >to solve is conservation of IP addresses used in a single IP
subnet,
> > >and that it is necessary to use shared VLAN learning to keep
routers
> > >(in the subnet) from having to re-learn MAC+IP associations across
a
> > >set of VLANs in that same IP subnet, is that correct?
> > >
> > >Thanks!
> > >
> > >--
> > >Eric Gray
> > >Principal Engineer
> > >Ericsson
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >>[mailto:[email-masked]] On Behalf Of Radia Perlman
> > >>Sent: Thursday, March 29, 2007 2:56 AM
> > >>To: [email-masked]
> > >>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
> > >>
> > >>
> > >>
> > >>[email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 15:50:05 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 13361

Radia,

	There is an interesting problem that might arise out of
a router receiving VLAN tagged frames without being aware that
they are tagged.  

	A router is a MAC termination point - i.e. - it is an 
end-station at the MAC layer.  But it is also a forwarding
device.  Hence the slack that might apply to a host receiving
a MAC frame with "stuff" in the header it doesn't understand,
shouldn't be allowed for a router.

	Also, many routers do understand that it is possible to
have the same IP subnet connected to multiple logical interfaces.
That was where the original "Bridging Router" (or BRouter) came
from.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 4:10 PM
> To: Eric Gray (LO/EUS)
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> Importance: High
> 
> My understanding is that shared VLANs assume
> IP routers are not aware of VLANs.
> 
> My understanding is that the way it would work if the IP 
> router R *was* 
> aware of
> VLANs, is that R would treat the link as 4 separate links (by using 
> VLANs), and then the IP addresses
> on the 4 different links (VLANs A, B, C, and D) would have to have 
> different IP prefixes.
> 
> So therefore, I am assuming that the IP router is not 
> supposed to know 
> that the link is subdivided into VLANs.
> 
> So my understanding of the problem in this case is:
> 
> a) single IP address block shared by different communities
> b) desire to isolate these communities from layer 2 broadcast traffic 
> from each other
> c) desire to share some services (like DHCP and IP routers), without 
> those services being aware
> that the communities are separate
> 
> As for my question about proxy ARP, to further add
> to the confusion -- some people are assuming the 
> bridge/RBridge will be 
> doing
> the proxy ARP, and some others are assuming the router is.
> 
> And actually, after talking offline with Joel Halpern, I'll 
> send another 
> note with two different proposals
> (one just a cleanup of what I originally wrote, and the other a 
> different approach) for solving
> that vaguely stated problem.
> 
> Radia
> 
> 
> 
> 
> 
> Eric Gray (LO/EUS) wrote:
> 
> >Radia,
> >
> >	Let me try to re-state your explanation to see if I understand 
> >it...
> >
> >	You believe that the problem that shared VLAN learning is used
> >to solve is conservation of IP addresses used in a single IP subnet, 
> >and that it is necessary to use shared VLAN learning to keep routers 
> >(in the subnet) from having to re-learn MAC+IP associations across a
> >set of VLANs in that same IP subnet, is that correct?
> >
> >Thanks!
> >
> >--
> >Eric Gray
> >Principal Engineer
> >Ericsson  
> >
> >  
> >
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[mailto:[email-masked]] On Behalf Of Radia Perlman
> >>Sent: Thursday, March 29, 2007 2:56 AM
> >>To: [email-masked]
> >>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
> >>
> >>
> >>
> >>[email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 13:11:05 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 3770

Eric Gray wrote:
> Radia,
> 
> 	Let me try to re-state your explanation to see if I understand
it...
> 
> 	You believe that the problem that shared VLAN learning
> is used to solve is conservation of IP addresses used in a
> single IP subnet, and that it is necessary to use shared VLAN
> learning to keep routers (in the subnet) from having to
> re-learn MAC+IP associations across a set of VLANs in that
> same IP subnet, is that correct?
> 

It's a more fundamental problem that re-learning, and the goal
could more properly be stated as avoiding the neccesity of 
creating distinct subnets. Sharing the IP subnet does conserve
IP Addresses, but more importantly it conserves the effort of
dividing the IP addresses up into VLAN specific portions, and
of updating DNS entries when a host migrates to a new VLAN, etc.

There was actually a very good summary of the usage of such
a feature on a BSD list in 2005:

http://lists.freebsd.org/pipermail/freebsd-net/2005-November/009064.html

Different switches having different VID/FID mappings is confusing,
but ultimately it isn't that bad, especially since global MAC addresses
do tend to be unique within a campus even when they are being assigned
by decidedly non-global techniques.

But the associated ARP Proxy has a totally different problem.
Specifically, the scenario is where the *same* IP subnet is
used for two or more VLANs. Or to be more precise, what is
to *appear* to be one IP subnet to the outside world is
actually two or more VLAN divided subnets, and the assignment
of specific IP addresses to specific VLANs is dynamically
learned rather than administered.

So if RBridges scope the MAC/IP learning to a VID
specific instance then two RBridges can have
contradictory information about the meaning of
an IP address.

In fact, a single RBridge could have contradictory
information in two VID-specific instances about the
same IP address.

This creates a severe problem for the router (existing
router, mind you) that is the ingress point to this
shared IP subnet. When it has a received IP datagram
to x.y.z.1, and no entry in its ARP table, it will
have no idea which VLAN the datagram belongs to.
Therefore it will ARP on all VLANs to see where
it goes, and it expects to get at most one reply
because an IP address is only supposed to be
assigned to a single host. Not that the router
will get upset or have a fault. It will more
likely assume to all replies are redundant and
therefore it can always just use the most recent
one without bothering to remember any prior ARP
responses.

So, when a host migrates from VLAN A to VLAN B,
we have a problem if the RBridge on VLAN B does
not share its discovery with the RBridge on VLAN
A (and the two are part of a group / share the
same IP subnet). If the discovery is shared, then
the RBridge on VLAN A will delete its entry for
the IP address, and when the Router next ARPs
it will only get a response from VLAN B.

So while the groups that Radia describes will
solve the problem, the fundamental justification
for the solution arises when the semantics of
an IP subnet span multiple VIDs. When the
IP Address retained for Proxy ARP purposes
has a wider scope that the VLAN dissemination
of discovery cannot be confined to the VLAN.

And while I could see actually making the determination
based on IP Addressing, I don't see any real advantage
to doing so.

While we've been refining the examples, the underlying
problem remains as originally stated. Since RBridges
provide a distributed Proxy ARP service they simply
must avoid having contradictory information held 
by different RBridges (they can and should have
different subsets of the entire picutre, but no
RBridge should ever have data that contradicts the
data that other RBridgess have).

Date: Mon, 02 Apr 2007 13:10:04 -0700
From: Radia Perlman <[email-masked]>
To: "Eric Gray (LO/EUS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 11669

My understanding is that shared VLANs assume
IP routers are not aware of VLANs.

My understanding is that the way it would work if the IP router R *was* 
aware of
VLANs, is that R would treat the link as 4 separate links (by using 
VLANs), and then the IP addresses
on the 4 different links (VLANs A, B, C, and D) would have to have 
different IP prefixes.

So therefore, I am assuming that the IP router is not supposed to know 
that the link is subdivided into VLANs.

So my understanding of the problem in this case is:

a) single IP address block shared by different communities
b) desire to isolate these communities from layer 2 broadcast traffic 
from each other
c) desire to share some services (like DHCP and IP routers), without 
those services being aware
that the communities are separate

As for my question about proxy ARP, to further add
to the confusion -- some people are assuming the bridge/RBridge will be 
doing
the proxy ARP, and some others are assuming the router is.

And actually, after talking offline with Joel Halpern, I'll send another 
note with two different proposals
(one just a cleanup of what I originally wrote, and the other a 
different approach) for solving
that vaguely stated problem.

Radia

Eric Gray (LO/EUS) wrote:

>Radia,
>
>	Let me try to re-state your explanation to see if I understand 
>it...
>
>	You believe that the problem that shared VLAN learning is used
>to solve is conservation of IP addresses used in a single IP subnet, 
>and that it is necessary to use shared VLAN learning to keep routers 
>(in the subnet) from having to re-learn MAC+IP associations across a
>set of VLANs in that same IP subnet, is that correct?
>
>Thanks!
>
>--
>Eric Gray
>Principal Engineer
>Ericsson  
>
>  
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Radia Perlman
>>Sent: Thursday, March 29, 2007 2:56 AM
>>To: [email-masked]
>>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
>>
>>
>>
>>[email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 12:15:49 -0700
From: "J. R. Rivers" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 1880

More importantly is that sometimes R does reply to local ARPs and
sometimes it doesn't... as part of system vendor feature definitions.
Generally, I've always thought of ARP as a router/host function.  As the
lines blur between routers and switches, there have been many features
introduced into "switches" based on router functionality.

I'd argue that this is one great reason to leave ARP out of TRILL so
that any of these extensions can continue to work based on their
expectations of the underlying L2 network.

JR

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Caitlin Bestler
> Sent: Monday, April 02, 2007 11:21 AM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> Radia Perlman wrote:
> 
> > 
> > My question was -- how does R know *not* to respond to the
> > ARP? Or does sometimes R wind up forwarding between endnodes
> > in the same VLAN unnecessarily and we don't care because it's
> > not *incorrect*, it's just suboptimal?
> > 
> 
> I'm not sure what the relevant specs are, but my understanding
> has always been that a Proxy ARP only answers an ARP request
> if it is somehow between the requester and the machine it
> is proxying for.
> 
> My direct experience with this all relates to Cable Modems,
> so I haven't thought about corner cases where the "between"
> status might not be blatantly obvious. And in that case 
> flooding irrelevant packets from every home network upstream
> was not "suboptimal", it would have been a network killer.
> So luckily the distinction between the home network and
> the cable network was easily made.
> 
> 
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 14:05:30 -0500
From: "Eric Gray \(LO/EUS\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 10370

Radia,

	Let me try to re-state your explanation to see if I understand 
it...

	You believe that the problem that shared VLAN learning is used
to solve is conservation of IP addresses used in a single IP subnet, 
and that it is necessary to use shared VLAN learning to keep routers 
(in the subnet) from having to re-learn MAC+IP associations across a
set of VLANs in that same IP subnet, is that correct?

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Thursday, March 29, 2007 2:56 AM
> To: [email-masked]
> 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
> 
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 2 Apr 2007 11:21:28 -0700
From: "Caitlin Bestler" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 850

Radia Perlman wrote:

> 
> My question was -- how does R know *not* to respond to the
> ARP? Or does sometimes R wind up forwarding between endnodes
> in the same VLAN unnecessarily and we don't care because it's
> not *incorrect*, it's just suboptimal?
> 

I'm not sure what the relevant specs are, but my understanding
has always been that a Proxy ARP only answers an ARP request
if it is somehow between the requester and the machine it
is proxying for.

My direct experience with this all relates to Cable Modems,
so I haven't thought about corner cases where the "between"
status might not be blatantly obvious. And in that case 
flooding irrelevant packets from every home network upstream
was not "suboptimal", it would have been a network killer.
So luckily the distinction between the home network and
the cable network was easily made.

Content-class: urn:content-classes:message
Date: Sun, 1 Apr 2007 16:54:08 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Caitlin Bestler" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 4245

Yep, there are cases of such sub-optimal routing with private vlan. Host
can sometimes receive 2 arp responses, and then there is a chance of
host caching the arp response from the router. 

In private vlan, there are isolated secondary vlans and community
secondary vlans. Any port with isolated secondary vlan cannot tal to any
other port with same isolated secondary vlan. However, ports within the
same community secondary vlan can talk to each other. Of course, in
addition, these ports can talk to port of primary vlan (typically going
towards the router). So, in case ip-A1 and ip-A2 are sitting behind
community vlans, hosts may receive 2 arp responses. 

-Sanjay 

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Sunday, April 01, 2007 12:03 AM
To: Caitlin Bestler
Cc: Sanjay Sane (sanjays); [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
we care?

Argh! I'm really confused.

We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D),
it would be forwarded by the IP router R. And that the RBridge is not
doing this. 
Though someone could build
a project that was a combined router/RBridge.

But Sanjay -- I think you misunderstood my question. So let me restate
it.

Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D,
all in the same IP subnet. The router R is in VLAN Z. The VLAN grouping
is {primary=Z, secondaries = A, B, C, D}.
Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a
secondary in the group goes to all links in *that* secondary, plus Z.

Do we all understand and agree so far? So now my question.

a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged
with VLAN A. The RBridges forward it to all links in A, as well as Z
(the VLAN tag of the primary in the group {Z, A, B, C, D}.
R, with MAC address r, responds to the ARP with a reply saying "ip-D has
MAC address r".
So ip-A1 and ip-D talk through R.

b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which
is tagged with VLAN A.
The RBridges forward it to all links in A as well as Z.

But now both the real target, ip-A2, as well as the router R see the
ARP. If R replies, then ip-A1 and
ip-A2 will be talking through R.

My question was -- how does R know *not* to respond to the ARP? Or does
sometimes R wind up forwarding between endnodes in the same VLAN
unnecessarily and we don't care because it's not *incorrect*, it's just
suboptimal?

Even if R sees an ARP reply from ip-A2, I don't think R can tell what
VLAN ip-A2 is in. Because the packet, once it gets to R, either doesn't
have a VLAN tag on it, or the VLAN tag says Z.

So...I'd really like to understand this...

Radia

Caitlin Bestler wrote:

>[email-masked] 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.
>
>
>  
>

Content-class: urn:content-classes:message
Date: Sun, 1 Apr 2007 08:52:37 -0700
From: "Silvano Gai" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Russ White" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning:What is it and why should wecare?)
Status: RO
Content-Length: 6577

I said it wrong, sorry, retrying:

"It is not possible to configure an RBridge to NOT act as a transit node
for a particular VLAN".

In other words: "an RBridge that does not have any port/node in VLAN A
MUST act as a transit for VLAN A if other RBridges require so".

This is different from IEEE 802.1Q in which you can decide which switch
act as transit for which VLAN.

There is only one topology in RBridges, i.e. the core topology. In
Spanning Tree potentially there are many active topologies. In RBridge
the per VLAN instance only acts as "VLAN Pruning".

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Silvano Gai
> Sent: Sunday, April 01, 2007 7:54 AM
> To: Radia Perlman; Russ White
> Cc: [email-masked]
> Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN
> learning:What is it and why should wecare?)
> 
> 
> I changed the subject because I want us to clarify one of the
> confusions:
> 
> "It is not possible to configure an RBridge to act as a transit node
for
> a particular VLAN".
> 
> In other words: "an RBridge that does not have any port/node in VLAN A
> MUST act as a transit for VLAN A if other RBridges require so".
> 
> This is different from IEEE 802.1Q in which you can decide which
switch
> act as transit for which VLAN.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Radia Perlman
> > Sent: Saturday, March 31, 2007 11:40 PM
> > To: Russ White
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and why
should
> > wecare?
> >
> > 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-----
> > >
> > >
> >
> > [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Sun, 1 Apr 2007 08:07:37 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Russ White" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] Other reason for Confusion (RE: Shared VLAN learning: What is it and why should wecare?)
Status: RO
Content-Length: 5419

The other reason for confusion is that SVL exists also without Private
VLANs.

IVL and SVL are internal switch operation mode. Se IEEE 802.1Q-2005
Section 7.4 and the begging of Appendix B. IMHO they don't pose any
particular requirement on the IP routers. Each VLAN maps to a router
sub-interface, that maps to an IP subnet.

SVL is used by Private VLANs, but there is much more to Private VLANs
that just SVL. IEEE 802.1Q has the similar concept of Asymmetric VLANs,
see EEE 802.1Q-2005 B.1.3 Asymmetric VLANs.

In future posting, please clarify if what you are stating applies in
general to SVL or it is specific of Private VLANs.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Saturday, March 31, 2007 11:40 PM
> To: Russ White
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
> wecare?
> 
> 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-----
> >
> >
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Sun, 1 Apr 2007 07:53:47 -0700
From: "Silvano Gai" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Russ White" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning: What is it and why should wecare?)
Status: RO
Content-Length: 5194

I changed the subject because I want us to clarify one of the
confusions:

"It is not possible to configure an RBridge to act as a transit node for
a particular VLAN".

In other words: "an RBridge that does not have any port/node in VLAN A
MUST act as a transit for VLAN A if other RBridges require so".

This is different from IEEE 802.1Q in which you can decide which switch
act as transit for which VLAN.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Saturday, March 31, 2007 11:40 PM
> To: Russ White
> Cc: [email-masked]
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
> wecare?
> 
> 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-----
> >
> >
> 
> [email-masked]

Date: Sun, 01 Apr 2007 00:02:38 -0700
From: Radia Perlman <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care?
Status: RO
Content-Length: 3309

Argh! I'm really confused.

We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D), 
it would be
forwarded by the IP router R. And that the RBridge is not doing this. 
Though someone could build
a project that was a combined router/RBridge.

But Sanjay -- I think you misunderstood my question. So let me restate it.

Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D, 
all in the same IP
subnet. The router R is in VLAN Z. The VLAN grouping is {primary=Z, 
secondaries = A, B, C, D}.
Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a 
secondary in the group goes
to all links in *that* secondary, plus Z.

Do we all understand and agree so far? So now my question.

a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged 
with VLAN A. The RBridges
forward it to all links in A, as well as Z (the VLAN tag of the primary 
in the group {Z, A, B, C, D}.
R, with MAC address r, responds to the ARP with a reply saying "ip-D has 
MAC address r".
So ip-A1 and ip-D talk through R.

b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which 
is tagged with VLAN A.
The RBridges forward it to all links in A as well as Z.

But now both the real target, ip-A2, as well as the router R see the 
ARP. If R replies, then ip-A1 and
ip-A2 will be talking through R.

My question was -- how does R know *not* to respond to the ARP? Or does 
sometimes R wind up
forwarding between endnodes in the same VLAN unnecessarily and we don't 
care because it's
not *incorrect*, it's just suboptimal?

Even if R sees an ARP reply from ip-A2, I don't think R can tell what 
VLAN ip-A2 is in. Because the
packet, once it gets to R, either doesn't have a VLAN tag on it, or the 
VLAN tag says Z.

So...I'd really like to understand this...

Radia

Caitlin Bestler wrote:

>[email-masked] 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.
>
>
>  
>