MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-05-01
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-11
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-04-02
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-03-05
|
07 | (System) | IANA Action state changed to No IC |
2018-03-05
|
07 | (System) | RFC Editor state changed to EDIT |
2018-03-05
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-03-05
|
07 | (System) | Announcement was received by RFC Editor |
2018-03-05
|
07 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::Point Raised - writeup needed |
2018-03-05
|
07 | Cindy Morgan | IESG has approved the document |
2018-03-05
|
07 | Cindy Morgan | Closed "Approve" ballot |
2018-03-05
|
07 | Cindy Morgan | Ballot approval text was generated |
2018-03-05
|
07 | Cindy Morgan | Ballot writeup was changed |
2018-03-05
|
07 | Deborah Brungard | Ballot approval text was changed |
2018-03-01
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-03-01
|
07 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-07.txt |
2018-03-01
|
07 | (System) | New version approved |
2018-03-01
|
07 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Mach Chen , Carlos Pignataro , Gregory Mirsky , Zhenbin Li |
2018-03-01
|
07 | Stewart Bryant | Uploaded new revision |
2018-01-31
|
06 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2018-01-25
|
06 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2018-01-11
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Point Raised - writeup needed from Waiting for AD Go-Ahead |
2018-01-10
|
06 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-01-10
|
06 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-01-10
|
06 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-01-10
|
06 | Ben Campbell | [Ballot comment] I don't think the use of 2119 keywords adds value to this draft. The uses that I found seem more statement of fact … [Ballot comment] I don't think the use of 2119 keywords adds value to this draft. The uses that I found seem more statement of fact than normative assertions. (That is, they describe the state of the world rather than give instructions or grant permission.) I suggest removing the capitalization and the 2119 reference, and just let the words have their plain English meanings. |
2018-01-10
|
06 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-01-10
|
06 | Daniel Franke | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Daniel Franke. Sent review to list. |
2018-01-10
|
06 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-01-08
|
06 | Warren Kumari | [Ballot comment] Thank you for writing this, I think it is a useful document -- however, it does have a number of nits which would … [Ballot comment] Thank you for writing this, I think it is a useful document -- however, it does have a number of nits which would be nice to address (if you make any other edits). Nits: Section 1. Introduction O: "flow identification.The key" P: "flow identification. The key" R: missing space O: performance monitoring of MPLS flows when MPL is used for the encapsulation of user data packets. P: performance monitoring of MPLS flows when MPLS is used for the encapsulation of user data packets. R: Typo for MPLS? O: Indeed it is important that any flow identification technique be invisible to them and that no remnant of the identification of measurement process leaked into their network. P: Indeed it is important that any flow identification technique be invisible to them and that no remnant of the identification of measurement process leaks into their network. R: Tense / readability. Section 3. Loss Measurement Considerations O: Modern networks, if not oversubscribed, potentially drop relatively P: Modern networks, if not oversubscribed, generally drop relatively C: "potentially" makes it sound like this might happen. If a network isn't oversubscribed it usually won't drop packets. Section 4. Delay Measurement Considerations O: Most of the existing delay measurement methods are active measurement that depend on the extra injected test packet to evaluate C: I think that this should be "active measurements" or "active methods". I'm also confused by the singular of "packet". O: Also, for injected test packets, these may not be co-routed with the data traffic due to ECMP, or various link aggregation technologies all of which distribute flows across a number of paths at the network, or data-link and hence at the physical layer. C: This sentence is a run on / really confusing. I know what you are trying to say, but this doesn't communicate it well. Perhaps "Due to ECMP (or link aggregation techniques) injected test packets may traverse other links than the data traffic."? Still not great, but I think easier to parse. Section 5. Units of identification O: In particular note that there may be a need to impose identify at several different layers of the MPLS label stack. P: "identity" (or perhaps "identification"?) O: Such fine grained resolution may be possible by deep packet inspection, but this may not always be possible, or it may be desired to minimize processing costs by doing this only in entry to the network, and adding a suitable identifier to the packet for reference by other network elements. C: This feels like a run on. Also I *think* it is "fine-grained" and "on entry to the network" (nits) O: This allows for the case of instrumenting multiple LSPs operate between the same pair of nodes. P: This allows for the case of instrumenting multiple LSPs operating between the same pair of nodes. C: Readability. |
2018-01-08
|
06 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2018-01-08
|
06 | Warren Kumari | [Ballot comment] Thank you for writing this, I think it is a useful document -- however, it does have quite a number of nits which … [Ballot comment] Thank you for writing this, I think it is a useful document -- however, it does have quite a number of nits which would be nice to have addressed if you make any edits. Nits: Section 1. Introduction O: "flow identification.The key" P: "flow identification. The key" R: missing space O: performance monitoring of MPLS flows when MPL is used for the encapsulation of user data packets. P: performance monitoring of MPLS flows when MPLS is used for the encapsulation of user data packets. R: Typo for MPLS? O: Indeed it is important that any flow identification technique be invisible to them and that no remnant of the identification of measurement process leaked into their network. P: Indeed it is important that any flow identification technique be invisible to them and that no remnant of the identification of measurement process leaks into their network. R: Tense / readability. Section 3. Loss Measurement Considerations O: Modern networks, if not oversubscribed, potentially drop relatively P: Modern networks, if not oversubscribed, generally drop relatively C: "potentially" makes it sound like this might happen. If a network isn't oversubscribed it usually won't drop packets. Section 4. Delay Measurement Considerations O: Most of the existing delay measurement methods are active measurement that depend on the extra injected test packet to evaluate C: I think that this should be "active measurements" or "active methods". I'm also confused by the singular of "packet". O: Also, for injected test packets, these may not be co-routed with the data traffic due to ECMP, or various link aggregation technologies all of which distribute flows across a number of paths at the network, or data-link and hence at the physical layer. C: This sentence is a run on / really confusing. I know what you are trying to say, but this doesn't communicate it well. Perhaps "Due to ECMP (or link aggregation techniques) injected test packets may traverse other links than the data traffic."? Still not great, but I think easier to parse. Section 5. Units of identification O: In particular note that there may be a need to impose identify at several different layers of the MPLS label stack. P: "identity" (or perhaps "identification"?) O: Such fine grained resolution may be possible by deep packet inspection, but this may not always be possible, or it may be desired to minimize processing costs by doing this only in entry to the network, and adding a suitable identifier to the packet for reference by other network elements. C: This feels like a run on. Also I *think* it is "fine-grained" and "on entry to the network" (nits) O: This allows for the case of instrumenting multiple LSPs operate between the same pair of nodes. P: This allows for the case of instrumenting multiple LSPs operating between the same pair of nodes. C: Readability. |
2018-01-08
|
06 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-01-08
|
06 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-01-04
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-01-04
|
06 | Mirja Kühlewind | [Ballot comment] I'm uncertain about the archival value of this document in the RFC series as the document seems to be written rather for wg-internal … [Ballot comment] I'm uncertain about the archival value of this document in the RFC series as the document seems to be written rather for wg-internal consumption only; however, I will not object to its publication. One additional minor comment in section 5: CURRENT: "An example of such a fine grained case might be traffic from a specific application, or from a specific application from a specific source, particularly if matters related to service level agreement or application performance were being investigated." Besides the duplication nit, I would like to suggest the following small change: PROPOSED: "An example of such a fine grained case might be traffic belonging to a certain service or from a specific source, particularly if matters related to service level agreement or application performance were being investigated." I'd say "service" is less specific than "application" and includes such things like e.g. a video service that is offered by the ISP. |
2018-01-04
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-01-03
|
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-01-02
|
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-12-31
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2017-12-31
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2017-12-28
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Franke |
2017-12-28
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Franke |
2017-12-27
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2017-12-27
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-mpls-flow-ident-06, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-mpls-flow-ident-06, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2017-12-20
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2017-12-20
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2017-12-19
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-12-19
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-01-02): From: The IESG To: IETF-Announce CC: draft-ietf-mpls-flow-ident@ietf.org, mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, Loa … The following Last Call announcement was sent out (ends 2018-01-02): From: The IESG To: IETF-Announce CC: draft-ietf-mpls-flow-ident@ietf.org, mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, Loa Andersson , loa@pi.nu Reply-To: ietf@ietf.org Sender: Subject: Last Call: (MPLS Flow Identification Considerations) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Flow Identification Considerations' as Informational RFC 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 2018-01-02. 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 discusses the aspects that need to be be considered when developing a solution for MPLS flow identification. The key application that needs this is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-flow-ident/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-flow-ident/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-12-19
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-12-19
|
06 | Deborah Brungard | Ballot has been issued |
2017-12-19
|
06 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2017-12-19
|
06 | Deborah Brungard | Created "Approve" ballot |
2017-12-19
|
06 | Deborah Brungard | Ballot writeup was changed |
2017-12-19
|
06 | Deborah Brungard | Placed on agenda for telechat - 2018-01-11 |
2017-12-19
|
06 | Deborah Brungard | Last call was requested |
2017-12-19
|
06 | Deborah Brungard | Last call announcement was generated |
2017-12-19
|
06 | Deborah Brungard | Ballot approval text was generated |
2017-12-19
|
06 | Deborah Brungard | Ballot writeup was generated |
2017-12-19
|
06 | Deborah Brungard | IESG state changed to Last Call Requested from AD Evaluation |
2017-12-19
|
06 | Deborah Brungard | Changed consensus to Yes from Unknown |
2017-12-14
|
06 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-06.txt |
2017-12-14
|
06 | (System) | New version approved |
2017-12-14
|
06 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Mach Chen , Carlos Pignataro , Gregory Mirsky , Zhenbin Li |
2017-12-14
|
06 | Stewart Bryant | Uploaded new revision |
2017-11-06
|
05 | Deborah Brungard | IESG state changed to AD Evaluation from Expert Review |
2017-08-28
|
05 | Min Ye | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Manav Bhatia. |
2017-08-11
|
05 | Deborah Brungard | Reviewer for RTG Dir - Manav |
2017-08-11
|
05 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2017-08-10
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Manav Bhatia |
2017-08-10
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Manav Bhatia |
2017-08-10
|
05 | Deborah Brungard | Requested Last Call review by RTGDIR |
2017-07-28
|
05 | Loa Andersson | The MPLS WG requests that MPLS Flow Identification Considerations … The MPLS WG requests that MPLS Flow Identification Considerations draft-ietf-mpls-flow-ident is published as an Informational 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? The document is intended to become an Informational RFC, it is the first in a group of documents that discusses the need of and will specify standards for MPLS flows. It correct to publsih this document as an Informational, since it does not specifies new standard, but discusses why such MPLS flow identification standards are needed and what needs to be considered when such standards will be developed. (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 This document discusses the aspects that must be considered when developing a solution for MPLS flow identification. Flow identification is needed for e.g. in-band performance monitoring of user data packets. Flows need to be identified in MPLS networks to detect and measure e.g. packet loss and packet delay. A method of loss and delay measurement in MPLS networks were defined in RFC 6374. The packet loss measurment defined in RFC 6374 depends on OAM packets interjected into the flows for which packet loss is measured (active measurement). The packet performance measurement system needs to be extended to deal with flows of different granularities and to address multi- point cases in which multiple ingress LSRs send packets to one or more destinations. Flow identification technique need to invisible to the end user and that the flow identification does not cause side effects in the network. When there are multiple traffic sources, such as in MP2P and MP2MP network environments the sink need to distinguish between packets from the various sources, a multi-point to multi-point measurement model needs to be developed. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The MPLS working group have a long discussion on the need and method of source and flow identification. We have converged on the considerations captured in this framework document and on the method described in a set of forthcoming specifications. The working group is solidly behind this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This is a framework document, and as such it does not directly specify an implementable protocol, there are a set of documents in the pipe that will do that. Several vendors have indicated that they will implement the upcoming solution. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document SHephered. Deborah Brungard is the Responsible AD. (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. The document shepherd has reviewed the docuyment several times, e.g. when if first was posted, when preparing working group adoption and preparing working group last call. The shepherd has also been active in the soruce and flow identification discussion and reviewed several of the early documents. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns. (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 such reviews necessary. (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 such concerns. The document has been through an early review by the RTG-DIR, this review found some nits that has been addressed. (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. All authors and contributors has confirmed that they are unaware of any IPRs that has not been disclosed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosure against 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? Flow and source identfication are necessary components to meet the current requirements on packet loss and delay. The working group solidly support this document. (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 such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The document passes the nits-tool clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews required. (13) Have all references within this document been identified as either normative or informative? Yes, but there is only one normative reference - RFC 2119, all other references are informative. (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? All normative references (1 reference) is to published RFCs. (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 downward references. (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. There will be no status change of any existing RFC due to the publication of this document. (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). This document does not require any actions from the IANA. (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. No such 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 such reviews required. |
2017-07-28
|
05 | Loa Andersson | Responsible AD changed to Deborah Brungard |
2017-07-28
|
05 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2017-07-28
|
05 | Loa Andersson | IESG state changed to Publication Requested |
2017-07-28
|
05 | Loa Andersson | IESG process started in state Publication Requested |
2017-07-28
|
05 | Loa Andersson | Notification list changed to "Loa Andersson" <loa@pi.nu>, draft-ietf-mpls-flow-ident@ietf.org, mpls-chairs@ietf.org from "Loa Andersson" <loa@pi.nu> |
2017-07-28
|
05 | Loa Andersson | Changed document writeup |
2017-07-27
|
05 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-05.txt |
2017-07-27
|
05 | (System) | New version approved |
2017-07-27
|
05 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Mach Chen , Carlos Pignataro , Gregory Mirsky , Zhenbin Li |
2017-07-27
|
05 | Stewart Bryant | Uploaded new revision |
2017-07-04
|
04 | Loa Andersson | Changed document writeup |
2017-07-04
|
04 | Loa Andersson | Changed document writeup |
2017-07-04
|
04 | Loa Andersson | Changed document writeup |
2017-02-24
|
04 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-04.txt |
2017-02-24
|
04 | (System) | New version approved |
2017-02-24
|
04 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Mach Chen , Carlos Pignataro , Gregory Mirsky , Zhenbin Li |
2017-02-24
|
04 | Stewart Bryant | Uploaded new revision |
2017-02-20
|
03 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2017-02-02
|
03 | Min Ye | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Manav Bhatia. |
2017-01-23
|
03 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-03.txt |
2017-01-23
|
03 | (System) | New version approved |
2017-01-23
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Mach Chen" , "Gregory Mirsky" , "Zhenbin Li" , mpls-chairs@ietf.org, "Carlos Pignataro" , "Stewart Bryant" |
2017-01-23
|
03 | Stewart Bryant | Uploaded new revision |
2017-01-22
|
02 | Min Ye | Request for Early review by RTGDIR is assigned to Manav Bhatia |
2017-01-22
|
02 | Min Ye | Request for Early review by RTGDIR is assigned to Manav Bhatia |
2017-01-22
|
02 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2017-01-22
|
02 | Loa Andersson | Requested Early review by RTGDIR |
2017-01-22
|
02 | Loa Andersson | Intended Status changed to Informational from None |
2016-10-21
|
02 | Loa Andersson | Notification list changed to "Loa Andersson" <loa@pi.nu> |
2016-10-21
|
02 | Loa Andersson | Document shepherd changed to Loa Andersson |
2016-08-25
|
02 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-02.txt |
2016-06-10
|
01 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-01.txt |
2015-12-18
|
00 | Loa Andersson | This document now replaces draft-bryant-mpls-flow-ident instead of None |
2015-12-18
|
00 | Stewart Bryant | New version available: draft-ietf-mpls-flow-ident-00.txt |