Subject: [rbridge] TRILL Header Format

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 1 May 2007 11:48:14 -0400

Hi,

I agree with Dinesh's comment and would also like to say that my
personal preference is for Solution 2. I just don't feel there are
enough reserved bit available for future use in the minimal Solution 1
and since, in the general case, every Rbridge has to look at the VLAN
ID, putting it in a fixed place nearer the beginning of the frame, as
done in Solution 2, seems like a good idea.

Thanks,
Donald 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Dinesh G Dutt
Sent: Monday, April 30, 2007 3:19 PM
To: Silvano Gai
Cc: Rbridge at postel.org
Subject: Re: [rbridge] TRILL Header Format

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:
> 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
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 1 May 2007 14:14:32 -0700

Included comments from Dinesh, Donald and Dino (swap egress and ingress
nicknames).

Dino is for solution 1
Donald is for solution 2

No other preferences have been expressed

-- Silvano

-----------------------------------------------

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

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      | V |M|RSD|EH-length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress 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.

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

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

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.

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

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 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress 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|  RSD  |   Hop Count   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    RSD        |   EH-length   |  UP |DE|   Inner VID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Egress RBridge Nickname      |  Ingress 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: caitlinb at broadcom.com (Caitlin Bestler)
Date: Tue, 1 May 2007 14:25:54 -0700

rbridge-bounces at postel.org wrote:
> Included comments from Dinesh, Donald and Dino (swap egress
> and ingress nicknames).
> 
> Dino is for solution 1
> Donald is for solution 2
> 

I think keeping a clean layered separation between IEEE
and IETF is valuable, and all ties should be broken by
keeping IEEE defined headers intact and unmodified. I'm
not convinced that extra reserved bits justifies breaking
that clean layering.

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 01 May 2007 14:32:38 -0700

> done in Solution 2, seems like a good idea.

I agree in spirit, but don't agree that the inner frame should be
modified during processing; this just complicates parsing and debugging,
and increases the potential for implementation errors.

IMO, the VLAN tags should be copied, not moved.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070501/6d182200/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 1 May 2007 14:36:45 -0700

Joe,

In this case you have option 1,
The VLAN-ID is located at an easily computable offset from the TRILL
header

-- Silvano

> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Tuesday, May 01, 2007 2:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; Rbridge at postel.org

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 01 May 2007 14:42:49 -0700

> The VLAN-ID is located at an easily computable offset from the TRILL

Agreed. I'm not as concerned with the need for extra space as others; we
have a version field, which ought to cover future expansion if needed
anyway.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070501/8d60e0b4/signature.bin

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 1 May 2007 22:42:44 -0400

Hi Joe,

I see it as exactly the other way.

Most commonly, the VLAN ID is associated with a native frame only
because of the port it is received on, although it is certainly possible
for an end station to include one. Thus, in the most common case, it is
the current design which requires the ingress Rbridge to insert a Q/S
tag inside the encapsulated frame, thus modifying it, and similarly most
commonly requires the egress Rbridge to remove that tag from inside the
encapsulated frame, although their can be configurations where it is
retained.

Thus, Solution 2 would generally require *less* modification of
encapsulated frames at ingress and egress than would Solution 1.

The above is in answer to your point on 'modification' since I believe
Solution 2 results in less modification. I'm not sure I understand your
"parsing and debugging" point. For every Rbridge other than the ingress
Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
and (b) find the VLAN tag. It seems to me to make the parsing job
simpler to put the VLAN tag information at a fixed location in the TRILL
Header.

Donald

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Tuesday, May 01, 2007 5:33 PM
To: Eastlake III Donald-LDE008
Cc: Dinesh G Dutt; Silvano Gai; Rbridge at postel.org
Subject: Re: [rbridge] TRILL Header Format

Joe

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 1 May 2007 23:07:23 -0400

Hi Caitlin,

I just don't see how the separation you suggest could ultimately work.
Rbridges are replacements for Bridges and have to be able to do a
reasonable version of everything Bridges can do with VLANs, etc. So it
has to be possible to configure Rbridges to synthesize the VLAN tag
information on ingress of a native frame, etc. So, in any case, Rbridges
have to be able to synthesize, transport, understand, possibly map, and
eventually expunge the VLAN tag information. So how can there be "clean
layer separation"? And, in fact, the two byte format of the VLAN tag
information is exactly the same whether the two bytes of VLAN tag info
are prefixed by a Q/S-tag Ethertype and inserted within the encapsulated
frame or carried in a two byte field of the TRILL Header.

