Re: [rbridge] Mail regarding draft-ietf-trill-rbridge-protocol

[Donald Eastlake <[e-mail]>]

On Thu, Oct 28, 2010 at 9:28 AM,  <[e-mail]> wrote:
> Thank you a lot Donald for your response,
>
> Based on your answer, in case is just a point-to-point link between RB3 and RB4, and they  privately agree on any encoding they want, Do they can just decide to send the frames with nothing more than the TRILL header and the Inner Ethernet Header encapsulated?

Yes, since no one other than RB3 or RB4 has to see the traffic...

There are questions of how you would configure RB3 and RB4 to do this,
whether your hardware/firmware for sending and receiving would support
this, possibly problems that standard Ethernet diagnostic tools would
no longer work, questions about whether you would still have an FCS
(Frame Check Sequence), whether you can still send low level layer 2
control frames like LLDP or PAUSE, etc., but if you can get around all
those sorts of problems, RB3 and RB4 can do whatever they want to
communicate their TRILL Data and TRILL IS-IS frames to each other...

> Regards,
> Belen

Thanks,
Donald

>
> -----Message d'origine-----
> De : Donald Eastlake [mailto:[e-mail]]
> Envoyé : jeudi 28 octobre 2010 15:17
> À : BELEN EGUEZ Maria RD-BIZZ-ISS
> Cc : [e-mail]
> Objet : Re: Mail regarding draft-ietf-trill-rbridge-protocol
>
> Hi Maria,
>
> On Thu, Oct 28, 2010 at 8:28 AM,  <[e-mail]> wrote:
>> Good day Donald,
>>
>> I have some questions regarding interlink encapsulation,  considering this type of connection taken from the RFC for TRILL:
>>
>>     +-----+  +-------+   +-------+       +-------+   +-------+  +----+
>>     | ESa +--+  RB1  +---+  RB3  +-------+  RB4  +---+  RB2  +--+ESb |
>>     +-----+  |ingress|   |transit|       |transit|   |egress |  +----+
>>              +-------+   +-------+       +-------+   +-------+
>>
>>
>>  1.- For connection between RB3 and RB4: If this two rbridges are connected directly by some kind of cable (no bridges or endnodes between) Do data frames that travel through this cable flow according the format "Outer Ethernet Header - TRILL Header - Inner Header" or the format "TRILL Header - Inner Header"?
>
> It depends on the link protocol in use on the RB3 to RB4 connection.
> If this is an "Ethernet" 802.3 connection, then you have to have an Ethernet Header. If it is a PPP connection, you need a PPP header.
> Etc.
>
> Of course, if it is really just a point-to-point link between RB3 and RB4, they could privately agree on any encoding they want. There were some discussion of ways to abbreviate things, since a separate outer Ethernet header is really redundant in the P2P case. But the thinking was that this was not worth the complexity and oddness to be part of the base protocol. Also, if there happened to be a bridge between the RBridges (which admittedly means it isn't point-to-point), there could be problems with the bridge getting confused...
>
> However, we could, for example, define a hop-by-hop critical "Ethernet abbreviation" option. That way you could confirm that the next hop RBridge supports it. It could move the Inner.MacDA, Inner.MacSA, and Inner.VLAN to the Outer positions and just pinch out the space they were using in the encapsulated frame. This would save 16 bytes (6+6+4) but cost 4 bytes assuming a bit option (according to the current options draft) for a net saving of 12 bytes. Of course, this would be a significant change and current TRILL hardware probably wouldn't support it, but that's why it's an option. You could have a mix of RBridges that did and didn't support such an option and it would only get used between pairs that did support it. So it could be rolled out incrementally...
>
> Thanks,
> Donald
>
>> 2.- In case the answer for the first question is "TRILL Header - Inner Header" and if the link between RB1 and RB3 is through a regular L2 bridge then I suppose that the frame must add the "Outer Ethernet Header" in order to pass Transparently through the link.
>>
>> This questions come from a doubt I have that frames flowing through Rbbridges direct-links (just a cable that connects two rbridges directly) do not need to be transported over the IEEE 802.3 standard but instead just on TRILL Header - Inner Header right? If this is right then,this would mean that the ports that connect RB3 and RB4 are on TRUNK mode and by doing this no Ethernet frames will flow but instead "Ethernet frames encapsulated on TRILL"
>>
>> I really appreciate your attention and your help,
>>
>> Best regards,
>>
>> Belen Egüez
>>
>>
>> ________________________________
>>
>> De : Donald Eastlake [mailto:[e-mail]] Envoyé : mercredi 4
>> août 2010 18:53 À : BELEN EGUEZ Maria RD-BIZZ-ISS Cc :
>> [e-mail] Objet : Re: Mail regarding
>> draft-ietf-trill-rbridge-protocol
>>
>>
>> Hi Maria,
>>
>> On Wed, Aug 4, 2010 at 8:26 AM, <[e-mail]> wrote:
>>
>>        Good morning,
>>
>>        Im reading the RFC for TRILL and its benefits for multipathing
>> and loop avoidance. I have some doubts, among them i would like you
>> can explain me
>>
>>                1. if there is just one DRB per campus or can be more,
>>
>>  The DRB (Designated RBridge) in TRILL is the same as the "Designated Router" or "Designated Intermediate System" in IS-IS. There is one per link, not one per campus, using the word "link" as defined in the protocol draft. You may find it helpful to look at the IS-IS routing protocol.
>>
>>        2. Also for a network similar to the scheme attached in this mail:
>>        <<scheme.JPG>>
>>        This is a network example im trying to understand in order to
>> ease my comprehension of the protocol. Consider this four Rbridges
>> interconnected RB1, RB2, RB3 and  App Fw Vlan x. Imagine they are
>> connected through normal Bridges (therefore frames must be with an
>> outer header ehternet)
>>
>> OK.  Keep in mind that Appointed Forwarder status is a characteristic of an RBridge port, not of the entire RBridge.
>>
>>        In case Host B wants to send a packet to Host A, if these two belong to vlan x, the native packet will go to the spanning tree formed by Bridge 4, 6 and 5 up to RB1 wich could be the root tree (A.3.3 draft-ietf-trill-rbridge-protocol-16) ; then RB1 will encapsulate in TRILL Format and send the packet to the Appointed Forwarder for VLANx who will know to which path send this packet towards Host A. ?
>>
>> (A.3.3 is about an optional feature and is not too relevant to normal
>> RBridge operation.)
>>
>> Well, first I'll talk about this after MAC addresses have been learned:
>>   The port on RB1 that is connected to Bridge 4 is the only RBridge port connected to that bridge LAN so it must be acting as the appointed forwarder for VLAN X, otherwise the frame would be blocked at that port.
>>   Since I am assuming that MAC addresses have already been learned, RB1 will know that the MAC address and VLAN for Host A is attached to the RB you have labeled "App Fwd" which I will call RBAF. So RB1 encapsulates the frame putting the nickname for RBAF in the Egress Nickname field. In this case the shortest path is just one hop, but in the general case their could be intermediate transit RBridges that keep forwarding the frame, hop-by-hop, to RBAF.
>>   When the frame arrives at RBAF, it recognizes itself as the Egress, decapsulates the inner frame, looks up the MAC address and VLAN to find out which port to output it on. Since, in this case, there is only one RBridge port connected to the bridged LAN consisting of Bridge 2, Bridge 3, and "Root Bridge", that port has to be the Appointed Forwarder for any VLANs that are going to get service from the RBridge campus for things attached to those bridges.
>>   The bridges then direct the frame down to Host A.
>>
>> If MAC addresses had not yet been learned, when the frame arrived at RB1, it would have been encapsulated as a multi-destination frame, sent on a distribution tree, and output on all ports in the campus which are Appointed Forwarders for the frame's VLAN.
>>
>> Note that there are two separate spanning trees in your diagram. One composed of Bridges 4, 5, and 6 and one composed of Bridges 2, 3, and the one you label "Root Bridge". RBridges terminate the spanning tree, just like Layer 3 routers do.
>>
>>        Please I would appreciate your help with my doubts and thank you for your attention.
>>
>> I hope the above is helpful,
>>
>> Thanks,
>> Donald
>>
>>
>>        Picture (Metafile)
>>        Belén Egüez
>>        FT/RD/RD/BIZZ/CMC/LSD
>>        Stagiaire de R&D - Services LAN et Stockage de Données en
>> réseau
>>        tél. [phone]
>>        [e-mail]
>> <mailto:[e-mail]>
>>        Picture (Metafile)
>>
>>
>>
>>
>

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