Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks
RFC 6307
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
16 | (System) | Changed document authors from "Linda Dunbar, Moran Roth, Ronen Solomon" to "Linda Dunbar, Moran Roth, Ronen Solomon, David Black" |
|
2015-10-14
|
16 | (System) | Notify list changed from pwe3-chairs@ietf.org, draft-ietf-pwe3-fc-encap@ietf.org to (None) |
|
2012-08-22
|
16 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
|
2012-08-22
|
16 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
16 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
|
2012-08-22
|
16 | (System) | post-migration administrative database adjustment to the Yes position for Adrian Farrel |
|
2012-04-21
|
16 | (System) | RFC published |
|
2011-05-10
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-05-10
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2011-05-09
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-05-06
|
16 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-05-05
|
16 | (System) | IANA Action state changed to In Progress |
|
2011-05-05
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-05-05
|
16 | Amy Vezza | IESG has approved the document |
|
2011-05-05
|
16 | Amy Vezza | Closed "Approve" ballot |
|
2011-05-05
|
16 | Amy Vezza | Approval announcement text regenerated |
|
2011-05-05
|
16 | Stewart Bryant | Ballot writeup text changed |
|
2011-05-04
|
16 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
|
2011-05-04
|
16 | Adrian Farrel | [Ballot comment] Thanks for addressing my issues so speedily. I am now happy to ballot Yes on this document |
|
2011-05-04
|
16 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss |
|
2011-05-03
|
16 | (System) | New version available: draft-ietf-pwe3-fc-encap-16.txt |
|
2011-04-28
|
16 | Cindy Morgan | Removed from agenda for telechat |
|
2011-04-28
|
16 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
|
2011-04-28
|
16 | Adrian Farrel | [Ballot discuss] Updated Discuss after telechat --- I have one issue I would like to resolve with this document before moving to a "Yes" ballot. … [Ballot discuss] Updated Discuss after telechat --- I have one issue I would like to resolve with this document before moving to a "Yes" ballot. --- I was a little surprised by the mention of MPLS-TP in the Abstract. I am not sure how "taking advantage of MPLS-TP" is in any way different from "using an MPLS PW". It is probably not important, but it feels a bit like marketing-speak has escaped into your spec. Later in the document, however, I find: MPLS-TP provides mechanisms for communication over MPLS networks with very low loss rates and very low probability of reordering, making it possible for Fibre Channel ports to be interconnected directly over MPLS networks. I don't see how MPLS-TP provides such mechanisms, but the sentence is ambiguous because it is not clear from what you have written whether the networks intrinsically have the qualities described (and MPLS-TP provides mechanisms for communicating over them) or whether MPLS-TP somehow enhances the loss rates and reordering probability. In the first case, this something of a non-statement; in the second case I don't think it is true. How about cutting this text? Later still I find: FC PW traffic should only traverse controlled MPLS or MPLS-TP networks. Since all MPLS-TP networks are MPLS networks, I suggest you delete "or MPLS-TP" from this sentence. similalry, in the next paragraph: As a consequence, resilience of the emulated FC service to such outages is dependent upon MPLS-TE/MPLS-TP network. t I suggest you change "MPLS-TE/MPLS-TP networks." to "the underlying MPLS network." |
|
2011-04-28
|
16 | Jari Arkko | [Ballot discuss] I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document … [Ballot discuss] I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document and what it expects out of the underlying MPLS network. The combination of requiring no reordering and the possibility of any error resulting in 30-60 second delays at the FC processing level is worrisome. Can this statement from the draft be made precise: FC PW traffic should only traverse controlled MPLS or MPLS-TP networks. The network should enforce policing of incoming traffic and network resource/bandwidth allocation so that the FC PW delivery quality can be assured. To extend FC across an uncontrolled network, FCIP SHOULD be used instead of an FC PW, see [RFC3821] and [FC-BB-6]. What exactly is considered a controlled network? What kind of mechanisms are sufficient for the resource allocation? |
|
2011-04-28
|
16 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss |
|
2011-04-28
|
16 | Jari Arkko | [Ballot comment] I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document … [Ballot comment] I'm not looking to block the document based on this, but I think we should discuss in the IESG telechat about this document and what it expects out of the underlying MPLS network. The combination of requiring no reordering and the possibility of any error resulting in 30-60 second delays at the FC processing level is worrisome. Can this statement from the draft be made precise: FC PW traffic should only traverse controlled MPLS or MPLS-TP networks. The network should enforce policing of incoming traffic and network resource/bandwidth allocation so that the FC PW delivery quality can be assured. To extend FC across an uncontrolled network, FCIP SHOULD be used instead of an FC PW, see [RFC3821] and [FC-BB-6]. What exactly is considered a controlled network? What kind of mechanisms are sufficient for the resource allocation? |
|
2011-04-28
|
16 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-04-27
|
16 | Pete Resnick | [Ballot comment] I don't think this is worthy of a discuss, but is the byte order for FC PW Control Word (and other items) specified? … [Ballot comment] I don't think this is worthy of a discuss, but is the byte order for FC PW Control Word (and other items) specified? Does it need to be in this document? |
|
2011-04-27
|
16 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-27
|
16 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-27
|
16 | Dan Romascanu | [Ballot discuss] The document has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at … [Ballot discuss] The document has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at least some considerations about the OAM mapping extensions, as the Pseudowire (PW) OAM Message Mapping I-D (draft-ietf-pwe3-oam-msg-map-16.txt) does not cover FC services over PW. |
|
2011-04-27
|
16 | Dan Romascanu | [Ballot discuss] The documents has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at … [Ballot discuss] The documents has no operational and manageability considerations section, and no reference to the operational and manageability aspects. I would have expected at least some considerations about the OAM mapping extensions, as the Pseudowire (PW) OAM Message Mapping I-D (draft-ietf-pwe3-oam-msg-map-16.txt) does not cover FC services over PW. |
|
2011-04-27
|
16 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-04-26
|
16 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-26
|
16 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-26
|
16 | Stephen Farrell | [Ballot comment] |
|
2011-04-26
|
16 | Stephen Farrell | [Ballot discuss] The text says: "FC Primitive Sequence Reduction: a subset of repetitive FC Primitive Sequences received from the attached … [Ballot discuss] The text says: "FC Primitive Sequence Reduction: a subset of repetitive FC Primitive Sequences received from the attached FC port at the source PE is selected for WAN transmission..." It's just not clear to me how the subset is selected, though I think this is most likely just me not understanding (probably 3.3.2). I expect to clear once this is explained to me:-) |
|
2011-04-26
|
16 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
|
2011-04-25
|
16 | Adrian Farrel | [Ballot comment] Section 3.1 Although you say: The fragmentation bits (bits 8-9) are not used by the FC PW protocol. These bits may … [Ballot comment] Section 3.1 Although you say: The fragmentation bits (bits 8-9) are not used by the FC PW protocol. These bits may be used in the future for FC specific indications as defined in [RFC4385]. It appears from the diagram that you require these bits to be set to zero, and I suspect that a future extension might interpret the bits. I think you should be more explicit in the text. === Nits Section 1 "the TCP protocol" The P in TCP stands for what? :-) --- Section 1.1 s/port on far end of the FC link/port on the far end of the FC link/ |
|
2011-04-24
|
16 | Adrian Farrel | [Ballot comment] Section 3.1 Although you say: The fragmentation bits (bits 8-9) are not used by the FC PW protocol. These bits may … [Ballot comment] Section 3.1 Although you say: The fragmentation bits (bits 8-9) are not used by the FC PW protocol. These bits may be used in the future for FC specific indications as defined in [RFC4385]. It appears from the diagram that you require these bits to be set to zero, and I suspect that a future extension might interpret the bits. I think you should be more explicit in the text. === Nits Section 1 "the TCP protocol" The P in TCP stands for what? :-) --- Section 1.1 s/port on far end of the FC link/port on the far end of the FC link/ --- Section 1.2 I could probably look this up in the references, but easier to ask you. Do you mean "continuously" or "continually"? (several instances) |
|
2011-04-24
|
16 | Adrian Farrel | [Ballot discuss] I have two issues I would like to resolve with this document before moving to a "Yes" ballot. --- I was a little … [Ballot discuss] I have two issues I would like to resolve with this document before moving to a "Yes" ballot. --- I was a little surprised by the mention of MPLS-TP in the Abstract. I am not sure how "taking advantage of MPLS-TP" is in any way different from "using an MPLS PW". It is probably not important, but it feels a bit like marketing-speak has escaped into your spec. Later in the document, however, I find: MPLS-TP provides mechanisms for communication over MPLS networks with very low loss rates and very low probability of reordering, making it possible for Fibre Channel ports to be interconnected directly over MPLS networks. I don't see how MPLS-TP provides such mechanisms, but the sentence is ambiguous because it is not clear from what you have written whether the networks intrinsically have the qualities described (and MPLS-TP provides mechanisms for communicating over them) or whether MPLS-TP somehow enhances the loss rates and reordering probability. In the first case, this something of a non-statement; in the second case I don't think it is true. How about cutting this text? Later still I find: FC PW traffic should only traverse controlled MPLS or MPLS-TP networks. Since all MPLS-TP networks are MPLS networks, I suggest you delete "or MPLS-TP" from this sentence. similalry, in the next paragraph: As a consequence, resilience of the emulated FC service to such outages is dependent upon MPLS-TE/MPLS-TP network. t I suggest you change "MPLS-TE/MPLS-TP networks." to "the underlying MPLS network." --- This element of the Discuss is for discussion with the IESG. No action from the authors is requested. The procedures for lock-step with ANSI seem worrisome. Do we really need to go through these hoops, and how vulnerable are we to ANSI delays? It seems to me that, although [FC-BB-6] is needed in conjunciton to this spec to get the whole picture, [FC-BB-6] is not actually required as a normative reference for the understanding of this spec. |
|
2011-04-24
|
16 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-04-23
|
16 | Stephen Farrell | [Ballot comment] NSP is used without expansion. |
|
2011-04-23
|
16 | Stephen Farrell | [Ballot discuss] The text says: "FC Primitive Sequence Reduction: a subset of repetitive FC Primitive Sequences received from the attached … [Ballot discuss] The text says: "FC Primitive Sequence Reduction: a subset of repetitive FC Primitive Sequences received from the attached FC port at the source PE is selected for WAN transmission..." It's just not clear to me how the subset is selected, though I think this is most likely just me not understanding (probably 3.3.2). I expect to clear once this is explained to me:-) |
|
2011-04-23
|
16 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-04-21
|
16 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-20
|
16 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-19
|
16 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-04-15
|
16 | Stewart Bryant | Placed on agenda for telechat - 2011-04-28 by Stewart Bryant |
|
2011-04-15
|
16 | Stewart Bryant | [Note]: 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.' added by Stewart Bryant |
|
2011-04-15
|
16 | Stewart Bryant | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
|
2011-04-15
|
16 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
|
2011-04-15
|
16 | Stewart Bryant | Ballot has been issued |
|
2011-04-15
|
16 | Stewart Bryant | Created "Approve" ballot |
|
2011-03-31
|
16 | Stewart Bryant | Ballot writeup text changed |
|
2011-03-31
|
16 | Stewart Bryant | Ballot writeup text changed |
|
2011-03-31
|
16 | Stewart Bryant | Ballot writeup text changed |
|
2011-03-14
|
16 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-03-14
|
15 | (System) | New version available: draft-ietf-pwe3-fc-encap-15.txt |
|
2011-03-04
|
16 | Stewart Bryant | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.<br>To address various LC comments |
|
2011-02-22
|
16 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Steve Hanna. |
|
2011-02-21
|
16 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-02-18
|
16 | Amanda Baber | IANA understands that, upon approval of this document, there are two IANA Actions which need to be completed. First, in the MPLS Pseudowire Types Registry … IANA understands that, upon approval of this document, there are two IANA Actions which need to be completed. First, in the MPLS Pseudowire Types Registry in the Pseudowire Name Spaces registry located at: http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml IANA has previously reserved PW type 0x001F for this draft. IANA will now make the registration permanent as follows: PW type Description Reference -------- -------------- ---------- 0x001F FC Port Mode [RFC-to-be] Second, in the Pseudowire Interface Parameters Sub-TLV type Registry in the Pseudowire Name Spaces registry located at: http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml IANA has previously reserved the following values for this draft: 0x12 0x13 0x14 0x15 IANA will now make these permanent registrations with the words "Reserved by {RFC-to-be]" in the description as follows: Parameter ID Length Description Reference --------- --------- ------------------ ---------- 0x12 4 Reserved by [RFC-to-be] [RFC-to-be] 0x13 4 Reserved by [RFC-to-be] [RFC-to-be] 0x14 4 Reserved by [RFC-to-be] [RFC-to-be] 0x15 4 Reserved by [RFC-to-be] [RFC-to-be] IANA understands that these actions are the only IANA Actions that need to be completed upon approval of this document. |
|
2011-02-16
|
16 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
|
2011-02-16
|
16 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
|
2011-02-07
|
16 | Amy Vezza | Last call sent |
|
2011-02-07
|
16 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pwe3@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-pwe3-fc-encap-14.txt> (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks' <draft-ietf-pwe3-fc-encap-14.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@ietf.org mailing lists by 2011-02-21. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ |
|
2011-02-07
|
16 | Stewart Bryant | Ballot writeup text changed |
|
2011-02-07
|
16 | Stewart Bryant | Last Call was requested |
|
2011-02-07
|
16 | Stewart Bryant | State changed to Last Call Requested from Publication Requested. |
|
2011-02-07
|
16 | Stewart Bryant | Last Call text changed |
|
2011-02-07
|
16 | (System) | Ballot writeup text was added |
|
2011-02-07
|
16 | (System) | Last call text was added |
|
2011-02-07
|
16 | (System) | Ballot approval text was added |
|
2011-01-17
|
16 | Cindy Morgan | (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 … (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? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwading to the IESG. (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? Yes, the document has received adequate review. The document received a number of comments during WG last call and been widely reviewed and discussed in the working group over a long period of time. (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. (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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG aprticipants. It has been devloped over a long period in the WG. (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.) None indicated. (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? The document passes ID nits. This document is not subject to MIB doctor or other reviews. (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]. Yes, the references are split appropriately. (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? The IANA considerations section exists, is consistent with the rest of the document, and with the style of the IANA registries that it requests allocations from. There are several requests for allocations from the MPLS PW Type registry and for PW Interface Parameters. It does not request any new registries or new processes for allocations from registries. (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 sections that use a formal language. (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 A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of the reliable transport of MPLS-TE/MPLS-TP to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary This draft originated as draft-roth-pwe3-fc-encap-01 in 2005, which contained a basic specification for the transport of FC over MPLS using PWs. Subsequently, there was significant debate about the congestion control and QoS implications of FC, which requires a reliable underlying transport. The document was reviewed by the transport area resulting in the development of a TCP-friendly congestion control protocol. However, this protocol was felt to add significant complexity, and was removed from the draft and instead the applicability of FC PWs limited to controlled MPLS / MPLS-TP networks. Document Quality There are no concerns about protocol quality. Personnel Who is the Document Shepherd for this document? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Who is the Responsible Area Director? Stewart Bryant |
|
2011-01-17
|
16 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-01-17
|
16 | Cindy Morgan | [Note]: 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.' added |
|
2011-01-11
|
14 | (System) | New version available: draft-ietf-pwe3-fc-encap-14.txt |
|
2011-01-06
|
13 | (System) | New version available: draft-ietf-pwe3-fc-encap-13.txt |
|
2010-08-25
|
12 | (System) | New version available: draft-ietf-pwe3-fc-encap-12.txt |
|
2010-06-29
|
11 | (System) | New version available: draft-ietf-pwe3-fc-encap-11.txt |
|
2010-02-26
|
10 | (System) | New version available: draft-ietf-pwe3-fc-encap-10.txt |
|
2009-01-16
|
09 | (System) | New version available: draft-ietf-pwe3-fc-encap-09.txt |
|
2008-08-21
|
08 | (System) | New version available: draft-ietf-pwe3-fc-encap-08.txt |
|
2008-01-17
|
07 | (System) | New version available: draft-ietf-pwe3-fc-encap-07.txt |
|
2007-10-17
|
06 | (System) | New version available: draft-ietf-pwe3-fc-encap-06.txt |
|
2007-09-18
|
05 | (System) | New version available: draft-ietf-pwe3-fc-encap-05.txt |
|
2007-07-26
|
04 | (System) | New version available: draft-ietf-pwe3-fc-encap-04.txt |
|
2007-04-27
|
03 | (System) | New version available: draft-ietf-pwe3-fc-encap-03.txt |
|
2006-10-20
|
02 | (System) | New version available: draft-ietf-pwe3-fc-encap-02.txt |
|
2006-06-29
|
01 | (System) | New version available: draft-ietf-pwe3-fc-encap-01.txt |
|
2006-03-01
|
00 | (System) | New version available: draft-ietf-pwe3-fc-encap-00.txt |