Re: [rbridge] TRILL tentatively scheduled for Monday afternoon in Minneapolis

["Donald Eastlake" <[e-mail]>]

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 <[e-mail]> 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   [phone] (home)
>> 155 Beaver Street
>> Milford, MA 01757 USA
>> [e-mail] <mailto:[e-mail]>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> 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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9VJraXX027438 for <[e-mail]>; Fri, 31 Oct 2008 12:53:37 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1414227rvf.45 for <[e-mail]>; Fri, 31 Oct 2008 12:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OaszzW6L8/JLF2ogu8XBStjdWzQN4roUFqhvPR6qC2I=; b=ZfCQz4vXQ1y3OtOr0OMM9jYH7CuCy0DsjqSnbKaA+mtwnZfTzsCPIiXBallXOZLIwJ IZ8lAEYsULisqb3gYHaJOXUtjfdV1Ux9rkvlaAY7lxS3u78vtybMMQuhMpzsOfwhxO4T 26v6a7W5W9CRRAHPRVILWvb7VdP151iX4yCZo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ucuKQM/PkEa8q8f1OKlLaJ1HdURp+ZCvy/3Tmk60eEXSVz+QNFgZ9o9387KeTUt6Z7 lltkZMDUbdGx9XtOUtAGhy5TWDigzHoXPF17U63AIhrjq/14uGF/2jWG+hWvacDWZ7cx ifX8El3aZ8SfwHvFcWamFFDQCgjx825mgJ7cQ=
Received: by 10.141.179.5 with SMTP id g5mr5883265rvp.30.1225482815874; Fri, 31 Oct 2008 12:53:35 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Fri, 31 Oct 2008 12:53:35 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2008 15:53:35 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] TRILL tentatively scheduled for Monday afternoon in Minneapolis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2008 19:54:18 -0000
Status: RO
Content-Length: 1424

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 <[e-mail]> 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   [phone] (home)
>> 155 Beaver Street
>> Milford, MA 01757 USA
>> [e-mail] <mailto:[e-mail]>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> 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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9VJEfkW011048 for <[e-mail]>; Fri, 31 Oct 2008 12:14:42 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1392199rvf.45 for <[e-mail]>; Fri, 31 Oct 2008 12:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ycULcKCzmaLcL+HQehIPTh8sSEpGID74yQ7/jK5uSQM=; b=oKJGHODyWw477kolE2PKkFX0UiyLZbe7Nxpk+NwgUjDvo0+FlhR7MFXch8Ovu0/mlv vQJLfLX6ihAw40BscUywDfUbPc35YIUFJEu6eQx3gTC3Ww5S00UmafYwUIbvLQtU9Y+B LtJLB6tgHvsQdzVzqemhwqH/FI3UrGAVRw0us=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=wP4mX2+ourI3t0eR4gESV76j/v7LcjXsiJJLPbPqENbEpqXwiuEroMEoUQGfedNBnh G4ZB7H2DP0pRifkIWlPgd47l0g6Xzk4eoAyrvPLpduQ5DxZH+UGDJeXd7hv0Pz0AmJ0s eu0hlnbO0KyDtHeIFkkSN/cwD/5e+LBoFD/pU=
Received: by 10.141.71.14 with SMTP id y14mr6876983rvk.24.1225480480917; Fri, 31 Oct 2008 12:14:40 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Fri, 31 Oct 2008 12:14:40 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2008 15:14:40 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] VLAN Mapping Draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2008 19:15:11 -0000
Status: RO
Content-Length: 1129

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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9TNjlmS002210 for <[e-mail]>; Wed, 29 Oct 2008 16:45:47 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so264127rvf.45 for <[e-mail]>; Wed, 29 Oct 2008 16:45:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=I4xLQF0q8Ag78x5Jmnck9ZYmTGQJwh4cEhijsjJef/k=; b=f9pCaGsuGpaaOlxhTgadEkvcTkofiMUaFMKUocIV5T+lOk2y+DBJmzePCx011exQeG o/wTO2+fQad/HP32UV1dmo1+L5+SaynMQt4dD+ylA5DRsYQfNzEgEh0w4dE/UPnND3SP 4P36qX1weXVIUKoPiD1Kdg3584gZm7O7Wu0F4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BdsImkSsNEi23dZlKNpTClmltQfa7NM4rngHcnyOpOxe30o6QZwAZ1cq/ja5/uTB7U CgYvSs4H8VvqMjDdjiAGG5sf/Uuubp1OzrfH54XiIDs60JxZp77NXsl97pdYsXSvq0BS GNFLm4GoBvQBViQ3Weman5HdS9WNWL1Xk8Sgw=
Received: by 10.141.36.10 with SMTP id o10mr5233527rvj.176.1225323946680; Wed, 29 Oct 2008 16:45:46 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Wed, 29 Oct 2008 16:45:46 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 19:45:46 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2008 23:46:15 -0000
Status: RO
Content-Length: 5381

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 <[e-mail]> 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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9TIgEen012281 for <[e-mail]>; Wed, 29 Oct 2008 11:42:15 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 29 Oct 2008 11:42:03 -0700 (PDT)
Received: from [129.150.32.255] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 29 Oct 2008 11:42:03 -0700 (PDT)
Date: Wed, 29 Oct 2008 11:41:58 -0700
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] (more efficiently) announcing "which multicast roots"
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2008 18:43:00 -0000
Status: RO
Content-Length: 2192

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






Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9THITRt022124 for <[e-mail]>; Wed, 29 Oct 2008 10:18:29 -0700 (PDT)
Received: from jurassic.eng.sun.com ([129.146.104.31]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9THIQpS021735 for <[e-mail]>; Wed, 29 Oct 2008 17:18:26 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9THIOS4410584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 10:18:24 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 10:18:24 -0700
From: Erik Nordmark <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080923)
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Topics for Minneapolis meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2008 17:22:17 -0000
Status: RO
Content-Length: 69

Please send any requests for WG topics to us.

    Erik and Donald



Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9LKNEMI014455 for <[e-mail]>; Tue, 21 Oct 2008 13:23:15 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2420599rvf.45 for <[e-mail]>; Tue, 21 Oct 2008 13:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2zfj+uS/n5j7FVlza6W+YUEvM8h4e35IlvzHNuBN2HM=; b=lxvWXmGCVcXimGvT2BKfhyi7ViLzmH/Y733MjgYke4u/ZADSmt6+rtc2AYFjZ2ymI9 B2mDpm+v4ZqL/AgHxHTb/kaUNE60cQh+phm6/Dz9jpNLNdU66xg7NpZnGkHh88qeiQgb 8OtlOeupJzHFrCMFik86Tp8vYAKdR+SW1XbHo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=D20kHN3LdhKZTw5k2HTBAKAWU9+eqp6zM/WhYjDN93qvIiATAGgJ6T+XCpRrHt6Xmw R0o478RYxmjKifR+l9/aAEoQ2VtMDAUpV9JVcJNkO2LDeR82N9snquROE0o9Z1t1K1Pa bz//7pcVs0aQHeFCE8pY2lZJd1rCjBsR/btOk=
Received: by 10.141.197.14 with SMTP id z14mr5898660rvp.283.1224620593533; Tue, 21 Oct 2008 13:23:13 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Tue, 21 Oct 2008 13:23:13 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 16:23:13 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2008 20:23:27 -0000
Status: RO
Content-Length: 2524

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 <[e-mail]> 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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HIdCRe018121 for <[e-mail]>; Fri, 17 Oct 2008 11:39:13 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9HIdBVq006862 for <[e-mail]>; Fri, 17 Oct 2008 18:39:11 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9HIdA5o035851 for <[e-mail]>; Fri, 17 Oct 2008 14:39:10 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9HHvtbB001842; Fri, 17 Oct 2008 13:57:55 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9HHvs54001839; Fri, 17 Oct 2008 13:57:54 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 13:57:54 -0400
From: James Carlson <[e-mail]>
To: Caitlin Bestler <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "[e-mail]" <[e-mail]>, "Venkatsubramaniyan G, TLS-Chennai" <[e-mail]>, gvsm <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 18:40:02 -0000
Status: RO
Content-Length: 2632

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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HIZrJf016567 for <[e-mail]>; Fri, 17 Oct 2008 11:35:54 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9HIZqfZ017610 for <[e-mail]>; Fri, 17 Oct 2008 18:35:52 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9HIZpCv034364 for <[e-mail]>; Fri, 17 Oct 2008 14:35:51 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9HI285X001861; Fri, 17 Oct 2008 14:02:08 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9HI263G001858; Fri, 17 Oct 2008 14:02:06 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 14:02:06 -0400
From: James Carlson <[e-mail]>
To: Caitlin Bestler <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, "[e-mail]" <[e-mail]>, gvsm <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 18:36:20 -0000
Status: RO
Content-Length: 2186

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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HHqPCv026162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 17 Oct 2008 10:52:26 -0700 (PDT)
Received: (qmail 6506 invoked from network); 17 Oct 2008 17:52:24 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 17 Oct 2008 17:52:24 -0000
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 10:52:23 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: James Carlson <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, "[e-mail]" <[e-mail]>, gvsm <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 17:52:55 -0000
Status: RO
Content-Length: 2218

James Carlson wrote:
> Donald Eastlake writes:
>> On Thu, Oct 16, 2008 at 9:28 PM, gvsm <[e-mail]> 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
[e-mail] - http://www.asomi.com/CaitlinBestlerResume.pdf


Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HH32ON001502 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Fri, 17 Oct 2008 10:03:04 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9HH32k9014504 for <[e-mail]>; Fri, 17 Oct 2008 17:03:02 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9HH31xR054108 for <[e-mail]>; Fri, 17 Oct 2008 13:03:01 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9HGaiIE001487; Fri, 17 Oct 2008 12:36:44 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9HGah8G001484; Fri, 17 Oct 2008 12:36:43 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 12:36:43 -0400
From: James Carlson <[e-mail]>
To: Donald Eastlake <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "[e-mail]" <[e-mail]>, gvsm <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 17:03:46 -0000
Status: RO
Content-Length: 995

