[rbridge] Fwd: In-order delivery not an issue?

Fri Oct 17 07:47:37 PDT 2008

See below...

On Thu, Oct 16, 2008 at 9:28 PM, gvsm <g.venkatasubramaniyan at gmail.com> wrote:
> I think I have not drafted my question properly and hence restarting
> the discussion.  Apologies ...
>
> [1] I am going through a book on Network convergence which lists TRILL
> as one of the enabling technologies and more specifically towards the
> multipath offering of the protocol [Ref-1] and this is my source of
> interest.
>
> [2]I am aware of scope of TRILL. It has clearly stated that this would
> introduce frame reordering.
>
>   Multipathing of multi-destination frames through alternative
>   distribution tree roots and ECMP (Equal Cost MultiPath) of unicast
>   frames are supported (see Appendix C). Multipathing may introduce
>   frame reordering as can differing frame priorities or changes in
>   network topology.

It says "may" not "will". It depends what your standard is for
re-ordering. As stated in Appendix C, if you are going to do ECMP, you
have to decide what your criteria is for a flow. Frames in different
flows can be re-ordered. Frames in the same flow would not normally be
re-ordered. Although this thread has somewhat wandered into Layer-3
areas, I thought this was made clear in earlier answers.

> [3] I think the frame ordering, if its not in the scope of TRILL, the

Where does the spec say that frame ordering is out of scope for TRILL?
I don't think that the definition and granularity of ECMP flows being
out of scope is the same as frame ordering being out of scope. There
was considerable discussion of frame ordering in the early days of
TRILL.

> protocol needs to be extensible to support additional features of this
> kind. I am not right? In my understanding Link aggregation works only

Exactly what features?

> at Link level and may not be suitable enough for multipath. I think

I don't know that much about link aggregation but I believe it
currently is actually not an 802.1 protocol but a 802.3 protocol that
only works across multiple single hop equal speed physical paths.
Furthermore, you have to have it implemented in the ports at both ends
of the physical paths.

> though in theory it can be possible the use of Slow Protocols
> Multicast address would prohibit in present form. Will this multicast
> packets forwarded? I dont think so. There are studies of new protocols

Indeed, no 802.1 conformant customer bridge will forward any frame
with a destination address in the range 01-80-C2-00-00-00 to
01-80-C2-00-00-0F. If it doesn't understand the protocol the frame
refers to, it is required to drop the frame. If it does understand it,
it processes the frame. It never forwards such frames. There are
exceptions for provider bridges and the like.

> to overcome this limitation[Ref-2].
>
> All I was asking that is the protocol should be extensible for
> features like this, something with "options".

Again, exactly what "features"?

> Hope I am clear this time.

Well, I don't understand exactly what you want. Can you be more specific?

Sorry,
Donald

> Thanks a lot,
> venkatg
>
> Ref-1 : Data center Networks and Fiber Channel over Ethernet by Silvano Gai
> Ref-2 : High speed, Short Latency Multipath Ethernet Transport for
> Interconnections, [
> http://doi.ieeecomputersociety.org/10.1109/HOTI.2008.13&ei=d-j3SJ2pAaa0qAOS3tHtCg&sig2=UQ4ZsidRizrOTow70xQqdQ&ct=w
> ]
>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Dinesh G Dutt wrote:
>> One more point. The TCP/IP RFCs don't talk about maintaining order
>> either, but products do it.
>
> TCP/IP does talk about NOT requiring order (sometimes referred to as
> 'sequencing') to be maintained, and explicitly require tolerating it at
> the network layer:
>
> 791 - sec 1.2
> 793 - sec 1.5
> 1122 = sec 1.1.2
> 1812 - sec 2.2.1
>
> Agreed that these RFCs don't focus on efficiencies afforded when packets
> arrive in the order sent, but that's not what is being discussed here.
>
> Joe
>
>>> ---------- Forwarded message ----------
>>> From: Venkatsubramaniyan G, TLS-Chennai <venkatg at hcl.in>
>>> Date: Mon, Oct 6, 2008 at 7:21 PM
>>> Subject: RE: [rbridge] In-order delivery not an issue?
>>> To: rbridge at postel.org, Radia Perlman <Radia.Perlman at sun.com>
>>> Cc: gvsm <g.venkatasubramaniyan at gmail.com>
>>>
>>>
>>>
>>> Radia,
>>>
>>> Assuming a traffic flow (of given SRC, DST and QoS) happens through
>>> multiple equal cost paths in Rbridge cloud, I think TRILL cannot not
>>> offer guarantees that the frames at egress are in the same order as in
>>> ingress in Layer-2.  The individual paths can have different traffic
>>> conditions and reaction mechanisms which may not give in-order behavior,
>>> which could largely vary.
>>>
>>> At present it is assumed this is left for ES ('s higher layer) to handle
>>> out-of-order packets.
>>>
>>> If this needs to be handled inside TRILL, there may be a need for
>>> seq-numbering the packets for each flow inside the TRILL cloud. Is it
>>> not?
>>> It may also need an elaborate session management and control protocols
>>> between ingress R-Bridge and egress R-Brdge, so that in-order is
>>> guaranteed.
>>>
>>>
>>> BTW, do not 802 solutions in *steady state* give in-order delivery for a
>>> given flow?
>>>
>>> Thanks a lot,
>>> Venkatg
>>>
>>> -----Original Message-----
>>> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
>>> Sent: Monday, October 06, 2008 1:10 PM
>>> To: gvsm
>>> Cc: rbridge at postel.org; Venkatsubramaniyan G, TLS-Chennai
>>> Subject: Re: [rbridge] In-order delivery not an issue?
>>>
>>> TRILL ought to do in-order delivery, except with an occasional out of
>>> order packet in very rare cases. The 802 solutions also, with low
>>> probability, will occasionally reorder packets. Perhaps one could argue
>>> that the probability
>>> might be slightly larger with TRILL, but in either case it will be "very
>>>
>>> rare".
>>>
>>> Certainly we took the desire for in-order delivery into account in the
>>> design of TRILL.
>>>
>>> Radia
>>>
>>>
>>> gvsm wrote:
>>>
>>>> Hi,
>>>>
>>>> Does not present Ethernet by STP families give inorder delivery of
>>>> frames for a flow?
>>>> Will not this be compromised with this(TRILL) solution or is it
>>>> assumed implementation would take care of it?
>>>>
>>>> Thanks,
>>>> venkatg
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>
>>> DISCLAIMER:
>>> -----------------------------------------------------------------------------------------------------------------------
>>>
>>> The contents of this e-mail and any attachment(s) are confidential and
>>> intended for the named recipient(s) only.
>>> It shall not attach any liability on the originator or HCL or its
>>> affiliates. Any views or opinions presented in
>>> this email are solely those of the author and may not necessarily
>>> reflect the opinions of HCL or its affiliates.
>>> Any form of reproduction, dissemination, copying, disclosure,
>>> modification, distribution and / or publication of
>>> this message without the prior written consent of the author of this
>>> e-mail is strictly prohibited. If you have
>>> received this email in error please delete it and notify the sender
>>> immediately. Before opening any mail and
>>> attachments please check them for viruses and defect.
>>>
>>> -----------------------------------------------------------------------------------------------------------------------
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjqk5IACgkQE5f5cImnZrtgNgCdF3sxWNIS2ZgMmWGuL5PV/25z
> hF0AoKKoRZwwy7mDdhBo3VbwLCE3386g
> =nMhu
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com