Skip to main content

Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
RFC 7178

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from trill-chairs@ietf.org, draft-ietf-trill-rbridge-channel@ietf.org to (None)
2014-05-12
08 (System) IANA registries were updated to include RFC7178
2014-05-07
08 (System) RFC published
2014-05-07
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-04-14
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-04-07
08 (System) RFC Editor state changed to RFC-EDITOR from REF
2014-03-21
08 (System) RFC Editor state changed to REF from EDIT
2014-02-03
08 (System) RFC Editor state changed to EDIT from MISSREF
2012-10-01
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-10-01
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-10-01
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-10-01
08 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-09-29
08 (System) IANA Action state changed to In Progress
2012-09-29
08 Cindy Morgan State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2012-09-29
08 Cindy Morgan IESG has approved the document
2012-09-29
08 Cindy Morgan Closed "Approve" ballot
2012-09-29
08 Cindy Morgan Ballot approval text was generated
2012-09-29
08 Cindy Morgan Ballot writeup was changed
2012-08-14
08 Stewart Bryant [Ballot comment]
Thank your for addressing my concerns.
2012-08-14
08 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2012-07-14
08 Donald Eastlake New version available: draft-ietf-trill-rbridge-channel-08.txt
2012-07-09
07 Stephen Farrell
[Ballot comment]

"No protection is provided against forging of the ingress nickname
in a TRILL Data formatted channel message or the Outer.MacSA in a
native …
[Ballot comment]

"No protection is provided against forging of the ingress nickname
in a TRILL Data formatted channel message or the Outer.MacSA in a
native RBridge Channel frame. This may result in misdirected return
responses or error messages." Can you explain why this is ok? (Not
sure if some text change might follow or not.)
2012-07-09
07 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2012-06-27
07 Barry Leiba [Ballot comment]
Thanks for the IANA Considerations changes.  I'm fine with -07.
2012-06-27
07 Barry Leiba Ballot comment text updated for Barry Leiba
2012-06-27
07 Barry Leiba [Ballot comment]
Thanks for the IANA Considerations changes.
2012-06-27
07 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-06-27
07 Stephen Farrell
[Ballot discuss]


"No protection is provided against forging of the ingress nickname
in a TRILL Data formatted channel message or the Outer.MacSA in a
native …
[Ballot discuss]


"No protection is provided against forging of the ingress nickname
in a TRILL Data formatted channel message or the Outer.MacSA in a
native RBridge Channel frame. This may result in misdirected return
responses or error messages." Can you explain why this is ok? (Not
sure if some text change might follow or not.)
2012-06-27
07 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2012-06-27
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-06-27
07 Donald Eastlake New version available: draft-ietf-trill-rbridge-channel-07.txt
2012-06-21
06 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2012-06-21
06 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-06-21
06 Adrian Farrel
[Ballot comment]
I don't think my Comments warrant a Discuss, although I personally "would not have done it like this".

---

There is an assumption …
[Ballot comment]
I don't think my Comments warrant a Discuss, although I personally "would not have done it like this".

---

There is an assumption here that bridge alert (just like router alert)
is an acceptable function. I am not convinced and I note RFC 6398 that
seems to suggest that router alert is not a good idea in general,
although not catastrophic in certain deployments that might be similar
to early Trill deployments.

But I worry that if the popularity of Trill grows, the bridge alert
function will cause many of the same problems it caused in IP networks.

It is worth noting that MPLS (and you do draw the comparison with G-ACh)
has a router alert label, but this is not used on the G-ACh.

At the very least, the use of bridge alert causes packets to be thrown
out of the normal forwarding path at each bridge along the path. This
means that packets are not treated the same way as data packets and so
some of the properties of OAM are lost. (Note that if you want to send
an OAM packet to a transit bridge, you will use bridge alert and all
other transit bridges along the path up to the intended target will need
to inspect the packet.)

---

Section 3.2

What is the meaning of
    0    - Not an RBridge Channel error frame.
I didn't finf itdiscussed in the text.

Why is
  15    Reserved
And what does "reserved" mean? IANA will need to know whether it means
"never to be allocated".

---

Why are Channel protocol numbers 0 and xFFF reserved? (And you will need
to clarify to IANA that you mean "reserved and not to be allocated".)

---

I wasn't clear about the Security aspects. I understand that if a
payload protocol needs protection, it is responsible for this itself.
However, is there any way to protext the content of the channel header?
What would be the consequence of someone tweaking the SL bit?

