Skip to main content

MPLS Flow Identification Considerations
RFC 8372

Revision differences

Document history

Date Rev. By Action
2018-05-02
07 (System)
Received changes through RFC Editor sync (created alias RFC 8372, changed abstract to 'This document discusses aspects to consider when developing a solution for …
Received changes through RFC Editor sync (created alias RFC 8372, changed abstract to 'This document discusses aspects to consider when developing a solution for MPLS flow identification.  The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.', changed standardization level to Informational, changed state to RFC, added RFC published event at 2018-05-02, changed IESG state to RFC Published)
2018-05-02
07 (System) RFC published
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