From d3e3e3 at gmail.com  Sun Dec  5 18:28:41 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Sun, 5 Dec 2010 21:28:41 -0500
Subject: [rbridge] TRILL Options draft, proposed changes
Message-ID: <AANLkTikvZ_Ns0SCDF8uTdcxpOtW2zXVgiX77cE+=4jZy@mail.gmail.com>

Hi,

Some changes to the TRILL Options draft
(draft-ietf-trill-rbridge-options) were presented at the Beijing
meeting:
http://www.ietf.org/proceedings/79/slides/trill-4/trill-4.htm

There were some questions about these changes, but no objections, at
the meeting. I plan to go ahead and make these changes with two
additions: (1) further update the ECN option to correspond to the just
published RFC 6040 and (2) instead of having a "Flow ID valid" bit,
have a non-zero Flow ID field indicate it has a valid value.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?d3e3e3 at gmail.com


From vishwas.ietf at gmail.com  Sun Dec  5 18:48:14 2010
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Sun, 5 Dec 2010 18:48:14 -0800
Subject: [rbridge] TRILL Options draft, proposed changes
In-Reply-To: <AANLkTikvZ_Ns0SCDF8uTdcxpOtW2zXVgiX77cE+=4jZy@mail.gmail.com>
References: <AANLkTikvZ_Ns0SCDF8uTdcxpOtW2zXVgiX77cE+=4jZy@mail.gmail.com>
Message-ID: <AANLkTi=P0oQom-vbyUmFHGZ0Sn-hZV10k0iSoaxk+3ri@mail.gmail.com>

Hi Donald,

Please do.

Thanks,
Vishwas

On Sun, Dec 5, 2010 at 6:28 PM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> Hi,
>
> Some changes to the TRILL Options draft
> (draft-ietf-trill-rbridge-options) were presented at the Beijing
> meeting:
> http://www.ietf.org/proceedings/79/slides/trill-4/trill-4.htm
>
> There were some questions about these changes, but no objections, at
> the meeting. I plan to go ahead and make these changes with two
> additions: (1) further update the ECN option to correspond to the just
> published RFC 6040 and (2) instead of having a "Flow ID valid" bit,
> have a non-zero Flow ID field indicate it has a valid value.
>
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?d3e3e3 at gmail.com
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


From nordmark at acm.org  Tue Dec  7 10:32:23 2010
From: nordmark at acm.org (Erik Nordmark)
Date: Tue, 07 Dec 2010 10:32:23 -0800
Subject: [rbridge] Change of email address
Message-ID: <4CFE7DB7.5010002@acm.org>


The IETF web pages have been updated to point at
	nordmark at acm dot org

My sun.com and oracle.com email addresses will stop working at the end 
of this week.

   Erik


From stbryant at cisco.com  Mon Dec 13 02:16:45 2010
From: stbryant at cisco.com (Stewart Bryant)
Date: Mon, 13 Dec 2010 10:16:45 +0000
Subject: [rbridge] Fwd: Re: [Isis-wg] Last Call: draft-ietf-isis-layer2
 (Extensions to	IS-ISfor Layer-2	Systems) to Proposed Standard
Message-ID: <4D05F28D.3050309@cisco.com>


Copying the Trill WG and doc authors.

- Stewart


-------- Original Message --------
Subject: 	Re: [Isis-wg] Last Call: draft-ietf-isis-layer2 (Extensions to 
IS-ISfor Layer-2 Systems) to Proposed Standard
Date: 	Sun, 12 Dec 2010 08:21:06 -0800
From: 	Les Ginsberg (ginsberg) <ginsberg at cisco.com>
To: 	The IESG <iesg-secretary at ietf.org>, IETF-Announce 
<ietf-announce at ietf.org>
CC: 	isis-wg at ietf.org



There is a conflict between the suggested value of 141 (Section 2.1.
The MAC-Reachability TLV) and the already assigned value in the IS-IS
TLV codepoints registry:

http://www.iana.org/assignments/isis-tlv-codepoints/

141       inter-AS reachability information       n    y    n
[RFC5316]

While this conflict will no doubt get sorted out by IANA when they make
the official assignment, it is likely to be of interest to early
implementors of all the L2 IS-IS technologies who likely are using the
conflicting value (141).

    Les