Since Trill (and Ethernet) are routed sysetms (unlike MPLS) attacks
from outside seem feasible. While you might protect the payload
protocols through their own mechanisms, how do you protect the bridges
themselves from attacks? The rbridge channel and the bridge alert flag
see like vectors for DoS.

Rate limiting as described in 2.4 provides some mitigation. Maybe you
should reference this in the security section.
2012-06-21
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-06-21
06 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-06-21
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-06-20
06 Ralph Droms State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-06-20
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-06-20
06 Stewart Bryant
[Ballot discuss]

Section 2.4 Special Transmission and Rate Considerations says:

  RBridge Channel messages represent a burden on the RBridges and links
  in a …
[Ballot discuss]

Section 2.4 Special Transmission and Rate Considerations says:

  RBridge Channel messages represent a burden on the RBridges and links
  in a campus and should be rate limited, especially if they are sent
  as high priority, multi-destination, or multi-hop frames or have an
  RBridge Channel Alert extended header flag set.

In the IANA section you have provision for private use and no standards track
channels, but you provide no guidance on how implementers and reviewers
ensure that they avoid the concern called up in section 2.4

I am not sure why the multi value restrictions are in place, and the way that
it is worded invites work arounds

(2) RBridge Channel protocol code points from 0x100 to 0xFF7 require
  RFC Publication to allocate a single value or IETF Review to allocate
  multiple values.

If the goal is to prevent a run on the registry, it would be simpler to
make the range smaller and update the RFC if we look like we are
goingto run out.
2012-06-20
06 Stewart Bryant
[Ballot comment]
  It is anticipated that various protocols operating at the TRILL level
  will be desired in RBridge campuses.

SB> I am not …
[Ballot comment]
  It is anticipated that various protocols operating at the TRILL level
  will be desired in RBridge campuses.

SB> I am not sure what it means to "Operate at the TRILL level"
2012-06-20
06 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant
2012-06-20
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-06-20
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-06-19
06 Sean Turner [Ballot comment]
I support Stephen's discuss positions.
2012-06-19
06 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-06-19
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-06-19
06 Miguel García Request for Last Call review by GENART Completed. Reviewer: Miguel Garcia.
2012-06-19
06 Stephen Farrell
[Ballot discuss]

(1) I think that section 7 needs a 2119 MUST in the 2nd paragraph,
that is, I reckon it ought say: "If these …
[Ballot discuss]

(1) I think that section 7 needs a 2119 MUST in the 2nd paragraph,
that is, I reckon it ought say: "If these services are required for a
particular RBridge Channel protocol, they MUST be supplied by that
channel protocol." I'd not like to see someone come along and say that
its ok that they don't do security because this doesn't.

(2) "No protection is provided against forging of the ingress nickname
in a TRILL Data formatted channel message or the Outer.MacSA in a
native RBridge Channel frame. This may result in misdirected return
responses or error messages." Can you explain why this is ok? (Not
sure if some text change might follow or not.)

(3) Is this supposed to allow or prevent end-stations talking to one
another? (Rather than to RBridges.) I think that ought be clarified,
and if its not supposed to happen, then what prevents/detects it? That
last might need a bit of text.
2012-06-19
06 Stephen Farrell
[Ballot comment]

- 1.2, "Inner.MacDA and inner Ethertype" could maybe do with
references/forward-pointers.

- Section 2 - the figure mapping the message and document structure …
[Ballot comment]

- 1.2, "Inner.MacDA and inner Ethertype" could maybe do with
references/forward-pointers.

- Section 2 - the figure mapping the message and document structure
is great - thanks!

