From Internet-Drafts at ietf.org  Wed Oct  1 13:45:02 2008
From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org)
Date: Wed,  1 Oct 2008 13:45:02 -0700 (PDT)
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-09.txt
Message-ID: <20081001204502.ECA013A6C57@core3.amsl.com>



From g.venkatasubramaniyan at gmail.com  Fri Oct  3 16:58:52 2008
From: g.venkatasubramaniyan at gmail.com (gvsm)
Date: Sat, 4 Oct 2008 05:28:52 +0530
Subject: [rbridge] In-order delivery not an issue?
Message-ID: <b8190bf40810031658u7549136ew1c65c269a34ed8ce@mail.gmail.com>

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

From trill at punk.co.nz  Sat Oct  4 06:25:50 2008
From: trill at punk.co.nz (Kris Price)
Date: Sat, 04 Oct 2008 21:25:50 +0800
Subject: [rbridge] Questions - VLANs & MPLS
In-Reply-To: <18658.6137.271907.615010@gargle.gargle.HOWL>
References: <48DDDC83.1050701@punk.co.nz>	<1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com>	<48DF4620.8060900@punk.co.nz>
	<48DFD0DA.9030802@cisco.com>
	<18658.6137.271907.615010@gargle.gargle.HOWL>
Message-ID: <48E76EDE.7070406@punk.co.nz>

James Carlson wrote:
> Dinesh G Dutt writes:
>> MPLS format was originally considered and rejected for a few reasons. For 
>> example, we wanted the source and destination RBridge addresses instead of 
>> only the destination RBridge because of the need to support things like 
>> IEEE's congestion management, support troubleshooting tools such as 
>> traceroute and ping within an TRILL cloud etc.
> 
> I think a more important reason for it is that you can't do MAC
> address learning of decapsulated packets unless you know where (what
> encapsulator) they came from.

I wondered about that, but I didn't understand why an RBridge needed to 
do MAC address learning. It seemed that was handled by IS-IS. If I read 
the original paper right that was the intention. (?)

But reading the draft (properly this time) I see MAC learning is now the 
favoured method, with distribution by IS-IS optional. Part of me favours 
this now that I understand it. It means intermediate RBridges don't have 
to maintain information in their FIBs that they're not using.

I guess it was a contentious issue whether learning should've all been 
via a routing protocol, or via learning. Had the former been favoured, 
MPLS label switched paths would've been a feasible forwarding method.

Makes sense now, thanks for your answers :)

Cheers
Kris

From d3e3e3 at gmail.com  Sat Oct  4 12:22:13 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sat, 4 Oct 2008 15:22:13 -0400
Subject: [rbridge] Questions - VLANs & MPLS
In-Reply-To: <48E76EDE.7070406@punk.co.nz>
References: <48DDDC83.1050701@punk.co.nz>
	<1028365c0809270959i3ad4911dp4077622dcc480d6f@mail.gmail.com>
	<48DF4620.8060900@punk.co.nz> <48DFD0DA.9030802@cisco.com>
	<18658.6137.271907.615010@gargle.gargle.HOWL>
	<48E76EDE.7070406@punk.co.nz>
Message-ID: <1028365c0810041222y6c99ffbaj612b717ef268e2a2@mail.gmail.com>

See below...

On Sat, Oct 4, 2008 at 9:25 AM, Kris Price <trill at punk.co.nz> wrote:

> James Carlson wrote:
>
>> Dinesh G Dutt writes:
>>
>>> MPLS format was originally considered and rejected for a few reasons. For
>>> example, we wanted the source and destination RBridge addresses instead of
>>> only the destination RBridge because of the need to support things like
>>> IEEE's congestion management, support troubleshooting tools such as
>>> traceroute and ping within an TRILL cloud etc.
>>>
>>
>> I think a more important reason for it is that you can't do MAC
>> address learning of decapsulated packets unless you know where (what
>> encapsulator) they came from.
>>
>
> I wondered about that, but I didn't understand why an RBridge needed to do
> MAC address learning. It seemed that was handled by IS-IS. If I read the
> original paper right that was the intention. (?)


Yes, that was the original intention. Someone from a routing background
would find that way of doing things to be natural.

But reading the draft (properly this time) I see MAC learning is now the
> favoured method, with distribution by IS-IS optional. Part of me favours
> this now that I understand it. It means intermediate RBridges don't have to
> maintain information in their FIBs that they're not using.
>

Yes, those from a bridging background think that learning in the data plane
is much more natural, doesn't overburden the control plane, etc.

However, it was never the case that transit (intermediate) RBridges needed
to maintain link state for end station addresses (unless they have directly
connected end stations in the same VLAN, in which case they really aren't
transit RBridges). The end station address distribution instances are
tunneled through transit RBridges and handled, by transit RBridges, exactly
like data frames. See protocol draft -09 Section 4.2.4.


> I guess it was a contentious issue whether learning should've all been via
> a routing protocol, or via learning. Had the former been favoured, MPLS
> label switched paths would've been a feasible forwarding method.
>
> Makes sense now, thanks for your answers :)
>
> Cheers
> Kris
>

Indeed, this was contentious for a while.
Thanks,
Donald
-- 
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081004/367f5f19/attachment.html

From Radia.Perlman at sun.com  Mon Oct  6 00:39:30 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 06 Oct 2008 00:39:30 -0700
Subject: [rbridge] In-order delivery not an issue?
In-Reply-To: <b8190bf40810031658u7549136ew1c65c269a34ed8ce@mail.gmail.com>
References: <b8190bf40810031658u7549136ew1c65c269a34ed8ce@mail.gmail.com>
Message-ID: <48E9C0B2.7040708@sun.com>

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
>   


From ddutt at cisco.com  Mon Oct  6 07:33:50 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 06 Oct 2008 07:33:50 -0700
Subject: [rbridge] In-order delivery not an issue? (resending with my
 correct addr)
In-Reply-To: <48E9C0B2.7040708@sun.com>
References: <b8190bf40810031658u7549136ew1c65c269a34ed8ce@mail.gmail.com>
	<48E9C0B2.7040708@sun.com>
Message-ID: <48EA21CE.3090308@cisco.com>

One place where TRILL will out-of-order a frame where a 802.1Q won't is for
the case of an unknown unicast vs known unicast. If the first frame is
flooded and the subsequent frame is not, it is possible that they may get
out of order as they follow different paths. With spanning tree, all frames
follow the same path because there is only one path.

I have not run into any customer who thought that this was an issue when I
explicitly raised this point with them.

Dinesh
P.S: I've fixed my emailer to not send emails to rbridge with my personal 
a/c. Apologies for the double posting.
Radia Perlman wrote:
> 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
>>   
> 
> _______________________________________________
> 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


From touch at ISI.EDU  Mon Oct  6 07:41:57 2008
From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Oct 2008 07:41:57 -0700
Subject: [rbridge] In-order delivery not an issue?
In-Reply-To: <48E9C0B2.7040708@sun.com>
References: <b8190bf40810031658u7549136ew1c65c269a34ed8ce@mail.gmail.com>
	<48E9C0B2.7040708@sun.com>
Message-ID: <48EA23B5.5010305@isi.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Radia Perlman wrote:
> 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".

Agreed.

That has been in the problem statement as an assumed requirement from
the beginning of the WG, FWIW. See section 3.1.

Joe

> 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
>>   
> 
> _______________________________________________
> 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

iEYEARECAAYFAkjqI7UACgkQE5f5cImnZrvs9ACgrZDDeZUpt4KsUyuaikhZdgDz
VPkAoIUdkGer4WN+EmLDt74YwabNMv60
=fBzd
-----END PGP SIGNATURE-----

From g.venkatasubramaniyan at ieee.org  Mon Oct  6 09:59:48 2008
From: g.venkatasubramaniyan at ieee.org ( G.Venkatasubramaniyan)
Date: Mon, 6 Oct 2008 22:29:48 +0530
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
References: <48E9C0B2.7040708@sun.com>
	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
Message-ID: <b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>

resending my previous mail ...
Thanks,
venkatg
---------- 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.

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

From Caitlin.Bestler at neterion.com  Mon Oct  6 10:40:07 2008
From: Caitlin.Bestler at neterion.com (Caitlin Bestler)
Date: Mon, 6 Oct 2008 13:40:07 -0400
Subject: [rbridge] In-order delivery not an issue? (resending with my
	correct addr)
In-Reply-To: <48EA21CE.3090308@cisco.com>
References: <b8190bf40810031658u7549136ew1c65c269a34ed8ce@mail.gmail.com><48E9C0B2.7040708@sun.com>
	<48EA21CE.3090308@cisco.com>
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7704634577@nekter>



> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Dinesh G Dutt
> Sent: Monday, October 06, 2008 7:34 AM
> To: Radia Perlman
> Cc: rbridge at postel.org; venkatg at hcl.in; gvsm
> Subject: Re: [rbridge] In-order delivery not an issue? (resending with
> my correct addr)
> 
> One place where TRILL will out-of-order a frame where a 802.1Q won't
is
> for
> the case of an unknown unicast vs known unicast. If the first frame is
> flooded and the subsequent frame is not, it is possible that they may
> get
> out of order as they follow different paths. With spanning tree, all
> frames
> follow the same path because there is only one path.
> 
> I have not run into any customer who thought that this was an issue
> when I
> explicitly raised this point with them.
> 
> Dinesh

The shift from unknown to known is the one case where TRILL could have
an out of ordering scenario that spanning tree alone would not have.

But it should also be noted that TRILL will *reduce* the frequency of
spanning tree bridges forgetting addresses because those bridges will
see fewer addresses.

Benefits from reduction in excess flooding would far outweigh any
extreme
corner case re-ordering potential that TRILL may create.



From james.d.carlson at sun.com  Mon Oct  6 11:39:49 2008
From: james.d.carlson at sun.com (James Carlson)
Date: Mon, 6 Oct 2008 14:39:49 -0400
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
References: <48E9C0B2.7040708@sun.com>
	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
Message-ID: <18666.23413.817202.388244@gargle.gargle.HOWL>

 G.Venkatasubramaniyan writes:
> 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.

Absent events that cause any of the intermediate nodes to change their
forwarding database, I would expect something like that is true.

However, those events can occur, and the existence of them has nothing
to do with the identification of a given {SRC,DST,QoS} triplet.  If
some node in the middle of the network decides that the best path to
get to DST no longer goes through downstream node X but instead goes
to Y, then packets previously sent to X will race those now being sent
to Y.  If the source packet rate and switching time are 'short'
compared to the time delta between the two paths, then some packets
are bound to arrive out of order.

There's little we can do about that short of deliberately dropping
packets.  It gives us only "rare" and "unintentional" reordering
characteristics.

>  The individual paths can have different traffic
> conditions and reaction mechanisms which may not give in-order behavior,
> which could largely vary.

Yes; exactly.

> 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?

I think that'd be a terrible mistake.  It's something we could handle
with options, if it were necessary, but I suspect that worrying about
the narrow cases where this can happen in various networks and trying
to 'fix' all of them is just taking a flamethrower to a gnat of a
problem.  It might be better to worry about the countryside that's
scorched in the process.

(I've seen a variant of this used in other protocols: if the sender
[original encapsulator] *knows* that the encapsulated message can
tolerate reordering, then don't bother numbering it.  If the sender
doesn't know, or knows that it cannot tolerate reordering, then add a
number.  That way, most protocols don't pay the price in overhead and
loss, but [unfortunately] all implementations do pay it in
complexity.)

> BTW, do not 802 solutions in *steady state* give in-order delivery for a
> given flow?

If one can assume *steady-state*, then pretty much everything except a
deliberately malicious node provides in-order delivery.

If we are permitted to assume that, then RBridges are every bit as
non-reordering as are any of the standard 802 bridges.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From Caitlin.Bestler at neterion.com  Mon Oct  6 12:11:04 2008
From: Caitlin.Bestler at neterion.com (Caitlin Bestler)
Date: Mon, 6 Oct 2008 15:11:04 -0400
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
References: <48E9C0B2.7040708@sun.com><66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77046345E4@nekter>

> 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.
> 

I do not believe that is an accurate characterization of Appendix C.
There it states that the mechanism(s) used to ensure that conversations
are not mis-ordered by ECMP is "out of scope".

   When multipathing is used, frames that follow different paths will be
   subject to different delays and may be re-ordered.  While some
   traffic may be order/delay insensitive, typically most traffic
   consists of flows of frames such the re-ordering within a flow is
   damaging. How to determine flows or what granularity flows should
   have is beyond the scope of this document but, as an example, under
   many circumstances it would be safe to consider all the frames
   flowing between a particular pair of end station ports to be a flow.

It might be useful to explicitly state that any flow considered to be 
a "conversation" for 802.3ad purposes SHOULD be similarly treated by
any RBRidge implementing multi-pathing. But such a statement is only
making explicit what I think is already clearly the intent.



From d3e3e3 at gmail.com  Mon Oct  6 12:32:59 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 6 Oct 2008 15:32:59 -0400
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
References: <48E9C0B2.7040708@sun.com>
	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
Message-ID: <1028365c0810061232y6087fe7pd2bbf62ba67d1be0@mail.gmail.com>

See below

On Mon, Oct 6, 2008 at 12:59 PM, G.Venkatasubramaniyan
<g.venkatasubramaniyan at ieee.org> wrote:
>
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- 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.

TRILL does not define what a flow is. If you believe that frames with
the same source and destination MAC address and priority should be
delivered in order, then you would use that as the definition of a
flow and send all the frames in that flow over the same equal cost
path in an RBridge campus just as you would send them all over the
same link in the case of link aggregation. Although TRILL supports
equal cost multipath, it does not fully specify it and the granularity
of flows is one aspect left to the implementer.

> 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.

I do not see any need for this to be "handled inside TRILL".

> BTW, do not 802 solutions in *steady state* give in-order delivery for a
> given flow?

Yes, as does TRILL.

> Thanks a lot,
> Venkatg

Donald

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

From mrthom at essex.ac.uk  Mon Oct  6 13:54:02 2008
From: mrthom at essex.ac.uk (Thomas, Matthew R)
Date: Mon, 6 Oct 2008 21:54:02 +0100
Subject: [rbridge] Fwd: In-order delivery not an issue?
References: <48E9C0B2.7040708@sun.com><66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
	<1028365c0810061232y6087fe7pd2bbf62ba67d1be0@mail.gmail.com>
Message-ID: <7AC902A40BEDD411A3A800D0B7847B661D3B3FCE@sernt14.essex.ac.uk>

Donald,
 
I also agree,
 
The phrasing I think is well handled as it is,
 
MT
 
The nice thing about LS protocols is that you get a certain load sharing anyway as you have multiple differing src - dst trees anyway.

________________________________

From: rbridge-bounces at postel.org on behalf of Donald Eastlake
Sent: Mon 06/10/2008 20:32
To: G.Venkatasubramaniyan
Cc: rbridge at postel.org
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?



See below

On Mon, Oct 6, 2008 at 12:59 PM, G.Venkatasubramaniyan
<g.venkatasubramaniyan at ieee.org> wrote:
>
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- 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.

TRILL does not define what a flow is. If you believe that frames with
the same source and destination MAC address and priority should be
delivered in order, then you would use that as the definition of a
flow and send all the frames in that flow over the same equal cost
path in an RBridge campus just as you would send them all over the
same link in the case of link aggregation. Although TRILL supports
equal cost multipath, it does not fully specify it and the granularity
of flows is one aspect left to the implementer.

> 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.

I do not see any need for this to be "handled inside TRILL".

> BTW, do not 802 solutions in *steady state* give in-order delivery for a
> given flow?

Yes, as does TRILL.

> Thanks a lot,
> Venkatg

Donald

> -----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
--
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge




From ddutt at cisco.com  Mon Oct  6 14:30:51 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 06 Oct 2008 14:30:51 -0700
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
References: <48E9C0B2.7040708@sun.com>	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
Message-ID: <48EA838B.7080006@cisco.com>