>  -----Original Message-----
>  From: isis-wg-bounces at ietf.org [mailto:isis-wg-bounces at ietf.org] On
>  Behalf Of The IESG
>  Sent: Monday, November 29, 2010 9:11 AM
>  To: IETF-Announce
>  Cc: isis-wg at ietf.org
>  Subject: [Isis-wg] Last Call: draft-ietf-isis-layer2 (Extensions to
IS-
>  ISfor Layer-2 Systems) to Proposed Standard
>
>  The IESG has received a request from the IS-IS for IP Internets WG
>  (isis)
>  to consider the following document:
>
>  - 'Extensions to IS-IS for Layer-2 Systems '
>     <draft-ietf-isis-layer2-08.txt>  as a Proposed Standard
>
>  The IESG plans to make a decision in the next few weeks, and solicits
>  final comments on this action.  Please send substantive comments to
the
>  ietf at ietf.org mailing lists by 2010-12-14. Exceptionally,
>  comments may be sent to iesg at ietf.org instead. In either case, please
>  retain the beginning of the Subject line to allow automated sorting.
>
>  The file can be obtained via
>  http://www.ietf.org/internet-drafts/draft-ietf-isis-layer2-08.txt
>
>
>  IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>  =18360&rfc_flag=0
>
>  No IPR declarations have been submitted directly on this I-D.
>  _______________________________________________
>  Isis-wg mailing list
>  Isis-wg at ietf.org
>  https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20101213/0aa08a82/attachment.html

From d3e3e3 at gmail.com  Tue Dec 14 13:49:49 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 14 Dec 2010 16:49:49 -0500
Subject: [rbridge] My Affiliation
In-Reply-To: <AANLkTimI5SWG0i0sCtK194o6ovS3gV5LjZL9vsloaMre@mail.gmail.com>
References: <1028365c0909110626t352a189eh6591114fe6ca5e1e@mail.gmail.com>
	<AANLkTimI5SWG0i0sCtK194o6ovS3gV5LjZL9vsloaMre@mail.gmail.com>
Message-ID: <AANLkTikwYEK1MD6-RgskmK-iCzyUd+Jy2kBpPa2_78pn@mail.gmail.com>

As a further update on my affiliation, I am now a Huawei employee.

Thanks,
Donald (Co-Chair)

From nordmark at acm.org  Wed Dec 15 08:29:56 2010
From: nordmark at acm.org (Erik Nordmark)
Date: Wed, 15 Dec 2010 08:29:56 -0800
Subject: [rbridge] Request for review of draft-ietf-trill-rbridge-mib-01.txt
Message-ID: <4D08ED04.2050503@acm.org>


In Beijing there were not that many that had read the MIB document.
Bill Fenner volunteered to read it and send comments, but it would be 
good to get some other reviewers.

Any additional volunteers?

Particular things to look at is whether there are other traps that would 
be useful for an operator.

    Erik



From Internet-Drafts at ietf.org  Thu Dec 16 00:45:01 2010
From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org)
Date: Thu, 16 Dec 2010 00:45:01 -0800
Subject: [rbridge] I-D Action:draft-ietf-trill-adj-00.txt
Message-ID: <20101216084501.29187.13070.idtracker@localhost>



From d3e3e3 at gmail.com  Mon Dec 27 19:26:12 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 27 Dec 2010 22:26:12 -0500
Subject: [rbridge] Request for review of
	draft-ietf-trill-rbridge-mib-01.txt
In-Reply-To: <4D08ED04.2050503@acm.org>
References: <4D08ED04.2050503@acm.org>
Message-ID: <AANLkTinR4jaqvEaFDnPYKS38H1zPMba17aN8fQbmTtr3@mail.gmail.com>

Hi,

It would be helpful if people would review the MIB document. Here is a
comment of mine:

I think that Sz, the campus wide minimum MTU that an RBridge has
calculated, should be a read-only per-RBridge MIB object and that it
should be possible for a change in Sz to cause a notification.

Thanks,
Donald

On Wed, Dec 15, 2010 at 11:29 AM, Erik Nordmark <nordmark at acm.org> wrote:
>
> In Beijing there were not that many that had read the MIB document.
> Bill Fenner volunteered to read it and send comments, but it would be good
> to get some other reviewers.
>
> Any additional volunteers?
>
> Particular things to look at is whether there are other traps that would be
> useful for an operator.
>
> ? Erik
>
>
>