- Be better to give the figures/diagrams names, numbers and captions.
(If editing tools don't make that a pain.) In particular, referring to
"the figure above" from 2.1.1 back to the previous sections isn't
great.

- List of error conditions on p11 - I wondered why aren't there any
security conditions?
2012-06-19
06 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2012-06-19
06 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2012-06-18
06 Pearl Liang
IANA has reviewed draft-ietf-trill-rbridge-channel-06 and has the following comments:

IANA understands that upon approval of this document, there are five IANA
actions which must be …
IANA has reviewed draft-ietf-trill-rbridge-channel-06 and has the following comments:

IANA understands that upon approval of this document, there are five IANA
actions which must be completed.

First, in the TRILL Nicknames subregistry of the Transparent Interconnection of
Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

a new TRILL nickname will be registered as follows:

Name: [ TBD ]
Description: Any-RBridge
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 0xFFC0 for [ TBD ].

Second, in the TRILL Multicast Addresses subregistry of the Transparent
Interconnection of Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

in the existing entry for multicast address 01-80-C2-00-00-42, the description
will be changed from "All-ESADI-RBridges" to "All-ESADI-RBridges /
All-Egress-RBridges"

Third, in the TRILL Multicast Addresses subregistry of the Transparent
Interconnection of Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

IANA will allocate two new TRILL Multicast Addresses as follows:

Address: [ TBD2 ]
Description: TRILL-End-Stations
Reference: [ RFC-to-be ]

Address: [ TBD3 ]
Description: All-Edge-RBridges
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested values for TBD2 and TBD3 as follows:

TBD2 (01-80-C2-00-00-45 suggested)
TBD3 (01-80-C2-00-00-46 suggested)

Fourth, a new subregistry of the Transparent Interconnection of Lots of Links
(TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

will be created. The new subregistry will be called the "RBridge Channel
Protocols" subregistry. There are initial allocations in the registry as follows:

Protocol Description Reference
-------- ----------- ---------
0x000 Reserved (This document)
0x001 RBridge Channel Error (This document)
0x002-0x0FF Available (1)
0x100-0xFF7 Available (2)
0xFF8-0xFFE Private Use
0xFFF Reserved (This document)

RBridge Channel protocol code points from 0x002 to 0x0FF require Standards
Action for allocation.

RBridge Channel protocol code points from 0x100 to 0xFF7 require RFC Publication
to allocate a single value or IETF Review to allocate multiple values.

Fourth, a new subregistry of the Transparent Interconnection of Lots of Links
(TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

will be created. The new subregistry will be called the "RBridge Channel Header
Flags" subregistry. Management of the RBridge Channel Header Flag
subregistry is based on Standards Action. There are initial allocations in the
registry as follows:

Flag Bit Mnemonic Allocation
-------- -------- ----------
0 SL Silent
1 MH Multi-hop
2 NA Native
3-11 - Available for allocation

All items in this new subregistry will be marked with a reference of [ RFC-to-be ].

Fifth, a new subregistry of the Transparent Interconnection of Lots of Links
(TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/trill-parameters.xml

will be created. The new subregistry will be called the "RBridge Channel Error
codes" subregistry. Management of the new RBridge Channel Error codes
subregistry is done through Standards Action.

ERR Meaning
--- -------
0 - Not an RBridge Channel error frame.
1 Frame too short (truncated Ethertype or RBridge Channel Header)
2 Unrecognized Ethertype
3 Unimplemented value of CHV
4 Wrong value of NA flag
5 Channel Protocol is reserved or unimplemented
6-14 - Available for allocation, see Section 6.
15 Reserved

All items in this new subregistry will be marked with a reference of [ RFC-to-be ].

IANA understands that these actions are the only ones that need to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2012-06-15
06 Brian Haberman
[Ballot comment]
I only have two minor comments on this document:

1. The introduction contains the following standalone sentence: "Familiarity with [RFC6325] and …
[Ballot comment]
I only have two minor comments on this document:

1. The introduction contains the following standalone sentence: "Familiarity with [RFC6325] and [RFC6327] is assumed in this document."  What is the purpose of this sentence given that both references are listed as normative?

2. Section 3 says that these channel messages are subject to the usual TRILL message checks and then lists some checks that are performed.  I would suggest making an explicit reference to the document that defines those checks and list any that are not performed on channel messages.
2012-06-15
06 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-06-14
06 Barry Leiba
[Ballot discuss]
This seems a well-written, clear document, which looks technically sound.  One small point that should be easy to resolve:

For the new RBridge …
[Ballot discuss]
This seems a well-written, clear document, which looks technically sound.  One small point that should be easy to resolve:

For the new RBridge Channel Protocols registry:

1. The correct 5226 policy is "RFC Required" (not "RFC Publication").

2. What's the reason for requiring IETF Review for more than one request?  If someone has a document in the Independent Stream and needs two codes, this means that it has to be re-routed through the IETF Stream or split into two ISE documents -- both of which might not make sense.  If it's just that you want someone to sanity-check requests for multiple values, you could make that "IESG Approval" instead of "IETF Review".  That would allow the IESG to block multiple-value registrations through the Independent Stream if necessary, but to choose to approve them without forcing the RFC to go through the IETF Stream.
2012-06-14
06 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2012-06-14
06 Ralph Droms Ballot has been issued
2012-06-14
06 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms
2012-06-14
06 Ralph Droms Created "Approve" ballot
2012-06-07
06 Jean Mahoney Request for Last Call review by GENART is assigned to Miguel Garcia
2012-06-07
06 Jean Mahoney Request for Last Call review by GENART is assigned to Miguel Garcia
2012-06-06
06 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TRILL: RBridge Channel Support) to Proposed …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TRILL: RBridge Channel Support) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL: RBridge Channel Support'
  as 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@ietf.org mailing lists by 2012-06-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a general channel mechanism for sending
  messages, such as BFD (Bidirectional Forwarding Detection) messages,
  between RBridges (Routing Bridges) and between RBridges and end
  stations in an RBridge campus through extensions to the TRILL
  (TRansparent Interconnection of Lots of Links) protocol.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-channel/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-channel/ballot/


No IPR declarations have been submitted directly on this I-D.


2012-06-06
06 Amy Vezza State changed to In Last Call from Last Call Requested
2012-06-06
06 Ralph Droms Last call was requested
2012-06-06
06 Ralph Droms State changed to Last Call Requested from Last Call Requested
2012-06-06
06 Ralph Droms Placed on agenda for telechat - 2012-06-21
2012-06-06
06 Ralph Droms Last call was requested
2012-06-06
06 Ralph Droms Ballot approval text was generated
2012-06-06
06 Ralph Droms State changed to Last Call Requested from AD Evaluation
2012-06-06
06 Ralph Droms Last call announcement was generated
2012-06-06
06 Ralph Droms Ballot writeup was changed
2012-06-06
06 Ralph Droms Ballot writeup was generated
2012-05-25
06 Ralph Droms State changed to AD Evaluation from Publication Requested
2012-05-21
06 Donald Eastlake IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2012-05-16
06 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard as indicated in the title page header. This
document specifies how a channel (with associated code points) for
carrying things like BFD and error reports for TRILL.

(2) 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

The TRILL base protocol standard [RFC6325] provides for TRILL Data
messages and TRILL IS-IS messages.

This document specifies a general channel mechanism for the
transmission of other messages within an RBridge campus, such as BFD
(Bidirectional Forwarding Detection, [RFC5880]) and error messages,
between
RBridges and end stations that are directly connected on the same
link and between RBridges. This mechanism supports a requirement to
be able to operate with minimal configuration.

Working Group Summary

There was consensus in the working group in favor of the document.

Document Quality

The document has been carefully reviewed in the WG and by the document
shepherd. There are currently no known implementations of the channel
mechanism, but BFD and error reporting will drive their implementation.

Personnel

Who is the Document Shepherd?

Erik Nordmark

Who is the Responsible Area Director?

Ralph Droms

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Careful review of the whole document, including looking at
dependencies to and from rbridge-bfd and rbridge-extension.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures on this document.

(9) 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?

The consensus is reasonably broad.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria apply.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) 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 plan for their completion?

There are normative references to draft-ietf-trill-rbridge-extension
which is being advanced simultaneously and to
draft-eastlake-isis-rfc6326bis whose move to an ISIS WG draft has
been requested.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.


The IANA considerations section lists the additional code points
and multicast addresses, and also the three new sub-registries.
The description of the sub-registries and their initial content is
consistent with the rest of the docuument.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The new subregistries do not require Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None. No part of this draft is in a formal language.
2012-05-16
06 Donald Eastlake Submitted for publication.
2012-05-16
06 Cindy Morgan Note added 'Erik Nordmark (nordmark@acm.org) is the document shepherd.'
2012-05-16
06 Cindy Morgan Intended Status changed to Proposed Standard
2012-05-16
06 Cindy Morgan IESG process started in state Publication Requested
2012-05-16
06 (System) Earlier history may be found in the Comment Log for draft-eastlake-trill-rbridge-bfd
2012-05-15
06 Donald Eastlake New version available: draft-ietf-trill-rbridge-channel-06.txt
2012-04-27
05 Donald Eastlake IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2012-02-21
05 (System) New version available: draft-ietf-trill-rbridge-channel-05.txt
2012-02-21
05 Donald Eastlake This draft has working group consensus.
2012-01-18
04 (System) New version available: draft-ietf-trill-rbridge-channel-04.txt
2011-10-31
03 (System) New version available: draft-ietf-trill-rbridge-channel-03.txt
2011-07-28
02 (System) New version available: draft-ietf-trill-rbridge-channel-02.txt
2011-07-05
05 Donald Eastlake In WG LC since June 27
2011-07-05
05 Donald Eastlake IETF state changed to In WG Last Call from WG Document
2011-06-04
01 (System) New version available: draft-ietf-trill-rbridge-channel-01.txt
2011-04-21
00 (System) New version available: draft-ietf-trill-rbridge-channel-00.txt