Donald Eastlake writes:
> On Thu, Oct 16, 2008 at 9:28 PM, gvsm <[e-mail]> 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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HGHuR8009529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 17 Oct 2008 09:17:57 -0700 (PDT)
Received: (qmail 9522 invoked from network); 17 Oct 2008 16:17:55 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 17 Oct 2008 16:17:55 -0000
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 09:17:55 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 16:18:11 -0000
Status: RO
Content-Length: 605

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
[e-mail] - http://www.asomi.com/CaitlinBestlerResume.pdf


Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HGBoqA006470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 17 Oct 2008 09:11:51 -0700 (PDT)
Received: (qmail 3521 invoked from network); 17 Oct 2008 16:11:49 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 17 Oct 2008 16:11:49 -0000
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 09:11:49 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: gvsm <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "[e-mail]" <[e-mail]>, "Venkatsubramaniyan G, TLS-Chennai" <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 16:12:04 -0000
Status: RO
Content-Length: 2269

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
[e-mail] - http://www.asomi.com/CaitlinBestlerResume.pdf


Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HEwP8g027659 for <[e-mail]>; Fri, 17 Oct 2008 07:58:26 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so541169rvf.45 for <[e-mail]>; Fri, 17 Oct 2008 07:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gNo/iiP69kIHYWauguDY1Mvh5gKHl2kxYMs98rNy2oQ=; b=Oc0zX28t+2AdQqACL6TLaB6GaFdFOYLsINC/oWYMDvOIEtlI6cWWzYwzlTYnBoNDCV jTccnVF7H/TveemAwsYCwQGsgvwytV23LY0TVqdNZhWjcRD9ab4ZM2c7CkRsOIr44WnG hBYQyt0rH6I+4pLZ70CRP7cJwIJ4OkWS33nNw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KJi2akMYZMqg9eUwGHv+12QoYYiP9rX+ATjFpDuMX/gzQe0y9VdTSvqyL4D36/N5/Q ZwQKaYs8VytdtOHHjJrQNYDyQPp/XA2zuHgx1RS5oAOYQChUikYOfiT/Bzi+BHQJmQ2o UKOBPkzfKLRLA4PP4QNbS/98IV556yMA/Rb/g=
Received: by 10.141.193.1 with SMTP id v1mr2569184rvp.245.1224255505390; Fri, 17 Oct 2008 07:58:25 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Fri, 17 Oct 2008 07:58:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 10:58:25 -0400
From: "Donald Eastlake" <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Base protocol working group last call early warning
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 14:59:21 -0000
Status: RO
Content-Length: 588

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 <[e-mail]> 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   [phone] (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> [e-mail]


Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9HEld6l022116 for <[e-mail]>; Fri, 17 Oct 2008 07:47:41 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so536787rvf.45 for <[e-mail]>; Fri, 17 Oct 2008 07:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Zs4Y5a5aA+TxpmR1TEo0yNZsbRkthipUi5822RinqBA=; b=iBg3yaaHeU+ci+ttde+kHc8vzGGiaGZQRipOaMZpENlJ2jgJ6gxnSlVH7lOD+PeKdV q5fWMCHYZ9gLLl4j7YHyEMXSvL21fY7soKN4+rb4VlCVbaIxrGpxx01H3Aeweim1It0C a38/+jyi1H4xSH9VgrTnmdNVPdcf7IqdV0Q+k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=O7pQ1Ftmf8XH71pfGpx+TdHsyGhN9Su8Kaq/lDzjNDmEtrMH3Joc0HYamCFPJ+Bz6o /hOQL4ZsHvCVW0PaqwyId5wjPxf/Xq/iwodIk/DmhRWVmzfHC/t1jBj1FqLwvkeNslhB jwi06cZwhEKHKNzKZQaQTKEr3N3vn4H7dGZ9A=
Received: by 10.140.136.5 with SMTP id j5mr2598765rvd.0.1224254857795; Fri, 17 Oct 2008 07:47:37 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Fri, 17 Oct 2008 07:47:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 10:47:37 -0400
From: "Donald Eastlake" <[e-mail]>
To: gvsm <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 14:48:40 -0000
Status: RO
Content-Length: 8219

See below...

On Thu, Oct 16, 2008 at 9:28 PM, gvsm <[e-mail]> 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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>



-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9H1Sa47024670 for <[e-mail]>; Thu, 16 Oct 2008 18:28:37 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 8so235257qwh.63 for <[e-mail]>; Thu, 16 Oct 2008 18:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qbxVRSDSgv6Fj1LnvVp9PrhD2AwAyycvnWG9DYBa21Y=; b=qVYL8WGGzGM8jtigzM3Z3c2SFMojOONlx2pe7vTc/CYlp06ZRfG34s4wv/sYfzuMcG q2UlxFFIpvFv0BZ8DQFLGQSkrsXdkUZQRFiba+2zZbpAdepM0k/kpAWKcOFyC+W1gGBv IWEHxF3Fz1dYepsgN2lq7D7ij7OOWTx3THrKE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qsqHMU2QZ1IBkJGgvYpfAOjOowCep8vQbJHvfbySpcgRJjheUgU6t6NkSVDiZtIyqY YrnPVYcLUQEThhzEGFDc6vpIiJ72juo5q2PwliEE3OIt4sY+r5KpLlktJ6ClC+puNwxW Bkl3D56cv6Rci7XT9Wnkl9m5PxjehUsKpeRrY=
Received: by 10.214.81.3 with SMTP id e3mr3967619qab.70.1224206915814; Thu, 16 Oct 2008 18:28:35 -0700 (PDT)
Received: by 10.214.150.21 with HTTP; Thu, 16 Oct 2008 18:28:35 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 06:58:35 +0530
From: gvsm <[e-mail]>
To: "Venkatsubramaniyan G, TLS-Chennai" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2008 01:29:28 -0000
Status: RO
Content-Length: 6107

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


Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9GJxOFm023184 for <[e-mail]>; Thu, 16 Oct 2008 12:59:25 -0700 (PDT)
Received: by gxk14 with SMTP id 14so165702gxk.21 for <[e-mail]>; Thu, 16 Oct 2008 12:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=hlCFnnD4j862zRRiYbIRA2dAB3+zriSmoeFoFzrNEfY=; b=NttgslXhOoGgcgjV6razMgY29IbgFBSEhHtbH0BxaVysZ3yYyZBtLuLCC7/KXy4kqv CP/bUM3hWBt0tN5T9GQtqMhKYUQqmjAHfs5R+wy22OVN318qe9vWoP9yak6no/kMKaLe JR3PWFnAZPgh7KORoavBNvdp/RhZluiXgqyog=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=jNdAVwFDVedsyLD8P1TokfHN4gG6TnP2GkSZHR+sAOv351nXEZ98YWARg+m0Q1uCK9 pYGKbvuy3yYthzP7uFTviwjLF24Rdkq2jTLYrP3WM1teNi/TRH/8Cra0A98Q3uF2pH0a CM7ckeP7LXAnZwKIVqquLuetqUJ70WrP5A2KU=
Received: by 10.100.207.14 with SMTP id e14mr4191365ang.60.1224187163422; Thu, 16 Oct 2008 12:59:23 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Thu, 16 Oct 2008 12:59:23 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 16 Oct 2008 15:59:23 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_26481_24073601.1224187163407"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2008 20:00:56 -0000
Status: RO
Content-Length: 9844

------=_Part_26481_24073601.1224187163407
Content-Type: multipart/alternative; 
	boundary="----=_Part_26482_21132465.1224187163407"

------=_Part_26482_21132465.1224187163407
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <[e-mail]> 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 <[e-mail]> 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
>> [e-mail] -- http://www.asomi.com/CaitlinBestlerResume.pdf
>>
>>
>
>
> --
> =============================
> Donald E. Eastlake 3rd   [phone] (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> [e-mail]
>



-- 
=============================
Donald E. Eastlake 3rd   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]

------=_Part_26482_21132465.1224187163407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi Caitlin,<div><br></div><div>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?</div>
<div><br></div><div>Thanks,</div><div>Donald<br><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 9:00 PM, Donald Eastlake <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr">Hi Caitlin,<div><br></div><div>That&#39;s a good example.</div><div><br></div><div>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.</div>

<div><br></div><div>Thanks,</div><div>Donald<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 1:43 PM, Caitlin Bestler <span dir="ltr">&lt;<a href="mailto:[e-mail]" target="_blank">[e-mail]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Donald,<br>
<br>
Here&#39;s one example where clearly stating where TRILL resides<br>
compared to IEEE 802.1 would be a benefit: Section <a href="http://4.4.2.2" target="_blank"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 4.4.2.2</a><br>
states:<br>
<br>
 &nbsp; The port on which the frame was received is first checked and the<br>
 &nbsp; frame discarded if there is no TRILL core IS-IS adjacency on that<br>
 &nbsp; port.<br>
<br>
If it is clear that EISS is the relevant interface then there is<br>
no ambiguity as to whether this is a logical (aggregated) port<br>
or a physical port. It would also allow the TRILL core IS-IS<br>
adjacency to be restricted to the controlled port (802.1X).<br>
<br>
With clean layering we don&#39;t have to belabor issues like what<br>
if any interactions there are between TRILL and Link Aggregation,<br>
or MACsec.<br>
<br>
Given the background of those working on TRILL, this is merely<br>
documenting the assumptions that I believe everyone has made<br>
while reviewing the draft. But assumptions are best explicitly<br>
stated.<br>
<br>
<br>
<br>
-----<br><font color="#888888">
Caitlin Bestler<br>
<a href="mailto:[e-mail]" target="_blank">[e-mail]</a> -- <a href="http://www.asomi.com/CaitlinBestlerResume.pdf" target="_blank">http://www.asomi.com/CaitlinBestlerResume.pdf</a><br>
<br>
</font></blockquote></div><br><br clear="all"><br></div></div><div class="Ih2E3d">-- <br>=============================<br> Donald E. Eastlake 3rd &nbsp; [phone] (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br>
 <a href="mailto:[e-mail]" target="_blank">[e-mail]</a><br>

</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>=============================<br> Donald E. Eastlake 3rd &nbsp; [phone] (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[e-mail]">[e-mail]</a><br>

</div></div>

------=_Part_26482_21132465.1224187163407--

------=_Part_26481_24073601.1224187163407
Content-Type: text/plain; name=Figure2-4.txt
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fmdtahq30
Content-Disposition: attachment; filename=Figure2-4.txt

CiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICBSQnJpZGdlICAgICAgICAgICAgICAg
ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBGb3J3YXJkaW5nIEVu
Z2luZSwgSVMtSVMsIEV0Yy4KICAgICAgICAgICAgICAgICAgICAgICAgICB8
IFByb2Nlc3Npbmcgb2YgbmF0aXZlIGFuZCBUUklMTCBmcmFtZXMKICAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICstLS0tKy0tLSstLS0tLS0tLSsrLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg
IHwgICAgICAgIHx8ICAgICAgICAgb3RoZXIgcG9ydHMuLi4KICAgICAgICAg
ICAgICAgICArLS0tLS0tLS0tLS0tLSsgICB8ICAgICAgICB8fAogICAgICAg
ICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgIHx8CiAgICAr
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rICAgfCAgICAgICAgfHwKICAg
IHwgICAgICAgICBSQnJpZGdlICAgICAgICAgIHwgICB8ICAgICAgICB8fAog
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwgICArLS0tLSsr
LS0tLS0tKyA8LSBFSVNTCiAgICB8IEhpZ2ggbGV2ZWwgQ29udHJvbCBGcmFt
ZSB8ICAgfCAgIHwgICAgICAgICAgICB8CiAgICB8ICBQcm9jZXNzaW5nIChC
UERVLCBWUlApICB8ICAgfCAgIHwgICA4MDIuMVEgICB8CiAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgfCAgIHwgUG9ydCBWTEFOICB8CiAg
ICArLS0tLS0tLS0tLS0rKy0tLS0tLS0tLS0tLS0rICAgfCAgIHwgUHJvY2Vz
c2luZyB8CiAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgfCAg
IHwgICAgICAgICAgICB8CiAgICAgICstLS0tLS0tLS0rKy0tLS0tLS0tLS0t
LS0tLS0tKy0tLSstLS0tLS0tLS0tLS0rIDwtLSBJU1MKICAgICAgfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg
ICAgfCAgICA4MDIuMS84MDIuMyBMb3cgTGV2ZWwgQ29udHJvbCBGcmFtZSAg
ICAgIHwKICAgICAgfCAgICBQcm9jZXNzaW5nLCBQb3J0L0xpbmsgQ29udHJv
bCBMb2dpYyAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0tKyst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg
ICAgICAgfHwKICAgICAgICAgICAgICAgICAgfHwgICAgICAgICstLS0tLS0t
LS0tLS0rCiAgICAgICAgICAgICAgICAgIHx8ICAgICAgICB8IDgwMi4zIFBI
WSAgfAogICAgICAgICAgICAgICAgICB8Ky0tLS0tLS0tKyAoUGh5c2ljYWwg
ICstLS0tLS0tLS0gODAyLjMKICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t
LSsgSW50ZXJmYWNlKSArLS0tLS0tLS0tIExpbmsKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICArLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAg
ICAgIEZpZ3VyZSAyLjQ6IFJCcmlkZ2UgUG9ydCBNb2RlbAoKCiAgIEZpZ3Vy
ZSAyLjQgc2hvdyBhIGhpZ2ggbGV2ZWwgZGlhZ3JhbSBvZiBhbiBSQnJpZGdl
IHBvcnQgY29ubmVjdGVkCiAgIHRvIGFuIElFRUUgODAyLjMgYmFzZWQgbGlu
ay4gU2luZ2xlIGxpbmVzIHJlcHJlc2VudCB0aGUgZmxvdyBvZgogICBjb250
cm9sIGluZm9ybWF0aW9uLCBkb3VibGUgbGluZXMgdGhlIGZsb3cgb2YgZnJh
bWVzIGFuZCBjb250cm9sCiAgIGluZm9ybWF0aW9uLgoKICAgUkJyaWRnZXMg
bWFrZSB1c2Ugb2YgODAyLjFRIHBvcnQgVkxBTiBwcm9jZXNzaW5nIGFuZCBs
b3dlciBsZXZlbAogICA4MDIuMSBwcm90b2NvbHMgYXMgd2VsbCBhcyB0aGUg
cHJvdG9jb2xzIGZvciB0aGUgbGluayBpbiB1c2UsIHN1Y2gKICAgYXMgcG9y
dCBiYXNlZCBhY2Nlc3MgY29udHJvbCBbODAyLjFYXSBvciBsaW5rIGFnZ3Jl
Z2F0aW9uLiBUaGUgb25seQogICBjdXJyZW50IGV4Y2VwdGlvbnMgYXJlIHRo
b3NlIHByb3RvY29scyByZWxhdGVkIHRvIGhpZ2ggbGV2ZWwKICAgY29udHJv
bCBmcmFtZXMsIHN1Y2ggYXMgdGhlIHNwYW5uaW5nIHRyZWUgcHJvdG9jb2wg
d2hpY2ggaXMgbm90CiAgIHVzZWQgaW4gUkJyaWRnZXMuIFRoZXJlIG1heSBp
biB0aGUgZnV0dXJlIGJlIGFkZGl0aW9uYWwgbG93ZXIgbGV2ZWwKICAgODAy
LjEgcHJvdG9jb2xzIHdoaWNoIHJlcXVpcmUgZGlmZmVyZW50IGhhbmRsaW5n
IGluIGFuIFJCcmlkZ2UgYXMKICAgY29tcGFyZWQgd2l0aCBhbiA4MDIuMSBi
cmlkZ2UuIFRoZSB1cHBlciBpbnRlcmZhY2UgdG8gdGhlIGxvd2VyCiAgIGxl
dmVsIHBvcnQvbGluayBjb250cm9sIGxvZ2ljIGNvcnJlc3BvbmRzIHRvIHRo
ZSBJbnRlcm5hbCBTdWJsYXllcgogICBTZXJ2aWNlIChJU1MpIGluIDgwMi4x
US4gSW4gUkJyaWRnZXMsIGhpZ2ggbGV2ZWwgY29udHJvbCBmcmFtZXMgYXJl
CiAgIHByb2Nlc3NlZCBhYm92ZSB0aGUgSVNTIGludGVyZmFjZS4KCiAgIFRo
ZSB1cHBlciBpbnRlcmZhY2UgdG8gdGhlIHBvcnQgVkxBTiBwcm9jZXNzaW5n
IGNvcnJlc3BvbmRzIHRvIHRoZQogICBFeHRlbmRlZCBJbnRlcm5hbCBTdWJs
YXllciBTZXJ2aWNlIChFSVNTKSBpbiA4MDIuMVEuIEluIFJCcmlkZ2VzLAog
ICBuYXRpdmUgYW5kIFRSSUxMIGZyYW1lcyBhcmUgcHJvY2Vzc2VkIGFib3Zl
IHRoZSBFSVNTIGludGVyZmFjZSBhbmQKICAgYXJlIHN1YmplY3QgdG8gcG9y
dCBWTEFOIGFuZCBwcmlvcml0eSBwcm9jZXNzaW5nLg==

------=_Part_26481_24073601.1224187163407--


Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9GIKOFC007809 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Thu, 16 Oct 2008 11:20:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,425,1220227200"; d="scan'208";a="109041143"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 16 Oct 2008 18:20:24 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9GIKOxN025957;  Thu, 16 Oct 2008 11:20:24 -0700
Received: from [10.21.150.145] (sjc-vpn7-1681.cisco.com [10.21.150.145]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9GIKNJA026390; Thu, 16 Oct 2008 18:20:23 GMT
Message-ID: <[e-mail]>
Date: Thu, 16 Oct 2008 11:20:24 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1006; t=1224181224; x=1225045224; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20TRILL=20tentatively=20sched uled=20for=20Monday=20afternoon=20in=0A=20Minneapolis |Sender:=20; bh=8hsA5WrUJ7ZeE9krDHgTboe0fvwoD+GChiPZzcXK4F8=; b=ditATSVMc8RhSQXKrjd2Ak3x19mA9MxzciorRNHjEa3kX0qBc4bRrhautu sOjkvqO80fp4qUU5xXrImQKBIAMD3IILDdZBk0lpqC8voFq3q+OpJOegvM3d 0WSlOuLxug;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] TRILL tentatively scheduled for Monday afternoon in Minneapolis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2008 18:21:33 -0000
Status: RO
Content-Length: 978

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   [phone] (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> [e-mail] <mailto:[e-mail]>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> 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



Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9GHEAfE007234 for <[e-mail]>; Thu, 16 Oct 2008 10:14:11 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so74879rvf.45 for <[e-mail]>; Thu, 16 Oct 2008 10:14:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=FspIe+VGGAK396HS+XQioAZ6pkcJWVUlO/02xNsyJMU=; b=OahE76lOlXGBcn5fjK70iuXALEIN3UvLvcII1GxMB6a6HbwGeMrEcXiBBzkEPEyzrm RYY2PedwetJRpEQoxae49ZoGigB6u3u/TMn6IgksIlDO4P0GkA0FfPwAlTDT4SnFSxUL c3eBMHyx0KqYX04axq/vTKnkD5f+eMb+tZvOs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=lQcdvAVad+AWxhF092c6V1AvLQVK+QJmWnVg/Ooi9lQ0IT7mHFaJHC1ahXiLTJrQba BDFMG29xIe0vuktQZZGLvpWOvZ+ZJ6kItkMeyDWHO9hcFlFNFyBFjxNDpyzsXanARnVG 07ycAAAgyqokkP3Z2kciuSOEeuSZN5DosxRkQ=
Received: by 10.140.161.11 with SMTP id j11mr1771314rve.134.1224177250300; Thu, 16 Oct 2008 10:14:10 -0700 (PDT)
Received: by 10.140.208.6 with HTTP; Thu, 16 Oct 2008 10:14:10 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 16 Oct 2008 13:14:10 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_51847_1866698.1224177250247"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] TRILL tentatively scheduled for Monday afternoon in Minneapolis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 16 Oct 2008 17:14:32 -0000
Status: RO
Content-Length: 1381

------=_Part_51847_1866698.1224177250247
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]

------=_Part_51847_1866698.1224177250247
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">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 <a href="http://www.ietf.org/meetings/73/">http://www.ietf.org/meetings/73/</a> web page.<br>
<br>Thanks,<br>Donald<br>=============================<br> Donald E. Eastlake 3rd &nbsp; [phone] (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[e-mail]">[e-mail]</a><br><br>
</div>

------=_Part_51847_1866698.1224177250247--


Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.240]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9E105k4011456 for <[e-mail]>; Mon, 13 Oct 2008 18:00:06 -0700 (PDT)
Received: by hs-out-0708.google.com with SMTP id 23so914659hsn.13 for <[e-mail]>; Mon, 13 Oct 2008 18:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=H/PmEp3njuo6hKpUZoXTScdt2TUGyeFbnw6ioWqNyGo=; b=yFbbxA3zajjmWO6w+y96hL0irGXmhInmgrKlSJszqTCXN3wtQqliFfK5hMVN9YIJH1 qOvYmYGkU7bKewFqooCatcIZEPSiDaw9d0TaWYE2DlqW439s8asEGMkiBF3aTTa73k8v opKoM27xPJXnUf1qjpFTPinZ1Ia8sBDJe1b04=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=mC0y91CJVozOUqQhkbQan/TgXtAFreaT7KgplpvAi5GsfHvzKUEO8VooKVYh/3gnpE d182uyfI3MfMccNc3Rn85jcKCINf+/UAorJrIg2zYCxoLVaOBmjGXMgHzAdb0wYSyZBn kP2FYuU1PVLXaglT0erocAKqHG8i6cE+0ZT+o=
Received: by 10.100.112.6 with SMTP id k6mr6665757anc.121.1223946004321; Mon, 13 Oct 2008 18:00:04 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Mon, 13 Oct 2008 18:00:04 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 21:00:04 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_130191_31430242.1223946004326"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 14 Oct 2008 01:00:20 -0000
Status: RO
Content-Length: 4083

------=_Part_130191_31430242.1223946004326
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <[e-mail]> 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
> [e-mail] -- http://www.asomi.com/CaitlinBestlerResume.pdf
>
>


-- 
=============================
Donald E. Eastlake 3rd   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]

------=_Part_130191_31430242.1223946004326
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi Caitlin,<div><br></div><div>That&#39;s a good example.</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Donald<br><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 1:43 PM, Caitlin Bestler <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Donald,<br>
<br>
Here&#39;s one example where clearly stating where TRILL resides<br>
compared to IEEE 802.1 would be a benefit: Section <a href="http://4.4.2.2" target="_blank"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 4.4.2.2</a><br>
states:<br>
<br>
 &nbsp; The port on which the frame was received is first checked and the<br>
 &nbsp; frame discarded if there is no TRILL core IS-IS adjacency on that<br>
 &nbsp; port.<br>
<br>
If it is clear that EISS is the relevant interface then there is<br>
no ambiguity as to whether this is a logical (aggregated) port<br>
or a physical port. It would also allow the TRILL core IS-IS<br>
adjacency to be restricted to the controlled port (802.1X).<br>
<br>
With clean layering we don&#39;t have to belabor issues like what<br>
if any interactions there are between TRILL and Link Aggregation,<br>
or MACsec.<br>
<br>
Given the background of those working on TRILL, this is merely<br>
documenting the assumptions that I believe everyone has made<br>
while reviewing the draft. But assumptions are best explicitly<br>
stated.<br>
<br>
<br>
<br>
-----<br><font color="#888888">
Caitlin Bestler<br>
<a href="mailto:[e-mail]" target="_blank">[e-mail]</a> -- <a href="http://www.asomi.com/CaitlinBestlerResume.pdf" target="_blank">http://www.asomi.com/CaitlinBestlerResume.pdf</a><br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>=============================<br> Donald E. Eastlake 3rd &nbsp; [phone] (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[e-mail]">[e-mail]</a><br>

</div></div>

------=_Part_130191_31430242.1223946004326--


Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DLnAaO026677 for <[e-mail]>; Mon, 13 Oct 2008 14:49:10 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 13 Oct 2008 14:49:07 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] encoding of TRILL IS-IS frames
Thread-Index: AckrpQbwBZ3JqjcDTzaJQSwLmZuE3QBu5MfwAAchmoA=
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Silvano Gai" <[e-mail]>
To: "Anoop Ghanwani" <[e-mail]>, "Dinesh G Dutt" <[e-mail]>, "Donald Eastlake" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m9DLnAaO026677
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 21:49:35 -0000
Status: RO
Content-Length: 1644

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] 
> [mailto:[e-mail]] 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
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge



Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DL9GC4007669 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Mon, 13 Oct 2008 14:09:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,405,1220227200"; d="scan'208";a="90331179"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2008 21:09:15 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9DL9F0E000443;  Mon, 13 Oct 2008 14:09:15 -0700
Received: from [10.21.91.89] (sjc-vpn5-857.cisco.com [10.21.91.89]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9DL9Fv6025659; Mon, 13 Oct 2008 21:09:15 GMT
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 14:09:16 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Anoop Ghanwani <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1306; t=1223932155; x=1224796155; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20encoding=20of=20TRILL=20IS- IS=20frames |Sender:=20; bh=u6SFd/ELqV0CU0S5AXHz8L9JnQO8b31VcAVlpHCcHwU=; b=KyOmZQ1Xr8hiyjZXZQxlN1oBgzlCPhDAV1WQVI/mtby3QKUtqvokDrIxzV n9p7lwjjrzia/rVgzosu3eGg7gWh91ZHOXM0BRU/fvoyB/Fc++HZPmGk5EeV 8dzJ2Sid48;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 21:09:57 -0000
Status: RO
Content-Length: 1266

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: [e-mail] 
>> [mailto:[e-mail]] 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



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DJFSRX017122 for <[e-mail]>; Mon, 13 Oct 2008 12:15:30 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 13 Oct 2008 12:15:25 -0700 (PDT)
Received: from [129.150.36.207] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 13 Oct 2008 12:15:25 -0700 (PDT)
Date: Mon, 13 Oct 2008 12:15:10 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Caitlin Bestler <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 19:16:07 -0000
Status: RO
Content-Length: 2002

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



Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DJEg9x016743 for <[e-mail]>; Mon, 13 Oct 2008 12:14:43 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 9so1341879eyd.63 for <[e-mail]>; Mon, 13 Oct 2008 12:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=8dV00CSHJyFxtjQxxwHuHIkDvjOVtF2WPQ1axKV66Us=; b=BeKIYXJgxa5jTxc8UVyS+VyRCueTjnmzbg+yU/A2Yaf91tubYpUuPyE1dv+uUgi521 9wl4a/h+pOK+RYK0X54eB8kWCSPzsmcCAt47gHUePl/9IEUEtl7SnRx9H0zrQPOZcX6D 7t1kCnPgIHChZp+AsvW1EN/IeLXcB/XNMrPtk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=LKJdyskS3mNnL8p0L13LzaWcQDPL93J0GGXL6gHYKDIGxZgh1YR4CyQWIOhec7Yl9A EHE0hKo9fsvM+CsJvRm3Rhs9bqHaR067j22vR2kNsOo5mhAstp/Ta3tFY2rKl055/Mdq SIoSvCmRYNx6wYN9ZRpMU1KroLKNEM55BRc2A=
Received: by 10.187.168.2 with SMTP id v2mr1160664fao.23.1223925281400; Mon, 13 Oct 2008 12:14:41 -0700 (PDT)
Received: by 10.187.234.19 with HTTP; Mon, 13 Oct 2008 12:14:41 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 15:14:41 -0400
From: "RTP Techie" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_143192_30821675.1223925281393"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] L2 ISIS - P2P over LAN
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 19:15:07 -0000
Status: RO
Content-Length: 1678

------=_Part_143192_30821675.1223925281393
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_143192_30821675.1223925281393
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi,<br>I&#39;m new to Rbridge and just reading the protocol spec.&nbsp; <br>One thing that comes to me is that for ISIS, it talks about the use of it in LAN mode.<br>&nbsp;<br>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.<br>
&nbsp;<br>Would the same technique applicable to L2 ISIS? If not, can you please provide some insights as why?<br>&nbsp;<br>Thanks in advance,<br>Ming Chan</div>

------=_Part_143192_30821675.1223925281393--


Received: from mx10.brocade.com (mx10.brocade.com [208.185.105.18]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DIRYaE023407 for <[e-mail]>; Mon, 13 Oct 2008 11:27:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,404,1220252400"; d="scan'208";a="134120172"
Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 13 Oct 2008 11:27:33 -0700
Received: from HQ-EXCHFE-3.corp.brocade.com (unknown [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id DE52F23839C; Mon, 13 Oct 2008 11:27:33 -0700 (PDT)
Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 13 Oct 2008 11:27:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 13 Oct 2008 11:27:28 -0700
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] encoding of TRILL IS-IS frames
Thread-Index: AckrpQbwBZ3JqjcDTzaJQSwLmZuE3QBu5Mfw
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Anoop Ghanwani" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>, "Donald Eastlake" <[e-mail]>
X-OriginalArrivalTime: 13 Oct 2008 18:27:33.0897 (UTC) FILETIME=[5C373790:01C92D61]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m9DIRYaE023407
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 18:28:12 -0000
Status: RO
Content-Length: 853

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 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



Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DHhr6T001726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 13 Oct 2008 10:43:54 -0700 (PDT)
Received: (qmail 5547 invoked from network); 13 Oct 2008 17:43:52 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 13 Oct 2008 17:43:51 -0000
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 10:43:51 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 17:44:26 -0000
Status: RO
Content-Length: 964

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
[e-mail] -- http://www.asomi.com/CaitlinBestlerResume.pdf



Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DH4pRb011746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 13 Oct 2008 10:04:53 -0700 (PDT)
Received: (qmail 14526 invoked from network); 13 Oct 2008 17:04:48 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 13 Oct 2008 17:04:48 -0000
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 10:04:47 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 17:05:42 -0000
Status: RO
Content-Length: 1768

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.


Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9DGOKVx019481 for <[e-mail]>; Mon, 13 Oct 2008 09:24:21 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id b38so144123ana.81 for <[e-mail]>; Mon, 13 Oct 2008 09:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=V9WqbNUhkmI1+oYXL/XBD2viaqjcvWgrZFrwfCWQT5I=; b=N/VcfHfPUXbt4UU0ZGPkTcCkwOJLGJCbQpJjSH0hZKdk4ZE3n1yi566i3QqPnwfDM3 +59LuUrcDOB+eUreMMhr6vL0UuEoBEr2AAcAtzDN3kItp4/fL8Dd1uWrYBIOOYtWYW4+ r27a5u5kn2U24VZqIGyCpBIEE2zks8F88j5UE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Wj5JP6iE+x/SsoSk74WPJGSBrx1tMaY9LMnj9g/ECfjjhZl/0dKhk2DiLZ/h5b20VL ebkg4qoV3FMwajaHd7m3qCE2TqXimp+YZ0Hg6oCnSSaSe+WQTm8Anu6366atEWtS74R6 EvkKejI3p8guPnAziDAn9COdPAwJ4C0N1TI4Y=
Received: by 10.100.140.15 with SMTP id n15mr4751743and.111.1223915059199; Mon, 13 Oct 2008 09:24:19 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Mon, 13 Oct 2008 09:24:19 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 12:24:19 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>, "Caitlin Bestler" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 16:25:05 -0000
Status: RO
Content-Length: 4368

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 <[e-mail]> 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
>> [e-mail] - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>>
>> task group,
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> 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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9D50OSE008868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 12 Oct 2008 22:00:25 -0700 (PDT)
Received: (qmail 5214 invoked from network); 13 Oct 2008 05:00:24 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 13 Oct 2008 05:00:24 -0000
Message-ID: <[e-mail]>
Date: Sun, 12 Oct 2008 22:00:23 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Dinesh G Dutt <[e-mail]>
References: <[e-mail]>		<[e-mail]>		<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2008 05:00:57 -0000
Status: RO
Content-Length: 4333

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 <[e-mail]> 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
[e-mail] -- http://www.asomi.com/CaitlinBestlerResume.pdf



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9C47SLZ002480 for <[e-mail]>; Sat, 11 Oct 2008 21:07:29 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 11 Oct 2008 21:07:18 -0700 (PDT)
Received: from [129.150.36.207] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Sat, 11 Oct 2008 21:07:16 -0700 (PDT)
Date: Sat, 11 Oct 2008 21:07:14 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Donald Eastlake <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 12 Oct 2008 04:08:15 -0000
Status: RO
Content-Length: 8956

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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
>>>>>> [e-mail]
>>>>>> 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
>>
>>
>>     
>
>
>
>   



Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9BBbDNc027387 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Sat, 11 Oct 2008 04:37:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,393,1220227200"; d="scan'208";a="89692837"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2008 11:37:12 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9BBbCfn020999;  Sat, 11 Oct 2008 04:37:12 -0700
Received: from [10.21.69.235] (sjc-vpn3-1515.cisco.com [10.21.69.235]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9BBbCKY015983; Sat, 11 Oct 2008 11:37:12 GMT
Message-ID: <[e-mail]>
Date: Sat, 11 Oct 2008 04:37:14 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4577; t=1223725032; x=1224589032; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20encoding=20of=20TRILL=20IS- IS=20frames |Sender:=20; bh=o1fkhKDqeiiFHgrFjbmAWqFTVQYCsQZgPRSsTMbkLpc=; b=NxsmVyuxs6mnUhhpj96WM0149rLGWYkTSCryDCDOyPaV3OaCOwx3KFbhla MuTnbfp1ZeFbihN5N7xUaDwJZ7yxEaF2tA4LgyHwYRmWHrm2/HlPVjsGgNIa ON3hfA+BTP;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 12:05:28 -0000
Status: RO
Content-Length: 4489

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



Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B2wALI012202 for <[e-mail]>; Fri, 10 Oct 2008 19:58:11 -0700 (PDT)
Received: by gxk14 with SMTP id 14so609775gxk.21 for <[e-mail]>; Fri, 10 Oct 2008 19:58:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6guoVl9EVWmU3hwSs1r4HFI50j0f6UOvEyXzD9Fnx2s=; b=N+QCACOrb06/o/uJuB13RyFNmHcumKiWpC2ntY+TxxDPKQmMLnMEPObPuGYZ5/nL1f 3LtAlfyosQvb4yhZvT82CYBFUovoTAMbWTVUNnRgT0TyGh2AXHS7mHyTRvfPsqqghCyX eZrAoy8cxrznuRgbRG0FBUUQMRMbhrb87nWaI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ca3mnc3I/G2Aho1Q7gbbAeWYRy11CUjWt4qIDk7GMYwd3K+9ZXb7zJknKA4HSr97SW LMmHn6kybHrd4LKBbeMV2gLOaplPvs2F9cDbJXFxOJD4SCz5hbgYe2RYJnuEDyZg3Mk/ GkTqTS4Vr3MYti7jNDbA1Fp5irewFHuSxuzZA=
Received: by 10.100.212.5 with SMTP id k5mr3305155ang.48.1223693889835; Fri, 10 Oct 2008 19:58:09 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Fri, 10 Oct 2008 19:58:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 22:58:09 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Making VLAN mapping not illegal -- minor wording change
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 02:58:39 -0000
Status: RO
Content-Length: 765

Good idea,
Donald

On Fri, Oct 10, 2008 at 6:47 PM, Radia Perlman <[e-mail]> 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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B2rFuJ010913 for <[e-mail]>; Fri, 10 Oct 2008 19:53:16 -0700 (PDT)
Received: by gxk14 with SMTP id 14so607202gxk.21 for <[e-mail]>; Fri, 10 Oct 2008 19:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=USCbsKn2bBjVkY5LqiKoApUZswKUEvOD8mG4CPwQxSQ=; b=Z7GgiASKjEidk+UV0iWE/ToAssPDuzss9zWEA76U6j+ziv0hgOoUoOvd2BPKiMSrkv 6hZPdRf244wP786WomQ74QCwnEkyrHlmNlPrNefS7PcajTqtS0pDdO9GmHcEHnQERJvs EkTcv6Iskfcrza+mjmGzMsxa0qOzvoNaVD1cs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZFA+B1Phwu8Q2k0QqGwnSy4rvhgyDH64JN/slRHf3rDZozMlvsKH0HXTw9ajQqUDHE XKQCbbGZA2QcrpD7ATNJW6um00FPQyGl4bJRS4czoxrM/MB5NT9JJjAoGYtHo4fKUuwe k20BgfQYvVH6qAa9hx0nzl73bkKLD8E7nrjJM=
Received: by 10.100.96.10 with SMTP id t10mr3312628anb.32.1223693594852; Fri, 10 Oct 2008 19:53:14 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Fri, 10 Oct 2008 19:53:14 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 22:53:14 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 02:53:42 -0000
Status: RO
Content-Length: 6256

See below...

On Fri, Oct 10, 2008 at 10:24 PM, Dinesh G Dutt <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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
>>>>> [e-mail]
>>>>> 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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B2WQZQ004374 for <[e-mail]>; Fri, 10 Oct 2008 19:32:27 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 5so280782ywh.75 for <[e-mail]>; Fri, 10 Oct 2008 19:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dQ7+zabM+6JCWGe36qSZctfgL3PU96DW7/mBMQC2jqE=; b=L43SOmpLYpnxlRVv5KQ/AXpRFEbf5A7W8STfcPkSCUhOEV5fLXxvKtYXe3ZyZAVyJs NmYVf3JmCJdH+rjpfZXTOf8RQd9qhJmlyviWMhVXYl6E+BxnCNC/0Qyp/mg5Xc1WFQIH O71HoZsYC8mj7BTK8ufvtLMCpKI3uslKZFLS8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=osZ9mSqv1rPNYU8nvIVSaqMq5Km1JXE2ofIIqsQtOnbCJrajpSu6g0gPr4tGYfNt7d Nbfd59avFL1DdIGJOTyoFKo7gLFd94BB3yHFzDvCBOpX/dJNSy3sRvFY6hnvf+MKhJ0v JID2hojx8h7L+fk5x8b7zvjTwWI0z7mdaWrvY=
Received: by 10.100.216.12 with SMTP id o12mr3263869ang.92.1223692345881; Fri, 10 Oct 2008 19:32:25 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Fri, 10 Oct 2008 19:32:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 22:32:25 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 02:32:46 -0000
Status: RO
Content-Length: 4606

See below...

On Fri, Oct 10, 2008 at 6:43 PM, Radia Perlman <[e-mail]> 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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B2O36X000577 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 10 Oct 2008 19:24:04 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,392,1220227200"; d="scan'208";a="173023149"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2008 02:24:03 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9B2O3NZ009325;  Fri, 10 Oct 2008 19:24:03 -0700
Received: from [10.21.69.235] (sjc-vpn3-1515.cisco.com [10.21.69.235]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9B2O2BP009278; Sat, 11 Oct 2008 02:24:02 GMT
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 19:24:03 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4638; t=1223691843; x=1224555843; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20base=20protocol=20minor=20r ewording=20issue=20--=204.4.1.1=20bullet=0A=203 |Sender:=20; bh=zjUdK+/Dqp9raU4kUypq00ScKvgJJfw13LfMk0vxxZg=; b=RV4epim0Vmr5OzU9FK6CY6lhugYvddrRxduCh8XRj6BXDezQF9wjlHP0nQ ZHkwhLpjynPXZqfZdVrTNXBeVo4paCtl6Z645OEwhg0NX7R/4Muvt4ys2TXv ZGPytRfKwo;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 02:25:40 -0000
Status: RO
Content-Length: 4515

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 <[e-mail]> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> 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



Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B0whMG027578 for <[e-mail]>; Fri, 10 Oct 2008 17:58:44 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id b38so92176ana.81 for <[e-mail]>; Fri, 10 Oct 2008 17:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sbyvEnUcQG1K7h53ZHb10gjic/gO3rmgPB8MmbKcgNA=; b=UoENwHK+H/MztiJ8TxOaxjH4xmIGgT/1aHRsZaCsbVC9R3x1Da2EWF387rhP//7za8 07KKlml93ADhFY5EX/tpbmXbTgAnYrtBcwlo20SafXNfmP85tV3Ii4X6bV3OZx62eAVK IJ4cCcbITKEaxGY6iQ1xa2mSzKp+i4a+ARAkY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Z+2oAZTLAx3D6OvPllYyeKalKWzmKnBGoh66fmL9fgPZMRO1wsDkPb6czD6nQL3zF6 Fdubjsj4UICpH9K+8MY/o0PHWIQ61xexSpSy4+CCKAAkqCGQTRNM5UDbEzrp7i3ttfp8 vj7Kt43tlLplmmss4tRjulCcw9VCNIM2QlXUk=
Received: by 10.100.226.6 with SMTP id y6mr3159468ang.146.1223686723588; Fri, 10 Oct 2008 17:58:43 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Fri, 10 Oct 2008 17:58:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 20:58:43 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Dinesh G Dutt" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 00:59:13 -0000
Status: RO
Content-Length: 3697

See below:

On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <[e-mail]> 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> 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   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B0JW0c012792 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 10 Oct 2008 17:19:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,392,1220227200"; d="scan'208";a="94333170"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2008 00:18:44 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9B0Ii5M026732;  Fri, 10 Oct 2008 17:18:44 -0700
Received: from [10.21.69.235] (sjc-vpn3-1515.cisco.com [10.21.69.235]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9B0IipO028371; Sat, 11 Oct 2008 00:18:44 GMT
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 17:18:44 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Donald Eastlake <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2301; t=1223684324; x=1224548324; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20base=20protocol=20minor=20r ewording=20issue=20--=204.4.1.1=20bullet=0A=203 |Sender:=20; bh=Dmf1RLR/e5qsDOSZjQG8nEn9JPKd5Hlj0eXEtSGniDU=; b=bFqp1wD13n1E0uFDXNdhkUBm/IicI4pibxW0Cobpm+dUHiersfnQ272/RN 8j/s5duAvJEk0nCXao4ourjF+8Zx2A4zjZqEqkzhsn4Y7UPcAV8X+AAdXQye bPGRNO3J+l;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 00:20:11 -0000
Status: RO
Content-Length: 2241

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 <[e-mail]> 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
>> [e-mail]
>> 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



Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9B0AqaI008721 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 10 Oct 2008 17:10:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,392,1220227200"; d="scan'208";a="89595666"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2008 00:10:52 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9B0AqOW018191;  Fri, 10 Oct 2008 17:10:52 -0700
Received: from [10.21.69.235] (sjc-vpn3-1515.cisco.com [10.21.69.235]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m9B0AqsJ007793; Sat, 11 Oct 2008 00:10:52 GMT
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 17:10:52 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1961; t=1223683852; x=1224547852; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20encoding=20of=20TRILL=20IS- IS=20frames |Sender:=20; bh=o3sQbw22IzC6LZOAzcy0IBVqmSYgnc7swIrZ360UMMs=; b=VMyrkZDTGbRd0o+BXfUaqGQU87YqdFiDE46lKmIv8djFkz7H0M6KB502vV +fCo/xNx7ZAPTvnj/hJwR3NBo3RDKvq9NsJVzSbs+vtt3OAm/fRVbLHJZEej j1Tqmrn7tb;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 00:11:08 -0000
Status: RO
Content-Length: 1911

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
> [e-mail]
> 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



Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9ANxSv0004168 for <[e-mail]>; Fri, 10 Oct 2008 16:59:29 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id b38so91122ana.81 for <[e-mail]>; Fri, 10 Oct 2008 16:59:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dHnaor6M5I+n8O0XAadoj88NqH9r0bofAsirK0SGy0Y=; b=bpw6FrpDyE7qW6BhKEEWu5rUvmMVDtQfGBVHl04RChzJYPBvnRUVQxDI8qNVh6u0X8 HmI1PHI2cZ3T852b4yXjy+TGAmE8Q0zMvSFYJfdJYDa6Jc4OnO5hMWeolFaQUrQES7Kx uX1vfkm8zBFAQtJaKSSpmOOJetb7UXy9hNMjA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mEepmdRCblpY7wE3ez8/k99Ig6XbU8j1wXO3/Q2dEwFzuY8taairQxT70ul/7EhfQ5 relhHBziSp23Py/LCI6XeFXHvCv9OA5cM5iNj5ssG2AzFZxvyIMdWrdow+XpLD6bZH+Q wROnCHzQLyhuHBJ8hobOtOuV+uX+4jSKKTYPQ=
Received: by 10.100.240.17 with SMTP id n17mr3125249anh.138.1223683167743; Fri, 10 Oct 2008 16:59:27 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Fri, 10 Oct 2008 16:59:27 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 19:59:27 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Radia Perlman" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2008 00:00:16 -0000
Status: RO
Content-Length: 1719

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 <[e-mail]> 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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
=============================
 Donald E. Eastlake 3rd   [phone] (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]


Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9ANlUMw029655 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 10 Oct 2008 16:47:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,391,1220227200"; d="scan'208";a="48637619"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 10 Oct 2008 23:47:29 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9ANlTiR026641;  Fri, 10 Oct 2008 16:47:29 -0700
Received: from [10.21.69.235] (sjc-vpn3-1515.cisco.com [10.21.69.235]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9ANlTBP002373; Fri, 10 Oct 2008 23:47:29 GMT
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 16:47:29 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Caitlin Bestler <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3143; t=1223682449; x=1224546449; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Relationship=20with=20802.1 |Sender:=20; bh=DQWqW9rLN1GikSEXm3IXejLy7NhoCA4ItFjul/6VaLo=; b=YX30X5ZB4mqbwxrqArePc5jUOjGB2sYgT6ucA9qEsHvBfCP+XfJRF3//2N XLjpP2BY98mZh/dS5SkNdDZW9sYC4sjPz6XovNd1PX4unCuuj4iDgaK09Wu1 yJJPrTafxt;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2008 23:48:18 -0000
Status: RO
Content-Length: 3065

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
> [e-mail] - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>
> task group,
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> 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



Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9ANYCsQ024835 for <[e-mail]>; Fri, 10 Oct 2008 16:34:13 -0700 (PDT)
Received: by rn-out-0910.google.com with SMTP id k57so507621rnd.13 for <[e-mail]>; Fri, 10 Oct 2008 16:34:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=eJ5cgrqrEjxc3XxCGLVpCrNmeSEGs+EzkehLrbM+PvA=; b=xXt/mv586fm4ezTreL2vgqmXHxisBhq91dn2l/XRjDN1z2oY+ALjx2AkM14K/j8/ee lP6ErBgj2tY9dsKVkRWFqLQlq5d+n9Vlbm1iPU7BNxzPJp7rSlpVRIODUlKeGJAaA52v XkDCLnjbKPB0RzgzSeNJ1x9+w9Dr/PWAIJDkk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Fb4b5MXS9QloBVLDrUy74xyeUXjib0OgYyJkDiDFoxo9zyNfLAregNsRZHkFw+l6nv KVDqp4nbCFF233yPwD3VeSvuZVafyojLB6CmW+yQv4znN38DFqJAsWgp4asmyMobL/Sj gu8omYPhN/WxwpMlFTRW5isXt++xwTmoE1PJo=
Received: by 10.100.6.13 with SMTP id 13mr3153044anf.70.1223681651173; Fri, 10 Oct 2008 16:34:11 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Fri, 10 Oct 2008 16:34:11 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 19:34:11 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Caitlin Bestler" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2008 23:34:36 -0000
Status: RO
Content-Length: 4273

Hi Caitlin,

A few comments below...

On Fri, Oct 10, 2008 at 1:23 PM, Caitlin Bestler <[e-mail]> 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
> [e-mail] - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf
>
> task group,
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge

--
=============================
Donald E. Eastlake 3rd   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9AMlLNk006720 for <[e-mail]>; Fri, 10 Oct 2008 15:47:21 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 10 Oct 2008 15:47:20 -0700 (PDT)
Received: from [129.150.36.207] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 10 Oct 2008 15:47:20 -0700 (PDT)
Date: Fri, 10 Oct 2008 15:47:21 -0700
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Making VLAN mapping not illegal -- minor wording change
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2008 22:47:32 -0000
Status: RO
Content-Length: 364

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




Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9AMhcYc005228 for <[e-mail]>; Fri, 10 Oct 2008 15:43:38 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 10 Oct 2008 15:43:37 -0700 (PDT)
Received: from [129.150.36.207] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 10 Oct 2008 15:43:37 -0700 (PDT)
Date: Fri, 10 Oct 2008 15:43:37 -0700
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] encoding of TRILL IS-IS frames
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2008 22:44:01 -0000
Status: RO
Content-Length: 1122

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


Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9AMXrr6001999 for <[e-mail]>; Fri, 10 Oct 2008 15:33:54 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 10 Oct 2008 15:33:43 -0700 (PDT)
Received: from [129.150.36.207] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 10 Oct 2008 15:33:43 -0700 (PDT)
Date: Fri, 10 Oct 2008 15:33:44 -0700
From: Radia Perlman <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2008 22:34:03 -0000
Status: RO
Content-Length: 516

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.


Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9AHNvPS013989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 10 Oct 2008 10:23:58 -0700 (PDT)
Received: (qmail 7770 invoked from network); 10 Oct 2008 17:23:56 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 10 Oct 2008 17:23:56 -0000
Message-ID: <[e-mail]>
Date: Fri, 10 Oct 2008 10:23:55 -0700
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Relationship with 802.1
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2008 17:24:31 -0000
Status: RO
Content-Length: 2348

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
[e-mail] - http://www.asomi.com/CaitlinBestlerResume-Oct2008.pdf

task group,




Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m9944oTT027645 for <[e-mail]>; Wed, 8 Oct 2008 21:04:51 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 5so700847ywh.75 for <[e-mail]>; Wed, 08 Oct 2008 21:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=lMUZ2wxuUQXqi/aseLX4DhvYlaMY7y7/pL3aG5E/7S0=; b=VX0ryHgucRtYwwENaCKmPZIi9gXP7c9jqsKyR4/hbIme4YX9ehImWRJ2nuHwHpzeEa hBwMy2TlSL2TV1ypwxtwysoDcIUNpsd2pP8CRXm/ze9kQoyfZIFpEiqlxjvSY0e4Boib BbSkjulr3Y09CN6WKxok1xENwznlMC+AEnK84=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=MNVPhTFUzFzJWVPZtHEb1MRRnuxRMzEHzLDrX+/fmK2QAv5Upb0UiQB5RHugtIoEjo x+uy8n+pqMGGaMxghVdIhnbWpoccH87WbZ2c9e3a8GAPIModD4L0zIJ5pGDQ5gsjBPsr oIYYvgIDhpjaFT1m7i4aCvWMCP2pdKaXFkqPE=
Received: by 10.101.67.11 with SMTP id u11mr3033126ank.88.1223525089295; Wed, 08 Oct 2008 21:04:49 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Wed, 8 Oct 2008 21:04:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 9 Oct 2008 00:04:49 -0400
From: "Donald Eastlake" <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_77904_18979459.1223525089290"
References: <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] draft-ietf-trill-prob-05.txt Publication Request
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2008 04:05:26 -0000
Status: RO
Content-Length: 18896

------=_Part_77904_18979459.1223525089290
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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
[e-mail]


(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 <[e-mail]>

    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.

------=_Part_77904_18979459.1223525089290
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi,<br><div class="gmail_quote"><div dir="ltr"><div><br></div><div>We have requested publication of&nbsp;<span style="border-collapse:collapse;white-space:pre">draft-ietf-trill-prob-05.txt</span>&nbsp;as an Informational RFC. The PROTO statement is below.<br>


<div class="gmail_quote"><div dir="ltr">
<div><br></div><div>Thanks,</div><div>Donald and Erik<br>=============================<br> Donald E. Eastlake 3rd<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[e-mail]" target="_blank">[e-mail]</a><br>




</div><div><br></div><div><br></div><div><div>(1.a) Who is the Document Shepherd for this document? &nbsp;Has the</div><div>&nbsp;&nbsp; &nbsp; &nbsp;Document Shepherd personally reviewed this version of the</div><div>&nbsp;&nbsp; &nbsp; &nbsp;document and, in particular, does he or she believe this version</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;is ready for forwarding to the IESG for publication?</div><div><br></div><div>&nbsp;&nbsp; &nbsp;Donald E. Eastlake 3rd &lt;<a href="mailto:[e-mail]" target="_blank">[e-mail]</a>&gt;</div><div><br></div><div>


&nbsp;&nbsp; &nbsp;Yes</div><div>
<br></div><div>(1.b) Has the document had adequate review both from key WG members&nbsp;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;and from key non-WG members? Does the Document Shepherd have&nbsp;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;any concerns about the depth or breadth of the reviews that&nbsp;</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;have been performed?&nbsp;</div><div><br></div><div>&nbsp;&nbsp; &nbsp;The document has had adequate review. In its early days, when it</div><div>&nbsp;&nbsp; &nbsp;was incomplete and it appear to be difficult to get comments, a</div><div>&nbsp;&nbsp; &nbsp;first WGLC was done which succeeded in eliciting comments. A</div>


<div>&nbsp;&nbsp; &nbsp;complete revised&nbsp;document&nbsp;was WGLCed here</div><div>&nbsp;&nbsp; &nbsp;<a href="http://www.postel.org/pipermail/rbridge/2008-July/003059.html" target="_blank">http://www.postel.org/pipermail/rbridge/2008-July/003059.html</a></div>



<div>&nbsp;&nbsp; &nbsp;producing comments the resolutions of which are here</div><div>&nbsp;&nbsp; &nbsp;<a href="http://www.postel.org/pipermail/rbridge/2008-August/003083.html" target="_blank">http://www.postel.org/pipermail/rbridge/2008-August/003083.html</a></div>



<div>&nbsp;&nbsp; &nbsp;resulting is a revised draft notice of posting of which is here</div><div>&nbsp;&nbsp; &nbsp;<a href="http://www.postel.org/pipermail/rbridge/2008-September/003110.html" target="_blank">http://www.postel.org/pipermail/rbridge/2008-September/003110.html</a></div>



<div><br></div><div>(1.c) Does the Document Shepherd have concerns that the document&nbsp;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;needs more review from a particular or broader perspective,&nbsp;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;e.g., security, operational complexity, someone familiar with&nbsp;</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;AAA, internationalization or XML?</div><div><br></div><div>&nbsp;&nbsp; &nbsp;No.</div><div><br></div><div>(1.d) Does the Document Shepherd have any specific concerns or issues</div><div>&nbsp;&nbsp; &nbsp; &nbsp;with this document that the Responsible Area Director and/or the</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;IESG should be aware of? For example, perhaps he or she is</div><div>&nbsp;&nbsp; &nbsp; &nbsp;uncomfortable with certain parts of the document, or has</div><div>&nbsp;&nbsp; &nbsp; &nbsp;concerns whether there really is a need for it. In any event, if</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;the WG has discussed those issues and has indicated that it</div><div>&nbsp;&nbsp; &nbsp; &nbsp;still wishes to advance the document, detail those concerns</div><div>&nbsp;&nbsp; &nbsp; &nbsp;here. Has an IPR disclosure related to this document been filed?</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;If so, please include a reference to the disclosure and</div><div>&nbsp;&nbsp; &nbsp; &nbsp;summarize the WG discussion and conclusion on this issue.</div><div><br></div><div>&nbsp;&nbsp; &nbsp;No specific concerns.</div><div><br></div><div>&nbsp;&nbsp; &nbsp;No IPR disclosure specific to this document has been filed but see</div>



<div>&nbsp;&nbsp; &nbsp;<a href="http://www.ietf.org/ietf/IPR/sun-ipr-draft-perlman-rbridge.txt" target="_blank">http://www.ietf.org/ietf/IPR/sun-ipr-draft-perlman-rbridge.txt</a></div><div>&nbsp;&nbsp; &nbsp;for the Sun Microsystems RBridge disclosure.</div>


<div><br>
</div><div>(1.e) How solid is the WG consensus behind this document? Does it</div><div>&nbsp;&nbsp; &nbsp; &nbsp;represent the strong concurrence of a few individuals, with</div><div>&nbsp;&nbsp; &nbsp; &nbsp;others being silent, or does the WG as a whole understand and</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;agree with it?</div><div><br></div><div>&nbsp;&nbsp; &nbsp;This document represents the opinion of the working group as</div><div>&nbsp;&nbsp; &nbsp;discerned by the co-chairs. There has been discussion of how</div><div>&nbsp;&nbsp; &nbsp;the document should &quot;describe&quot; IEEE 802 spanning tree protocol</div>


<div>&nbsp;&nbsp; &nbsp;but that does not affect the techncial content of this document.</div><div>&nbsp;&nbsp; &nbsp;In this the&nbsp;document represents something reasonably close to</div><div>&nbsp;&nbsp; &nbsp;the center of working&nbsp;group opinion.</div><div><br></div>


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


&nbsp;&nbsp; &nbsp;No.&nbsp;</div><div><br></div><div>(1.g) Has the Document Shepherd personally verified that the document</div><div>&nbsp;&nbsp; &nbsp; &nbsp;satisfies all ID nits? (See</div><div>&nbsp;&nbsp; &nbsp; &nbsp;<a href="http://www.ietf.org/ID-Checklist.html" target="_blank">http://www.ietf.org/ID-Checklist.html</a> and</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;<a href="http://tools.ietf.org/tools/idnits/" target="_blank">http://tools.ietf.org/tools/idnits/</a>). Boilerplate checks are not</div><div>&nbsp;&nbsp; &nbsp; &nbsp;enough; this check needs to be thorough. Has the document met</div>


<div>&nbsp;&nbsp; &nbsp; &nbsp;all formal review criteria it needs to, such as the MIB Doctor,</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp;media type and URI type reviews?</div><div><br></div><div>&nbsp;&nbsp; &nbsp;Yes.</div><div><br></div><div>(1.h) Has the document split its references into normative and</div><div>&nbsp;&nbsp; &nbsp; &nbsp;informative? Are there normative references to documents that</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;are not ready for advancement or are otherwise in an unclear</div><div>&nbsp;&nbsp; &nbsp; &nbsp;state? If such normative references exist, what is the strategy</div><div>&nbsp;&nbsp; &nbsp; &nbsp;for their completion? Are there normative references that are</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;downward references, as described in [RFC3967]? If so, list</div><div>&nbsp;&nbsp; &nbsp; &nbsp;these downward references to support the Area Director in the</div><div>&nbsp;&nbsp; &nbsp; &nbsp;Last Call procedure for them [RFC3967].</div><div><br></div>



<div>&nbsp;&nbsp;References are split but there are no normative references.</div><div><br></div><div>(1.i) Has the Document Shepherd verified that the document IANA</div><div>&nbsp;&nbsp; &nbsp; &nbsp;consideration section exists and is consistent with the body of</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;the document? If the document specifies protocol extensions, are</div><div>&nbsp;&nbsp; &nbsp; &nbsp;reservations requested in appropriate IANA registries? Are the</div><div>&nbsp;&nbsp; &nbsp; &nbsp;IANA registries clearly identified? If the document creates a</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;new registry, does it define the proposed initial contents of</div><div>&nbsp;&nbsp; &nbsp; &nbsp;the registry and an allocation procedure for future</div><div>&nbsp;&nbsp; &nbsp; &nbsp;registrations? Does it suggest a reasonable name for the new</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;registry? See [RFC5226]. If the document describes an Expert</div><div>&nbsp;&nbsp; &nbsp; &nbsp;Review process has Shepherd conferred with the Responsible Area</div><div>&nbsp;&nbsp; &nbsp; &nbsp;Director so that the IESG can appoint the needed Expert during</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;the IESG Evaluation?</div><div><br></div><div>&nbsp;&nbsp; &nbsp;None of the above is applicable to this document. That IANA</div><div>&nbsp;&nbsp; &nbsp;section correctly states that no IANA actions are required and</div><div>&nbsp;&nbsp; &nbsp;that the section should be removed on publication.</div>



<div><br></div><div>(1.j) Has the Document Shepherd verified that sections of the document</div><div>&nbsp;&nbsp; &nbsp; &nbsp;that are written in a formal language, such as XML code, BNF</div><div>&nbsp;&nbsp; &nbsp; &nbsp;rules, MIB definitions, etc., validate correctly in an automated</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp;checker?</div><div><br></div><div>&nbsp;&nbsp;There are no such sections in this document.</div><div><br></div><div>(1.k) The IESG approval announcement includes a Document Announcement</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Write-Up. Please provide such a Document Announcement</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Write-Up? Recent examples can be found in the &quot;Action&quot;</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;announcements for approved documents. The approval</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;announcement contains the following sections:</div>



<div><br></div><div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp;Technical Summary&nbsp;</div><div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This document discusses the avoidance of some problems in</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Layer 2 forwarding with the spanning tree protocol</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; through the use of link state routing techniques,</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; possibly with a hop count limit. Desired properties and</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the applicability of such improved forwarding are also</div>



<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; given.</div><div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp;Working Group Summary&nbsp;</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div><div><span style="white-space:pre">	</span> &nbsp; &nbsp; This document was Working Group Last Called twice. There</div>
<div><span style="white-space:pre">	</span> &nbsp; &nbsp; were informal complaints that the first WGLC was improper</div><div><span style="white-space:pre">	</span> &nbsp; &nbsp; because the document was not complete at that time.</div>
<div>&nbsp;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;Document Quality&nbsp;</div><div><br></div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This is an informational document intended to describe</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the problem to which the TRILL working group is addressed</div>


<div>
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; and the applicability of solutions. Document quality is</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; good.</div><div><br></div></div></div></div></div></div></div><br>
</div>

------=_Part_77904_18979459.1223525089290--


Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m992o697024849 for <[e-mail]>; Wed, 8 Oct 2008 19:50:07 -0700 (PDT)
Received: by wr-out-0506.google.com with SMTP id c37so2005779wra.25 for <[e-mail]>; Wed, 08 Oct 2008 19:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=4zNQWeRvdQJO4AznxPjSMFo/zPLUmme2eW6gUkWqJ6c=; b=PwFLSydc4jgc/5RkXVP0CqxnjNHc0b9+O0wmfg9NMdDrFZejDdWfaRLfIHRcrlZS92 0Uwxkc4iaG6zNsczpxqOo9cb0Gw8CRFGaaWGqTOzZ0TQZuvbJ1hsiQyKcR8N7ZU824Ds BLiOeLp44lWRVZih3jLwtFLaJR+spllGwXtW8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=T6FT7pPnxzpY3xfLxw7dRliPEho6J/Zzc04Q08RGC9qWADnndUrbjtSQ0nb1JYL7Ah 65yXVQ/sw4RfU+kfsiBVxTmuMSBtka9JBhrEhpCtG40gtYXVSbyjrzlspVn1vT/t0zlu MT6QZwleJXPNOcpzpkLILCyY6D9F9TYawcaoE=
Received: by 10.100.92.9 with SMTP id p9mr2959451anb.102.1223520605761; Wed, 08 Oct 2008 19:50:05 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Wed, 8 Oct 2008 19:50:05 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 8 Oct 2008 22:50:05 -0400
From: "Donald Eastlake" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_77012_9063289.1223520605733"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Base protocol working group last call early warning
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2008 02:50:43 -0000
Status: RO
Content-Length: 1044

------=_Part_77012_9063289.1223520605733
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]

------=_Part_77012_9063289.1223520605733
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi,<div><br></div><div>We plan to start a Working Group Last Call on the &quot;Rbridges: Base Protocol Specification&quot; draft&nbsp;early next week.</div><div><br>Thanks,</div><div>Donald and Erik<br>=============================<br>
 Donald E. Eastlake 3rd &nbsp; [phone] (home)<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:[e-mail]">[e-mail]</a><br>
</div></div>

------=_Part_77012_9063289.1223520605733--


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m97FaKsm019455 for <[e-mail]>; Tue, 7 Oct 2008 08:36:21 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m97FaKIX012519 for <[e-mail]>; Tue, 7 Oct 2008 15:36:20 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m97FaJYB042380 for <[e-mail]>; Tue, 7 Oct 2008 11:36:19 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m97F2Oqj028872; Tue, 7 Oct 2008 11:02:24 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m97F2C8J028865; Tue, 7 Oct 2008 11:02:12 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 7 Oct 2008 11:02:12 -0400
From: James Carlson <[e-mail]>
To: ravikumarb <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "[e-mail]" <[e-mail]>, "G.Venkatasubramaniyan" <[e-mail]>
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2008 15:36:48 -0000
Status: RO
Content-Length: 3021

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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from kecgate06.infosys.com (kecgate06.progeon.com [61.95.162.82]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m974lUPh002128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 21:47:35 -0700 (PDT)
X-TM-IMSS-Message-ID: <[e-mail]>
Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([61.95.162.82]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 0a06c63d0000fe3f ; Tue, 7 Oct 2008 10:17:17 +0530
Received: from BLRKECMBX03.ad.infosys.com ([10.66.236.23]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Tue, 7 Oct 2008 10:17:22 +0530
From: ravikumarb <[e-mail]>
To: Dinesh G Dutt <[e-mail]>, "G.Venkatasubramaniyan" <[e-mail]>
Date: Tue, 7 Oct 2008 10:17:17 +0530
Thread-Topic: [rbridge] Fwd:  In-order delivery not an issue?
Thread-Index: AckoA7fzselcvOrYSnWmbP0fGo3d0gAM1yrQ
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m974lUPh002128
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2008 04:47:51 -0000
Status: RO
Content-Length: 6198

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: [e-mail] [mailto:[e-mail]] On Behalf Of Dinesh G Dutt
Sent: Tuesday, October 07, 2008 4:01 AM
To: G.Venkatasubramaniyan
Cc: [e-mail]
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 <[e-mail]>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: [e-mail], Radia Perlman <[e-mail]>
> Cc: gvsm <[e-mail]>
>
>
>
> 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:[e-mail]]
> Sent: Monday, October 06, 2008 1:10 PM
> To: gvsm
> Cc: [e-mail]; 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
>> [e-mail]
>> 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
> [e-mail]
> 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
[e-mail]
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***



Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m970VvAq001197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 17:31:58 -0700 (PDT)
Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m970UoL7013261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Oct 2008 17:30:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 06 Oct 2008 17:30:50 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Dinesh G Dutt <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], "G.Venkatasubramaniyan" <[e-mail]>
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2008 00:32:15 -0000
Status: RO
Content-Length: 4639

-----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 <[e-mail]>
>> Date: Mon, Oct 6, 2008 at 7:21 PM
>> Subject: RE: [rbridge] In-order delivery not an issue?
>> To: [e-mail], Radia Perlman <[e-mail]>
>> Cc: gvsm <[e-mail]>
>>
>>
>>
>> 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:[e-mail]]
>> Sent: Monday, October 06, 2008 1:10 PM
>> To: gvsm
>> Cc: [e-mail]; 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
>>> [e-mail]
>>> 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
>> [e-mail]
>> 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-----


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96Me4tl017467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 15:40:05 -0700 (PDT)
Received: from [75.214.136.146] (146.sub-75-214-136.myvzw.com [75.214.136.146]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m96MdFhU007269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Oct 2008 15:39:18 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 06 Oct 2008 15:39:14 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Dinesh G Dutt <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], "G.Venkatasubramaniyan" <[e-mail]>
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 22:40:38 -0000
Status: RO
Content-Length: 4418

-----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 <[e-mail]>
>> Date: Mon, Oct 6, 2008 at 7:21 PM
>> Subject: RE: [rbridge] In-order delivery not an issue?
>> To: [e-mail], Radia Perlman <[e-mail]>
>> Cc: gvsm <[e-mail]>
>>
>>
>>
>> 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:[e-mail]]
>> Sent: Monday, October 06, 2008 1:10 PM
>> To: gvsm
>> Cc: [e-mail]; 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
>>> [e-mail]
>>> 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
>> [e-mail]
>> 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-----


Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96Lv1VT029721 for <[e-mail]>; Mon, 6 Oct 2008 14:57:01 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m96Lv0B6026011 for <[e-mail]>; Mon, 6 Oct 2008 21:57:00 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m96LuvmW017993 for <[e-mail]>; Mon, 6 Oct 2008 17:56:57 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m96LUWcJ026901; Mon, 6 Oct 2008 17:30:32 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m96LUUKO026898; Mon, 6 Oct 2008 17:30:30 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 6 Oct 2008 17:30:30 -0400
From: James Carlson <[e-mail]>
To: Caitlin Bestler <[e-mail]>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77046345E4@nekter>
References: <[e-mail]> <[e-mail]> <[e-mail]> <78C9135A3D2ECE4B8162EBDCE82CAD77046345E4@nekter>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], " G.Venkatasubramaniyan" <[e-mail]>
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 21:57:31 -0000
Status: RO
Content-Length: 795

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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96LX2fv016572 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 14:33:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,369,1220227200"; d="scan'208";a="106804240"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2008 21:32:54 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m96LWqtk029291;  Mon, 6 Oct 2008 14:32:52 -0700
Received: from [10.21.148.155] (sjc-vpn7-1179.cisco.com [10.21.148.155]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m96LWqR6011749; Mon, 6 Oct 2008 21:32:52 GMT
Message-ID: <[e-mail]>
Date: Mon, 06 Oct 2008 14:32:54 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: "G.Venkatasubramaniyan" <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4105; t=1223328772; x=1224192772; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Fwd=3A=20=20In-order=20deli very=20not=20an=20issue? |Sender:=20; bh=u+06ekc/BxTPk2+GmlijOmR2bL77wNEVfn/CFOwW1CA=; b=uKz/ID5C9itX5KdGRHfLFk1OSik9CwwXXuZjmCu/OZSWPp980FgF/tjG1d oPSuekJevjqGTiiS7t669C7b0E4dKiabNNk2YQa0IpAWK4Y8sElaPfeuNW/z JRLxOZ02YP;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 21:33:41 -0000
Status: RO
Content-Length: 3993

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 <[e-mail]>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: [e-mail], Radia Perlman <[e-mail]>
> Cc: gvsm <[e-mail]>
>
>
>
> 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:[e-mail]]
> Sent: Monday, October 06, 2008 1:10 PM
> To: gvsm
> Cc: [e-mail]; 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
>> [e-mail]
>> 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
> [e-mail]
> 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



Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96LUo7n015633 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 14:30:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,369,1220227200"; d="scan'208";a="169892594"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2008 21:30:50 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m96LUomf025727;  Mon, 6 Oct 2008 14:30:50 -0700
Received: from [10.21.148.155] (sjc-vpn7-1179.cisco.com [10.21.148.155]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m96LUo6f009701; Mon, 6 Oct 2008 21:30:50 GMT
Message-ID: <[e-mail]>
Date: Mon, 06 Oct 2008 14:30:51 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: "G.Venkatasubramaniyan" <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4410; t=1223328650; x=1224192650; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20Fwd=3A=20=20In-order=20deli very=20not=20an=20issue? |Sender:=20; bh=JPdbGFBUSJoGXi1xQp2ZJ5Hn1z1XATaGmBs1c6yEY0Y=; b=Tik9eR7nY8ol5if/t7E9FXbKPzOm5GSiRfmi7McLzKgMyhwcZaMo5auVdU gOMNF/W3mJAHqSKD80MYpJSxo+EnFrWiBa2ir9dvmrcu0NJ4Xm6390Ez8u8K zCcheZnIiV;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 21:31:18 -0000
Status: RO
Content-Length: 4291

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 <[e-mail]>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: [e-mail], Radia Perlman <[e-mail]>
> Cc: gvsm <[e-mail]>
>
>
>
> 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:[e-mail]]
> Sent: Monday, October 06, 2008 1:10 PM
> To: gvsm
> Cc: [e-mail]; 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
>> [e-mail]
>> 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
> [e-mail]
> 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



Received: from sernt4.essex.ac.uk (sernt4.essex.ac.uk [155.245.48.30]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96KuAYh023883 for <[e-mail]>; Mon, 6 Oct 2008 13:56:11 -0700 (PDT)
Received: from sernt14.essex.ac.uk ([155.245.42.34]) by sernt4.essex.ac.uk with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 6 Oct 2008 21:56:08 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 6 Oct 2008 21:54:02 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Fwd: In-order delivery not an issue?
Thread-Index: Ackn9OcHLo9XgowYSfK0VcW3KNmBKwAAMLgt
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Thomas, Matthew R" <[e-mail]>
To: "Donald Eastlake" <[e-mail]>, "G.Venkatasubramaniyan" <[e-mail]>
X-OriginalArrivalTime: 06 Oct 2008 20:56:08.0000 (UTC) FILETIME=[F48B2400:01C927F5]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m96KuAYh023883
Cc: [e-mail]
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 20:56:41 -0000
Status: RO
Content-Length: 3687

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: [e-mail] on behalf of Donald Eastlake
Sent: Mon 06/10/2008 20:32
To: G.Venkatasubramaniyan
Cc: [e-mail]
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?



See below

On Mon, Oct 6, 2008 at 12:59 PM, G.Venkatasubramaniyan
<[e-mail]> wrote:
>
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- Forwarded message ----------
> From: Venkatsubramaniyan G, TLS-Chennai <[e-mail]>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: [e-mail], Radia Perlman <[e-mail]>
> Cc: gvsm <[e-mail]>
>
>
>
> 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:[e-mail]]
> Sent: Monday, October 06, 2008 1:10 PM
> To: gvsm
> Cc: [e-mail]; 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   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]
_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge





Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96JWxE5010658 for <[e-mail]>; Mon, 6 Oct 2008 12:33:00 -0700 (PDT)
Received: by gxk14 with SMTP id 14so5290283gxk.21 for <[e-mail]>; Mon, 06 Oct 2008 12:32:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FgRBaFeycRoMSr5+GEynAl8XqoTDe5QdMTJVMNzc8jY=; b=WKoC4iXBa59lTP7x478V397W4vEhbk2lH5uTh4YlDmcXTLft9UxcKd4Ik+AGghPsbK yYhclClREHoCHSkesW1SnUUQTSXz1MxUQaOXy6dWIW/py1pDP1mIeSShSQshCSVcgC/b m0yVpeH9N+AEx7oS0nInqf/BxDmUtIu5/w18o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MrETsYi3ehHtpiIMQz8ijH8aOCQcv5PZRYRbo1ErLN+UCWKBvx6Gu3nOZJNUvIvQwK wGWRFTgcBVW6fop9cOvASq0kfmVCpseuYKOuVnn/ltE87f7DwreoYZlUOxLR6Nj+ufGH Ax46ZITo6W6F6OpZWjQ8pqQ1TI7u1Yp3cs0ag=
Received: by 10.100.249.10 with SMTP id w10mr5364380anh.156.1223321579414; Mon, 06 Oct 2008 12:32:59 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Mon, 6 Oct 2008 12:32:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 6 Oct 2008 15:32:59 -0400
From: "Donald Eastlake" <[e-mail]>
To: "G.Venkatasubramaniyan" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Fwd: In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 19:33:34 -0000
Status: RO
Content-Length: 3094

See below

On Mon, Oct 6, 2008 at 12:59 PM, G.Venkatasubramaniyan
<[e-mail]> wrote:
>
> resending my previous mail ...
> Thanks,
> venkatg
> ---------- Forwarded message ----------
> From: Venkatsubramaniyan G, TLS-Chennai <[e-mail]>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: [e-mail], Radia Perlman <[e-mail]>
> Cc: gvsm <[e-mail]>
>
>
>
> 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:[e-mail]]
> Sent: Monday, October 06, 2008 1:10 PM
> To: gvsm
> Cc: [e-mail]; 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   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]


Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96JB5dk027917 for <[e-mail]>; Mon, 6 Oct 2008 12:11:06 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Oct 2008 15:11:04 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77046345E4@nekter>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Fwd:  In-order delivery not an issue?
Thread-Index: Ackn3k9jwZ/SCm0hQ9SzPUXRBB6VbgACC40w
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: " G.Venkatasubramaniyan" <[e-mail]>, <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m96JB5dk027917
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 19:11:24 -0000
Status: RO
Content-Length: 1789

> From: Venkatsubramaniyan G, TLS-Chennai <[e-mail]>
> Date: Mon, Oct 6, 2008 at 7:21 PM
> Subject: RE: [rbridge] In-order delivery not an issue?
> To: [e-mail], Radia Perlman <[e-mail]>
> Cc: gvsm <[e-mail]>
> 
> 
> 
> 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.




Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96IwrkC019797 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 11:58:54 -0700 (PDT)
Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m96Iwkfo006727 for <[e-mail]>; Mon, 6 Oct 2008 18:58:52 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m96Iwbk9012267 for <[e-mail]>; Mon, 6 Oct 2008 14:58:37 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m96IdoAO025667; Mon, 6 Oct 2008 14:39:50 -0400 (EDT)
Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m96IdnQ4025664; Mon, 6 Oct 2008 14:39:49 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 6 Oct 2008 14:39:49 -0400
From: James Carlson <[e-mail]>
To: " G.Venkatasubramaniyan" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 19:00:47 -0000
Status: RO
Content-Length: 2736

 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              <[e-mail]>
Sun Microsystems / 35 Network Drive        71.232W   Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax [phone]


Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96HeECT006201 for <[e-mail]>; Mon, 6 Oct 2008 10:40:15 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Oct 2008 13:40:07 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7704634577@nekter>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] In-order delivery not an issue? (resending with my correct addr)
Thread-Index: AcknxaWDhGABKWKqTbG+uuM2OhuIagAFB9iA
References: <[e-mail]><[e-mail]> <[e-mail]>
From: "Caitlin Bestler" <[e-mail]>
To: <[e-mail]>, "Radia Perlman" <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m96HeECT006201
Cc: [e-mail], [e-mail], gvsm <[e-mail]>
Subject: Re: [rbridge] In-order delivery not an issue? (resending with my correct addr)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 17:40:53 -0000
Status: RO
Content-Length: 1273

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Dinesh G Dutt
> Sent: Monday, October 06, 2008 7:34 AM
> To: Radia Perlman
> Cc: [e-mail]; [e-mail]; 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.




Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96Gxn7Y016253 for <[e-mail]>; Mon, 6 Oct 2008 09:59:50 -0700 (PDT)
Received: by rn-out-0910.google.com with SMTP id k57so840664rnd.13 for <[e-mail]>; Mon, 06 Oct 2008 09:59:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=41vgYWaw9IXFB8tHyBz4/q2hxCwHrydAl61PcayckEM=; b=IXj9ooP4h6NTMrqZfsCFUj5iuwmtMOIDKGUEW+kjF+SCy+YLoUR9SuNJKyXPfsEMcX P0Tq5GxdUE+EmJKv2ODihrJxiWZbanV4z0faGw3c1+ymVblMxYddjkREERHtuffaAzzl 67JZgs0IceHpJWATVfDjJqOKNu8F5eL7aHC/c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=IJmMW1QNmea7AdguDuNR/zWMP807kVi0QVTJzGxUJKQtoGYcLoUSCkSeLljyWPHQrc i7PmY34F/GPCqthTOaIG9hRoxe75fOJZsPIvwXbil4CNXfmqIOAtm4Z0wf3kBTz567J2 9Mh4jjlXxSfQYkCDKJi75vkBXOsb8wFQYrXyE=
Received: by 10.143.41.5 with SMTP id t5mr2095766wfj.216.1223312388133; Mon, 06 Oct 2008 09:59:48 -0700 (PDT)
Received: by 10.142.225.6 with HTTP; Mon, 6 Oct 2008 09:59:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 6 Oct 2008 22:29:48 +0530
From: " G.Venkatasubramaniyan" <[e-mail]>
Sender: [e-mail]
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
X-Google-Sender-Auth: a37861663e3444c9
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Fwd:  In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 17:00:47 -0000
Status: RO
Content-Length: 3248

resending my previous mail ...
Thanks,
venkatg
---------- Forwarded message ----------
From: Venkatsubramaniyan G, TLS-Chennai <[e-mail]>
Date: Mon, Oct 6, 2008 at 7:21 PM
Subject: RE: [rbridge] In-order delivery not an issue?
To: [e-mail], Radia Perlman <[e-mail]>
Cc: gvsm <[e-mail]>



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:[e-mail]]
Sent: Monday, October 06, 2008 1:10 PM
To: gvsm
Cc: [e-mail]; 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
> [e-mail]
> 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.

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


Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96Eh7JR012738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 07:43:07 -0700 (PDT)
Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m96Efvbe004031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Oct 2008 07:41:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 06 Oct 2008 07:41:57 -0700
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail], gvsm <[e-mail]>
Subject: Re: [rbridge] In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 14:43:23 -0000
Status: RO
Content-Length: 1348

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


Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m96EXoPZ007686 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Mon, 6 Oct 2008 07:33:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,368,1220227200"; d="scan'208";a="169628127"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2008 14:33:50 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m96EXofF031424;  Mon, 6 Oct 2008 07:33:50 -0700
Received: from [10.21.66.12] (sjc-vpn3-524.cisco.com [10.21.66.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m96EXoUO009896; Mon, 6 Oct 2008 14:33:50 GMT
Message-ID: <[e-mail]>
Date: Mon, 06 Oct 2008 07:33:50 -0700
From: Dinesh G Dutt <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Radia Perlman <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1806; t=1223303630; x=1224167630; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Dinesh=20G=20Dutt=20<[e-mail]> |Subject:=20Re=3A=20[rbridge]=20In-order=20delivery=20not=2 0an=20issue?=20(resending=20with=20my=0A=20correct=20addr) |Sender:=20; bh=LTjNWA1fI6xABCAGxYiFtRb3Ruh3kUaE0FBxysY8KBo=; b=MEaVHibkCv75VE3OH3c7mzRXBDBOSXaYFMbEAtgEM9N/U8Z8gPcrGqBdwT D3uFZRzFTsPbAxsCwtAcWHoxoWqFoisCLoZ5lPl8uczZiRlGVsY+P3HC6+hn 5fxr8sc1qa;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail], gvsm <[e-mail]>
Subject: Re: [rbridge] In-order delivery not an issue? (resending with my correct addr)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: [e-mail]
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 14:34:27 -0000
Status: RO
Content-Length: 1756

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



Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m967dWoE027732 for <[e-mail]>; Mon, 6 Oct 2008 00:39:33 -0700 (PDT)
Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 06 Oct 2008 00:39:30 -0700 (PDT)
Received: from [192.168.1.100] ([24.16.68.114]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 06 Oct 2008 00:39:28 -0700 (PDT)
Date: Mon, 06 Oct 2008 00:39:30 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: gvsm <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: [rbridge] In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2008 07:40:05 -0000
Status: RO
Content-Length: 809

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
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m94JMDYI022553 for <[e-mail]>; Sat, 4 Oct 2008 12:22:14 -0700 (PDT)
Received: by gxk14 with SMTP id 14so3629444gxk.21 for <[e-mail]>; Sat, 04 Oct 2008 12:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=1iebkxLeep8J/EUGyzwPq0DxRWhg9QjVEKv+uO8f8WA=; b=boNZUBtec40QZbcsf64R/oooe4+EgZQ41yKXic43pQ2uZij4NRZHef2cBhyF2yv/jw 9HkJhne58TcqLXP6A34ap2BMM2CobppWzjr9jM2HlLvuVn97YtdJN/KSTDzpkKGERMx7 yb640hAuhvgsuC6RlOQyALuorZCI9CryR2zu4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=cwGtbp2izxdWjTwtVb5AkbUMl5M2/+OcUwhMWGBZBCBWSw0C/S5pzapck+GqijGM+4 ma15TR8VwRS2CfJGhCc9bc1RHlLjGpLWK9V4y6huUK+aGQsRxG3DO0vrLIcSQYCT8g3A kLghZXCdn5dnOa6nISrz3/7JmXV4PnCTw4xmw=
Received: by 10.100.214.19 with SMTP id m19mr3219811ang.1.1223148133378; Sat, 04 Oct 2008 12:22:13 -0700 (PDT)
Received: by 10.100.214.7 with HTTP; Sat, 4 Oct 2008 12:22:13 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 4 Oct 2008 15:22:13 -0400
From: "Donald Eastlake" <[e-mail]>
To: "Kris Price" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_21589_29465622.1223148133389"
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] Questions - VLANs & MPLS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Oct 2008 19:23:00 -0000
Status: RO
Content-Length: 6204

------=_Part_21589_29465622.1223148133389
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

See below...

On Sat, Oct 4, 2008 at 9:25 AM, Kris Price <[e-mail]> 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   [phone] (home)
155 Beaver Street
Milford, MA 01757 USA
[e-mail]

------=_Part_21589_29465622.1223148133389
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">See below...<br><br><div class="gmail_quote">On Sat, Oct 4, 2008 at 9:25 AM, Kris Price <span dir="ltr">&lt;<a href="mailto:[e-mail]" target="_blank">[e-mail]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>James Carlson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dinesh G Dutt writes:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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&#39;s congestion management, support troubleshooting tools such as traceroute and ping within an TRILL cloud etc.<br>


</blockquote>
<br>
I think a more important reason for it is that you can&#39;t do MAC<br>
address learning of decapsulated packets unless you know where (what<br>
encapsulator) they came from.<br>
</blockquote>
<br></div>
I wondered about that, but I didn&#39;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. (?)</blockquote><div><br>

</div><div>Yes, that was the original intention. Someone from a routing background would find that way of doing things to be natural.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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&#39;t have to maintain information in their FIBs that they&#39;re not using.<br>

</blockquote><div><br></div><div>Yes, those from a bridging background think that learning in the data plane is much more natural, doesn&#39;t overburden the control plane, etc.</div><div><br></div><div>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&#39;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 <a href="http://4.2.4."><font color="red"><b>MailScanner has detected a possible fraud attempt from "4.2.4." claiming to be</b></font> 4.2.4.</a></div>

<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess it was a contentious issue whether learning should&#39;ve all been via a routing protocol, or via learning. Had the former been favoured, MPLS label switched paths would&#39;ve been a feasible forwarding method.<br>


<br>
Makes sense now, thanks for your answers :)<br>
<br>
Cheers<br><font color="#888888">
Kris<br>
</font></blockquote></div><br>Indeed, this was contentious for a while.<div><br></div><div>Thanks,<br clear="all">Donald<br>-- <br>=============================<br> Donald E. Eastlake 3rd &nbsp; [phone] (home)<br> 155 Beaver Street<br>
 Milford, MA 01757 USA<br> <a href="mailto:[e-mail]" target="_blank">[e-mail]</a><br>