Venkat,

Think about how in-order delivery guarantees are offered within IP 
today. Even TCP does not like dealing with out of order frames without 
suffering loss of throughput.

What is done is that we send all frames associated with a flow (and 
different products have different definitions of flow, ranging from {DA, 
SA, VLAN} to the full 5 TCP/IP tuple and more) on the same path thereby 
guaranteeing in order delivery for that flow, in steady state. AFAIK, 
there is no requirement for the network to maintain order across flows.

Dinesh
 G.Venkatasubramaniyan wrote:
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- 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
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


From ddutt at cisco.com  Mon Oct  6 14:32:54 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 06 Oct 2008 14:32:54 -0700
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
References: <48E9C0B2.7040708@sun.com>	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
Message-ID: <48EA8406.5000701@cisco.com>

One more point. The TCP/IP RFCs don't talk about maintaining order 
either, but products do it. IIRC, even IEEE's link aggregation doesn't 
specify how to maintain order when spreading frames across the different 
links of a link agg group.

Dinesh
 G.Venkatasubramaniyan wrote:
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- 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
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


From james.d.carlson at sun.com  Mon Oct  6 14:30:30 2008
From: james.d.carlson at sun.com (James Carlson)
Date: Mon, 6 Oct 2008 17:30:30 -0400
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77046345E4@nekter>
References: <48E9C0B2.7040708@sun.com>
	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
	<78C9135A3D2ECE4B8162EBDCE82CAD77046345E4@nekter>
Message-ID: <18666.33654.244755.26183@gargle.gargle.HOWL>

Caitlin Bestler writes:
> It might be useful to explicitly state that any flow considered to be 
> a "conversation" for 802.3ad purposes SHOULD be similarly treated by
> any RBRidge implementing multi-pathing. But such a statement is only
> making explicit what I think is already clearly the intent.

I'd support that.  Given the amount of wiggle room the 802.3ad
'conversation' definition allows -- it's just the frames between
stations that must maintain order, without necessarily restricting how
one identifies such frames -- I'd even say this could be a safe MUST.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From touch at ISI.EDU  Mon Oct  6 15:39:14 2008
From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Oct 2008 15:39:14 -0700
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <48EA8406.5000701@cisco.com>
References: <48E9C0B2.7040708@sun.com>	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
	<48EA8406.5000701@cisco.com>
Message-ID: <48EA9392.4060705@isi.edu>

-----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-----

From touch at ISI.EDU  Mon Oct  6 17:30:50 2008
From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Oct 2008 17:30:50 -0700
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <48EA838B.7080006@cisco.com>
References: <48E9C0B2.7040708@sun.com>	<66E8AEE9980BB44CA5FCAD39EBA56AC604A6E0E7@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>	<b8190bf40810060959j61e291fcxe5cefb79bc0f9a1f@mail.gmail.com>
	<48EA838B.7080006@cisco.com>
Message-ID: <48EAADBA.5040905@isi.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Dinesh G Dutt wrote:
> Venkat,
> 
> Think about how in-order delivery guarantees are offered within IP 
> today. Even TCP does not like dealing with out of order frames without 
> suffering loss of throughput.

Let's be a little more careful with words here:

	- the Internet does not rely on in-order "guarantees"

	- some protocols react better to out-of-order than others
		e.g., UDP does just fine, as should TCP w/SACK

	- the impact of out of order depends on how spread-out
	the reordering is in some cases
		e.g., TCP should react to small reorderings
		due to multipath fairly well within a RTT;
		it will be more bursty, but should not cut
		the window down just because packets arrive
		out of order

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

iEYEARECAAYFAkjqrZwACgkQE5f5cImnZrs7wQCghKvOsyk/+2XbQWMvzbsHc9Pj
+IsAn1au07bAwjkwf+WTS2EutBEdYRSS
=2zRk
-----END PGP SIGNATURE-----

From ravikumarb at infosys.com  Mon Oct  6 21:47:17 2008
From: ravikumarb at infosys.com (ravikumarb)
Date: Tue, 7 Oct 2008 10:17:17 +0530
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <48EA838B.7080006@cisco.com>
Message-ID: <EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>

Dinesh,

What you are saying is perfectly fine with IP and TCP. But Ethernet is a layer 2 (link layer) protocol. In steady state, Ethernet always delivers packets in order. There are occasional packet losses but not out-or-order packet delivery.

802.3ad mandates in-order delivery for packets belonging to a conversation. In similar lines, TRILL can maintain in-order deliver *only* for packets belonging to a CONVERSATION (by taking the same path), which in our case can loosely be defined as packets from a Source to Destination machine.

Regards,
Ravi

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
Sent: Tuesday, October 07, 2008 4:01 AM
To: G.Venkatasubramaniyan
Cc: rbridge at postel.org
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?

Venkat,

Think about how in-order delivery guarantees are offered within IP
today. Even TCP does not like dealing with out of order frames without
suffering loss of throughput.

What is done is that we send all frames associated with a flow (and
different products have different definitions of flow, ranging from {DA,
SA, VLAN} to the full 5 TCP/IP tuple and more) on the same path thereby
guaranteeing in order delivery for that flow, in steady state. AFAIK,
there is no requirement for the network to maintain order across flows.

Dinesh
 G.Venkatasubramaniyan wrote:
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- 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
>
>

--
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

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***


From james.d.carlson at sun.com  Tue Oct  7 08:02:12 2008
From: james.d.carlson at sun.com (James Carlson)
Date: Tue, 7 Oct 2008 11:02:12 -0400
Subject: [rbridge] Fwd:  In-order delivery not an issue?
In-Reply-To: <EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
References: <48EA838B.7080006@cisco.com>
	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
Message-ID: <18667.31220.5239.43072@gargle.gargle.HOWL>

ravikumarb writes:
> What you are saying is perfectly fine with IP and TCP. But Ethernet is a layer 2 (link layer) protocol. In steady state, Ethernet always delivers packets in order. There are occasional packet losses but not out-or-order packet delivery.

Agreed, though we're also talking about bridging here, and out-of-
order is at least remotely possible when failures and reconfigurations
are considered.

As long as we don't have to consider recovery from "failure," with
"failure" defined as anything that changes the computed paths in the
network, I think requiring in-order delivery is fine.  In fact, it'd
likely require extra work to achieve out-of-order under those
conditions.

> 802.3ad mandates in-order delivery for packets belonging to a conversation. In similar lines, TRILL can maintain in-order deliver *only* for packets belonging to a CONVERSATION (by taking the same path), which in our case can loosely be defined as packets from a Source to Destination machine.

802.3ad does mandate it for a conversation, and it seems reasonable
that for the narrow case of ECMP we should recommend it to the extent
possible, but there are multiple issues here.  One is that 802.3ad
doesn't quite define what constitutes a "conversation" except in
circular terms via the definition in 1.4.94: you must keep those
packets in order because they're packets that are kept in order.

(It even seems to equivocate on that point by setting one of the goals
as a "low risk of duplication or misordering," and not just "none.")