In fact, it is not clear to me how any IEEE device can get past the
TRILL Header, because IEEE devices will not recognize the TRILL
Ethertype. Thus, such devices will never even see the Q/S tag Ethertype
that might be inserted with the VLAN tag information into the
encapsulated frame. So I just can't see any gain in wasting those two
bytes on that Ethertype since it is not going to help any IEEE device.
Why not make those bytes available for reserved bits and more relaxed
field sizes in the TRILL Header as suggested in Solution 2?

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Caitlin Bestler
Sent: Tuesday, May 01, 2007 5:26 PM
To: Silvano Gai; Rbridge at postel.org
Subject: Re: [rbridge] TRILL Header Format - Version 2

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 01 May 2007 20:46:08 -0700

> encapsulated frames at ingress and egress than would Solution 1.

Agreed - IF the VLAN tag is something we insert/delete, then agreed.
That presumes that the ingress rbridge is the receive port that adds the
VLAN tag.

However, I read the previous posts as "extract the VLAN from the inner
header and put it in the TRILL header. That would assume some other
bridge had inserted the VLAN tag. If that's the case, then I don't see
the utility in moving things around.

> simpler to put the VLAN tag information at a fixed location in the TRILL

It's in a fixed location if it's in the inner header too, however if it
truly belongs to the inner header, regardless of whether we act on it in
conjunction with TRILL information, it ought to stay in the inner
header. Otherwise debugging equipment will show a false inner header
that lacks the VLAN tag it owns.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070501/d55afa07/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 01 May 2007 20:54:21 -0700

Eastlake III Donald-LDE008 wrote:
> information on ingress of a native frame, etc. 

Why would that not go in the innermost header? The expectation is that
the bridge closest to the host removes such tags, right? If so, then
this is a conventional bridge function that can be added to an rbridge,
but has nothing to do with the rbridge transit operation, and thus
belongs in the inner header, not the TRILL header.

Joe

> So, in any case, Rbridges

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070501/14bb6540/signature.bin

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 05:14:16 -0500

Donald,

	I think you're losing sight of an important aspect of
the proposal you're advocating - it assumes that it is okay 
to always include space of a VLAN tag, even when one is not
needed.  This further implies that VLAN tagging is the case
we wish to optimize for (i.e. - the "normal" case), and that
implies that configuration will normally be required.

	I much prefer not to include extra space in the TRILL
header that optimizes for the case where TRILL adds no real
value over conventional IS-IS routing and bridging.

--
Eric Gray
Principal Engineer
Ericsson  

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 10:43 PM
> To: Joe Touch
> > maybe different from the tag that we received at the 
> ingress port and
> is
> >

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 05:17:49 -0500

Donald,

	I agree with Caitlin and would point out that the "layer
violation" is a concern because there are other forms of ".Q"
(and ".Q-like") encapsulations out there, and we might want to
consider what the implications of the use of these other forms
of L2 encapsulation are on what should go in the fields you're
proposing we add to the TRILL header.

	If we don't add those fields, then it is not necessary to
concern ourselves with what might need to go into them...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, May 01, 2007 11:07 PM
> To: Caitlin Bestler
> [mailto:rbridge-bounces at postel.org] On

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 2 May 2007 06:34:33 -0400

The present design defaults to always inserting four bytes of VLAN tag
Ethertype and VLAN tag data inside the encapsulated frame although it
does provide that they "MAY" be omitted when everything is defaulting to
VLAN 1.

Donald

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
Sent: Wednesday, May 02, 2007 6:14 AM
To: Eastlake III Donald-LDE008; Joe Touch
Cc: Rbridge at postel.org
Subject: RE: [rbridge] TRILL Header Format

Donald,

--
Eric Gray
Principal Engineer
Ericsson

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 2 May 2007 05:43:01 -0500

Donald,

	What you've just described sounds a lot like standard