</div></div>

------=_Part_21589_29465622.1223148133389--


Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m94DPmgh019101 for <[e-mail]>; Sat, 4 Oct 2008 06:25:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvcAAKsJ50h5LOXB/2dsb2JhbAAIuVqBaA
X-IronPort-AV: E=Sophos;i="4.33,360,1220193000"; d="scan'208";a="221772886"
Received: from ppp121-44-229-193.lns1.per1.internode.on.net (HELO [10.1.1.2]) ([121.44.229.193]) by ipmail05.adl2.internode.on.net with ESMTP; 04 Oct 2008 22:55:46 +0930
Message-ID: <[e-mail]>
Date: Sat, 04 Oct 2008 21:25:50 +0800
From: Kris Price <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: James Carlson <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Donald Eastlake <[e-mail]>, [e-mail]
Subject: Re: [rbridge] Questions - VLANs & MPLS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 04 Oct 2008 13:26:04 -0000
Status: RO
Content-Length: 1330

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


Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m93Nwrei024648 for <[e-mail]>; Fri, 3 Oct 2008 16:58:54 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1743600rvf.45 for <[e-mail]>; Fri, 03 Oct 2008 16:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=d2aA3xh715N+2nO7RmVvAIDlkGWpgRWHs0V42M6vszc=; b=bUVpkdZo7b05ZUdDJdNBC+RLoqiTlLkWC4HKVbh6jGiFxV+MA74UkwrOab/OKMSFGl sfSsERqwafASJuzQnFAleiOfAjmemgkM27yIG0Lop2gnWQm3u+CRl5w2hlRIdkYKppO0 2b00ZIjGxs5Jv3sQ8dTbNgPATF3NO6GGwmTQo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=I9G1HANrhIY7crn4rPM1BkcSVom2d6NFAWOXVjhH6YKhmHUL68KL+DxClUh7VbRQzs q0km0xaYPEAb9BhXVgJ20mgaxSm1YIWT8JmBY5CL29LwvdTqE9ODLJ2A36U5xgxBDiUX yC0W3kql0AsC4Gfg7893TKQtsp2gOvBRLjZXU=
Received: by 10.142.237.20 with SMTP id k20mr596710wfh.146.1223078332976; Fri, 03 Oct 2008 16:58:52 -0700 (PDT)
Received: by 10.142.225.6 with HTTP; Fri, 3 Oct 2008 16:58:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 4 Oct 2008 05:28:52 +0530
From: gvsm <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] In-order delivery not an issue?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2008 23:59:10 -0000
Status: RO
Content-Length: 218

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


Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m91KkS1c021148 for <[e-mail]>; Wed, 1 Oct 2008 13:46:29 -0700 (PDT)
Received: by core3.amsl.com (Postfix, from userid 0) id ECA013A6C57; Wed,  1 Oct 2008 13:45:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  1 Oct 2008 13:45:02 -0700 (PDT)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-09.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Oct 2008 20:46:53 -0000
Status: RO
Content-Length: 1916

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman
	Filename	: draft-ietf-trill-rbridge-protocol-09.txt
	Pages		: 84
	Date		: 2008-10-1
	
RBridges provide optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and support for multipathing of both unicast and multicast
   traffic. They achieve these goals using IS-IS routing and
   encapsulation of traffic with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 customer bridges as
   well as IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs and optimization of the distribution of
   multi-destination frames based on VLAN and IP derived multicast
   groups.  It also allows forwarding tables to be based on RBridge
   destinations (rather than end node destinations), which allows
   internal forwarding tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-09.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-trill-rbridge-protocol-09.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--