From d3e3e3 at gmail.com  Wed Dec 29 13:56:16 2010
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 29 Dec 2010 16:56:16 -0500
Subject: [rbridge] Improvements to draft-ietf-trill-adj
Message-ID: <AANLkTin4nzJ75yp5Gpzq44f=oKCHDmFABhM3qZd1qZ8t@mail.gmail.com>

Hi,

Looking over draft-ietf-trill-adj-00, I'd like to make the following changes:

(1) In references to Hello holding timers, remove all occurrences of
"decrement" and re-word so as to use "expiration". This will make the
wording more closer to that in other specifications that refer to the
holding time running out.

(2) Event 4 in Section 3.3 is a bit ambiguous. It currently says:

   4. Decrement of Hello holding timers changes them so both are zero

which can be interpreted to mean that both holding timers associated
with an adjacency have to expire at the same time. I propose
re-wording it as

  4. The expiration of one or both Hello holding timers results in
them both being expired.

(3) The current abstract is just one short sentence and does not give
much context. I propose changing it to the two paragraphs posted at
the end of this message.

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


Proposed Abstract for draft-ietf-trill-adj:

  The IETF TRILL protocol provides optimal pair-wise data forwarding
  without configuration, safe forwarding even during periods of
  temporary loops, and support for multipathing of both unicast and
  multicast traffic. TRILL accomplishes this by using IS-IS link
  state routing and by encapsulating traffic using a header that
  includes a hop count. Devices that implement TRILL are called
  RBridges.

  TRILL supports multi-access LAN links that can have multiple end
  stations and RBridges attached. This document describes the TRILL
  LAN Hello protocol used on such links as regards adjacency,
  designated RBridge selection, and MTU procedures, with state
  machines. TRILL requires no changes to adjacency state machinery for
  IS-IS point-to-point Hellos, which are used on links configured as
  point-to-point.


From radiaperlman at gmail.com  Wed Dec 29 14:35:20 2010
From: radiaperlman at gmail.com (Radia Perlman)
Date: Wed, 29 Dec 2010 14:35:20 -0800
Subject: [rbridge] Improvements to draft-ietf-trill-adj
In-Reply-To: <AANLkTin4nzJ75yp5Gpzq44f=oKCHDmFABhM3qZd1qZ8t@mail.gmail.com>
References: <AANLkTin4nzJ75yp5Gpzq44f=oKCHDmFABhM3qZd1qZ8t@mail.gmail.com>
Message-ID: <AANLkTikS3m3iubtGVwdaMVJwDn+uUjspqZ1zq2MTrHD7@mail.gmail.com>

Fine with me.

Radia




On Wed, Dec 29, 2010 at 1:56 PM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> Hi,
>
> Looking over draft-ietf-trill-adj-00, I'd like to make the following changes:
>
> (1) In references to Hello holding timers, remove all occurrences of
> "decrement" and re-word so as to use "expiration". This will make the
> wording more closer to that in other specifications that refer to the
> holding time running out.
>
> (2) Event 4 in Section 3.3 is a bit ambiguous. It currently says:
>
> ? 4. Decrement of Hello holding timers changes them so both are zero
>
> which can be interpreted to mean that both holding timers associated
> with an adjacency have to expire at the same time. I propose
> re-wording it as
>
> ?4. The expiration of one or both Hello holding timers results in
> them both being expired.
>
> (3) The current abstract is just one short sentence and does not give
> much context. I propose changing it to the two paragraphs posted at
> the end of this message.
>
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?155 Beaver Street
> ?Milford, MA 01757 USA?? +1-508-634-2066 (home)
> ?d3e3e3 at gmail.com
>
>
> Proposed Abstract for draft-ietf-trill-adj:
>
> ?The IETF TRILL protocol provides optimal pair-wise data forwarding
> ?without configuration, safe forwarding even during periods of
> ?temporary loops, and support for multipathing of both unicast and
> ?multicast traffic. TRILL accomplishes this by using IS-IS link
> ?state routing and by encapsulating traffic using a header that
> ?includes a hop count. Devices that implement TRILL are called
> ?RBridges.
>
> ?TRILL supports multi-access LAN links that can have multiple end
> ?stations and RBridges attached. This document describes the TRILL
> ?LAN Hello protocol used on such links as regards adjacency,
> ?designated RBridge selection, and MTU procedures, with state
> ?machines. TRILL requires no changes to adjacency state machinery for
> ?IS-IS point-to-point Hellos, which are used on links configured as
> ?point-to-point.
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>