bridging - i.e. - 802.1Q is used, but 802.3 encapsulation MAY 
be used if no VLANs are present.

	Perhaps I am missing (or misunderstanding) something?

	In the TRILL header, I would very much like to have just
one format.  What goes in the inner header may or may not be
changed in a device that has RBridging function, but should be
decided - not by the RBridging function within that device, but
- by the standard bridging function within that same device.

	In other words, by keeping to a separation of the content
of the "inner" 802 header and the content of the TRILL header,
the device implementations will be able to do the "standard
bridging" things they should do - AND - the TRILL encapsulation
independently...

--
Eric Gray
Principal Engineer
Ericsson  

> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Wednesday, May 02, 2007 6:35 AM
> To: Eric Gray (LO/EUS)
> Importance: High
> > > 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
> > > 
> > >>                                       |  V  |M|S| RSD |  
>  Hop Count
> > >> into the TRILL header. The Inner 1Q/1S tag is no longer 
> present in
> > the
> > >> inner frame.
> > >>
> > >> The EH-length is 8 bits, with a granularity of 2 bytes 
> it allows up
> > to
> > >> 512 bytes of extensions.
> > >>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 2 May 2007 10:28:16 -0400

Hi Joe,

I don't see any reason to assume any bridges are involved. To the extent
that Rbridges do what bridges do, only better, one would expect them to
replace all bridges. So in the end state, which it seems to me is what
you should optimize for, there are no bridges. Even if a bridge had
inserted a VLAN tag before the ingress Rbridge, that Rbridge might be
performing some mapping on VLAN IDs so it has to change the VLAN tag and
it might be the case the egress Rbridge has to remove the VLAN tag
anyway.

There is no suggestion that we change the two byte format for the VLAN
tag information, just change how this meta information is incorporated
in messages with a TRILL header being transmitted between Rbridges.

What happens when such a message is received by a transit Rbridge? There
might be an outer 802.1AE tag or the like, which is removed and
processed at the port. There might be an outer VLAN tag which is
logically removed on receipt so frame now logically and perhaps
physically starts with a TRILL Ethertype. The Rbridge MUST then derive
inner VLAN tag information to decide how to forward the frame. With
Solution 2, it is at a fixed offset from the TRILL Ethertype and close
to the beginning of the frame, to speed cut through switching. With
Solution 1, the Rbridge has to skip over a variable amount of extension
data and extract the VLAN tag information from deeper in the frame at a
variable offset from the TRILL Ethertype.

For a TRILL encapsulated frame between Rbridges, it seems to me that all
the meta information such as egress Rbridge, multi-destination bit, VLAN
ID, etc., should all be placed for the convenience of Rbridges. While it
is true that an egress Rbridge might have to insert a VLAN tag, most
likely all the meta information will be tossed at the egress Rbridge
which will just output an untagged native frame.

Furthermore, I don't see how debugging equipment is going to be
confused. If the debugging equipment understands the TRILL Ethertype, it
will know where the two bytes of VLAN information are and can display
them appropriately no matter what the WG decides. If it does not
understand the TRILL Ethertype, then it can look no further into the
frame since it would have no idea how long the TRILL tag is or how it is
structured.

Thanks,
Donald

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Tuesday, May 01, 2007 11:46 PM
To: Eastlake III Donald-LDE008
Cc: Rbridge at postel.org
Subject: Re: [rbridge] TRILL Header Format

Joe

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 2 May 2007 10:29:57 -0400

