Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling
draft-ietf-trill-fine-labeling-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-05
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-04-14
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-04-07
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-03-24
|
07 | (System) | RFC Editor state changed to REF from AUTH |
2014-03-20
|
07 | (System) | RFC Editor state changed to AUTH from EDIT |
2014-02-04
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-02-04
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-02-03
|
07 | (System) | IANA Action state changed to Waiting on Authors from On Hold |
2014-02-03
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2013-05-24
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-05-23
|
07 | (System) | RFC Editor state changed to MISSREF |
2013-05-23
|
07 | (System) | Announcement was received by RFC Editor |
2013-05-23
|
07 | (System) | IANA Action state changed to On Hold |
2013-05-23
|
07 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-05-23
|
07 | Amy Vezza | IESG has approved the document |
2013-05-23
|
07 | Amy Vezza | Closed "Approve" ballot |
2013-05-23
|
07 | Amy Vezza | Ballot approval text was generated |
2013-05-23
|
07 | Ted Lemon | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-05-21
|
07 | Stewart Bryant | [Ballot comment] Thank you for making the changes to the Ethernet assignment. |
2013-05-21
|
07 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2013-05-20
|
07 | Donald Eastlake | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2013-05-20
|
07 | Donald Eastlake | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2013-05-17
|
07 | Donald Eastlake | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-17
|
07 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-07.txt |
2013-05-16
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Steve Hanna. |
2013-05-16
|
06 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-05-16
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-05-16
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-05-16
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-05-16
|
06 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-05-15
|
06 | Spencer Dawkins | [Ballot comment] I balloted Yes because I like it. The document seems well-written and complete, gives thought to operational aspects and security aspects, and provides … [Ballot comment] I balloted Yes because I like it. The document seems well-written and complete, gives thought to operational aspects and security aspects, and provides good background for readers who might not have been the implementers for TRILL VL, but are now implementing FGL on the next release. I do have some comments, but they're not blocking. Is this draft about coexistence or migration? I'm seeing both words used in the text. We spent some time talking about this recently ("if you're migrating for decades, you're coexisting"). In this text: 2.2 Base Protocol TRILL Data Labeling This section provides a brief review of the [RFC6325] TRILL Data packet VL Labeling and changes the description of the TRILL Header by moving its end point. This descriptive change does not involve any change in the bits on the wire or in the behavior of VL TRILL switches. I found "this descriptive change" confusing on first read. Perhaps "this change in description" might be clearer. Thanks to the WG for describing the things that could happen when you send FGL frames to a switch that's not FGL-safe. In Appendix A, I found a "unicat" - guessing that's a typo. |
2013-05-15
|
06 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-05-15
|
06 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-05-15
|
06 | Pete Resnick | [Ballot comment] Throughout: I assume that "campus" is a well-understood term of art in this area? This was not a familiar use to me. 4.1: … [Ballot comment] Throughout: I assume that "campus" is a well-understood term of art in this area? This was not a familiar use to me. 4.1: It MUST be possible to configure the ports of an FGL-edge TRILL switch to ingress native frames as FGL. I don't understand this requirement. Are you simply saying, "An FGL-edge TRILL switch MUST ingress native frames. It MAY ingress them or FGL or MAY ingress them as VL, depending on local configuration."? If so, say that. Otherwise, it sounds like you're saying, "The purchase order for buying an FGL switch MUST say that it is configurable to...", which is silly. FGL-edge TRILL switches MUST support configurable per port mapping from the C-VLAN of a native frame, as reported by the ingress port, to an FGL. See above. What is the protocol requirement you are trying to express? |
2013-05-15
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-05-14
|
06 | Adrian Farrel | [Ballot comment] I am entering these notes as Comments because I am actually not too bothered whether you address them or not. I do not … [Ballot comment] I am entering these notes as Comments because I am actually not too bothered whether you address them or not. I do not believe that failure to address my points will result in a less stable or useful internet. I think that you might make your document more easily used and clearer for people trying to understand the technology if you find ways to answer the points in your text. --- I found that the Abstract and Introduction are not clear on the motivation for this work. The number of IDs supported is not a direct statement of the granularity of labeleing. Thus, the motivation needs to be clarified. Is the requirement to increase the number of labels available? Or is the requirement to enable subdivision of existing labels to increase granularity? --- I am trying to understand why it is necessary to include the Ethertype twice in order to stack the label. Surely the first 893b provides sufficient information that what follows will be two label values. I shouldn't be surprised to find that the answer is in bullet 2 of section 2.1, or maybe it is to do with 32 bit alignment, but this sort of design choice probably needs to be called out if you don't want future generations to become confused or even break Trill. But the way things are constructed means that you should also handle the case where the second Ethertype has a different value. --- Like Stewart, I am surprised that you have chosen to limit the label stack to exactly two components: a high part and a low part. This seems remarkably un-forward-looking given the experience we have of the value of deeper label stacks in other technologies. --- The description of the fields in the two parts of the label in Section 2.3 seems to be incomplete. I find: The two bytes following each 0x893B have, in their low order 12 bits, fine-grained label information. The upper 4 bits of those two bytes are used for a 3-bit priority field and one drop eligibility indicator (DEI) bit. The priority field of the Inner.Label High Part is the priority used for frame transport across the TRILL campus from ingress to egress. The label bits in the Inner.Label High Part are the high order part of the FGL and those bits in the Inner.Label Low Part are the low order part of the FGL. This omits: - In what order are the priority field and DEI arranged? - What is the meaning of the priority field in the low part? - What is the meaning of the DEI in the low part? - What is the link between the label format here and that in 6325 where the 3-bit priority field is accompanied by a "C" bit? I know that some of the answers appear later in the document, but it seems odd that you describe some fields, but not all of them, and it looks like not all questions do actually get answered. --- Section 3 has: It is the responsibility of the network manager to properly configure the TRILL switches in the campus to obtain the desired mappings. This seems to leave quite an opening for fat fingers. What mechanisms are provided to assist the operate in detecting her mistakes? Do you have defaults you can recommend for "out of the box" behavior? |
2013-05-14
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-05-14
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-05-14
|
06 | Joel Jaeggli | [Ballot comment] I am sympathetic to stuart's discussion point. as I noted there is historical precedent for setting the registration of an ieee registerd resource … [Ballot comment] I am sympathetic to stuart's discussion point. as I noted there is historical precedent for setting the registration of an ieee registerd resource to IANA (rather than to a working group or individual. -- |
2013-05-14
|
06 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-05-13
|
06 | Stewart Bryant | [Ballot discuss] My discuss originally said: "I see that Ethertype 893B is owned by IETF TRILL Working Group, 155 Beaver Street, Milford MA 01757, UNITED … [Ballot discuss] My discuss originally said: "I see that Ethertype 893B is owned by IETF TRILL Working Group, 155 Beaver Street, Milford MA 01757, UNITED STATES. It is unusual for an IETF WG to own codepoints in other SDOs, and in any case I do not recognize that address as a normal IETF address. Who owns change control and IPR for Ethertype 893B? Why is this not clearly an IETF assignment at IETF main office." From the ensuing discussion I think that the policy of the IETF should be that the Etherypes of its protocols point to a formal IETF contact address. What we do about historic Ethertypes is a different matter to what we do going forward. I will clear this when the IESG has agreed the best way to move forward on this and that policy is enacted. |
2013-05-13
|
06 | Stewart Bryant | [Ballot comment] I think a more precise definition of Ethertype 893B is required that is provided by this draft. Specifically it looks like the structure … [Ballot comment] I think a more precise definition of Ethertype 893B is required that is provided by this draft. Specifically it looks like the structure 893B/lower/893B/upper is the only structure allowed and the draft should be more emphatic on this. |
2013-05-13
|
06 | Stewart Bryant | Ballot comment and discuss text updated for Stewart Bryant |
2013-05-10
|
06 | Stewart Bryant | [Ballot discuss] This is a Discuss-Discuss and needs to be addressed by the responsible AD. As far as I can see this extension to the … [Ballot discuss] This is a Discuss-Discuss and needs to be addressed by the responsible AD. As far as I can see this extension to the TRILL protocol that is not covered by the current TRILL charter. I would like to discuss with IESG whether my interpretation of the charter is correct, and if so what actions are appropriate. I see that Ethertype 893B is owned by IETF TRILL Working Group, 155 Beaver Street, Milford MA 01757, UNITED STATES. It is unusual for an IETF WG to own codepoints in other SDOs, and in any case I do not recognize that address as a normal IETF address. Who owns change control and IPR for Ethertype 893B? Why is this not clearly an IETF assignment at IETF main office. In any case I think a more precise definition of Ethertype 893B is required that is provided by this draft. There is text that implies that a double nesting of 893B is required, is this the only nesting that is allowed? |
2013-05-10
|
06 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2013-05-10
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-05-09
|
06 | Sean Turner | [Ballot comment] Seems like another bullet to be added to s5.3 is that the swithc needs to check for the Ehtertype? |
2013-05-09
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-05-08
|
06 | Ted Lemon | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-05-08
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-05-06
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA OK - Actions Needed |
2013-05-06
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-05-06
|
06 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-trill-fine-labeling-06.txt. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-trill-fine-labeling-06.txt. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA notes that one of the IANA actions requested in this document is dependent on actions requested in another yet-to-be-approved Internet-Draft. IANA understands that upon approval of this document, there are two actions which IANA needs to complete. First, IANA understands that the request to register Ethertype 0x893B for use as the TRILL FGL Ethertype has been completed by the IEEE registration authority and that IANA need take no further action. Second, IANA understands that the authors regues a capability bit [value TBD] in the TRILL-VER sub-TLV capability sub-registry that will be created by the approval of draft-ietf-isis-rfc6326bis. IANA understands that these are the only actions required 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. |
2013-05-03
|
06 | Ted Lemon | Ballot has been issued |
2013-05-03
|
06 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2013-05-03
|
06 | Ted Lemon | Created "Approve" ballot |
2013-04-25
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2013-04-25
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2013-04-25
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2013-04-25
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2013-04-24
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-04-24
|
06 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TRILL (Transparent Interconnection of Lots … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling) 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 (Transparent Interconnection of Lots of Links): Fine-Grained Labeling' 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 2013-05-08. 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 The IETF has standardized TRILL (Transparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine-grained labeling of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1688/ |
2013-04-24
|
06 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-04-24
|
06 | Cindy Morgan | Last call announcement was generated |
2013-04-23
|
06 | Ted Lemon | Placed on agenda for telechat - 2013-05-16 |
2013-04-23
|
06 | Ted Lemon | Last call was requested |
2013-04-23
|
06 | Ted Lemon | Ballot approval text was generated |
2013-04-23
|
06 | Ted Lemon | State changed to Last Call Requested from AD Evaluation |
2013-04-23
|
06 | Ted Lemon | Ballot writeup was changed |
2013-04-23
|
06 | Ted Lemon | Ballot writeup was changed |
2013-04-23
|
06 | Ted Lemon | Ballot writeup was generated |
2013-04-23
|
06 | Ted Lemon | Last call announcement was generated |
2013-04-19
|
06 | Ted Lemon | State changed to AD Evaluation from Publication Requested |
2013-04-17
|
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 is requested and noted in the title page header. This document specifies an optional extension to the IETF TRILL protocol, updating RFCs 6325 which is a Proposed Standard. (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 supports labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require more fine-grained labeling of data for configurable isolation based on different tenants, service instances, or the like. This document updates TRILL by specifying an optional extension that supports an additional 2**24 labels, called fine-grained labels (FGLs). Provisions for mixed networks of TRILL switches that do and do not support FGLs are provided. Working Group Summary: The two primary points of discussion in the WG were how to encode fine grained labels and how to handled mixed networks. Early versions of FGL, for maximum backwards compatibility with the TRILL base protocol, made a non-standard use of an Ethertype assigned to another group as part of FGL encoding, but this ws not allowed by the asignee of that Ethertype. So the encoding was changed to use a new Ethertype allocated for TRILL FGL. After discussion, the consensus of the working group was to use an encoding structure optimized for support by existing fast path silicon, although this is not the most compact encoding. For handling mixed networks, the problem to be solved was how to avoid giving an FGL TRILL Data packet to a TRILL switch not supporting FGL that might mishandle it. The WG decision was to avoid methods that would require silicon changes or additional shortest path calculation, yet have the protocol be robust against mixtures of old and new TRILL switches. Document Quality: The document has been reviewed by participants from the TRILL vendors that appear to plan to implement this specification. The document shepherd has reviewed the document in its most recent form. Personnel: Erik Nordmark is the Document Shepherd. Ted Lemon is the Responsible Area Director. (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. Looked at the document for editorial clarity, especially in the area of how old TRIL switches and FGL TRILL switches interact. This resulted in some editorial restructuring of the document. (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. There is no such need. (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? 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. No special concerns. (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. Yes - https://datatracker.ietf.org/ipr/1688/ The WG was made aware of that first by the secretariat's IPR Disclosure on 2/24/12. On 11/8/12 the document shepheard reminded the WG of this IPR, and included a reference to rfc3979. There has been no discussion of that IPR on the mailing list or at the WG meetings. (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? There is a solid consensus for the document. One individual raised concerns at the Atlanta IETF meeting that the FGL encoding could be simplified to have a single 24 bit field instead of 2x12 bit fields. There did not seem to be any uptake on that idea in any subsequent discussions. (10) 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 publicly available.) 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. idnits is clean. There is a note regarding pre-RFC5378 work which we will address and the expected warning about possible downref for ISO/IEC 10589 (the IS-IS ISO standard). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. This document requires no such formal review. (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? No. (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. The above notes IS-IS warning is due to idnits not knowing about the standards status for ISO specifications. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Verified that the IANA considerations section is consistent with the document text (merely a request for a capability bit). (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. This document creates no new IANA registries. (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. No sections of the document are written in a formal language requiring such validation. |
2013-04-17
|
06 | Cindy Morgan | Note added 'Erik Nordmark (nordmark@acm.org) is the Document Shepherd.' |
2013-04-17
|
06 | Cindy Morgan | Intended Status changed to Proposed Standard |
2013-04-17
|
06 | Cindy Morgan | IESG process started in state Publication Requested |
2013-04-17
|
06 | (System) | Earlier history may be found in the Comment Log for draft-eastlake-trill-rbridge-fine-labeling |
2013-03-29
|
06 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-06.txt |
2013-02-13
|
05 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-05.txt |
2012-12-31
|
04 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-04.txt |
2012-12-12
|
03 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-03.txt |
2012-11-12
|
02 | Donald Eastlake | IETF state changed to In WG Last Call from WG Document |
2012-10-22
|
02 | Donald Eastlake | In WG last call starting at the TRILL WG meeting in Atlanta |
2012-10-22
|
02 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-02.txt |
2012-06-10
|
01 | Donald Eastlake | New version available: draft-ietf-trill-fine-labeling-01.txt |
2012-02-24
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-trill-fine-labeling-00 | |
2011-12-08
|
00 | (System) | New version available: draft-ietf-trill-fine-labeling-00.txt |