[rbridge] IVLANs vs OVLANs
Gray, Eric
Eric.Gray at marconi.com
Thu Nov 16 07:31:10 PST 2006
Silvano,
Sorry, but you are incorrect.
Routers are "end-stations" to a layer 2 network - hence it is
necessarily the case that TRILL frames MUST egress the RBridge CRED
prior to being delivered to a "routing function." In the same way,
any frame delivered frome a "routing function" MUST ingress the CRED
for subsequent delivery in the form of TRILL frames.
This is a logical distinction and does not - in any way - limit
your implementation choices. Logically, what happens is:
1) the TRILL encapsulation is stripped, along with the SHIM header,
2) the frame is forwarded (possibly locally, possibly only logically)
to the component that implements the "routing function",
3) the remaining Ethernet header is stripped, delivering the data (an
IP packet) - along with relevant packet information (such as length)
- to the "routing function",
4) the "routing function" is used (including, for example ACLs, policy
based forwarding, etc.) to determine how to forward the _packet_ -
including forwarding to a logical "interface" on a distinct VLAN,
5) after the forwarding decision is made, appropriate encapsulation is
added to the IP packet, again converting it (in this case) to an
Ethernet frame,
6) the resulting Ethernet frame is forwarded (possibly locally, possibly
only logically) from the component implementing the "routing function"
to the appropriate RBridge component,
7) the RBridge component then provides ingress for the frame by adding
a SHIM and re-encapsulating the frame with the appropriate TRILL
encapsulation.
To RE-EMPHASIZE, this is what happens logically. What you do in
your implementation may differ substantially from this. It may - for
example - be quite a bit simpler. How you do this is why you get paid
the big bucks.
--
Eric
--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com]
--> Sent: Thursday, November 16, 2006 1:45 AM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] IVLANs vs OVLANs
-->
-->
--> Eric,
-->
--> On a second thought, you cannot put a router between OVLAN=1 and
--> OVLAN=2, the frame is not routable, since its Ethertype is
--> TRILL, not
--> IPv4 or IPv6.
-->
--> -- Silvano
-->
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > Sent: Wednesday, November 15, 2006 12:13 PM
--> > To: Silvano Gai
--> > Cc: rbridge at postel.org
--> > Subject: RE: [rbridge] IVLANs vs OVLANs
--> >
--> > Silvano,
--> >
--> > First of all, I will take very large exception to the way
--> > which you have over-loaded the term "CRED." This term was coined
--> > to eliminate confusion caused by the various different was people
--> > were over-loading the term "Campus."
--> >
--> > At the "core" of your question, however, is the issue of
--> > how VLANs interact in a bridged/RBridge environment. It is not
--> > different than would be the case in a "classical bridged LAN."
--> >
--> > This issue is based on a misconception that existed very
--> > early on in the life of the TRILL working group (in the first
--> > BoF, in fact). The misconception is that VLAN connectivity may
--> > be provided by RBridges and/or bridges.
--> >
--> > This is fundamentally incorrect.
--> >
--> > Interconnection of VLANs is strictly a routing function.
--> > In deployed equipment that does this today, there may be some
--> > form of "smart VLAN bridging" that occurs in devices people are
--> > used to referring to as "bridges" or "switches." That does not
--> > change the fact that forwarding from one VLAN to another is a
--> > "routing function."
--> >
--> > Note that, in this context, when I say "forwarding from
--> > one VLAN to another" - I mean "VLAN" in the sense of "virtual
--> > LAN" as a logical concept. This has nothing to do with the fact
--> > that a VLAN ID might change in traversing a VLAN-aware bridge.
--> >
--> > Consequently, in the picture you have below, the VLANs
--> > represented by the VLAN-tag in the tunnel encapsulation may
--> > not be connected together by RB1.
--> >
--> > To correctly restate your question, the original topology
--> > would be as follows:
--> >
--> >
--> > +-----+ 1,2 +-----------+
--> > | RB1 |-------| Rtg Fnctn |
--> > +-----+ +-----------+
--> > |
--> > | 1,2
--> > |
--> > +-----+ 1 +-----+ 2 +-----+
--> > | RB2 |--------| SW1 |----------| RB3 |
--> > +-----+ +-----+ +-----+
--> >
--> > The resulting logical topology MUST then be as follows:
--> >
--> >
--> > +-----+ +-----+ +-----------+
--> > | RB2 |--------| RB1 |-------| Rtg Fnctn |
--> > +-----+ +-----+ +-----+-----+
--> > |
--> > +--+--+ +-----+
--> > | RB1 |----------| RB3 |
--> > +-----+ +-----+
--> >
--> > Since the "routing function" is orthogonal, and well understood,
--> > it does not make sense for us to try to combine this concept with
--> > RBridge behaviors and protocol interactions.
--> >
--> > --
--> > Eric
--> >
--> >
--> > --> -----Original Message-----
--> > --> From: rbridge-bounces at postel.org
--> > --> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> > --> Sent: Tuesday, November 14, 2006 8:11 PM
--> > --> To: rbridge at postel.org
--> > --> Subject: [rbridge] IVLANs vs OVLANs
--> > -->
--> > -->
--> > --> During the last WG meeting I had an action item to send an
--> > --> email on the
--> > --> VLAN issue. Here it is.
--> > -->
--> > --> In a previous email I introduced the concept of IVLAN
--> and OVLAN.
--> > -->
--> > --> IVLAN refers to the VLAN present on the untagged frames,
--> > --> which must be
--> > --> propagated by ISIS, VLAN pruning must be performed and so
--> > --> on. All the
--> > --> IVLANs share the same core instance of ISIS.
--> > -->
--> > --> OVLAN refers to the fact that the traffic between two
--> > --> RBridges can be
--> > --> encapsulated into a VLAN.
--> > -->
--> > --> If we look to the format of a TRILL encapsulated frame the
--> > --> position of
--> > --> these two fields is as follow:
--> > -->
--> > --> +--------------------------------+
--> > --> | DA |
--> > --> +----------------+---------------+
--> > --> | DA | SA |
--> > --> +----------------+---------------+
--> > --> | SA |
--> > --> +--------------------------------+
--> > --> | ET = 1Q | OVLAN ... |
--> > --> +--------------------------------+
--> > --> | ET = TRILL | RES | TTL |
--> > --> +--------------------------------+
--> > --> | Egress Add. | Ingress Add. |
--> > --> +--------------------------------+
--> > --> | DA |
--> > --> +----------------+---------------+
--> > --> | DA | SA |
--> > --> +----------------+---------------+
--> > --> | SA |
--> > --> +--------------------------------+
--> > --> | ET = 1Q | IVLAN ... |
--> > --> +--------------------------------+
--> > --> | Payload |
--> > -->
--> > --> Now let's consider the following topology:
--> > -->
--> > --> +-----+
--> > --> | RB1 |
--> > --> +-----+
--> > --> |
--> > --> | 1,2
--> > --> |
--> > --> +-----+ 1 +-----+ 2 +-----+
--> > --> | RB2 |--------| SW1 |----------| RB3 |
--> > --> +-----+ +-----+ +-----+
--> > -->
--> > --> RB1, RB2, RB3 are Rbridges, SW1 is a classical
--> Ethernet switch.
--> > --> The link between RB2 and SW1 is in OVLAN 1, the link
--> > --> between SW1 and RB3
--> > --> is in OVLAN 2 and the links between SW1 and RB1 is a
--> trunk and it
--> > --> carries both OVLAN 1 and 2.
--> > -->
--> > --> Now my question is: "do we have one CRED or two?"
--> > -->
--> > --> a) possible answer: "we have one CRED". RB2 is adjacent to
--> > --> RB1 but not
--> > --> to RB3. The same applies to RB3 that is adjacent to RB1,
--> > --> but not RB2.
--> > --> RB1 is adjacent to both RB2 and RB3. There is a single core
--> > --> instance of
--> > --> ISIS. RB2 may reach RB3 through RB1.
--> > -->
--> > --> The TRILL equivalent topology is:
--> > -->
--> > --> +-----+ +-----+ +-----+
--> > --> | RB2 |--------| RB1 |----------| RB3 |
--> > --> +-----+ +-----+ +-----+
--> > -->
--> > --> b) another possible answer: "we have two CREDs". One is
--> > --> composed by RB2
--> > --> and RB1, the other by RB3 and RB1. RB2 may not reach RB3,
--> > --> since they are
--> > --> in different CREDs.
--> > -->
--> > --> The TRILL equivalent topologies are:
--> > -->
--> > --> +-----+ +-----+
--> > --> | RB2 |--------| RB1 |
--> > --> +-----+ +-----+
--> > -->
--> > --> +-----+ +-----+
--> > --> | RB1 |----------| RB3 |
--> > --> +-----+ +-----+
--> > -->
--> > --> I like a) and I hope we are in agreement that the right
--> > --> answer is a),
--> > --> but I haven't seen it explained in any of the documents.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> rbridge at postel.org
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
-->
More information about the rbridge
mailing list