The underlying issue, though, is that it's really not feasible to
mandate an absolute here.  We don't have the same simple peer-to-peer
signaling situation that is in 802.3ad, so the same type of "Marker
PDU" mechanism is impractical; the streams are split across multiple
paths, not just multiple links.  Instead, for folks who implement
multipath at all (it's not a required part of the implementation),
they'll need to do whatever they feel is necessary to satisfy the
markets they go into.  That might mean avoiding or disabling ECMP, or
selecting a single path among the available ones on which to send all
"unknown" type packets, or perhaps applying some of the insights in
RFC 2992 to minimize pain.

Given that implementors *must* understand their markets and the
intended use of what they're producing and any additional constraints
that may impose in order to produce competent products (the RFCs alone
are never enough), and that multiple reasonable answers are possible
here, I don't think it's a good idea to nail this issue down in this
document.  A warning about the possible effects of ill-considered
reordering behavior might be reasonable, but constraining the solution
set doesn't sound like a good plan to me, particularly in an IETF
document.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From d3e3e3 at gmail.com  Wed Oct  8 19:50:05 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 8 Oct 2008 22:50:05 -0400
Subject: [rbridge] Base protocol working group last call early warning
Message-ID: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>

Hi,
We plan to start a Working Group Last Call on the "Rbridges: Base Protocol
Specification" draft early next week.

Thanks,
Donald and Erik
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081008/2f23efbe/attachment.html

From d3e3e3 at gmail.com  Wed Oct  8 21:04:49 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 9 Oct 2008 00:04:49 -0400
Subject: [rbridge] draft-ietf-trill-prob-05.txt Publication Request
In-Reply-To: <1028365c0810082045o721152f4u6e288be55de0f941@mail.gmail.com>
References: <1028365c0810082045o721152f4u6e288be55de0f941@mail.gmail.com>
Message-ID: <1028365c0810082104w42f2489dt3f1d253ce607f0aa@mail.gmail.com>

Hi,

We have requested publication of draft-ietf-trill-prob-05.txt as an
Informational RFC. The PROTO statement is below.

Thanks,
Donald and Erik
=============================
Donald E. Eastlake 3rd
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com


(1.a) Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this version
      is ready for forwarding to the IESG for publication?

    Donald E. Eastlake 3rd <d3e3e3 at gmail.com>

    Yes

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

    The document has had adequate review. In its early days, when it
    was incomplete and it appear to be difficult to get comments, a
    first WGLC was done which succeeded in eliciting comments. A
    complete revised document was WGLCed here
    http://www.postel.org/pipermail/rbridge/2008-July/003059.html
    producing comments the resolutions of which are here
    http://www.postel.org/pipermail/rbridge/2008-August/003083.html
    resulting is a revised draft notice of posting of which is here
    http://www.postel.org/pipermail/rbridge/2008-September/003110.html

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

    No.

(1.d) Does the Document Shepherd have any specific concerns or issues
      with this document that the Responsible Area Director and/or the
      IESG should be aware of? For example, perhaps he or she is
      uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it. In any event, if
      the WG has discussed those issues and has indicated that it
      still wishes to advance the document, detail those concerns
      here. Has an IPR disclosure related to this document been filed?
      If so, please include a reference to the disclosure and
      summarize the WG discussion and conclusion on this issue.

    No specific concerns.

    No IPR disclosure specific to this document has been filed but see
    http://www.ietf.org/ietf/IPR/sun-ipr-draft-perlman-rbridge.txt
    for the Sun Microsystems RBridge disclosure.

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

    This document represents the opinion of the working group as
    discerned by the co-chairs. There has been discussion of how
    the document should "describe" IEEE 802 spanning tree protocol
    but that does not affect the techncial content of this document.
    In this the document represents something reasonably close to
    the center of working group opinion.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

    No.

(1.g) Has the Document Shepherd personally verified that the document
      satisfies all ID nits? (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
      enough; this check needs to be thorough. Has the document met
      all formal review criteria it needs to, such as the MIB Doctor,
      media type and URI type reviews?

    Yes.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the strategy
      for their completion? Are there normative references that are
      downward references, as described in [RFC3967]? If so, list
      these downward references to support the Area Director in the
      Last Call procedure for them [RFC3967].

  References are split but there are no normative references.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document? If the document specifies protocol extensions, are
      reservations requested in appropriate IANA registries? Are the
      IANA registries clearly identified? If the document creates a
      new registry, does it define the proposed initial contents of
      the registry and an allocation procedure for future
      registrations? Does it suggest a reasonable name for the new
      registry? See [RFC5226]. If the document describes an Expert
      Review process has Shepherd conferred with the Responsible Area
      Director so that the IESG can appoint the needed Expert during
      the IESG Evaluation?

    None of the above is applicable to this document. That IANA
    section correctly states that no IANA actions are required and
    that the section should be removed on publication.

(1.j) Has the Document Shepherd verified that sections of the document
      that are written in a formal language, such as XML code, BNF
      rules, MIB definitions, etc., validate correctly in an automated
      checker?

  There are no such sections in this document.

(1.k) The IESG approval announcement includes a Document Announcement
          Write-Up. Please provide such a Document Announcement
          Write-Up? Recent examples can be found in the "Action"
          announcements for approved documents. The approval
          announcement contains the following sections:


      Technical Summary

             This document discusses the avoidance of some problems in
             Layer 2 forwarding with the spanning tree protocol
             through the use of link state routing techniques,
             possibly with a hop count limit. Desired properties and
             the applicability of such improved forwarding are also
             given.

      Working Group Summary

     This document was Working Group Last Called twice. There
     were informal complaints that the first WGLC was improper
     because the document was not complete at that time.

      Document Quality

             This is an informational document intended to describe
             the problem to which the TRILL working group is addressed
              and the applicability of solutions. Document quality is
             good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081009/cfe489ff/attachment.html

From cait at asomi.com  Fri Oct 10 10:23:55 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Fri, 10 Oct 2008 10:23:55 -0700
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
Message-ID: <48EF8FAB.3060903@asomi.com>

Does an RBridge implementation *use* 802.1 or does it
*include* an 802.1 implementation?

The problem statement implies that it *uses* 802.1.
 From the Abstract:

	This document assumes that solutions would not
	address issues of scalability beyond that of existing bridged 		 
(802.1) links, but that a solution would be backward compatible
	with 802.1, including hubs, bridges, and their existing
	plug-and-play capabilities.

That implies that RBridges would use the 802.1 defined EISS
interface, although that is not included in the cited list
of compatibilities.

However, Section 2.2 of the protocol discusses the encapsulation
in terms of 802.3, with PPP being given as one alternate encoding.

The presentation in this section could imply that an RBRidge 
implementation essentially subsumes the 802.1 role, including
being directly aware of 802.3 and alternate lower-layer L2s.

If TRILL *uses* 802.1 then the more correct description would be
that the TRILL Header, Inner Ethernet Header and Ethernet Payload
are submitted as the payload using EISS. The Elements that make
the Outer Ethernet Headers are parameters to EISS.

The diagrams presented in Section 2.2 represent the encapsulation
that the 802.1 layer will do in collaboration with 802.1 or PPP.
But to be totally correct, it does not specify them. IEEE documents
govern this behavior.

Up through 802.1Q-2005 this is strictly an academic question. The
processing between the EISS and ISS interfaces is very well understood
and there is no harm in integrating layers in implementation.

However, this could have an impact on the default interpretation of
TRILL interoperability with new 802.1Q amendments, especially those
in the Data Center Bridging. Interoperability with Provider Backbone
Bridging and Shortest Path Bridging may also be impacted.

I believe the best resolution here was covered previously in
mailing list discussions. We should just state than an RBridge
is a *client* of 802.1 services. That implies reasonable defaults
for RBridge interaction with post 2005 802.1 services. If there
are specific rationale for roto-tilling, as may be the case for
802.1Qau QCN (Congestion Notification) would require subsequent
drafts to justify and define them.


-----
Caitlin Bestler
cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf

task group,



From Radia.Perlman at sun.com  Fri Oct 10 15:33:44 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 10 Oct 2008 15:33:44 -0700
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
Message-ID: <48EFD848.9050303@sun.com>

I can't quite parse bullet 3 in section 4.4.1.1. It might be correct, 
but the wording is confusing.

It's talking about the case where RB1, designated forwarder, receives a 
packet that RB1 knows should
go to egress RBridge RB2.

Maybe this wording is clearer?

*************section 4.4.1.1 bullet 3

If the destination is known by RB1 to belong to egress RBridge RB2, then 
RB1 encapsulates the
frame with TRILL header specifying RB2's nickname as egress RBridge, and 
forwards the encapsulated
frame towards RB2.

From Radia.Perlman at sun.com  Fri Oct 10 15:43:37 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 10 Oct 2008 15:43:37 -0700
Subject: [rbridge] encoding of TRILL IS-IS frames
Message-ID: <48EFDA99.9070304@sun.com>

Someone asked me why IS-IS frames need to be TRILL-encapsulated, and I 
don't remember. I do know we
were somewhat concerned about differentiating TRILL IS-IS frames from 
layer 3 IS-IS frames. But assuming
we use a different multicast address for TRILL IS-IS than layer 3 IS-IS, 
with the additional safeguard of
using a different "area ID" (for TRILL, area ID=0), it seems like there 
would be no danger of confusion.

Perhaps we were concerned about possible unicast of IS-IS frames, like 
for instance, a PSNP that one might
send just to the DR? I think I verified with the IS-IS people that there 
are no IS-IS frames that are unicast.

So why doesn't the following work?

For core IS-IS frames, no encapsulation, but a special multicast address 
"all-nbr-TRILL-IS-IS" as
the destination address.

For ESADI, TRILL encapsulation like with ordinary data packets, but 
having as the destination
address in the inner Ethernet header a different multicast address 
"all-ESADI-TRILL"

The advantage of this is that for core TRILL IS-IS, we'd save header 
room and probably work for
RBridges to parse IS-IS packets.

Radia

From Radia.Perlman at sun.com  Fri Oct 10 15:47:21 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 10 Oct 2008 15:47:21 -0700
Subject: [rbridge] Making VLAN mapping not illegal -- minor wording change
Message-ID: <48EFDB79.5040908@sun.com>

Section 4.1.2 says "When a TRILL frame passes through a
transit RBridge, the Inner.VLAN MUST NOT be changed."

If we were to do VLAN mapping, (draft to come...) we would want to allow 
an RBridge
to change the inner VLAN tag. So the wording perhaps should be:

"....the Inner.VLAN MUST NOT be changed, except when VLAN mapping is
being intentionally performed."



From d3e3e3 at gmail.com  Fri Oct 10 16:34:11 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Oct 2008 19:34:11 -0400
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <48EF8FAB.3060903@asomi.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
	<48EF8FAB.3060903@asomi.com>
Message-ID: <1028365c0810101634m1aa50ebw4dea8069222b4327@mail.gmail.com>

Hi Caitlin,

A few comments below...

On Fri, Oct 10, 2008 at 1:23 PM, Caitlin Bestler <cait at asomi.com> wrote:
>
> Does an RBridge implementation *use* 802.1 or does it
> *include* an 802.1 implementation?

I'm not sure exactly what you mean.

An RBridge incorporates parts which are the same as 802.1Q but does
not include all of 802.1Q. In particular it does not include any
version of spanning tree protocol (although it does limited parsing of
and can do very limited generation of BPDUs). On the other hand, as
far as I can tell, RBridges perform the identical VLAN processing to
that between the ISS and EISS interfaces in 802.1Q.

> The problem statement implies that it *uses* 802.1.
>  From the Abstract:
>
>        This document assumes that solutions would not
>        address issues of scalability beyond that of existing bridged
> (802.1) links, but that a solution would be backward compatible
>        with 802.1, including hubs, bridges, and their existing
>        plug-and-play capabilities.
>
> That implies that RBridges would use the 802.1 defined EISS
> interface, although that is not included in the cited list
> of compatibilities.

I don't agree that it implies that. Backward compatibility seem
reasonably satisfied by the general ability to incrementally deploy
RBridges into a 802.1Q bridged LAN and and the ability to connect end
stations to an RBridge or a bridge.

> However, Section 2.2 of the protocol discusses the encapsulation
> in terms of 802.3, with PPP being given as one alternate encoding.
>
> The presentation in this section could imply that an RBRidge
> implementation essentially subsumes the 802.1 role, including
> being directly aware of 802.3 and alternate lower-layer L2s.

I think that is the best way to look at it, even if RBridges
incorporate some blocks of processing from 802.1Q. RBridges use the
802.1Q port VLAN processing because it is convenient.

> If TRILL *uses* 802.1 then the more correct description would be
> that the TRILL Header, Inner Ethernet Header and Ethernet Payload
> are submitted as the payload using EISS. The Elements that make
> the Outer Ethernet Headers are parameters to EISS.

The IETF generally doesn't do APIs. Figure 4.3 in the current protocol
draft indeed shows that native and TRILL frames being output to a port
of an RBridge can be thought of as going through an interface which is
logically equivalent to the 802.1Q EISS.

> The diagrams presented in Section 2.2 represent the encapsulation
> that the 802.1 layer will do in collaboration with 802.1 or PPP.
> But to be totally correct, it does not specify them. IEEE documents
> govern this behavior.
>
> Up through 802.1Q-2005 this is strictly an academic question. The
> processing between the EISS and ISS interfaces is very well understood
> and there is no harm in integrating layers in implementation.
>
> However, this could have an impact on the default interpretation of
> TRILL interoperability with new 802.1Q amendments, especially those
> in the Data Center Bridging. Interoperability with Provider Backbone
> Bridging and Shortest Path Bridging may also be impacted.
>
> I believe the best resolution here was covered previously in
> mailing list discussions. We should just state than an RBridge
> is a *client* of 802.1 services. That implies reasonable defaults
> for RBridge interaction with post 2005 802.1 services. If there
> are specific rationale for roto-tilling, as may be the case for
> 802.1Qau QCN (Congestion Notification) would require subsequent
> drafts to justify and define them.

There is no 802.1Q bridge lurking inside an RBridge or inside an
RBridge port. The port VLAN processing between the RBridge equivalent
of ISS and EISS is the same as 802.1Q port VLAN processing between ISS
and EISS but, as far as I can see, the logic above and below that has
differences.

Thanks,
Donald

> -----
> Caitlin Bestler
> cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>
> task group,
>
> _______________________________________________
> 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

From ddutt at cisco.com  Fri Oct 10 16:47:29 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 10 Oct 2008 16:47:29 -0700
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <48EF8FAB.3060903@asomi.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
	<48EF8FAB.3060903@asomi.com>
Message-ID: <48EFE991.2070405@cisco.com>

Caitlin,

You know that I support your statements below. I believe originally 
Silvano and I had written (or maybe only just presented) what you say 
below esp w.r.t EISS. I think it is critical that we include this in the 
base protocol spec.

Thanks for sending this email yet again,

Dinesh
Caitlin Bestler wrote:
> Does an RBridge implementation *use* 802.1 or does it
> *include* an 802.1 implementation?
>
> The problem statement implies that it *uses* 802.1.
>  From the Abstract:
>
> 	This document assumes that solutions would not
> 	address issues of scalability beyond that of existing bridged 		 
> (802.1) links, but that a solution would be backward compatible
> 	with 802.1, including hubs, bridges, and their existing
> 	plug-and-play capabilities.
>
> That implies that RBridges would use the 802.1 defined EISS
> interface, although that is not included in the cited list
> of compatibilities.
>
> However, Section 2.2 of the protocol discusses the encapsulation
> in terms of 802.3, with PPP being given as one alternate encoding.
>
> The presentation in this section could imply that an RBRidge 
> implementation essentially subsumes the 802.1 role, including
> being directly aware of 802.3 and alternate lower-layer L2s.
>
> If TRILL *uses* 802.1 then the more correct description would be
> that the TRILL Header, Inner Ethernet Header and Ethernet Payload
> are submitted as the payload using EISS. The Elements that make
> the Outer Ethernet Headers are parameters to EISS.
>
> The diagrams presented in Section 2.2 represent the encapsulation
> that the 802.1 layer will do in collaboration with 802.1 or PPP.
> But to be totally correct, it does not specify them. IEEE documents
> govern this behavior.
>
> Up through 802.1Q-2005 this is strictly an academic question. The
> processing between the EISS and ISS interfaces is very well understood
> and there is no harm in integrating layers in implementation.
>
> However, this could have an impact on the default interpretation of
> TRILL interoperability with new 802.1Q amendments, especially those
> in the Data Center Bridging. Interoperability with Provider Backbone
> Bridging and Shortest Path Bridging may also be impacted.
>
> I believe the best resolution here was covered previously in
> mailing list discussions. We should just state than an RBridge
> is a *client* of 802.1 services. That implies reasonable defaults
> for RBridge interaction with post 2005 802.1 services. If there
> are specific rationale for roto-tilling, as may be the case for
> 802.1Qau QCN (Congestion Notification) would require subsequent
> drafts to justify and define them.
>
>
> -----
> Caitlin Bestler
> cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>
> task group,
>
>
> _______________________________________________
> 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


From d3e3e3 at gmail.com  Fri Oct 10 16:59:27 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Oct 2008 19:59:27 -0400
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
	3
In-Reply-To: <48EFD848.9050303@sun.com>
References: <48EFD848.9050303@sun.com>
Message-ID: <1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>

It certainly is a run on sentence and it should be re-worded. But now
that there is no pseudo-code in the base protocol draft, I think the
specification needs to be fairly complete here. Your suggested text
leaves out a lot of details but this bullet is in the middle of
Section 4.4 which, to my mind at least, is supposed to give the
details for handling any possible input frame.

How about:

If the destination is known by RB1 to belong to egress RBridge RB2,
then RB1 encapsulates the frame with a TRILL header and transmits the
encapsulated frame towards RB2. This TRILL header has M = 0 and
specifies the nicknames for RB1 and RB2 as the ingress and egress
RBridges respectively. The transmitted frame has RB1 as the
Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.

Thanks,
Donald


On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com> wrote:
> I can't quite parse bullet 3 in section 4.4.1.1. It might be correct,
> but the wording is confusing.
>
> It's talking about the case where RB1, designated forwarder, receives a
> packet that RB1 knows should
> go to egress RBridge RB2.
>
> Maybe this wording is clearer?
>
> *************section 4.4.1.1 bullet 3
>
> If the destination is known by RB1 to belong to egress RBridge RB2, then
> RB1 encapsulates the
> frame with TRILL header specifying RB2's nickname as egress RBridge, and
> forwards the encapsulated
> frame towards RB2.
> _______________________________________________
> 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

From ddutt at cisco.com  Fri Oct 10 17:10:52 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 10 Oct 2008 17:10:52 -0700
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <48EFDA99.9070304@sun.com>
References: <48EFDA99.9070304@sun.com>
Message-ID: <48EFEF0C.9040703@cisco.com>

Hi Radia,

I agree with all your points below. Further, I think that ESADI 
discussion is better off in a separate document than the base protocol 
spec. I'm concerned that it maybe not all right if and when someone 
plans a serious implementation of it. I want a very solid base protocol 
specification that is lean, precise and easy to  follow through with as 
little unnecessary stuff in it as possible.

Dinesh
Radia Perlman wrote:
> Someone asked me why IS-IS frames need to be TRILL-encapsulated, and I 
> don't remember. I do know we
> were somewhat concerned about differentiating TRILL IS-IS frames from 
> layer 3 IS-IS frames. But assuming
> we use a different multicast address for TRILL IS-IS than layer 3 IS-IS, 
> with the additional safeguard of
> using a different "area ID" (for TRILL, area ID=0), it seems like there 
> would be no danger of confusion.
>
> Perhaps we were concerned about possible unicast of IS-IS frames, like 
> for instance, a PSNP that one might
> send just to the DR? I think I verified with the IS-IS people that there 
> are no IS-IS frames that are unicast.
>
> So why doesn't the following work?
>
> For core IS-IS frames, no encapsulation, but a special multicast address 
> "all-nbr-TRILL-IS-IS" as
> the destination address.
>
> For ESADI, TRILL encapsulation like with ordinary data packets, but 
> having as the destination
> address in the inner Ethernet header a different multicast address 
> "all-ESADI-TRILL"
>
> The advantage of this is that for core TRILL IS-IS, we'd save header 
> room and probably work for
> RBridges to parse IS-IS packets.
>
> Radia
> _______________________________________________
> 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


From ddutt at cisco.com  Fri Oct 10 17:18:44 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 10 Oct 2008 17:18:44 -0700
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
 3
In-Reply-To: <1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
References: <48EFD848.9050303@sun.com>
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
Message-ID: <48EFF0E4.3030001@cisco.com>

That doesn't work correctly either. You want to distinguish two separate 
cases:
- The destination Rbridge is known to be local to a link VS
- The destination Rbridge is not local to that link and RB1 is not the 
designated forwarder for that link

In the former case, you send the frame to RB2 directly (outer.MACDA is 
RB2) and in the latter case, you send it to the designated forwarder 
(outer.MACDA is RBm).

Dinesh
Donald Eastlake wrote:
> It certainly is a run on sentence and it should be re-worded. But now
> that there is no pseudo-code in the base protocol draft, I think the
> specification needs to be fairly complete here. Your suggested text
> leaves out a lot of details but this bullet is in the middle of
> Section 4.4 which, to my mind at least, is supposed to give the
> details for handling any possible input frame.
>
> How about:
>
> If the destination is known by RB1 to belong to egress RBridge RB2,
> then RB1 encapsulates the frame with a TRILL header and transmits the
> encapsulated frame towards RB2. This TRILL header has M = 0 and
> specifies the nicknames for RB1 and RB2 as the ingress and egress
> RBridges respectively. The transmitted frame has RB1 as the
> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.
>
> Thanks,
> Donald
>
>
> On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com> wrote:
>   
>> I can't quite parse bullet 3 in section 4.4.1.1. It might be correct,
>> but the wording is confusing.
>>
>> It's talking about the case where RB1, designated forwarder, receives a
>> packet that RB1 knows should
>> go to egress RBridge RB2.
>>
>> Maybe this wording is clearer?
>>
>> *************section 4.4.1.1 bullet 3
>>
>> If the destination is known by RB1 to belong to egress RBridge RB2, then
>> RB1 encapsulates the
>> frame with TRILL header specifying RB2's nickname as egress RBridge, and
>> forwards the encapsulated
>> frame towards RB2.
>> _______________________________________________
>> 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


From d3e3e3 at gmail.com  Fri Oct 10 17:58:43 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Oct 2008 20:58:43 -0400
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
	3
In-Reply-To: <48EFF0E4.3030001@cisco.com>
References: <48EFD848.9050303@sun.com>
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
	<48EFF0E4.3030001@cisco.com>
Message-ID: <1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>

See below:

On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> That doesn't work correctly either. You want to distinguish two separate
> cases:
> - The destination Rbridge is known to be local to a link VS
> - The destination Rbridge is not local to that link and RB1 is not the
> designated forwarder for that link

I don't understand your case descriptions above.

This bullet appears after two other bullets. (By the way, you only get
to this part of the text on receipt of a native from on a port where
RB1 is the appointed forwarder for the frame's VLAN.) The first bullet
says that if the destination is known to be on the same link, the
RBridge just discards the frame because the destination has already
gotten it. The second bullet says that if the destination is on
another link out of RB1 where RB1 is appointed forwarder for the
frame's VLAN you forward the frame in native form. This is the third
bullet where the destination is on a link for which another RBridge is
appointed forwarder for the frame's VLAN so you have to encapsulate
it.

> In the former case, you send the frame to RB2 directly (outer.MACDA is RB2)
> and in the latter case, you send it to the designated forwarder (outer.MACDA
> is RBm).

If you are just trying to say the text should have four cases by
splitting the encapsulation case into one where the egress RBridge
happens to be one RBridge hop from the ingress RBridge and a
"different" case where the egress RBridge happens to be multiple hops
from the ingress RBridge, I see no need to do that. If RB1 and RB2 are
one hop apart, then the next RBridge hop towards RB2 from RB1 is RB2.

Thanks,
Donald

> Dinesh
> Donald Eastlake wrote:
>>
>> It certainly is a run on sentence and it should be re-worded. But now
>> that there is no pseudo-code in the base protocol draft, I think the
>> specification needs to be fairly complete here. Your suggested text
>> leaves out a lot of details but this bullet is in the middle of
>> Section 4.4 which, to my mind at least, is supposed to give the
>> details for handling any possible input frame.
>>
>> How about:
>>
>> If the destination is known by RB1 to belong to egress RBridge RB2,
>> then RB1 encapsulates the frame with a TRILL header and transmits the
>> encapsulated frame towards RB2. This TRILL header has M = 0 and
>> specifies the nicknames for RB1 and RB2 as the ingress and egress
>> RBridges respectively. The transmitted frame has RB1 as the
>> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.
>>
>> Thanks,
>> Donald
>>
>>
>> On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com>
>> wrote:
>>
>>>
>>> I can't quite parse bullet 3 in section 4.4.1.1. It might be correct,
>>> but the wording is confusing.
>>>
>>> It's talking about the case where RB1, designated forwarder, receives a
>>> packet that RB1 knows should
>>> go to egress RBridge RB2.
>>>
>>> Maybe this wording is clearer?
>>>
>>> *************section 4.4.1.1 bullet 3
>>>
>>> If the destination is known by RB1 to belong to egress RBridge RB2, then
>>> RB1 encapsulates the
>>> frame with TRILL header specifying RB2's nickname as egress RBridge, and
>>> forwards the encapsulated
>>> frame towards RB2.
>>> _______________________________________________
>>> 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
>
>



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

From ddutt at cisco.com  Fri Oct 10 19:24:03 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Fri, 10 Oct 2008 19:24:03 -0700
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
 3
In-Reply-To: <1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
References: <48EFD848.9050303@sun.com>	
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>	
	<48EFF0E4.3030001@cisco.com>
	<1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
Message-ID: <48F00E43.80508@cisco.com>

Hi Donald,

Consider the following figure:
                                  | --- RB3 -- B
A --- RB1 --- RB2 +|
                                  | --- RB4 -- C

If in the shared segment between RB2-RB4, if RB2 is the designated 
forwarder, and a frame is sent from C to B, according to the wording of 
bullet 3, Outer.MACDA is set to RB2 and MACSA set to RB4. This doesn't 
work for the reasons you'll see if you follow the logic through. Even if 
it did work, I dislike the frame flow. I think the Outer.MACDA must be 
set to RB3.

This is what I'm trying to say. Did I read that section wrong ?

Dinesh
Donald Eastlake wrote:
> See below:
>
> On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>   
>> That doesn't work correctly either. You want to distinguish two separate
>> cases:
>> - The destination Rbridge is known to be local to a link VS
>> - The destination Rbridge is not local to that link and RB1 is not the
>> designated forwarder for that link
>>     
>
> I don't understand your case descriptions above.
>
> This bullet appears after two other bullets. (By the way, you only get
> to this part of the text on receipt of a native from on a port where
> RB1 is the appointed forwarder for the frame's VLAN.) The first bullet
> says that if the destination is known to be on the same link, the
> RBridge just discards the frame because the destination has already
> gotten it. The second bullet says that if the destination is on
> another link out of RB1 where RB1 is appointed forwarder for the
> frame's VLAN you forward the frame in native form. This is the third
> bullet where the destination is on a link for which another RBridge is
> appointed forwarder for the frame's VLAN so you have to encapsulate
> it.
>
>   
>> In the former case, you send the frame to RB2 directly (outer.MACDA is RB2)
>> and in the latter case, you send it to the designated forwarder (outer.MACDA
>> is RBm).
>>     
>
> If you are just trying to say the text should have four cases by
> splitting the encapsulation case into one where the egress RBridge
> happens to be one RBridge hop from the ingress RBridge and a
> "different" case where the egress RBridge happens to be multiple hops
> from the ingress RBridge, I see no need to do that. If RB1 and RB2 are
> one hop apart, then the next RBridge hop towards RB2 from RB1 is RB2.
>
> Thanks,
> Donald
>
>   
>> Dinesh
>> Donald Eastlake wrote:
>>     
>>> It certainly is a run on sentence and it should be re-worded. But now
>>> that there is no pseudo-code in the base protocol draft, I think the
>>> specification needs to be fairly complete here. Your suggested text
>>> leaves out a lot of details but this bullet is in the middle of
>>> Section 4.4 which, to my mind at least, is supposed to give the
>>> details for handling any possible input frame.
>>>
>>> How about:
>>>
>>> If the destination is known by RB1 to belong to egress RBridge RB2,
>>> then RB1 encapsulates the frame with a TRILL header and transmits the
>>> encapsulated frame towards RB2. This TRILL header has M = 0 and
>>> specifies the nicknames for RB1 and RB2 as the ingress and egress
>>> RBridges respectively. The transmitted frame has RB1 as the
>>> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.
>>>
>>> Thanks,
>>> Donald
>>>
>>>
>>> On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com>
>>> wrote:
>>>
>>>       
>>>> I can't quite parse bullet 3 in section 4.4.1.1. It might be correct,
>>>> but the wording is confusing.
>>>>
>>>> It's talking about the case where RB1, designated forwarder, receives a
>>>> packet that RB1 knows should
>>>> go to egress RBridge RB2.
>>>>
>>>> Maybe this wording is clearer?
>>>>
>>>> *************section 4.4.1.1 bullet 3
>>>>
>>>> If the destination is known by RB1 to belong to egress RBridge RB2, then
>>>> RB1 encapsulates the
>>>> frame with TRILL header specifying RB2's nickname as egress RBridge, and
>>>> forwards the encapsulated
>>>> frame towards RB2.
>>>> _______________________________________________
>>>> 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
>>
>>
>>     
>
>
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


From d3e3e3 at gmail.com  Fri Oct 10 19:32:25 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Oct 2008 22:32:25 -0400
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <48EFDA99.9070304@sun.com>
References: <48EFDA99.9070304@sun.com>
Message-ID: <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com>

See below...

On Fri, Oct 10, 2008 at 6:43 PM, Radia Perlman <Radia.Perlman at sun.com> wrote:
> Someone asked me why IS-IS frames need to be TRILL-encapsulated, and I
> don't remember. I do know we
> were somewhat concerned about differentiating TRILL IS-IS frames from
> layer 3 IS-IS frames. But assuming
> we use a different multicast address for TRILL IS-IS than layer 3 IS-IS,
> with the additional safeguard of
> using a different "area ID" (for TRILL, area ID=0), it seems like there
> would be no danger of confusion.

Yes, if all you are worried about is distinguishing TRILL IS-IS frames
from Layer 3 IS-IS frames when they are received by routers and
RBridges, then a different multi-cast address could be adequate. But
there are other considerations discussed below.

> Perhaps we were concerned about possible unicast of IS-IS frames, like
> for instance, a PSNP that one might
> send just to the DR? I think I verified with the IS-IS people that there
> are no IS-IS frames that are unicast.

There are no Layer 3 IS-IS frames that are unicast. However, according
to the current specification, TRILL frames (except for TRILL IS-IS
Hellos) that would otherwise be multicast MAY be unicast if there is
only one RBridge of interest out a port. This is to reduce the load
such frames would place on, for example, a complex bridged LAN where
they might otherwise be flooded. This applies to both TRILL data and
TRILL IS-IS frames. When an RBridge is processing a TRILL frame, after
a few early checks, the Outer.MacDA is ignored in the rest of the
processing. So it is currently not a big deal to the receiver whether
that outer DA is unicast, multicast, or even broadcast (which MAY be
treated as if it was multicast to All-Rbridges). In any case, the
Inner.MacDA for all TRILL IS-IS frames is All-IS-IS-RBridges.

> So why doesn't the following work?
>
> For core IS-IS frames, no encapsulation, but a special multicast address
> "all-nbr-TRILL-IS-IS" as
> the destination address.

What does "nbr" stand for? If you want to do away with encapsulation
for core TRILL IS-IS frames, I don't see any particular reason why you
couldn't just use the existing All-Rbridges multicast address so that
RBridges need to listen for only one multicast address to receive
TRILL frames.

> For ESADI, TRILL encapsulation like with ordinary data packets, but
> having as the destination
> address in the inner Ethernet header a different multicast address
> "all-ESADI-TRILL"

? Since ESADI frames need encapsulation and work fine in the current
protocol document, why change them at all? Like all TRILL IS-IS frames
currently, they have an Inner.MacDA of All-IS-IS-Rbridges.

> The advantage of this is that for core TRILL IS-IS, we'd save header
> room and probably work for
> RBridges to parse IS-IS packets.

Right, you save a little space but
       You vastly increase the probability of confusing anything TRILL
ignorant, such as network diagnostic equipment. With encapsulation,
all TRILL frame specific content is shielded by the TRILL Ethertype.
Devices that do not know that Ethertype know that can't parse the
following frame content.
       Such a change calls into question the optional optimization of
sending TRILL IS-IS frames (other than TRILL Hellos) unicast when
there is only one destination RBridge of interest out a port. At the
least, it would mean that TRILL would be the only protocol ever able
to use this optimization since, without the multicast destination
address or TRILL Ethertype, you could no longer tell unicast TRILL
IS-IS frames from any other protocol's attempt to use unencapsulated
IS-IS frames.
       You eliminate the possibility of using any TRILL options on
such frames. I can think of options I might want to use.
       You eliminate the possibility of using TRILL versions or header
reserved bits to affect such frames or their processing.

In all previous discussions of this sort of things, the working group
has clearly leaned in the direction of uniformity of processing, even
at the expense of a few more bytes, for reasons like those above and
to leave more freedom for possible future use of currently unused
fields should an unexpected need arise.

For these reasons, I believe that the core TRILL IS-IS frames should
remain encapsulated.

Thanks,
Donald

> Radia
> _______________________________________________
> 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

From d3e3e3 at gmail.com  Fri Oct 10 19:53:14 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Oct 2008 22:53:14 -0400
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
	3
In-Reply-To: <48F00E43.80508@cisco.com>
References: <48EFD848.9050303@sun.com>
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
	<48EFF0E4.3030001@cisco.com>
	<1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
	<48F00E43.80508@cisco.com>
Message-ID: <1028365c0810101953l1026a096p6ccb505a30481339@mail.gmail.com>

See below...

On Fri, Oct 10, 2008 at 10:24 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> Hi Donald,
>
> Consider the following figure:
>                                 | --- RB3 -- B
> A --- RB1 --- RB2 +|
>                                 | --- RB4 -- C
>
> If in the shared segment between RB2-RB4, if RB2 is the designated
> forwarder, and a frame is sent from C to B, according to the wording of
> bullet 3, Outer.MACDA is set to RB2 and MACSA set to RB4. This doesn't work
> for the reasons you'll see if you follow the logic through. Even if it did
> work, I dislike the frame flow. I think the Outer.MACDA must be set to RB3.

This bullet item concerns only native unicast frames when the
destination is know and only accessible via another RBridge than the
RBridge receiving the native frame.

Assume a native unicast frame is sent from C to B in your diagram
above. Assuming that RB4 is configured to receive this native unicast
frame and is the appointed forwarder for the frame's VLAN for the link
to C, then RB4 is the ingress RBridge. Of course, in the diagram,
there is no other RBridge that could be appointed forwarder on the
link to C, so RB4 has to be the DRB for that link and presumably
appoints itself.

Similarly, looking at the other end, RB3 must be the DRB for the link
to B and appoints itself forwarder for traffic to B. Assume RB4 has
learned that B is connected to RB3.

So, as I say above, RB4 is the ingress RBridge and encapsulates this
known unicast frame with RB3 the egress. It then sends the resulting
TRILL frame with Outer.MacSA being RB4 port on the shared link and
Outer.MacDA being the unicast address of RB3, since, in this case, RB3
is the "next hop" RBridge towards RB3.

If makes no difference to TRILL frames who is DRB or "Appointed
Forwarder" on the shared link. Appointed forwarder status has no
effect whatsoever on TRILL frames. It only affects native frame
reception and transmission.

Possibly my revised text needs further clarification....

Thanks,
Donald

> This is what I'm trying to say. Did I read that section wrong ?
>
> Dinesh
> Donald Eastlake wrote:
>>
>> See below:
>>
>> On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>>
>>>
>>> That doesn't work correctly either. You want to distinguish two separate
>>> cases:
>>> - The destination Rbridge is known to be local to a link VS
>>> - The destination Rbridge is not local to that link and RB1 is not the
>>> designated forwarder for that link
>>>
>>
>> I don't understand your case descriptions above.
>>
>> This bullet appears after two other bullets. (By the way, you only get
>> to this part of the text on receipt of a native from on a port where
>> RB1 is the appointed forwarder for the frame's VLAN.) The first bullet
>> says that if the destination is known to be on the same link, the
>> RBridge just discards the frame because the destination has already
>> gotten it. The second bullet says that if the destination is on
>> another link out of RB1 where RB1 is appointed forwarder for the
>> frame's VLAN you forward the frame in native form. This is the third
>> bullet where the destination is on a link for which another RBridge is
>> appointed forwarder for the frame's VLAN so you have to encapsulate
>> it.
>>
>>
>>>
>>> In the former case, you send the frame to RB2 directly (outer.MACDA is
>>> RB2)
>>> and in the latter case, you send it to the designated forwarder
>>> (outer.MACDA
>>> is RBm).
>>>
>>
>> If you are just trying to say the text should have four cases by
>> splitting the encapsulation case into one where the egress RBridge
>> happens to be one RBridge hop from the ingress RBridge and a
>> "different" case where the egress RBridge happens to be multiple hops
>> from the ingress RBridge, I see no need to do that. If RB1 and RB2 are
>> one hop apart, then the next RBridge hop towards RB2 from RB1 is RB2.
>>
>> Thanks,
>> Donald
>>
>>
>>>
>>> Dinesh
>>> Donald Eastlake wrote:
>>>
>>>>
>>>> It certainly is a run on sentence and it should be re-worded. But now
>>>> that there is no pseudo-code in the base protocol draft, I think the
>>>> specification needs to be fairly complete here. Your suggested text
>>>> leaves out a lot of details but this bullet is in the middle of
>>>> Section 4.4 which, to my mind at least, is supposed to give the
>>>> details for handling any possible input frame.
>>>>
>>>> How about:
>>>>
>>>> If the destination is known by RB1 to belong to egress RBridge RB2,
>>>> then RB1 encapsulates the frame with a TRILL header and transmits the
>>>> encapsulated frame towards RB2. This TRILL header has M = 0 and
>>>> specifies the nicknames for RB1 and RB2 as the ingress and egress
>>>> RBridges respectively. The transmitted frame has RB1 as the
>>>> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.
>>>>
>>>> Thanks,
>>>> Donald
>>>>
>>>>
>>>> On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> I can't quite parse bullet 3 in section 4.4.1.1. It might be correct,
>>>>> but the wording is confusing.
>>>>>
>>>>> It's talking about the case where RB1, designated forwarder, receives a
>>>>> packet that RB1 knows should
>>>>> go to egress RBridge RB2.
>>>>>
>>>>> Maybe this wording is clearer?
>>>>>
>>>>> *************section 4.4.1.1 bullet 3
>>>>>
>>>>> If the destination is known by RB1 to belong to egress RBridge RB2,
>>>>> then
>>>>> RB1 encapsulates the
>>>>> frame with TRILL header specifying RB2's nickname as egress RBridge,
>>>>> and
>>>>> forwards the encapsulated
>>>>> frame towards RB2.
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
>
>



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

From d3e3e3 at gmail.com  Fri Oct 10 19:58:09 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Oct 2008 22:58:09 -0400
Subject: [rbridge] Making VLAN mapping not illegal -- minor wording
	change
In-Reply-To: <48EFDB79.5040908@sun.com>
References: <48EFDB79.5040908@sun.com>
Message-ID: <1028365c0810101958t45aa37c7s3a11a8caa9126f64@mail.gmail.com>

Good idea,
Donald

On Fri, Oct 10, 2008 at 6:47 PM, Radia Perlman <Radia.Perlman at sun.com> wrote:
> Section 4.1.2 says "When a TRILL frame passes through a
> transit RBridge, the Inner.VLAN MUST NOT be changed."
>
> If we were to do VLAN mapping, (draft to come...) we would want to allow
> an RBridge
> to change the inner VLAN tag. So the wording perhaps should be:
>
> "....the Inner.VLAN MUST NOT be changed, except when VLAN mapping is
> being intentionally performed."
> _______________________________________________
> 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

From ddutt at cisco.com  Sat Oct 11 04:37:14 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Sat, 11 Oct 2008 04:37:14 -0700
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com>
References: <48EFDA99.9070304@sun.com>
	<1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com>
Message-ID: <48F08FEA.1000302@cisco.com>

Donald,

Donald Eastlake wrote:
> for core TRILL IS-IS frames, I don't see any particular reason why you
> couldn't just use the existing All-Rbridges multicast address so that
> RBridges need to listen for only one multicast address to receive
> TRILL frames.
>   
I do. We want to make it easy for the hardware to distinguish between 
control and data frames so that the control frames can be trapped easily 
and sent to the control processor. All protocols designed so far work 
that way. The control protocol always uses a separate MAC address than 
data frames.
> What does "nbr" stand for? If you want to do away with encapsulation
>> For ESADI, TRILL encapsulation like with ordinary data packets, but
>> having as the destination
>> address in the inner Ethernet header a different multicast address
>> "all-ESADI-TRILL"
>>     
>
> ? Since ESADI frames need encapsulation and work fine in the current
> protocol document, why change them at all? Like all TRILL IS-IS frames
> currently, they have an Inner.MacDA of All-IS-IS-Rbridges.
>   
Again because it is additional logic for hardware to distinguish between 
control frames that they care about and control frames that they don't 
care about depending on the TRILL header contents. Using a separate MAC 
DA makes it simple. In some ways, ESADI is a different protocol.
>   
>> The advantage of this is that for core TRILL IS-IS, we'd save header
>> room and probably work for
>> RBridges to parse IS-IS packets.
>>     
>
> Right, you save a little space but
>        You vastly increase the probability of confusing anything TRILL
> ignorant, such as network diagnostic equipment. With encapsulation,
> all TRILL frame specific content is shielded by the TRILL Ethertype.
> Devices that do not know that Ethertype know that can't parse the
> following frame content.
>   
Not even remotely true. The All-Rbridges-core-ISIS and 
All-Rbridges-ESADI-ISIS multicast addresses are unique. Today for L3 
ISIS, there is no addition of an IP header for example to address your 
issue above and no one has asked for it. This is the first instance 
where we're attempting to add a protocol header to IS-IS.
>        Such a change calls into question the optional optimization of
> sending TRILL IS-IS frames (other than TRILL Hellos) unicast when
> there is only one destination RBridge of interest out a port. At the
> least, it would mean that TRILL would be the only protocol ever able
> to use this optimization since, without the multicast destination
> address or TRILL Ethertype, you could no longer tell unicast TRILL
> IS-IS frames from any other protocol's attempt to use unencapsulated
> IS-IS frames.
>   
I don't care for this optimization and I doubt if many of those who're 
building switches do. IEEE has set the standard of identifying control 
frames using the MAC DA and that's what we're suggesting. Why are we 
adding stuff that no other protocol so far has done or cared about. This 
is the kind of minor details that make a very nice protocol a pain to 
implement. There is a precedence, let's follow it. I don't want control 
and data frames to have the same MAC DA and I don't want them to do 
complicated parsing to achieve the same result with little or no benefit.
>        You eliminate the possibility of using any TRILL options on
> such frames. I can think of options I might want to use.
>   
What options ? Stick them as additional TLVs. By that logic, L3 IS-IS 
not having an IP header is a big limitation. I've not heard anybody 
making this argument.
>        You eliminate the possibility of using TRILL versions or header
> reserved bits to affect such frames or their processing.
>   
I disagree. The control protocol has the versions supported. Any future 
version of TRILL MUST be able to understand the basic IS-IS TLVs.
> In all previous discussions of this sort of things, the working group
> has clearly leaned in the direction of uniformity of processing, even
> at the expense of a few more bytes, for reasons like those above and
> to leave more freedom for possible future use of currently unused
> fields should an unexpected need arise.
>   
I disagree. This is a major pain for implementation and sets a new 
precedence with zero to insignificant benefits. Let's follow what has 
been accepted so far and has been working well.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


From Radia.Perlman at sun.com  Sat Oct 11 21:07:14 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 11 Oct 2008 21:07:14 -0700
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
	3
In-Reply-To: <1028365c0810101953l1026a096p6ccb505a30481339@mail.gmail.com>
References: <48EFD848.9050303@sun.com>
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
	<48EFF0E4.3030001@cisco.com>
	<1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
	<48F00E43.80508@cisco.com>
	<1028365c0810101953l1026a096p6ccb505a30481339@mail.gmail.com>
Message-ID: <48F177F2.2070704@sun.com>

I don't understand Dinesh's first comment:

Dinesh said:
 >>That doesn't work correctly either. You want to distinguish two 
separate cases:
 >>- The destination Rbridge is known to be local to a link VS
 >>- The destination Rbridge is not local to that link and RB1 is not 
the designated forwarder for that link

 >>In the former case, you send the frame to RB2 directly (outer.MACDA 
is RB2) and in the latter case, you send it to the designated forwarder 
 >>(outer.MACDA is RBm).

Possibly because I don't know what "VS" is in "link VS" above. And 
possibly because I think the fonts messed up
Dinesh's ascii art in his followup email.

But let's say that RB1 is appointed forwarder on port a, and therefore 
receives and encpasulates a native packet received
on port a. Since RB1 has learned that RB2 is the proper egress RBridge 
for that destination, RB1 puts RB2 as
the egress RBridge in the TRILL header, and forwards towards
RB2. Once the packet is encpasulated, designated fowarders are irrelevant.

With this, as with any encapsualted data packet, RB1 looks at RB1's 
forwarding table
that tells RB1 which port and nexthop RBridge to forward the 
encapsulated packet to. Just like any already-encapsulated
packet that RB1 might receive, because RB1 happens to be on the path 
from the ingress RBridge to the egress RBridge.

I don't see anything wrong with Donald's wording, which seems to be the 
same technically as what I'd proposed, but
just a little more explicit:

 >>"If the destination is known by RB1 to belong to egress RBridge RB2,

>>then RB1 encapsulates the frame with a TRILL header and transmits the
>>encapsulated frame towards RB2. This TRILL header has M = 0 and
>>specifies the nicknames for RB1 and RB2 as the ingress and egress
>>RBridges respectively. The transmitted frame has RB1 as the
>>Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA."

I don't see why it needed to be any more explicit than what I'd said originally
(just forward the encapsulated packet towards RB2), since once the packet
is encapsulated, there is nothing different about it, as far as I can see,
than a packet that RB1 received already encapsulated with destination RB2.

Or am I missing something?

And if you really do want to be more explicit, you could throw in that you forward
onto the port indicated as the next hop towards RB2. (in addition to what Donald
threw in, which was that you put the next hop RBridge into the outer header).

Radia












Donald Eastlake wrote:
> See below...
>
> On Fri, Oct 10, 2008 at 10:24 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>   
>> Hi Donald,
>>
>> Consider the following figure:
>>                                 | --- RB3 -- B
>> A --- RB1 --- RB2 +|
>>                                 | --- RB4 -- C
>>
>> If in the shared segment between RB2-RB4, if RB2 is the designated
>> forwarder, and a frame is sent from C to B, according to the wording of
>> bullet 3, Outer.MACDA is set to RB2 and MACSA set to RB4. This doesn't work
>> for the reasons you'll see if you follow the logic through. Even if it did
>> work, I dislike the frame flow. I think the Outer.MACDA must be set to RB3.
>>     
>
> This bullet item concerns only native unicast frames when the
> destination is know and only accessible via another RBridge than the
> RBridge receiving the native frame.
>
> Assume a native unicast frame is sent from C to B in your diagram
> above. Assuming that RB4 is configured to receive this native unicast
> frame and is the appointed forwarder for the frame's VLAN for the link
> to C, then RB4 is the ingress RBridge. Of course, in the diagram,
> there is no other RBridge that could be appointed forwarder on the
> link to C, so RB4 has to be the DRB for that link and presumably
> appoints itself.
>
> Similarly, looking at the other end, RB3 must be the DRB for the link
> to B and appoints itself forwarder for traffic to B. Assume RB4 has
> learned that B is connected to RB3.
>
> So, as I say above, RB4 is the ingress RBridge and encapsulates this
> known unicast frame with RB3 the egress. It then sends the resulting
> TRILL frame with Outer.MacSA being RB4 port on the shared link and
> Outer.MacDA being the unicast address of RB3, since, in this case, RB3
> is the "next hop" RBridge towards RB3.
>
> If makes no difference to TRILL frames who is DRB or "Appointed
> Forwarder" on the shared link. Appointed forwarder status has no
> effect whatsoever on TRILL frames. It only affects native frame
> reception and transmission.
>
> Possibly my revised text needs further clarification....
>
> Thanks,
> Donald
>
>   
>> This is what I'm trying to say. Did I read that section wrong ?
>>
>> Dinesh
>> Donald Eastlake wrote:
>>     
>>> See below:
>>>
>>> On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>>>
>>>       
>>>> That doesn't work correctly either. You want to distinguish two separate
>>>> cases:
>>>> - The destination Rbridge is known to be local to a link VS
>>>> - The destination Rbridge is not local to that link and RB1 is not the
>>>> designated forwarder for that link
>>>>
>>>>         
>>> I don't understand your case descriptions above.
>>>
>>> This bullet appears after two other bullets. (By the way, you only get
>>> to this part of the text on receipt of a native from on a port where
>>> RB1 is the appointed forwarder for the frame's VLAN.) The first bullet
>>> says that if the destination is known to be on the same link, the
>>> RBridge just discards the frame because the destination has already
>>> gotten it. The second bullet says that if the destination is on
>>> another link out of RB1 where RB1 is appointed forwarder for the
>>> frame's VLAN you forward the frame in native form. This is the third
>>> bullet where the destination is on a link for which another RBridge is
>>> appointed forwarder for the frame's VLAN so you have to encapsulate
>>> it.
>>>
>>>
>>>       
>>>> In the former case, you send the frame to RB2 directly (outer.MACDA is
>>>> RB2)
>>>> and in the latter case, you send it to the designated forwarder
>>>> (outer.MACDA
>>>> is RBm).
>>>>
>>>>         
>>> If you are just trying to say the text should have four cases by
>>> splitting the encapsulation case into one where the egress RBridge
>>> happens to be one RBridge hop from the ingress RBridge and a
>>> "different" case where the egress RBridge happens to be multiple hops
>>> from the ingress RBridge, I see no need to do that. If RB1 and RB2 are
>>> one hop apart, then the next RBridge hop towards RB2 from RB1 is RB2.
>>>
>>> Thanks,
>>> Donald
>>>
>>>
>>>       
>>>> Dinesh
>>>> Donald Eastlake wrote:
>>>>
>>>>         
>>>>> It certainly is a run on sentence and it should be re-worded. But now
>>>>> that there is no pseudo-code in the base protocol draft, I think the
>>>>> specification needs to be fairly complete here. Your suggested text
>>>>> leaves out a lot of details but this bullet is in the middle of
>>>>> Section 4.4 which, to my mind at least, is supposed to give the
>>>>> details for handling any possible input frame.
>>>>>
>>>>> How about:
>>>>>
>>>>> If the destination is known by RB1 to belong to egress RBridge RB2,
>>>>> then RB1 encapsulates the frame with a TRILL header and transmits the
>>>>> encapsulated frame towards RB2. This TRILL header has M = 0 and
>>>>> specifies the nicknames for RB1 and RB2 as the ingress and egress
>>>>> RBridges respectively. The transmitted frame has RB1 as the
>>>>> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.
>>>>>
>>>>> Thanks,
>>>>> Donald
>>>>>
>>>>>
>>>>> On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> I can't quite parse bullet 3 in section 4.4.1.1. It might be correct,
>>>>>> but the wording is confusing.
>>>>>>
>>>>>> It's talking about the case where RB1, designated forwarder, receives a
>>>>>> packet that RB1 knows should
>>>>>> go to egress RBridge RB2.
>>>>>>
>>>>>> Maybe this wording is clearer?
>>>>>>
>>>>>> *************section 4.4.1.1 bullet 3
>>>>>>
>>>>>> If the destination is known by RB1 to belong to egress RBridge RB2,
>>>>>> then
>>>>>> RB1 encapsulates the
>>>>>> frame with TRILL header specifying RB2's nickname as egress RBridge,
>>>>>> and
>>>>>> forwards the encapsulated
>>>>>> frame towards RB2.
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> --
>> We make our world significant by the courage of our questions and by the
>> depth of our answers.                               - Carl Sagan
>>
>>
>>     
>
>
>
>   


From cait at asomi.com  Sun Oct 12 22:00:23 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Sun, 12 Oct 2008 22:00:23 -0700
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
 3
In-Reply-To: <48F00E43.80508@cisco.com>
References: <48EFD848.9050303@sun.com>		<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>		<48EFF0E4.3030001@cisco.com>	<1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
	<48F00E43.80508@cisco.com>
Message-ID: <48F2D5E7.9040202@asomi.com>

Dinesh G Dutt wrote:
> Hi Donald,
> 
> Consider the following figure:
>                                   | --- RB3 -- B
> A --- RB1 --- RB2 +|
>                                   | --- RB4 -- C
> 
> If in the shared segment between RB2-RB4, if RB2 is the designated 
> forwarder, and a frame is sent from C to B, according to the wording of 
> bullet 3, Outer.MACDA is set to RB2 and MACSA set to RB4. This doesn't 
> work for the reasons you'll see if you follow the logic through. Even if 
> it did work, I dislike the frame flow. I think the Outer.MACDA must be 
> set to RB3.
> 
> This is what I'm trying to say. Did I read that section wrong ?
> 
> Dinesh
> Donald Eastlake wrote:
>> See below:
>>
>> On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>>   
>>> That doesn't work correctly either. You want to distinguish two separate
>>> cases:
>>> - The destination Rbridge is known to be local to a link VS
>>> - The destination Rbridge is not local to that link and RB1 is not the
>>> designated forwarder for that link
>>>     
>> I don't understand your case descriptions above.
>>
>> This bullet appears after two other bullets. (By the way, you only get
>> to this part of the text on receipt of a native from on a port where
>> RB1 is the appointed forwarder for the frame's VLAN.) The first bullet
>> says that if the destination is known to be on the same link, the
>> RBridge just discards the frame because the destination has already
>> gotten it. The second bullet says that if the destination is on
>> another link out of RB1 where RB1 is appointed forwarder for the
>> frame's VLAN you forward the frame in native form. This is the third
>> bullet where the destination is on a link for which another RBridge is
>> appointed forwarder for the frame's VLAN so you have to encapsulate
>> it.
>>
>>   
>>> In the former case, you send the frame to RB2 directly (outer.MACDA is RB2)
>>> and in the latter case, you send it to the designated forwarder (outer.MACDA
>>> is RBm).
>>>     
>> If you are just trying to say the text should have four cases by
>> splitting the encapsulation case into one where the egress RBridge
>> happens to be one RBridge hop from the ingress RBridge and a
>> "different" case where the egress RBridge happens to be multiple hops
>> from the ingress RBridge, I see no need to do that. If RB1 and RB2 are
>> one hop apart, then the next RBridge hop towards RB2 from RB1 is RB2.
>>
>> Thanks,
>> Donald
>>
>>   
>>> Dinesh
>>> Donald Eastlake wrote:
>>>     
>>>> It certainly is a run on sentence and it should be re-worded. But now
>>>> that there is no pseudo-code in the base protocol draft, I think the
>>>> specification needs to be fairly complete here. Your suggested text
>>>> leaves out a lot of details but this bullet is in the middle of
>>>> Section 4.4 which, to my mind at least, is supposed to give the
>>>> details for handling any possible input frame.
>>>>
>>>> How about:
>>>>
>>>> If the destination is known by RB1 to belong to egress RBridge RB2,
>>>> then RB1 encapsulates the frame with a TRILL header and transmits the
>>>> encapsulated frame towards RB2. This TRILL header has M = 0 and
>>>> specifies the nicknames for RB1 and RB2 as the ingress and egress
>>>> RBridges respectively. The transmitted frame has RB1 as the
>>>> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.
>>>>
>>>> Thanks,
>>>> Donald

Dinish is correct that the current text incorrectly states the
target RBridge in Bullet 3. But more fundamentally, this section
should not be attempting to describe the forwarding of a TRILL
Data Frame at all.

Rather, it should describe how the native frame is encapsulated,
and then forwarded "as specified for TRILL Data frames in 4.4.2.2".

Bullet 2 describes an optimization for the degenerate case where
the encapsulated frame is "forwarded" to the same RBridge, would
would then decapsulate and deliver it (also as described elsewhere).

Collapsing these steps into merely forwarding the native frame is
clearly legal whether or not the document spells this out. For
tutorial purposes, it might be better if it was made clear that
this was an optimized handling and not truly a distinct protocol
requirement.






-----
Caitlin Bestler
cait at asomi.com -- http://www.asomi.com/CaitlinBestlerResume.pdf


From d3e3e3 at gmail.com  Mon Oct 13 09:24:19 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 13 Oct 2008 12:24:19 -0400
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <48EFE991.2070405@cisco.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
	<48EF8FAB.3060903@asomi.com> <48EFE991.2070405@cisco.com>
Message-ID: <1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>

Caitlin and Dinesh,

I find the statement that "TRILL uses 802.1" to be somewhat vague and ambiguous.

The current specification makes it more or less clear that what it
calls "port VLAN processing" in an RBridge is the same as the
processing between ISS and EISS in a customer 802.1Q bridge. If you
want that to be made clearer or more prominent, I'd have no problem
with that.

If what you are trying to say is that the all the processing below the
EISS interface (including that below the ISS interface) is the same in
an RBridge and in a customer 802.1Q bridge, it seems to me that isn't
quite right. You could say that all the processing below the EISS
interface is the same as in a customer 802.1Q bridge except for the
handling of some control frames but I have the impression that you
wouldn't be satisfied by that...

Thanks,
Donald

On Fri, Oct 10, 2008 at 7:47 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> Caitlin,
>
> You know that I support your statements below. I believe originally
> Silvano and I had written (or maybe only just presented) what you say
> below esp w.r.t EISS. I think it is critical that we include this in the
> base protocol spec.
>
> Thanks for sending this email yet again,
>
> Dinesh
> Caitlin Bestler wrote:
>> Does an RBridge implementation *use* 802.1 or does it
>> *include* an 802.1 implementation?
>>
>> The problem statement implies that it *uses* 802.1.
>>  From the Abstract:
>>
>>       This document assumes that solutions would not
>>       address issues of scalability beyond that of existing bridged
>> (802.1) links, but that a solution would be backward compatible
>>       with 802.1, including hubs, bridges, and their existing
>>       plug-and-play capabilities.
>>
>> That implies that RBridges would use the 802.1 defined EISS
>> interface, although that is not included in the cited list
>> of compatibilities.
>>
>> However, Section 2.2 of the protocol discusses the encapsulation
>> in terms of 802.3, with PPP being given as one alternate encoding.
>>
>> The presentation in this section could imply that an RBRidge
>> implementation essentially subsumes the 802.1 role, including
>> being directly aware of 802.3 and alternate lower-layer L2s.
>>
>> If TRILL *uses* 802.1 then the more correct description would be
>> that the TRILL Header, Inner Ethernet Header and Ethernet Payload
>> are submitted as the payload using EISS. The Elements that make
>> the Outer Ethernet Headers are parameters to EISS.
>>
>> The diagrams presented in Section 2.2 represent the encapsulation
>> that the 802.1 layer will do in collaboration with 802.1 or PPP.
>> But to be totally correct, it does not specify them. IEEE documents
>> govern this behavior.
>>
>> Up through 802.1Q-2005 this is strictly an academic question. The
>> processing between the EISS and ISS interfaces is very well understood
>> and there is no harm in integrating layers in implementation.
>>
>> However, this could have an impact on the default interpretation of
>> TRILL interoperability with new 802.1Q amendments, especially those
>> in the Data Center Bridging. Interoperability with Provider Backbone
>> Bridging and Shortest Path Bridging may also be impacted.
>>
>> I believe the best resolution here was covered previously in
>> mailing list discussions. We should just state than an RBridge
>> is a *client* of 802.1 services. That implies reasonable defaults
>> for RBridge interaction with post 2005 802.1 services. If there
>> are specific rationale for roto-tilling, as may be the case for
>> 802.1Qau QCN (Congestion Notification) would require subsequent
>> drafts to justify and define them.
>>
>>
>> -----
>> Caitlin Bestler
>> cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>>
>> task group,
>>
>>
>> _______________________________________________
>> 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
-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

From cait at asomi.com  Mon Oct 13 10:04:47 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Mon, 13 Oct 2008 10:04:47 -0700
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>	
	<48EF8FAB.3060903@asomi.com> <48EFE991.2070405@cisco.com>
	<1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>
Message-ID: <48F37FAF.9050207@asomi.com>

Donald Eastlake wrote:
> Caitlin and Dinesh,
> 
> I find the statement that "TRILL uses 802.1" to be somewhat vague and ambiguous.
> 
> The current specification makes it more or less clear that what it
> calls "port VLAN processing" in an RBridge is the same as the
> processing between ISS and EISS in a customer 802.1Q bridge. If you
> want that to be made clearer or more prominent, I'd have no problem
> with that.
> 
> If what you are trying to say is that the all the processing below the
> EISS interface (including that below the ISS interface) is the same in
> an RBridge and in a customer 802.1Q bridge, it seems to me that isn't
> quite right. You could say that all the processing below the EISS
> interface is the same as in a customer 802.1Q bridge except for the
> handling of some control frames but I have the impression that you
> wouldn't be satisfied by that...
> 
> Thanks,
> Donald
> 

Keep in mind that even for 802.1Q Bridges, the 802.1Q model does not
tell them how to process frames. Rather it is a detailed model that
accurately predicts how different protocol features will interact.
If you were to build a layered implementation which processed frames
in exactly this manner, you would achieve the correct results. There
may be many other methods of achieving the same result, and you are
encouraged to find them on your own.

In that same spirit, TRILL should be cleanly layered on top of 802.1
and the EISS interface. And using the EISS interface you really do
not know what the final frame looks like under 802.3, 802.11 or whatever
other protocol that may be selected. One of the strengths of TRILL is
that it ultimately does not care what transport gets the TRILL frames
from RBx to RBy. That's what layering is supposed to achieve.

From cait at asomi.com  Mon Oct 13 10:43:51 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Mon, 13 Oct 2008 10:43:51 -0700
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>	
	<48EF8FAB.3060903@asomi.com> <48EFE991.2070405@cisco.com>
	<1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>
Message-ID: <48F388D7.8020104@asomi.com>

Donald,

Here's one example where clearly stating where TRILL resides
compared to IEEE 802.1 would be a benefit: Section 4.4.2.2
states:

    The port on which the frame was received is first checked and the
    frame discarded if there is no TRILL core IS-IS adjacency on that
    port.

If it is clear that EISS is the relevant interface then there is
no ambiguity as to whether this is a logical (aggregated) port
or a physical port. It would also allow the TRILL core IS-IS
adjacency to be restricted to the controlled port (802.1X).

With clean layering we don't have to belabor issues like what
if any interactions there are between TRILL and Link Aggregation,
or MACsec.

Given the background of those working on TRILL, this is merely
documenting the assumptions that I believe everyone has made
while reviewing the draft. But assumptions are best explicitly
stated.



-----
Caitlin Bestler
cait at asomi.com -- http://www.asomi.com/CaitlinBestlerResume.pdf


From anoop at brocade.com  Mon Oct 13 11:27:28 2008
From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 13 Oct 2008 11:27:28 -0700
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <48F08FEA.1000302@cisco.com>
References: <48EFDA99.9070304@sun.com><1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com>
	<48F08FEA.1000302@cisco.com>
Message-ID: <4C94DE2070B172459E4F1EE14BD2364E0201846D@HQ-EXCH-5.corp.brocade.com>


> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
> Sent: Saturday, October 11, 2008 4:37 AM
> To: Donald Eastlake
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] encoding of TRILL IS-IS frames
> 
...
> IEEE has set the standard of 
> identifying control 
> frames using the MAC DA and that's what we're suggesting. 
...

Just a point of clarification...IEEE used to use the
DA to identify the protocol but they are starting to
move away from that model.  Once AB-REV is published,
we will set xSTP and LLDP frames using the same MAC
address; what will be used to distinguish them, then,
is the protocol type.

I think as long as we have a combination of (MAC DA +
protocol type) that is unique for TRILL's IS-IS, we
should be OK.

Anoop


From rtp.techie at gmail.com  Mon Oct 13 12:14:41 2008
From: rtp.techie at gmail.com (RTP Techie)
Date: Mon, 13 Oct 2008 15:14:41 -0400
Subject: [rbridge] L2 ISIS - P2P over LAN
Message-ID: <5c95ad230810131214t47b43981y934f2c983b70ee4c@mail.gmail.com>

Hi,
I'm new to Rbridge and just reading the protocol spec.
One thing that comes to me is that for ISIS, it talks about the use of it in
LAN mode.

For ISIS, there is an extension (just a very minor change on how to encap
the ISIS packet in the LAN environment) to allow it operates in P2P mode on
a LAN link if there is only two nodes in the link. I believe the primary
reason is to remove the need of running pseudo-node and election when if
user just connecting two nodes with a link directly.

Would the same technique applicable to L2 ISIS? If not, can you please
provide some insights as why?

Thanks in advance,
Ming Chan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081013/6bad845b/attachment.html

From Radia.Perlman at sun.com  Mon Oct 13 12:15:10 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 13 Oct 2008 12:15:10 -0700
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
	3
In-Reply-To: <48F2D5E7.9040202@asomi.com>
References: <48EFD848.9050303@sun.com>
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
	<48EFF0E4.3030001@cisco.com>
	<1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
	<48F00E43.80508@cisco.com> <48F2D5E7.9040202@asomi.com>
Message-ID: <48F39E3E.8090400@sun.com>

So...is the conclusion that this wording of bullet 3 is fine?

If the destination is known by RB1 to belong to egress RBridge RB2, then 
RB1 encapsulates the
frame with TRILL header specifying RB2's nickname as egress RBridge, and 
forwards the encapsulated
frame towards RB2 as specified for TRILL data frames in 4.4.2.2.

**************

And I agree with Caitlin that we don't really need bullet 2. I don't think
it's terribly harmful, but especially since the wording now says "unless inhibited as
in section 4.2.3.3", it makes the reader think too hard and wonder what
inhibitions it might have. (I wondered). As it turns out, it's all part of
how to forward, and is covered elsewhere. The spec gets too long, and too confusing
if all details of something like "forwarding towards egress RBridge" are spelled out
in multiple places.

Basically, once RB1 encapsulates the packet, it then forwards towards the
egress RBridge (as worded at the top of this message). We could add a note,
after that bullet, such as:

Note: if RB1 is the egress RBridge for the destination, then as an optimization,
RB1 can skip the encapsulation step, and forward the unencapsulated frame to
the destination link. Note this has the same effect as having RB1 encapsulate
towards RB1, then decapsulate before forwarding onto the destination's link.

Radia





Caitlin Bestler wrote:
>
> Rather, it should describe how the native frame is encapsulated,
> and then forwarded "as specified for TRILL Data frames in 4.4.2.2".
>
> Bullet 2 describes an optimization for the degenerate case where
> the encapsulated frame is "forwarded" to the same RBridge, would
> would then decapsulate and deliver it (also as described elsewhere).
>
> Collapsing these steps into merely forwarding the native frame is
> clearly legal whether or not the document spells this out. For
> tutorial purposes, it might be better if it was made clear that
> this was an optimized handling and not truly a distinct protocol
> requirement.
>
>   


From ddutt at cisco.com  Mon Oct 13 14:09:16 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 13 Oct 2008 14:09:16 -0700
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0201846D@HQ-EXCH-5.corp.brocade.com>
References: <48EFDA99.9070304@sun.com><1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com>
	<48F08FEA.1000302@cisco.com>
	<4C94DE2070B172459E4F1EE14BD2364E0201846D@HQ-EXCH-5.corp.brocade.com>
Message-ID: <48F3B8FC.8030601@cisco.com>

I'm fine with MAC DA + Ethertype, but since it's much harder to get 
multiple ethertypes for the same protocol, I prefer multiple MAC 
addresses. But either approach is fine,

Dinesh
Anoop Ghanwani wrote:
>> -----Original Message-----
>> From: rbridge-bounces at postel.org 
>> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
>> Sent: Saturday, October 11, 2008 4:37 AM
>> To: Donald Eastlake
>> Cc: Developing a hybrid router/bridge.; Radia Perlman
>> Subject: Re: [rbridge] encoding of TRILL IS-IS frames
>>
>>     
> ...
>   
>> IEEE has set the standard of 
>> identifying control 
>> frames using the MAC DA and that's what we're suggesting. 
>>     
> ...
>
> Just a point of clarification...IEEE used to use the
> DA to identify the protocol but they are starting to
> move away from that model.  Once AB-REV is published,
> we will set xSTP and LLDP frames using the same MAC
> address; what will be used to distinguish them, then,
> is the protocol type.
>
> I think as long as we have a combination of (MAC DA +
> protocol type) that is unique for TRILL's IS-IS, we
> should be OK.
>
> Anoop
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan


From sgai at nuovasystems.com  Mon Oct 13 14:49:07 2008
From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 13 Oct 2008 14:49:07 -0700
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <4C94DE2070B172459E4F1EE14BD2364E0201846D@HQ-EXCH-5.corp.brocade.com>
References: <48EFDA99.9070304@sun.com><1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com><48F08FEA.1000302@cisco.com>
	<4C94DE2070B172459E4F1EE14BD2364E0201846D@HQ-EXCH-5.corp.brocade.com>
Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA20670DF6B@nuova-ex1.hq.nuovaimpresa.com>


I agree that "as long as we have a combination of (MAC DA +
protocol type) that is unique for TRILL's IS-IS, we
should be OK."

Since it is hard to get multiple Ethertype, I propose a single Ethertype
and multiple MAC-DAs.

I cannot emphasize more how important it is to have simple
classification criteria that are HW friendly.

-- Silvano

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Anoop Ghanwani
Sent: Monday, October 13, 2008 11:27 AM
To: Dinesh G Dutt; Donald Eastlake
Cc: Developing a hybrid router/bridge.; Radia Perlman
Subject: Re: [rbridge] encoding of TRILL IS-IS frames


> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Dinesh G Dutt
> Sent: Saturday, October 11, 2008 4:37 AM
> To: Donald Eastlake
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] encoding of TRILL IS-IS frames
> 
...
> IEEE has set the standard of 
> identifying control 
> frames using the MAC DA and that's what we're suggesting. 
...

Just a point of clarification...IEEE used to use the
DA to identify the protocol but they are starting to
move away from that model.  Once AB-REV is published,
we will set xSTP and LLDP frames using the same MAC
address; what will be used to distinguish them, then,
is the protocol type.

I think as long as we have a combination of (MAC DA +
protocol type) that is unique for TRILL's IS-IS, we
should be OK.

Anoop

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge


From d3e3e3 at gmail.com  Mon Oct 13 18:00:04 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 13 Oct 2008 21:00:04 -0400
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <48F388D7.8020104@asomi.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
	<48EF8FAB.3060903@asomi.com> <48EFE991.2070405@cisco.com>
	<1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>
	<48F388D7.8020104@asomi.com>
Message-ID: <1028365c0810131800k579fd5cuac48a7e9c2766b1b@mail.gmail.com>

Hi Caitlin,
That's a good example.

If the draft made it clear that the behavior is as if Hello (actually all
TRILL PDU) processing was above EISS, which is how I have been thinking of
it, that would fall out automatically.

Thanks,
Donald

On Mon, Oct 13, 2008 at 1:43 PM, Caitlin Bestler <cait at asomi.com> wrote:

> Donald,
>
> Here's one example where clearly stating where TRILL resides
> compared to IEEE 802.1 would be a benefit: Section 4.4.2.2
> states:
>
>   The port on which the frame was received is first checked and the
>   frame discarded if there is no TRILL core IS-IS adjacency on that
>   port.
>
> If it is clear that EISS is the relevant interface then there is
> no ambiguity as to whether this is a logical (aggregated) port
> or a physical port. It would also allow the TRILL core IS-IS
> adjacency to be restricted to the controlled port (802.1X).
>
> With clean layering we don't have to belabor issues like what
> if any interactions there are between TRILL and Link Aggregation,
> or MACsec.
>
> Given the background of those working on TRILL, this is merely
> documenting the assumptions that I believe everyone has made
> while reviewing the draft. But assumptions are best explicitly
> stated.
>
>
>
> -----
> Caitlin Bestler
> cait at asomi.com -- http://www.asomi.com/CaitlinBestlerResume.pdf
>
>


-- 
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081013/5e1e1989/attachment.html

From d3e3e3 at gmail.com  Thu Oct 16 10:14:10 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 16 Oct 2008 13:14:10 -0400
Subject: [rbridge] TRILL tentatively scheduled for Monday afternoon in
	Minneapolis
Message-ID: <1028365c0810161014o356e80d5xea2370ab049e5549@mail.gmail.com>

Although it is still subject to change, a tentative schedule has been posted
for the Minneapolis IETF meeting next month which shows TRILL in the 13:00
to 15:00 time slot Monday afternoon. This schedule, and lots of other
information, is linked off the http://www.ietf.org/meetings/73/ web page.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081016/9a21ab56/attachment.html

From ddutt at cisco.com  Thu Oct 16 11:20:24 2008
From: ddutt at cisco.com (Dinesh G Dutt)
Date: Thu, 16 Oct 2008 11:20:24 -0700
Subject: [rbridge] TRILL tentatively scheduled for Monday afternoon in
 Minneapolis
In-Reply-To: <1028365c0810161014o356e80d5xea2370ab049e5549@mail.gmail.com>
References: <1028365c0810161014o356e80d5xea2370ab049e5549@mail.gmail.com>
Message-ID: <48F785E8.4000802@cisco.com>

That's great because the IS-IS WG is meeting immediately after this,

Dinesh
Donald Eastlake wrote:
> Although it is still subject to change, a tentative schedule has been 
> posted for the Minneapolis IETF meeting next month which shows TRILL 
> in the 13:00 to 15:00 time slot Monday afternoon. This schedule, and 
> lots of other information, is linked off the 
> http://www.ietf.org/meetings/73/ web page.
>
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   +1-508-634-2066 (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com <mailto:d3e3e3 at gmail.com>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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


From d3e3e3 at gmail.com  Thu Oct 16 12:59:23 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 16 Oct 2008 15:59:23 -0400
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <1028365c0810131800k579fd5cuac48a7e9c2766b1b@mail.gmail.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
	<48EF8FAB.3060903@asomi.com> <48EFE991.2070405@cisco.com>
	<1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>
	<48F388D7.8020104@asomi.com>
	<1028365c0810131800k579fd5cuac48a7e9c2766b1b@mail.gmail.com>
Message-ID: <1028365c0810161259w4e6a0ab8o45d1c6142fe1dd49@mail.gmail.com>

Hi Caitlin,
Attached is a text file with a modified and simplified version of Figure 4.3
and some text which might be appropriate to add to Section 2.4 of the Draft.
Would that do what you want?

Thanks,
Donald

On Mon, Oct 13, 2008 at 9:00 PM, Donald Eastlake <d3e3e3 at gmail.com> wrote:

> Hi Caitlin,
> That's a good example.
>
> If the draft made it clear that the behavior is as if Hello (actually all
> TRILL PDU) processing was above EISS, which is how I have been thinking of
> it, that would fall out automatically.
>
> Thanks,
> Donald
>
>
> On Mon, Oct 13, 2008 at 1:43 PM, Caitlin Bestler <cait at asomi.com> wrote:
>
>> Donald,
>>
>> Here's one example where clearly stating where TRILL resides
>> compared to IEEE 802.1 would be a benefit: Section 4.4.2.2
>> states:
>>
>>   The port on which the frame was received is first checked and the
>>   frame discarded if there is no TRILL core IS-IS adjacency on that
>>   port.
>>
>> If it is clear that EISS is the relevant interface then there is
>> no ambiguity as to whether this is a logical (aggregated) port
>> or a physical port. It would also allow the TRILL core IS-IS
>> adjacency to be restricted to the controlled port (802.1X).
>>
>> With clean layering we don't have to belabor issues like what
>> if any interactions there are between TRILL and Link Aggregation,
>> or MACsec.
>>
>> Given the background of those working on TRILL, this is merely
>> documenting the assumptions that I believe everyone has made
>> while reviewing the draft. But assumptions are best explicitly
>> stated.
>>
>>
>>
>> -----
>> Caitlin Bestler
>> cait at asomi.com -- http://www.asomi.com/CaitlinBestlerResume.pdf
>>
>>
>
>
> --
> =============================
> Donald E. Eastlake 3rd   +1-508-634-2066 (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com
>



-- 
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081016/cd39a1fe/attachment.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Figure2-4.txt
Url: http://mailman.postel.org/pipermail/rbridge/attachments/20081016/cd39a1fe/Figure2-4.txt

From g.venkatasubramaniyan at gmail.com  Thu Oct 16 18:28:35 2008
From: g.venkatasubramaniyan at gmail.com (gvsm)
Date: Fri, 17 Oct 2008 06:58:35 +0530
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <18667.31220.5239.43072@gargle.gargle.HOWL>
References: <48EA838B.7080006@cisco.com>
	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
	<18667.31220.5239.43072@gargle.gargle.HOWL>
Message-ID: <b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>

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.

[3] I think the frame ordering, if its not in the scope of TRILL, the
protocol needs to be extensible to support additional features of this
kind. I am not right? In my understanding Link aggregation works only
at Link level and may not be suitable enough for multipath. I think
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
to overcome this limitation[Ref-2].

All I was asking that is the protocol should be extensible for
features like this, something with "options".

Hope I am clear this time.

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-----

From d3e3e3 at gmail.com  Fri Oct 17 07:47:37 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 17 Oct 2008 10:47:37 -0400
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
References: <48EA838B.7080006@cisco.com>
	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
	<18667.31220.5239.43072@gargle.gargle.HOWL>
	<b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
Message-ID: <1028365c0810170747t57dd137fr2b9e0a890b90581b@mail.gmail.com>

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

From d3e3e3 at gmail.com  Fri Oct 17 07:58:25 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 17 Oct 2008 10:58:25 -0400
Subject: [rbridge] Base protocol working group last call early warning
In-Reply-To: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>
Message-ID: <1028365c0810170758u204cad93odadcffb478be0a62@mail.gmail.com>

There appear to be a sufficient number of sufficiently significant
changes being discussed that we will probably not do a working group
last call until version -10 of the base protocol specification.

Thanks,
Donald

On Wed, Oct 8, 2008 at 10:50 PM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> Hi,
> We plan to start a Working Group Last Call on the "Rbridges: Base Protocol
> Specification" draft early next week.
> Thanks,
> Donald and Erik
> =============================
> Donald E. Eastlake 3rd   +1-508-634-2066 (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com

From cait at asomi.com  Fri Oct 17 09:11:49 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Fri, 17 Oct 2008 09:11:49 -0700
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
References: <48EA838B.7080006@cisco.com>	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>	<18667.31220.5239.43072@gargle.gargle.HOWL>
	<b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
Message-ID: <48F8B945.8060008@asomi.com>

gvsm 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.
> 
> [3] I think the frame ordering, if its not in the scope of TRILL, 

Normally frame ordering is an issue left to the specific 802.1 LAN
that TRILL PDUs are sent over. That is, TRILL trusts the 802.1 and
the lower L2 layer (typically 802.3) to do nothing to introduce
frame mis-ordering within a "conversation" as defined in 802.3ad.

The extent to which TRILL should address is this is with the context
of Appendeix C. *If* an RBRidge is using ECMP (or any form of
multipathing) then it SHOULD avoid splitting any single 802.3ad
conversation over two paths.

That is something that anyone implementing multipathing probably
would have done anyway, but the standard would be more complete
if this was stated.

But on a given path, avoidance of mis-ordering should be left
to the 802.1 and lower layers. TRILL should deal with this *only*
to the extent that when it does multi-pathing it involves multiple
802.1 clouds -- and obviously two distinct clouds can make any
guarantees about how their timing will compare.

If someone wanted to provide multipathing within the context of
a single conversation, whether it involved multiple 802.1 clouds
or not, they would need to create a protocol that provided the
intended sequence information for a reassembly function at the
destination. That protocol could certainly be a TRILL extension,
but there is no real need to discuss such a possible extension
in the base protocol.


-----
Caitlin Bestler
cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf

From cait at asomi.com  Fri Oct 17 09:17:55 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Fri, 17 Oct 2008 09:17:55 -0700
Subject: [rbridge] Relationship with 802.1
In-Reply-To: <1028365c0810161259w4e6a0ab8o45d1c6142fe1dd49@mail.gmail.com>
References: <1028365c0810081950j2e694a7cx47653b64a994b7a5@mail.gmail.com>	<48EF8FAB.3060903@asomi.com>
	<48EFE991.2070405@cisco.com>	<1028365c0810130924h32ce3aedk39f8145369c05ef1@mail.gmail.com>	<48F388D7.8020104@asomi.com>	<1028365c0810131800k579fd5cuac48a7e9c2766b1b@mail.gmail.com>
	<1028365c0810161259w4e6a0ab8o45d1c6142fe1dd49@mail.gmail.com>
Message-ID: <48F8BAB3.1060102@asomi.com>

Donald Eastlake wrote:
> Hi Caitlin,
> 
> Attached is a text file with a modified and simplified version of Figure 
> 4.3 and some text which might be appropriate to add to Section 2.4 of 
> the Draft. Would that do what you want?
> 


Yes, that diagram is very clear.

It may be worth explicitly stating that any statements in the TRILL
protocol documents about processing below EISS and ISS are intended
to be informative and are not to be interpreted in a way that 
contradicts the relevant IEEE 802 specifications.

-----
Caitlin Bestler
cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf

From james.d.carlson at sun.com  Fri Oct 17 09:36:43 2008
From: james.d.carlson at sun.com (James Carlson)
Date: Fri, 17 Oct 2008 12:36:43 -0400
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <1028365c0810170747t57dd137fr2b9e0a890b90581b@mail.gmail.com>
References: <48EA838B.7080006@cisco.com>
	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
	<18667.31220.5239.43072@gargle.gargle.HOWL>
	<b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
	<1028365c0810170747t57dd137fr2b9e0a890b90581b@mail.gmail.com>
Message-ID: <18680.48923.878862.879700@gargle.gargle.HOWL>

Donald Eastlake writes:
> On Thu, Oct 16, 2008 at 9:28 PM, gvsm <g.venkatasubramaniyan at gmail.com> wrote:
> > 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.

That's correct.  In addition, it uses Marker PDUs to try to make sure
that order is preserved when there are link changes within the group.
(Or at least it _can_ use such PDUs; not all implementations include
the feature.)

It's rather different from ECMP, though superficially similar.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From cait at asomi.com  Fri Oct 17 10:52:23 2008
From: cait at asomi.com (Caitlin Bestler)
Date: Fri, 17 Oct 2008 10:52:23 -0700
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <18680.48923.878862.879700@gargle.gargle.HOWL>
References: <48EA838B.7080006@cisco.com>	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>	<18667.31220.5239.43072@gargle.gargle.HOWL>	<b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>	<1028365c0810170747t57dd137fr2b9e0a890b90581b@mail.gmail.com>
	<18680.48923.878862.879700@gargle.gargle.HOWL>
Message-ID: <48F8D0D7.6070803@asomi.com>

James Carlson wrote:
> Donald Eastlake writes:
>> On Thu, Oct 16, 2008 at 9:28 PM, gvsm <g.venkatasubramaniyan at gmail.com> wrote:
>>> 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.
> 
> That's correct.  In addition, it uses Marker PDUs to try to make sure
> that order is preserved when there are link changes within the group.
> (Or at least it _can_ use such PDUs; not all implementations include
> the feature.)
> 
> It's rather different from ECMP, though superficially similar.
> 


802.3ad requires that a given "conversation" (a sequence of frames
for which ordering is desired) not be shifted from one link to
another link without taking *some* mechanism to prevent re-ordering. 
Marker PDUs are defined as a standard method of achieving this goal,
but it is explicitly not the *only* solution.

Similarly, any specific ECMP strategy for RBridges would have to
ensure that moving a conversation from one path to another path
did not cause re-ordering. Specific solutions can be documented
in later specifications. There is no need to include them in the
base protocol, simply not moving them except after a path becoming
unavailable is sufficient with some simple timing heuristics.
Anyone who wants more dynamic load balancing even within a
single conversation can propose a specific algorithm in a
later draft.

These are fundamentally the same, its just switching paths
rather than switching links, and because paths are longer
than links the timing is on a different scale. But the fact
that so many link aggregating bridges do *not* use the Marker
PDUs is a strong argument on why the TRILL base protocol does
not need to specify their equivalent. The base protocol is
already a large document, we should not force extra material
into it that can be handled in supplemental specifications.


-----
Caitlin Bestler
cait at asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf

From james.d.carlson at sun.com  Fri Oct 17 11:02:06 2008
From: james.d.carlson at sun.com (James Carlson)
Date: Fri, 17 Oct 2008 14:02:06 -0400
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <48F8D0D7.6070803@asomi.com>
References: <48EA838B.7080006@cisco.com>
	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
	<18667.31220.5239.43072@gargle.gargle.HOWL>
	<b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
	<1028365c0810170747t57dd137fr2b9e0a890b90581b@mail.gmail.com>
	<18680.48923.878862.879700@gargle.gargle.HOWL>
	<48F8D0D7.6070803@asomi.com>
Message-ID: <18680.54046.102340.836463@gargle.gargle.HOWL>

Caitlin Bestler writes:
> 802.3ad requires that a given "conversation" (a sequence of frames
> for which ordering is desired) not be shifted from one link to
> another link without taking *some* mechanism to prevent re-ordering. 
> Marker PDUs are defined as a standard method of achieving this goal,
> but it is explicitly not the *only* solution.

True.

> Similarly, any specific ECMP strategy for RBridges would have to
> ensure that moving a conversation from one path to another path
> did not cause re-ordering.

Note that the same problem occurs when IS-IS recalculates a new path
for a given destination.  It's not a special problem of ECMP -- though
we seem to be talking about it that way -- it's inherent to datagram
routing when there may be topology changes.

> Specific solutions can be documented
> in later specifications. There is no need to include them in the
> base protocol, simply not moving them except after a path becoming
> unavailable is sufficient with some simple timing heuristics.
> Anyone who wants more dynamic load balancing even within a
> single conversation can propose a specific algorithm in a
> later draft.

I agree ... and this also points towards a "quality of implementation"
issue rather than something that needs to be specified as part of the
base protocol.

> These are fundamentally the same, its just switching paths
> rather than switching links, and because paths are longer
> than links the timing is on a different scale. But the fact
> that so many link aggregating bridges do *not* use the Marker
> PDUs is a strong argument on why the TRILL base protocol does
> not need to specify their equivalent. The base protocol is
> already a large document, we should not force extra material
> into it that can be handled in supplemental specifications.

I don't want us to do anything like that, either.  I pointed it out to
show that they drove well out of their way to address this problem,
while we are not.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From james.d.carlson at sun.com  Fri Oct 17 10:57:54 2008
From: james.d.carlson at sun.com (James Carlson)
Date: Fri, 17 Oct 2008 13:57:54 -0400
Subject: [rbridge] Fwd: In-order delivery not an issue?
In-Reply-To: <48F8B945.8060008@asomi.com>
References: <48EA838B.7080006@cisco.com>
	<EC85B82E47DBBE4C96B2457EC51AD53C05BB99D197@BLRKECMBX03.ad.infosys.com>
	<18667.31220.5239.43072@gargle.gargle.HOWL>
	<b8190bf40810161828p33bde47awb1d34f2a5c8c6f56@mail.gmail.com>
	<48F8B945.8060008@asomi.com>
Message-ID: <18680.53794.318208.878733@gargle.gargle.HOWL>

Caitlin Bestler writes:
> The extent to which TRILL should address is this is with the context
> of Appendeix C. *If* an RBRidge is using ECMP (or any form of
> multipathing) then it SHOULD avoid splitting any single 802.3ad
> conversation over two paths.

That's obvious enough that it ought not need to be said.  In other
words, I think that if you don't know at least that much, then you're
going to have trouble all over the place; ECMP is probably the least
of your worries.  The RFC should be a protocol spec, not a tutorial on
networking.

However, that's not sufficient in comparison to 802.3ad, because you
*can* get reordering within a single conversation without ever
splitting it across two paths.  This case can occur if you move
(forced or otherwise) a given conversation from one path to another:
the packets sent on the 'old' and 'new' paths race each other to the
destination, and you may have some trivial reordering as a result
until steady state returns.  (Max delay across the network)

Of course, the same thing happens if you don't have ECMP and you have
a change in the IS-IS layer that causes you to choose a different path
for an entire destination.

In 802.3ad, they use a Marker PDU to fix this problem (since the
underlying links may have some buffering that ends up behaving the
same way as delays in those separate ECMP paths), but we don't have
that.  We're stuck with trivial cases (all relating to link and
RBridge state transitions) that can introduce modest amounts of
reordering in some cases.

But so what?

> That is something that anyone implementing multipathing probably
> would have done anyway, but the standard would be more complete
> if this was stated.

Maybe ... though I think stating the obvious tends to bloat the
document and introduce other risks.  (Such as a mistaken belief that
the RFC is "all" that you would ever need to know in order to
implement.)

> If someone wanted to provide multipathing within the context of
> a single conversation, whether it involved multiple 802.1 clouds
> or not, they would need to create a protocol that provided the
> intended sequence information for a reassembly function at the
> destination. That protocol could certainly be a TRILL extension,
> but there is no real need to discuss such a possible extension
> in the base protocol.

Agreed; a sequencing mechanism is a mistake we can certainly make
later.  ;-}

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From d3e3e3 at gmail.com  Tue Oct 21 13:23:13 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 21 Oct 2008 16:23:13 -0400
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet
	3
In-Reply-To: <48F39E3E.8090400@sun.com>
References: <48EFD848.9050303@sun.com>
	<1028365c0810101659m7e1f07cfpc88f15044833ed31@mail.gmail.com>
	<48EFF0E4.3030001@cisco.com>
	<1028365c0810101758u5fdd86f6qd6c90e0e251f4808@mail.gmail.com>
	<48F00E43.80508@cisco.com> <48F2D5E7.9040202@asomi.com>
	<48F39E3E.8090400@sun.com>
Message-ID: <1028365c0810211323v63766e35r3c606b941966b593@mail.gmail.com>

Since it is operationally the same either way, whether bullet 2 stays
seems like more a matter of taste to me. However, since everyone who
has posted on the subject, except me, wants it to go, I'll remove it.

Donald

On Mon, Oct 13, 2008 at 3:15 PM, Radia Perlman <Radia.Perlman at sun.com> wrote:
> So...is the conclusion that this wording of bullet 3 is fine?
>
> If the destination is known by RB1 to belong to egress RBridge RB2, then RB1
> encapsulates the
> frame with TRILL header specifying RB2's nickname as egress RBridge, and
> forwards the encapsulated
> frame towards RB2 as specified for TRILL data frames in 4.4.2.2.
>
> **************
>
> And I agree with Caitlin that we don't really need bullet 2. I don't think
> it's terribly harmful, but especially since the wording now says "unless
> inhibited as
> in section 4.2.3.3", it makes the reader think too hard and wonder what
> inhibitions it might have. (I wondered). As it turns out, it's all part of
> how to forward, and is covered elsewhere. The spec gets too long, and too
> confusing
> if all details of something like "forwarding towards egress RBridge" are
> spelled out
> in multiple places.
>
> Basically, once RB1 encapsulates the packet, it then forwards towards the
> egress RBridge (as worded at the top of this message). We could add a note,
> after that bullet, such as:
>
> Note: if RB1 is the egress RBridge for the destination, then as an
> optimization,
> RB1 can skip the encapsulation step, and forward the unencapsulated frame to
> the destination link. Note this has the same effect as having RB1
> encapsulate
> towards RB1, then decapsulate before forwarding onto the destination's link.
>
> Radia
>
>
>
>
>
> Caitlin Bestler wrote:
>>
>> Rather, it should describe how the native frame is encapsulated,
>> and then forwarded "as specified for TRILL Data frames in 4.4.2.2".
>>
>> Bullet 2 describes an optimization for the degenerate case where
>> the encapsulated frame is "forwarded" to the same RBridge, would
>> would then decapsulate and deliver it (also as described elsewhere).
>>
>> Collapsing these steps into merely forwarding the native frame is
>> clearly legal whether or not the document spells this out. For
>> tutorial purposes, it might be better if it was made clear that
>> this was an optimized handling and not truly a distinct protocol
>> requirement.
>>
>>
>
>



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

From erik.nordmark at sun.com  Wed Oct 29 10:18:24 2008
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 29 Oct 2008 10:18:24 -0700
Subject: [rbridge] Topics for Minneapolis meeting
Message-ID: <49089AE0.6020206@sun.com>


Please send any requests for WG topics to us.

    Erik and Donald


From Radia.Perlman at sun.com  Wed Oct 29 11:41:58 2008
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 29 Oct 2008 11:41:58 -0700
Subject: [rbridge] (more efficiently) announcing "which multicast roots"
Message-ID: <4908AE76.9030609@sun.com>

The spec originally allowed each RBridge to enumerate any set of tree Roots.

Then we had the highest priority RBridge, R1,  limit the total number of 
tree roots, to be the value "n" specified in R1's
LSP. That limited the eligible set of tree roots to be the top n 
(selected based on the top n of (priority, ID)).

The spec (section 4.2.3.4, item 5) has, in R2's LSP, a list of nicknames 
of tree roots that R2 might specify (and of
course these would have to be among the top n, or else other RBridges 
wouldn't have calculated a tree based on them).
It says if the list is empty, that R2 will only use the highest priority 
distribution tree root.

R2 already says the number of roots, say "J" it would like (4.2.3.4, 
item 4). It seems like, with little loss of
generality, we could remove item 5 from the LSP, and assume that R2 will 
want to use the top J roots (unless J>n, in
which case it is n).

The only loss in generality is that R2 might have a different priority 
ordering of the roots (for instance, preferring roots that
are close to R2, or R2 might be manually configured with which roots to 
prefer).

So it seems like the possibilities are:

a) leave the spec as it is -- (leaving out item 5 in the LSP means "I'll 
only use the highest priority root")

b) reinterpret the omission of item 5 to be "I want the top J roots" (or 
the top n, if J>n), where "J" is the number I specified
in item 4

c) do b), but also allow item 5 if R2 is unhappy about using the top J 
roots and wants to specify them independently.

None of these is a major change from the spec. I prefer b over a, since 
it seems to get "for free", the ability to specify multiple
roots (assuming that R2's top choice of roots really is the top J).

Proposal c gives the most flexibility, and does not require inclusion of
this information except when R2 really prefers some subset of the top n 
roots other than the top J.

If we are leaving out item 5, then R2 could get the same functionality 
by specifying "J"=n, and it can use any of the top n it wants.
The cost of that is that "R2" will appear on the filtering lists of the 
(n-J) roots that it is not intending to specify.

Comments?

Radia





From d3e3e3 at gmail.com  Wed Oct 29 16:45:46 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 29 Oct 2008 19:45:46 -0400
Subject: [rbridge] encoding of TRILL IS-IS frames
In-Reply-To: <48F08FEA.1000302@cisco.com>
References: <48EFDA99.9070304@sun.com>
	<1028365c0810101932i6e17140dw90abc00d8643ac74@mail.gmail.com>
	<48F08FEA.1000302@cisco.com>
Message-ID: <1028365c0810291645la92b71dk47210c7b81fc3d90@mail.gmail.com>

There seems to have been no further comment on this.

Just to be sure people understand what is being adopted: There is no
change in TRILL data frames. TRILL core IS-IS frames have a different
outer multicast destination address from data, presumably
All-IS-IS-RBridges, and are not TRILL encapsulated. The remaining case
is ESADI IS-IS frames which are, by default, treated almost exactly
like data. The should have an All-RBridges outer DA and be
encapsulated, like data, but have some new special inner destination
MAC address: All-ESADI-RBridges.

Thanks,
Donald

On Sat, Oct 11, 2008 at 7:37 AM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> Donald,
>
> Donald Eastlake wrote:
>>
>> for core TRILL IS-IS frames, I don't see any particular reason why you
>> couldn't just use the existing All-Rbridges multicast address so that
>> RBridges need to listen for only one multicast address to receive
>> TRILL frames.
>>
>
> I do. We want to make it easy for the hardware to distinguish between
> control and data frames so that the control frames can be trapped easily and
> sent to the control processor. All protocols designed so far work that way.
> The control protocol always uses a separate MAC address than data frames.
>>
>> What does "nbr" stand for? If you want to do away with encapsulation
>>>
>>> For ESADI, TRILL encapsulation like with ordinary data packets, but
>>> having as the destination
>>> address in the inner Ethernet header a different multicast address
>>> "all-ESADI-TRILL"
>>>
>>
>> ? Since ESADI frames need encapsulation and work fine in the current
>> protocol document, why change them at all? Like all TRILL IS-IS frames
>> currently, they have an Inner.MacDA of All-IS-IS-Rbridges.
>>
>
> Again because it is additional logic for hardware to distinguish between
> control frames that they care about and control frames that they don't care
> about depending on the TRILL header contents. Using a separate MAC DA makes
> it simple. In some ways, ESADI is a different protocol.
>>
>>
>>>
>>> The advantage of this is that for core TRILL IS-IS, we'd save header
>>> room and probably work for
>>> RBridges to parse IS-IS packets.
>>>
>>
>> Right, you save a little space but
>>       You vastly increase the probability of confusing anything TRILL
>> ignorant, such as network diagnostic equipment. With encapsulation,
>> all TRILL frame specific content is shielded by the TRILL Ethertype.
>> Devices that do not know that Ethertype know that can't parse the
>> following frame content.
>>
>
> Not even remotely true. The All-Rbridges-core-ISIS and
> All-Rbridges-ESADI-ISIS multicast addresses are unique. Today for L3 ISIS,
> there is no addition of an IP header for example to address your issue above
> and no one has asked for it. This is the first instance where we're
> attempting to add a protocol header to IS-IS.
>>
>>       Such a change calls into question the optional optimization of
>> sending TRILL IS-IS frames (other than TRILL Hellos) unicast when
>> there is only one destination RBridge of interest out a port. At the
>> least, it would mean that TRILL would be the only protocol ever able
>> to use this optimization since, without the multicast destination
>> address or TRILL Ethertype, you could no longer tell unicast TRILL
>> IS-IS frames from any other protocol's attempt to use unencapsulated
>> IS-IS frames.
>>
>
> I don't care for this optimization and I doubt if many of those who're
> building switches do. IEEE has set the standard of identifying control
> frames using the MAC DA and that's what we're suggesting. Why are we adding
> stuff that no other protocol so far has done or cared about. This is the
> kind of minor details that make a very nice protocol a pain to implement.
> There is a precedence, let's follow it. I don't want control and data frames
> to have the same MAC DA and I don't want them to do complicated parsing to
> achieve the same result with little or no benefit.
>>
>>       You eliminate the possibility of using any TRILL options on
>> such frames. I can think of options I might want to use.
>>
>
> What options ? Stick them as additional TLVs. By that logic, L3 IS-IS not
> having an IP header is a big limitation. I've not heard anybody making this
> argument.
>>
>>       You eliminate the possibility of using TRILL versions or header
>> reserved bits to affect such frames or their processing.
>>
>
> I disagree. The control protocol has the versions supported. Any future
> version of TRILL MUST be able to understand the basic IS-IS TLVs.
>>
>> In all previous discussions of this sort of things, the working group
>> has clearly leaned in the direction of uniformity of processing, even
>> at the expense of a few more bytes, for reasons like those above and
>> to leave more freedom for possible future use of currently unused
>> fields should an unexpected need arise.
>>
>
> I disagree. This is a major pain for implementation and sets a new
> precedence with zero to insignificant benefits. Let's follow what has been
> accepted so far and has been working well.
>
> Dinesh
>
> --
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
>
>



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

From d3e3e3 at gmail.com  Fri Oct 31 12:14:40 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 31 Oct 2008 15:14:40 -0400
Subject: [rbridge] VLAN Mapping Draft
Message-ID: <1028365c0810311214k71716dbct99219999b8452a78@mail.gmail.com>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: RBridge VLAN Mapping
	Author(s)	: R. Perlman, D. Dutt, D. Eastlake 3rd
	Filename	: draft-perlman-trill-rbridge-vlan-mapping-00.txt
	Pages		: 11
	Date		: 2008-10-27
	
Some bridge products perform a feature known as "VLAN mapping", in
   which a bridge translates a data frame's VLAN ID from one VLAN to
   another when it forwards a frame from one port to another. This
   feature facilitates scenarios such as combining two bridged LANs with
   overlapping VLAN IDs into one bridged LAN without merging two
   communities just because they have been given the same VLAN ID in the
   original two clouds. This document describes how RBridges can achieve
   the same functionality.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-perlman-trill-rbridge-vlan-mapping-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From d3e3e3 at gmail.com  Fri Oct 31 12:53:35 2008
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 31 Oct 2008 15:53:35 -0400
Subject: [rbridge] TRILL tentatively scheduled for Monday afternoon in
	Minneapolis
In-Reply-To: <48F785E8.4000802@cisco.com>
References: <1028365c0810161014o356e80d5xea2370ab049e5549@mail.gmail.com>
	<48F785E8.4000802@cisco.com>
Message-ID: <1028365c0810311253l25bcffc6n3696b41b5eafa7fd@mail.gmail.com>

Although, of course, it is always subject to change, the 73rd IETF
meeting agenda has been declared "final" so it is now very unlikely
that the TRILL (or ISIS) WG meetings will be moved.

Thanks,
Donald

On Thu, Oct 16, 2008 at 2:20 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> That's great because the IS-IS WG is meeting immediately after this,
>
> Dinesh
>
> Donald Eastlake wrote:
>>
>> Although it is still subject to change, a tentative schedule has been
>> posted for the Minneapolis IETF meeting next month which shows TRILL in the
>> 13:00 to 15:00 time slot Monday afternoon. This schedule, and lots of other
>> information, is linked off the http://www.ietf.org/meetings/73/ web page.
>>
>> Thanks,
>> Donald
>> =============================
>> Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>> 155 Beaver Street
>> Milford, MA 01757 USA
>> d3e3e3 at gmail.com <mailto:d3e3e3 at gmail.com>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com