As I say, I don't see any reason to assume any bridges are involved. It
is true that conventional bridges (if 802.1Q compliant) associate VLAM
tag information with a frame and, if configured to do so, emit that
information in the frame by inserted a VLAN tag. But that is not
something that "can be added to an Rbridge". It is a capability that all
Rbridges MUST have (unless we want to define separate D-Rbridges which
don't support VLANs at all and Q-Rbridges which do). And far from having
"nothing to do with rbridge transit operations", such VLAN tag
information is essential to every Rbridge forwarding decision.

Donald

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Tuesday, May 01, 2007 11:54 PM
To: Eastlake III Donald-LDE008
Cc: Caitlin Bestler; Rbridge at postel.org
Subject: Re: [rbridge] TRILL Header Format - Version 2

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 02 May 2007 08:00:14 -0700

Eastlake III Donald-LDE008 wrote:
> Hi Joe,
> 
> I don't see any reason to assume any bridges are involved. 

Agreed. All functions that rbridges do that are identical to what
bridges do should be stated as an assumption (rbridges can subsume all
bridge functions except the rest of our discussion.

My point is that if a bridge (in an rbridge or not) adds a VLAN tag,
then a bridge (in an rbridge or not) nearest the destination host will
remove that tag. Even when the tag-adding bridge is the ingress rbridge,
we cannot assume in our architecture that the tag-removing bridge is the
egress rbridge; it could as easily be a bridge later in the arch.

To the extent that rbridges do this function (adding VLAN tags or
removing them), that happens to the inner header. That function has
nothing to do with rbridges per se; it doesn't belong in the rbridge
header. If rbridge functions need to refer to that tag, they know where
it would be and how to find it.

> variable offset from the TRILL Ethertype.

This argument would imply that if the rbridge were not there that a
bridge would need to extract the VLAN tag from the inner header at a
variable offset. Since that's already done, I see no problem.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070502/b205ce5d/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 2 May 2007 08:58:54 -0700

Joe,

I agree with you and I am in favor of solution 1

-- Silvano

> Sent: Tuesday, May 01, 2007 2:43 PM
> To: Silvano Gai
> Cc: Eastlake III Donald-LDE008; Dinesh G Dutt; Rbridge at postel.org
> >>> enough reserved bit available for future use in the minimal
Solution
> > 1
[mailto:rbridge-bounces at postel.org]
> > On
> >>> part of the port logic. For example, the frame may have come in
with
> > a
> >>> 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
> >>>>                                       |  V  |M|S| RSD |   Hop
Count
> >>>> into the TRILL header. The Inner 1Q/1S tag is no longer present
in
> >>>> The EH-length is 8 bits, with a granularity of 2 bytes it allows
up
> >>>> very limited. Often Router and Switches are not able to process
in
> > HW

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sun, 6 May 2007 23:47:49 -0400

Hi Joe,

First I want to refine an earlier statement of mine. The VLAN ID
information isn't involved in all forwarding decisions by Rbridges. But
it is involved in all multi-destination forwarding decisions by Rbridges
and for unicast it is involved in all ingress and egress processing. The
priority information, which is also in the VLAN tag information, is
relevant to queuing at every transit Rbridge.

See below at @@@ 

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Wednesday, May 02, 2007 11:00 AM
To: Eastlake III Donald-LDE008
Cc: Rbridge at postel.org
Subject: Re: [rbridge] TRILL Header Format

@@@ When you say "a bridge (in an rbridge or not)" you seem to imply
that there is a bridge inside every rbridge. That doesn't make any sense
to me. There isn't a bridge "inside" an Rbridge. The Rbridge is an
integrated device that is a bridge (Rbridge stands for "Routing
Bridge"). It is a better bridge. It uses IS-IS instead of *STP. It uses
different formats on the wire between Rbridges. It may or may not have
various optimizations. It's not an 802.1 bridge but it is a bridge
nevertheless. And once a frame is ingressed by an Rbridge and has a
TRILL Header added, every bit after the TRILL Ethertype through to just
before the FCS is completely private to TRILL capable devices and TRILL
capable software. Nothing TRILL ignorant will be able to parse past the
TRILL Ethertype. It seems only reasonable to format that information for
Rbridge convenience and efficiency.

@@@ Rbridges are bridges. Your artificially carving out of the VLAN
functionality, part of the heart of how Rbridges work, and declaring it
to have nothing to do with Rbridges makes no sense at all.

@@@ The best view of VLAN ID, the multi-destination bit, frame priority,
the "egress Rbridge", ... is that these are all pieces of
meta-information that are not part of the actual data frame. They exist
even when they are never encoded into a wire format.

@@@ In the future situation we are aiming for, the normal case will be
that this meta-information will by synthesized when an Rbridge receives
a native frame. It would never be wire encoded if the frame is between
two end stations both directly connected to that Rbridge. If the frame
has to be forwarded to another Rbridge, then the meta-information does
have to be wire encoded but such inter-Rbridge frames always have a
TRILL Header which is the obvious place for all this meta-information
all of which will be of interest to the receiving RBridge.

@@@ I don't understand your comment above at all. Sure, if your replace
all your Rbridges with 802.1Q bridges, then you have an 802.1Q bridge
synthesizing a more limited set of meta-information. And if you have
inter-802.1Q-bridge forwarding, then that meta-information is
wire-encoded in the 802.1Q format of a Ethertype followed by the two
bytes of Q/S-tag information. If you have Rbridges, then there is a
larger set of meta-information and if you have an inter-Rbridge
forwarding, then this larger set of meta-information is wire-encoded and
that wire-encoding is whatever we say it is. This encoding will only be
parsed by TRILL capable devices. It just makes no sense to me that, in
the Rbridge case, you want to split this meta-information into two
parts, throw away two bytes on an extra Ethertype, move the information
which corresponds to that in a Q/S tag at least 14 bytes deeper into the
frame to slow down cut through switching, and, in almost all cases,
modify the frame being encapsulated by inserting this part of the meta
information inside it.

@@@ I never claimed the current scheme won't work. I just claim that
keeping this meta information, which generally needs to be consulted by
every transit Rbridge, together in the TRILL header is more efficient
and simpler.

@@@ Thanks,
@@@ Donald

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 06 May 2007 21:05:37 -0700

Comments below...

Eastlake III Donald-LDE008 wrote:
> that there is a bridge inside every rbridge.

There can be; there need not be. More specifically, conventional bridge
functions such as VLAN tagging could be supported inside an rbridge.

> That doesn't make any sense
> Bridge"). It is a better bridge.

That would presume we subsumed the entirety of what bridges do; we have
to date focused on what has changed.

> It uses IS-IS instead of *STP. It uses
> nevertheless.

Then there could be 802.1 bridge functions additionally supported.

> And once a frame is ingressed by an Rbridge and has a
> capable software.

I disagree; TRILL devices are not encryption tunneling devices. As such,
the innermost header may be utilized at any rbridge, though one would
hope neither the innermost header nor the TRILL header would be used by
non-rbridge devices.

> Nothing TRILL ignorant will be able to parse past the

It does, but it isn't required that information inside that header be
copied; that is neither efficient nor necessarily more convenient.

> it would be and how to find it.

If an rbridge adds VLAN tags, it can do so in two places - the innermost
header or the outermost header; the innermost header would represent
'conventional' VLAN tagging, and the outermost would represent VLAN tags
used for intra-campus traversal.

If an rbridge supports conventional VLAN tagging (i.e., conventional
bridge capability), then the egress would NOT be the place to remove
that tag, so it would make no sense to have that tag anywhere other than
the innermost header.

> to have nothing to do with Rbridges makes no sense at all.

I disagree, as above. It is orthogonal to rbridge functionality.

> even when they are never encoded into a wire format.

Agreed, except for VLAN ID; that could be removed elsewhere, e.g.,
outside the campus, and as such has no business being in the TRILL header.

Keep in mind that rbridges may be a superset of bridges, but I don't
assume they replace all bridges everywhere. If there are bridges after
the egress, the VLAN tag would need to stay in place.

> two end stations both directly connected to that Rbridge.

Agreed. But that again presumes a world where there are no bridges in a
campus - either used for rbridge-rbridge or rbridge-endstation. I don't
agree that's to be assumed.

> If the frame

The reason, as above, to repeat, is that I don't assume all bridges or
all rbridges; I believe a mixed deployment is not only likely in
transition, but should be supported regardless.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070506/68445d55/signature-0001.bin

---

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Mon, 7 May 2007 08:50:59 -0700

In all fairness, the VLAN tag is at an easily calculated offset with
either proposal.

> Sent: Tuesday, May 01, 2007 7:43 PM
> To: Joe Touch

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 7 May 2007 13:36:18 -0400

I agree, although it is trivially easier to calculate the offset if the
VLAN tag information is in the TRILL Header.

I never claimed the current design wouldn't work or can't be
implemented. It just seems to me that saving 2 bytes on every frame and
speeding up cut through switching by moving the VLAN tag information at
least 14 bytes earlier in the frame are more important.

Donald