From Donald.Eastlake at motorola.com Tue May 1 08:48:14 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 1 May 2007 11:48:14 -0400 Subject: [rbridge] TRILL Header Format In-Reply-To: <46364123.2060008@cisco.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461E80DA.9010902@sun.com><461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! ! i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> Message-ID: <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot.com> 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 Tue May 1 14:14:32 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 1 May 2007 14:14:32 -0700 Subject: [rbridge] TRILL Header Format - Version 2 In-Reply-To: <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <941D5DCD8C42014FAF70FB7424686DCFB50CE7@eusrcmw721.eamcs.ericsson.se> <461BCD66.7070700@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA20151ABFE@nuova-ex1.hq.nuovaimpresa.com> <461C17AB.7000805@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFB514C5@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA20151AD73@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFB515A4@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA20151AE1E@nuova-ex1.hq.nuovaimpresa.com> <941D5DCD8C42014FAF70FB7424686DCFB516B4@eusrcmw721.eamcs.ericsson.se> <461E80DA.9010902@sun.com> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com> <461EB133.9030606@isi.edu> <461ED237.6020404@sun.com> <461ED550.9080501@isi.! edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is! ! ! i.e du> <34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201650E3C@nuova-ex1.hq.nuovaimpresa.com> 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. 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| RSD | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSD | EH-length | Inner IEEE 802.1Q/S tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Nickname | Ingress 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Tue May 1 14:25:54 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Tue, 1 May 2007 14:25:54 -0700 Subject: [rbridge] TRILL Header Format - Version 2 In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201650E3C@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D03A7B1CF@NT-IRVA-0750.brcm.ad.broadcom.com> 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 Tue May 1 14:32:38 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 01 May 2007 14:32:38 -0700 Subject: [rbridge] TRILL Header Format In-Reply-To: <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! ! i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! .com> Message-ID: <4637B1F6.3040605@isi.edu> Eastlake III Donald-LDE008 wrote: > 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. 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 > 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 >> >> > -- ---------------------------------------- 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 Tue May 1 14:36:45 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Tue, 1 May 2007 14:36:45 -0700 Subject: [rbridge] TRILL Header Format In-Reply-To: <4637B1F6.3040605@isi.edu> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! ! i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! .com> < 4637B1F6.3040605@isi.edu> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201650E70@nuova-ex1.hq.nuovaimpresa.com> Joe, In this case you have option 1, The VLAN-ID is located at an easily computable offset from the TRILL header -- Silvano > -----Original Message----- > 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 > Subject: Re: [rbridge] TRILL Header Format > > > > Eastlake III Donald-LDE008 wrote: > > 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. > > 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 > > > 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 > >> > >> > > > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment From touch at ISI.EDU Tue May 1 14:42:49 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 01 May 2007 14:42:49 -0700 Subject: [rbridge] TRILL Header Format In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201650E70@nuova-ex1.hq.nuovaimpresa.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! ! i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! ! .com> < 4637B1F6.3040605@isi.edu> <34BDD2A93E5FD84594BB230DD6C18EA201650E70@nuova-ex1.hq.nuovaimpresa.! com> Message-ID: <4637B459.9050403@isi.edu> Silvano Gai wrote: > Joe, > > In this case you have option 1, > The VLAN-ID is located at an easily computable offset from the TRILL > header 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 > > -- Silvano > >> -----Original Message----- >> 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 >> Subject: Re: [rbridge] TRILL Header Format >> >> >> >> Eastlake III Donald-LDE008 wrote: >>> 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. >> 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 >> >>> 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 >>>> >>>> >> -- >> ---------------------------------------- >> Joe Touch >> Sr. Network Engineer, USAF TSAT Space Segment > -- ---------------------------------------- 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/8d60e0b4/signature.bin From Donald.Eastlake at motorola.com Tue May 1 19:42:44 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 1 May 2007 22:42:44 -0400 Subject: [rbridge] TRILL Header Format In-Reply-To: <4637B1F6.3040605@isi.edu> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! ! i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! .com> < 4637B1F6.3040605@isi.edu> Message-ID: <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> 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 Eastlake III Donald-LDE008 wrote: > 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. 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 > 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 >> >> > -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment From Donald.Eastlake at motorola.com Tue May 1 20:07:23 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 1 May 2007 23:07:23 -0400 Subject: [rbridge] TRILL Header Format - Version 2 In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D03A7B1CF@NT-IRVA-0750.brcm.ad.broadcom.com> References: <34BDD2A93E5FD84594BB230DD6C18EA201650E3C@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D03A7B1CF@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <3870C46029D1F945B1472F170D2D97900278A62A@de01exm64.ds.mot.com> 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 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. _______________________________________________ rbridge mailing list rbridge at postel.org http://mailman.postel.org/mailman/listinfo/rbridge From touch at ISI.EDU Tue May 1 20:46:08 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 01 May 2007 20:46:08 -0700 Subject: [rbridge] TRILL Header Format In-Reply-To: <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! ! i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com> <3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! ! .com> < 4637B1F6.3040605@isi.edu> <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> Message-ID: <46380980.9070202@isi.edu> Eastlake III Donald-LDE008 wrote: > 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. 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. > 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. 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 > > 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 > > Eastlake III Donald-LDE008 wrote: >> 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. > > 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 > >> 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 >>> >>> > -- ---------------------------------------- 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/d55afa07/signature.bin From touch at ISI.EDU Tue May 1 20:54:21 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 01 May 2007 20:54:21 -0700 Subject: [rbridge] TRILL Header Format - Version 2 In-Reply-To: <3870C46029D1F945B1472F170D2D97900278A62A@de01exm64.ds.mot.com> References: <34BDD2A93E5FD84594BB230DD6C18EA201650E3C@nuova-ex1.hq.nuovaimpresa.com> <1EF1E44200D82B47BD5BA61171E8CE9D03A7B1CF@NT-IRVA-0750.brcm.ad.broadcom.com> <3870C46029D1F945B1472F170D2D97900278A62A@de01exm64.ds.mot.com> Message-ID: <46380B6D.2040800@isi.edu> Eastlake III Donald-LDE008 wrote: > 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. 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 > 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 > > 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. > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge -- ---------------------------------------- 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/14bb6540/signature.bin From Radia.Perlman at sun.com Tue May 1 21:26:16 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Tue, 01 May 2007 21:26:16 -0700 Subject: [rbridge] Optional configuration of RBridge nickname Message-ID: <463812E8.9040504@sun.com> Someone suggested that it would be useful to allow configuration of nicknames, so that nicknames can be more stable, and there would be no worry of an RBridge coming up and usurping a nickname from someone else. I'd like: a) for it to remain possible to be zero configuration (as in, not necessary to configure a nickname b) allow a mixture of configured and unconfigured nicknames c) work even with misconfiguration (configuring two RBridges with the same nickname) d) never allow an unconfigured nickname to accidentally usurp a nickname from a ocnfigured RBridge So I'm proposing the following: a) allow configuration of a nickname value b) have a "priority" value for owning a nickname that can also be configured, which I'd propose would be an 8-bit byte, where only the bottom 7 bits can be configured c) the 8th bit of the priority byte (the most significant bit) indicates whether the nickname was configured or not d) the default is priority=0 for RBridges that have not been configured with a nickname value, and priority=128 (top bit 1, rest 0) for an RBridge that has been configured with a nickname e) other values of nickname priority might be useful. For instance, an RBridge implementation might increment the nickname value after it's held the nickname for some amount of time (say 10 minutes). Or someone might want to configure some RBridges to have a more stable nickname (by giving them higher priority). f) Basically, the (nickname priority | system ID) is like the DR priority in IS-IS, where the DR election is based on (priority | system ID) Anyone object to this? Radia From eric.gray at ericsson.com Wed May 2 03:14:16 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Wed, 2 May 2007 05:14:16 -0500 Subject: [rbridge] TRILL Header Format In-Reply-To: <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! !i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com><3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! ! .com> <46 37B1F6.30406 05@isi.edu> <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFD051D8@eusrcmw721.eamcs.ericsson.se> 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 > -----Original Message----- > 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 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] TRILL Header Format > > 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 > > Eastlake III Donald-LDE008 wrote: > > 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. > > 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 > > > 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-p > rotocol-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 > >> > >> > > > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Wed May 2 03:17:49 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Wed, 2 May 2007 05:17:49 -0500 Subject: [rbridge] TRILL Header Format - Version 2 In-Reply-To: <3870C46029D1F945B1472F170D2D97900278A62A@de01exm64.ds.mot.com> References: <34BDD2A93E5FD84594BB230DD6C18EA201650E3C@nuova-ex1.hq.nuovaimpresa.com><1EF1E44200D82B47BD5BA61171E8CE9D03A7B1CF@NT-IRVA-0750.brcm.ad.broadcom.com> <3870C46029D1F945B1472F170D2D97900278A62A@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFD051D9@eusrcmw721.eamcs.ericsson.se> 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 > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III > Donald-LDE008 > Sent: Tuesday, May 01, 2007 11:07 PM > To: Caitlin Bestler > Cc: Rbridge at postel.org > Subject: Re: [rbridge] TRILL Header Format - Version 2 > > 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 > > 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. > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Wed May 2 03:31:02 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Wed, 2 May 2007 05:31:02 -0500 Subject: [rbridge] Optional configuration of RBridge nickname In-Reply-To: <463812E8.9040504@sun.com> References: <463812E8.9040504@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFD051DC@eusrcmw721.eamcs.ericsson.se> Radia, I would object strenuously to the use of a priority value in resolving the "ownership" of a nickname. The over-riding priority has to be determined in a way that ensures the existing network continues to work if a new device is inserted (i.e. - it would be best if any device were going to fail, it should be the one that has just been added). Adding "priority" would allow any device to assert a high priority ownership of any nickname currently in use, which would then make it trivially easy to stage a network disabling attack. Having it be so easy to attack the network, would necessitate mandatory defenses, almost certainly meaning that configuration would be required - possibly excepting the option of having the very highest priority value be the default assumed when no configuration is done at any RBridge. In either case (configuration absolutely required, or default highest priority with no configuration) would defeat your purpose. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman > Sent: Wednesday, May 02, 2007 12:26 AM > To: rbridge at postel.org > Subject: [rbridge] Optional configuration of RBridge nickname > > Someone suggested that it would be useful to allow configuration of > nicknames, so > that nicknames can be more stable, and there would be no worry of an > RBridge coming > up and usurping a nickname from someone else. I'd like: > a) for it to remain possible to be zero configuration (as in, not > necessary to configure > a nickname > b) allow a mixture of configured and unconfigured nicknames > c) work even with misconfiguration (configuring two RBridges with the > same nickname) > d) never allow an unconfigured nickname to accidentally usurp > a nickname > from > a ocnfigured RBridge > > So I'm proposing the following: > > a) allow configuration of a nickname value > b) have a "priority" value for owning a nickname > that can also be configured, which I'd propose would be an 8-bit byte, > where only the bottom 7 bits can be configured > c) the 8th bit of the priority byte (the most significant > bit) indicates > whether > the nickname was configured or not > d) the default is priority=0 for RBridges that have not been > configured with > a nickname value, and priority=128 (top bit 1, rest 0) for an > RBridge that > has been configured with a nickname > e) other values of nickname priority might be useful. For > instance, an > RBridge > implementation might increment the nickname value after it's held the > nickname > for some amount of time (say 10 minutes). Or someone might > want to configure > some RBridges to have a more stable nickname (by giving them higher > priority). > f) Basically, the (nickname priority | system ID) is like the DR > priority in IS-IS, > where the DR election is based on (priority | system ID) > > Anyone object to this? > > Radia > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Donald.Eastlake at motorola.com Wed May 2 03:34:33 2007 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Wed, 2 May 2007 06:34:33 -0400 Subject: [rbridge] TRILL Header Format In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFD051D8@eusrcmw721.eamcs.ericsson.se> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! !i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com><3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! ! .com> < 4637B1F6.304 0605@isi.edu> <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFD051D8@eusrcmw721.eamcs.ericsson.se> Message-ID: <3870C46029D1F945B1472F170D2D97900278A64D@de01exm64.ds.mot.com> 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, 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 > -----Original Message----- > 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 > Cc: Rbridge at postel.org > Subject: Re: [rbridge] TRILL Header Format > > 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 > > Eastlake III Donald-LDE008 wrote: > > 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. > > 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 > > > 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-p > rotocol-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 > >> > >> > > > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From eric.gray at ericsson.com Wed May 2 03:43:01 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Wed, 2 May 2007 05:43:01 -0500 Subject: [rbridge] TRILL Header Format In-Reply-To: <3870C46029D1F945B1472F170D2D97900278A64D@de01exm64.ds.mot.com> References: <941D5DCD8C42014FAF70FB7424686DCFA93D24@eusrcmw721.eamcs.ericsson.se> <461EA626.7020107@isi.edu> <461EB084.6090203@sun.com><461EB133.9030606@isi.edu> <461ED237.6020404@sun.com><461ED550.9080501@isi.!edu> <34BDD2A93E5FD84594BB230DD6C18EA20151B445@nuova-ex1.hq.nuovaimpresa.com> <46206B1B.9070107@isi.edu> <941D5DCD8C42014FAF70FB7424686DCFC1851C@eusrcmw721.eamcs.ericsson.se> <4626E9D3.7090502@is!! !i.e du><34BDD2A 93E5FD84594BB230DD6C18EA201574141@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C32EB@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA2015744D6@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D9790026C3332@de01exm64.ds.mot.com> <34BDD2A93E5FD84594BB230DD6C18EA201574563@nuova-ex1.hq.nuovaimpresa.com> <3870C46029D1F945B1472F170D2D979002704D3E@de01exm64.ds.mot.com><34BDD2A93E5FD84594BB230DD6C18EA2015E415C@nuova-ex1.hq.nuovaimpresa.com> <46364123.2060008@cisco.com><3870C46029D1F945B1472F170D2D97900278A1D4@de01exm64.ds.mot! ! ! .com> <4637B1F6.30 40605@isi.edu> <3870C46029D1F945B1472F170D2D97900278A61C@de01exm64.ds.mot.com> <941D5DCD8C42014FAF70FB7424686DCFD051D8@eusrcmw721.eamcs.ericsson.se> <3870C46029D1F945B1472F170D2D97900278A64D@de01exm64.ds.mot.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFD051DE@eusrcmw721.eamcs.ericsson.se> 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 > -----Original Message----- > From: Eastlake III Donald-LDE008 > [mailto:Donald.Eastlake at motorola.com] > Sent: Wednesday, May 02, 2007 6:35 AM > To: Eric Gray (LO/EUS) > Cc: Rbridge at postel.org > Subject: RE: [rbridge] TRILL Header Format > Importance: High > > 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, > > 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 > > > -----Original Message----- > > 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 > > Cc: Rbridge at postel.org > > Subject: Re: [rbridge] TRILL Header Format > > > > 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 > > > > Eastlake III Donald-LDE008 wrote: > > > 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. > > > > 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 > > > > > 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-p > > rotocol-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 > > > | > > > +-+-+-