Skip to main content

Synonymous Flow Label Framework
RFC 8957

Revision differences

Document history

Date Rev. By Action
2021-01-22
11 (System)
Received changes through RFC Editor sync (created alias RFC 8957, changed abstract to 'RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing …
Received changes through RFC Editor sync (created alias RFC 8957, changed abstract to 'RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture.  This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service.  These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.', changed pages to 9, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-01-22, changed IESG state to RFC Published)
2021-01-22
11 (System) RFC published
2021-01-19
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-11-16
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-11-06
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-10-29
11 (System) IANA Action state changed to No IANA Actions from In Progress
2020-10-28
11 (System) RFC Editor state changed to EDIT
2020-10-28
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-10-28
11 (System) Announcement was received by RFC Editor
2020-10-28
11 (System) IANA Action state changed to In Progress
2020-10-28
11 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2020-10-28
11 Cindy Morgan IESG has approved the document
2020-10-28
11 Cindy Morgan Closed "Approve" ballot
2020-10-28
11 Cindy Morgan Ballot approval text was generated
2020-10-28
11 Cindy Morgan Ballot writeup was changed
2020-10-28
11 Deborah Brungard Ballot approval text was changed
2020-10-02
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-02
11 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-11.txt
2020-10-02
11 (System) New version accepted (logged-in submitter: Stewart Bryant)
2020-10-02
11 Stewart Bryant Uploaded new revision
2020-09-24
10 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2020-09-24
10 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2020-09-24
10 Robert Wilton [Ballot comment]
Thanks for this document.  I found it both easy to read and follow.

Regards,
Rob
2020-09-24
10 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-24
10 Martin Vigoureux [Ballot comment]
Hi,

thank you for this document.

Interestingly you use ingress/egress LSR rather than LER.

Nit:
s/a existing label/an existing label/
2020-09-24
10 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-09-23
10 Roman Danyliw
[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Tero Kivinen for doing it)

I had the same reaction as …
[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Tero Kivinen for doing it)

I had the same reaction as Martin Duke – I found one RFC2119/normative phrase in the document (Section 5).  I’m not sure if this means it should be information or normative requirements should be articulated more clearly.

The reviews TSVART and Ben Kaduk already capture my feedback on Sections 6 and 7.

** Section 3.  What is “triggering IPFIX inspection”?  I wasn’t familiar with this phrasing.  Is the intent to trigger more in-depth analysis of header information, as opposed to “triggering … DPI”, which will do content inspection?

** Editorial Nits:
-- Section 3.  Typo. s/co-ordinating/coordinating/

-- Section 4.1.  Typo. s/are present/is present/

-- Section 5.  Typo. s/invalidate the certain uses/invalidate certain uses/
2020-09-23
10 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-23
10 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-21
10 Murray Kucherawy
[Ballot comment]
In Section 4.1.1, "LSE" should be expanded on first use.  Also in that section, "the SFL MAY be to some other value" is …
[Ballot comment]
In Section 4.1.1, "LSE" should be expanded on first use.  Also in that section, "the SFL MAY be to some other value" is missing the word "set".
2020-09-21
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-21
10 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENT points.

I hope that this helps …
[Ballot comment]
Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 1 --
I agree with other IESG review: this section could be expanded a little. Section 3 is the real introduction ;-)

-- Section 3 --
"also causes an agreed action", when there is an agreement, there are usual parties agreeing together. It is a little unclear what are those parties here ? Also, I am not sure whether the 'action' is really agreed upon; i.e., one router could use a SFL to get more QoS but the routers on the path with use this SFL to also do IPFIX or DPI...

For the sake of curiosity, I would have welcome some more words about how an PE router selects to use SFL or the 'normal' label: deep packet inspection ? or based on the ingress interface or ? (I may be completely wrong with this question)
2020-09-21
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-19
10 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 3 ]

* "make packet loss measurement": perhaps "make packet loss measurements"?

[ section 4.1.1 ]

* "an …
[Ballot comment]
[[ nits ]]

[ section 3 ]

* "make packet loss measurement": perhaps "make packet loss measurements"?

[ section 4.1.1 ]

* "an applications need" -> "an application need"

* "the SFL MAY be to some other value": perhaps
  "the SFL MAY be set to some other value"?

[ section 5 ]

* "invalidate the certain uses" -> "invalidate certain uses"
2020-09-19
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-18
10 Benjamin Kaduk
[Ballot comment]
I agree with the TSV-ART reviewer that some discussion of how/why the
RFC 8372 requirements are met would have been welcome.

Other than …
[Ballot comment]
I agree with the TSV-ART reviewer that some discussion of how/why the
RFC 8372 requirements are met would have been welcome.

Other than that, I basically only have nits and minor comments; this is
pretty straightforward and well-specified.

Section 1

The Introduction is essentially a verbatim copy of the Abstract with
formatting changes.  It seems likely that the Introduction could be
expanded slightly if desired.

  [RFC8372] (MPLS Flow Identification Considerations) describes the
  requirement for introducing flow identities within the MPLS

nit: "requirement" singular or "requirements" plural?  (It itself seems
to only claim to give "considerations" relevant for flow identification.)

  architecture.  This document describes a method of accomplishing this

nit: the second "this" that is to be accomplished doesn't have a
terribly precise referent -- it is in some sense "accomplishing the task
of meeting the requirements" but not "accomplishing the requirements".

  by using a technique called Synonymous Flow Labels (SFL) in which
  labels which mimic the behaviour of other labels provide the
  identification service.  These identifiers can be used to trigger
  per-flow operations on the packet at the receiving label switching
  router.

nit: we currently introduce the LSR acronym in Section 3 but this seems
to be the first non-Abstract usage.

Section 3

  An SFL is defined to be a label that causes exactly the same
  behaviour at the egress Label Switching Router (LSR) as the label it
  replaces, but in addition also causes an agreed action to take place
  on the packet.  There are many possible additional actions such as

nit: is this "agreed action" on the path or also at the egress?  If at
the egress, then "exactly the same behavior" is debatable, in a pedantic
sense.

  the measurement of the number of received packets in a flow,
  triggering IPFIX inspection, triggering other types of Deep Packet

nit: while IPFIX appears on
https://www.rfc-editor.org/materials/abbrev.expansion.txt it is not
marked as "well-known", thus probably merits expansion.

  acceptable for scaling reasons.  We therefore have no choice but to
  introduce an additional label.  Where penultimate hop popping (PHP)
  is in use, the semantics of this additional label can be similar to
  the LSP label.  Where PHP is not in use, the semantics are similar to
  an MPLS explicit NULL [RFC3032].  In both of these cases the label
  has the additional semantics of the SFL.

[I note that here we weaken the statement to be only "similar to", not
"exactly the same".]

  Finally we need to consider the case where there is no MPLS
  application label such as occurs when sending IP over an LSP.  In

nit/editorial: I would consider mentioning the application label
earlier, to accentuate the contrasting case being introduced here.

Section 4

  As noted in Section 3 it is necessary to consider two cases:
  [...]
  2.  Single label stack

(editorial) Some minor rewording in Section 3 to specifically mention
the "single label stack" case in such terms would probably help the
document feel more cohesive.  (I assume it's meant to be the converse of
the "application label present" case, i.e., the "there is no MPLS
application label such as occurs when sending IP over an LSP" case.)

Section 4.1

  At the egress LSR the LSP label is popped (if present).  Then the SFL
  is processed in exactly the same way as the corresponding application
  label would have been processed.

[Just noting that "exact" is used here; I have no specific comment]

Section 4.1.1

  that the SFL is synonymous with.  However it is recognised that, if
  there is an applications need, the SFL MAY be to some other value.

(nit) Barry already noted the missing "set", but I think it's also "the
TTL and TC bits in the SFL" and not the SFL itself -- the SFL itself is
inherently a different value, otherwise it would be called the
"identical flow label" and we probably wouldn't be writing a document
about it :)

Section 4.2

I wondered to myself for Figure 1, and wonder out loud here for Figure
2, if we can make some indication that the "May be PHPed" applies to
both the "Normal" label stack as well as to the "with SFL" label stack.
(For Figure 1 it was vertically aligned, but is not so, here.)

  If the LSP label is present, it processed exactly as it would
  normally processed and then it is popped.  This reveals the SFL which
  in the case of [RFC6374] measurements is simply counted and then
  discarded.  In this respect the processing of the SFL is synonymous

nit: it's not entirely clear to me why this specific case merits mention of
RFC 6374 measurement but we don't want to mention it anywhere earlier.

Section 4.3

Is the Aggregate SFL also in some sense "synonymous with Explicit NULL"
(as was mentioned in Figure 2)?

Section 5

  2.  The operator can elect to use [RFC6790] Entropy Labels in a
      network that fully supports this type of ECMP.  If this approach
      is adopted, the intervening MPLS network MUST NOT load balance on
      any packet field other than the entropy label.  Note that this is
      stricter than the text in Section 4.2 of [RFC6790].  In networks

Is Section 4.2 ("Ingress LSR") really the best reference in RFC 6790?
Section 4.3 seems much more relevant, to me.

      in which the ECMP decision is independent of both the value of
      any other label in the label stack, and the MPLS payload, the
      path of the flow with the SFL will be congruent with the path
      without the SFL.

(side note) what would the ECMP decision be made on, in that case?  A
random number generator?

Section 6

Thank you for noting the privacy considerations even though the
incremental exposure is fairly small!

I might note that whenever IPFIX or other DPI techniques are used, their
relevant privacy considerations apply.

  The inclusion of originating and/or flow information in a packet
  provides more identity information and hence potentially degrades the
  privacy of the communication.  Whilst the inclusion of the additional

At risk of banality, I suggest "potentially degrades the privacy of the
communiation to an attacker in position to observe the added
identifier", to subtly emphasize that the relevant attacker here has
capabilities that already allow for similar types of attack.  That is,
what's new for the attacker here is that they get some signal as to how
the ingress decides to classify traffic -- they already have all the
traffic in the first place and could be doing their own classification
on it.

  granularity does allow greater insight into the flow characteristics
  it does not specifically identify which node originated the packet
  other than by inspection of the network at the point of ingress, or
  inspection of the control protocol packets.  This privacy threat may

nit: I suggest s/other than by/unless the attacker can/; s/inspection
of/inspect/ (since the attacker needs to both observe the labeled
traffic and obtain the origination-mapping information in order to
effectuate the identification).

Section 7

I think that the type of attack opened up by having multiple synonyms
for conceptulaly "the same traffic", that Tero noted in the secdir
review, would be in cases where the attacker is sending traffic over the
LSP in question and knows both the classification algorithm used to
apply the SFL and the nature of the DPI performed on SFL-marked traffic,
and is thus able to ensure that whatever nefarious things they are doing
that would have been noticed by the DPI instead take the non-DPI path
and remain undetected.  Now, AFAICT the type of DPI envisioned here is
mostly not going to be looking for nefarious things, and even the
existence of such nefarious things that need to be going over this LSP
that the attacker can already send traffic over seems a bit contrived,
but that's my take on the additional incremental attack that this
mechanism opens up.

  There are no new security issues associated with the MPLS dataplane.
  Any control protocol used to request SFLs will need to ensure the
  legitimacy of the request.

I'd suggest mentioning authorization checks as well -- a request can in
some sense still be "legitimate" even if the requestor is not currently
authorized to receive the service.

Section 10.2

Hmm, in some reading "can elect to use [RFC6790] Entropy Labels" [..]
MUST NOT load balance on any packet field other than the entropy label"
makes 6790 a normative reference (required reading for an optional
feature).
2020-09-18
10 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-09-18
10 Martin Duke
[Ballot comment]
I counted a total of three normative requirements in this document, none of them earth-shattering, and wonder if this could be changed to …
[Ballot comment]
I counted a total of three normative requirements in this document, none of them earth-shattering, and wonder if this could be changed to Informational and perhaps the important requirements moved into drafts that provide interoperable specs. ISTM that asking implementers to implement both this and a draft that describes an actual protocol is unnecessarily heavyweight.
2020-09-18
10 Martin Duke Ballot comment text updated for Martin Duke
2020-09-18
10 Martin Duke
[Ballot comment]
I counted a total of three normative requirements in this document, none if them earth-shattering, and wonder if this could be changed to …
[Ballot comment]
I counted a total of three normative requirements in this document, none if them earth-shattering, and wonder if this could be changed to Informational and perhaps the important requirements moved into drafts that provide interoperable specs. ISTM that asking implementers to implement both this and a draft that describes an actual protocol is unnecessarily heavyweight.
2020-09-18
10 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-09-18
10 Barry Leiba
[Ballot comment]
Thanks for a clear, well-written document that was an easy read.  Just a few nits here:

— Section 3 —

  would introduce …
[Ballot comment]
Thanks for a clear, well-written document that was an easy read.  Just a few nits here:

— Section 3 —

  would introduce network wide forwarding state.

“network-wide” needs a hyphen

  Note that to achieve the goals set out above SFLs need to be
  allocated from the platform label table.

A comma after “above” will help readability here (avoiding a reading of “above SFLs”).

— Section 4.1 —
The title says “applications label” and the first paragraph says “application label”.  It seems that this should be consistent.

  function present runs over the "normal" stack, and SFL enabled flows

“SFL-enabled” needs a hyphen (also in Section 4.2).

— Section 4.1.1 —

  However it is recognised that, if
  there is an applications need, the SFL MAY be to some other value.

I think “MAY be set to some other value” (add “set”) reads better.

— Section 4.2 —

  If the LSP label is present, it processed exactly as it would
  normally processed and then it is popped.

Missing words: “it is processsed” and “normally be processed”.

  This reveals the SFL which
  in the case of [RFC6374] measurements is simply counted and then

Punctuation: “SFL, which, in the case of [RFC6374] measurements, is”

  system described in this document the behaviour of two approaches are
  indistinguishable and thus either may be implemented.

Missing word: “of the two approaches”.
And “behaviours”, needs to be plural.

— Section 4.3 —

  application is large, and consequently the increase in the number of
  allocated labels needed to support the SFL actions consequently
  becomes too large to be viable.

You have “consequently” twice, and should remove one of them.

— Section 5 —

  The introduction to an SFL to an existing flow may cause that flow to

Make it, “The introduction of an SFL to an existing flow”.

  This in turn may invalidate the certain uses

Remove “the”.

— Section 6 —

  This privacy threat may
  be mitigated by encrypting the control protocol packets, regularly
  changing the synonymous labels and by concurrently using a number of
  such labels.

The second item isn’t parallel to the other two.  Either make it “by regularly” (to make the second item match the third) or remove “by” before “concurrently” (to make the third match the second).

Also, is “and” right?  Would you do all three of these together?  Or should it be “or”?  I’m not sure, but I wanted to check.
2020-09-18
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-09-16
10 Cindy Morgan Placed on agenda for telechat - 2020-09-24
2020-09-16
10 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2020-09-16
10 Deborah Brungard Ballot has been issued
2020-09-16
10 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2020-09-16
10 Deborah Brungard Created "Approve" ballot
2020-09-16
10 Deborah Brungard Ballot writeup was changed
2020-09-16
10 Tarek Saad
Writeup for draft-ietf-mpls-sfl-framework-05.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper …
Writeup for draft-ietf-mpls-sfl-framework-05.txt

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

Intended status: Standards Track on the title page.
This RFC describes a Synonymous Flow Label framework for achieving flow identities within the MPLS architecture.

(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

From the Abstract:
  RFC 8372 describes the requirement for introducing flow identities
  within the MPLS architecture.  This document describes a method of
  accomplishing this by using a technique called Synonymous Flow Labels
  in which labels which mimic the behaviour of other labels provide the
  identification service.  These identifiers can be used to trigger
  per-flow operations on the packet at the receiving label
  switching router.
 
Working Group Summary

The Working Group has reached consensus that this document is useful and should be published.
This document went through multiple reviews within the working group over the course of its development.
The techniques defined in this document are useful in several applications, such as the
measurement of the number of received packets in a flow for performance monitoring,
triggering IPFIX inspection, triggering other types of Deep Packet
Inspection, or identification of the packet source.

   
Document Quality

Review was done by MPLS review-team (MPLS-RT) and from several members of the WG.
All comments have been addressed, and there are currently no open issues.

Personnel

Tarek Saad is the Document Shepherd.
Deborah Brungard 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.

The document shepherd has reviewed the specification during WG last call and subsequently
checked all diffs. Comments on the mailing list were addressed in the last version.

There are other companion drafts to this document that are progressing in parallel.
draft-ietf-mpls-rfc6374-sfl
and draft-bryant-mpls-sfl-control
The control plane draft  is optional and this technology could be deployed using SDN/controller based methods.

The document shepherd believes that this document is ready for publication.

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

The shepherd has no concerns about the depth and breadth of the reviews that were performed.

(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.

The document still needs to be reviewed by the relevant directorates.

(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.

Some discussions were triggered on the mailing list pertaining to the SFL Control message
exchange. These will be addressed/closed as part of draft-bryant-mpls-sfl-control.
The shepherd does not have any other concerns about this document.

(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. There were no specific discussions or conclusions in the WG.

(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 consensus of all people who have reviewed and contributed to the 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.

(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.

None errors found.

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

Appropriate MPLS expert reviews and WG reviews have been done.

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

None.

(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.

None.

(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 other documents when this document is published.

(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 draft makes no IANA requests.

(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 new IANA registries are being defined.

(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 formal reviews necessary.
2020-09-16
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-09-15
10 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-09-15
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mpls-sfl-framework-10, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mpls-sfl-framework-10, 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
2020-09-08
10 Bernard Aboba Request for Last Call review by TSVART Completed: Ready. Reviewer: Bernard Aboba. Sent review to list.
2020-09-08
10 Wesley Eddy Request for Last Call review by TSVART is assigned to Bernard Aboba
2020-09-08
10 Wesley Eddy Request for Last Call review by TSVART is assigned to Bernard Aboba
2020-09-02
10 Amy Vezza
The following Last Call announcement was sent out (ends 2020-09-16):

From: The IESG
To: IETF-Announce
CC: tsaad.net@gmail.com, mpls-chairs@ietf.org, draft-ietf-mpls-sfl-framework@ietf.org, mpls@ietf.org, db3546@att.com …
The following Last Call announcement was sent out (ends 2020-09-16):

From: The IESG
To: IETF-Announce
CC: tsaad.net@gmail.com, mpls-chairs@ietf.org, draft-ietf-mpls-sfl-framework@ietf.org, mpls@ietf.org, db3546@att.com, Tarek Saad
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Synonymous Flow Label Framework) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Synonymous Flow Label Framework'
  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
last-call@ietf.org mailing lists by 2020-09-16. 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


  RFC 8372 (MPLS Flow Identification Considerations) describes the
  requirement for introducing flow identities within the MPLS
  architecture.  This document describes a method of accomplishing this
  by using a technique called Synonymous Flow Labels in which labels
  which mimic the behaviour of other labels provide the identification
  service.  These identifiers can be used to trigger per-flow
  operations on the packet at the receiving label switching router.

Note: This is a 2nd Last Call to reflect the status change from Informational to Proposed Standard as a result of comments received during Directorate reviews.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sfl-framework/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2705/
  https://datatracker.ietf.org/ipr/2605/
  https://datatracker.ietf.org/ipr/2582/
  https://datatracker.ietf.org/ipr/2849/





2020-09-02
10 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-09-02
10 Amy Vezza Last call announcement was changed
2020-09-02
10 Amy Vezza Last call announcement was generated
2020-09-02
10 Deborah Brungard Last call was requested
2020-09-02
10 Deborah Brungard IESG state changed to Last Call Requested from Waiting for Writeup
2020-09-02
10 Deborah Brungard Last call announcement was changed
2020-09-02
10 Deborah Brungard Intended Status changed to Proposed Standard from Informational
2020-08-27
10 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-10.txt
2020-08-27
10 (System) New version accepted (logged-in submitter: Stewart Bryant)
2020-08-27
10 Stewart Bryant Uploaded new revision
2020-07-16
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2020-07-08
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-07-08
09 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-09.txt
2020-07-08
09 (System) New version accepted (logged-in submitter: Stewart Bryant)
2020-07-08
09 Stewart Bryant Uploaded new revision
2020-07-06
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-07-02
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Tero Kivinen. Sent review to list.
2020-07-02
08 Al Morton Assignment of request for Last Call review by OPSDIR to Al Morton was rejected
2020-07-02
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2020-07-02
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2020-07-01
08 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-07-01
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mpls-sfl-framework-08, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mpls-sfl-framework-08, 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
2020-06-30
08 Bernard Aboba Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Bernard Aboba. Sent review to list.
2020-06-29
08 Pete Resnick Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list.
2020-06-27
08 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2020-06-27
08 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2020-06-27
08 Mohit Sethi Assignment of request for Last Call review by GENART to Mohit Sethi was rejected
2020-06-26
08 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2020-06-26
08 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2020-06-25
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2020-06-25
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2020-06-23
08 Wesley Eddy Request for Last Call review by TSVART is assigned to Bernard Aboba
2020-06-23
08 Wesley Eddy Request for Last Call review by TSVART is assigned to Bernard Aboba
2020-06-22
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-06-22
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-07-06):

From: The IESG
To: IETF-Announce
CC: Tarek Saad , db3546@att.com, mpls-chairs@ietf.org, tsaad.net@gmail.com, …
The following Last Call announcement was sent out (ends 2020-07-06):

From: The IESG
To: IETF-Announce
CC: Tarek Saad , db3546@att.com, mpls-chairs@ietf.org, tsaad.net@gmail.com, draft-ietf-mpls-sfl-framework@ietf.org, mpls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Synonymous Flow Label Framework) to Informational RFC


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Synonymous Flow Label Framework'
  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
last-call@ietf.org mailing lists by 2020-07-06. 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


  RFC 8372 (MPLS Flow Identification Considerations) describes the
  requirement for introducing flow identities within the MPLS
  architecture.  This document describes a method of accomplishing this
  by using a technique called Synonymous Flow Labels in which labels
  which mimic the behaviour of other labels provide the identification
  service.  These identifiers can be used to trigger per-flow
  operations on the packet at the receiving label switching router.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sfl-framework/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2705/
  https://datatracker.ietf.org/ipr/2605/
  https://datatracker.ietf.org/ipr/2582/
  https://datatracker.ietf.org/ipr/2849/





2020-06-22
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-06-22
08 Deborah Brungard Last call was requested
2020-06-22
08 Deborah Brungard Ballot approval text was generated
2020-06-22
08 Deborah Brungard Ballot writeup was generated
2020-06-22
08 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2020-06-22
08 Deborah Brungard Last call announcement was changed
2020-06-08
08 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-08.txt
2020-06-08
08 (System) New version accepted (logged-in submitter: Stewart Bryant)
2020-06-08
08 Stewart Bryant Uploaded new revision
2020-06-03
07 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-07.txt
2020-06-03
07 (System) New version approved
2020-06-03
07 (System)
Request for posting confirmation emailed to previous authors: Stewart Bryant , Zhenbin Li , George Swallow , Siva Sivabalan , Greg Mirsky , mpls-chairs@ietf.org, …
Request for posting confirmation emailed to previous authors: Stewart Bryant , Zhenbin Li , George Swallow , Siva Sivabalan , Greg Mirsky , mpls-chairs@ietf.org, Mach Chen
2020-06-03
07 Stewart Bryant Uploaded new revision
2020-05-29
06 Deborah Brungard Authors pinged to respond to rtg-dir reviewer.
2020-05-29
06 Deborah Brungard Changed consensus to Yes from Unknown
2020-02-05
06 Michael Richardson Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Michael Richardson. Sent review to list.
2020-02-05
06 Min Ye Request for Last Call review by RTGDIR is assigned to Michael Richardson
2020-02-05
06 Min Ye Request for Last Call review by RTGDIR is assigned to Michael Richardson
2020-02-03
06 Deborah Brungard Requested Last Call review by RTGDIR
2020-02-02
06 Tarek Saad
Writeup for draft-ietf-mpls-sfl-framework-05.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper …
Writeup for draft-ietf-mpls-sfl-framework-05.txt

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

Intended status: Informational indicated on the title page.
This RFC describes a Synonymous Flow Label framework for achieving flow identities within the MPLS architecture.

(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

From the Abstract:
  RFC 8372 describes the requirement for introducing flow identities
  within the MPLS architecture.  This document describes a method of
  accomplishing this by using a technique called Synonymous Flow Labels
  in which labels which mimic the behaviour of other labels provide the
  identification service.  These identifiers can be used to trigger
  per-flow operations on the packet at the receiving label
  switching router.
 
Working Group Summary

The Working Group has reached consensus that this document is useful and should be published.
This document went through multiple reviews within the working group over the course of its development.
The techniques defined in this document are useful in several applications, such as the
measurement of the number of received packets in a flow for performance monitoring,
triggering IPFIX inspection, triggering other types of Deep Packet
Inspection, or identification of the packet source.

   
Document Quality

Review was done by MPLS review-team (MPLS-RT) and from several members of the WG.
All comments have been addressed, and there are currently no open issues.

Personnel

Tarek Saad is the Document Shepherd.
Deborah Brungard 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.

The document shepherd has reviewed the specification during WG last call and subsequently
checked all diffs. Comments on the mailing list were addressed in the last version.

There are other companion drafts to this document that are progressing in parallel.
draft-ietf-mpls-rfc6374-sfl
and draft-bryant-mpls-sfl-control
The control plane draft  is optional and this technology could be deployed using SDN/controller based methods.

The document shepherd believes that this document is ready for publication.

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

The shepherd has no concerns about the depth and breadth of the reviews that were performed.

(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.

The document still needs to be reviewed by the relevant directorates.

(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.

Some discussions were triggered on the mailing list pertaining to the SFL Control message
exchange. These will be addressed/closed as part of draft-bryant-mpls-sfl-control.
The shepherd does not have any other concerns about this document.

(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. There were no specific discussions or conclusions in the WG.

(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 consensus of all people who have reviewed and contributed to the 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.

(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.

None errors found.

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

Appropriate MPLS expert reviews and WG reviews have been done.

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

None.

(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.

None.

(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 other documents when this document is published.

(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 draft makes no IANA requests.

(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 new IANA registries are being defined.

(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 formal reviews necessary.
2020-02-02
06 Tarek Saad Responsible AD changed to Deborah Brungard
2020-02-02
06 Tarek Saad IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2020-02-02
06 Tarek Saad IESG state changed to Publication Requested from I-D Exists
2020-02-02
06 Tarek Saad IESG process started in state Publication Requested
2020-02-02
06 Tarek Saad Tag Doc Shepherd Follow-up Underway cleared.
2020-02-02
06 Tarek Saad Intended Status changed to Informational from None
2020-01-14
06 Tarek Saad Tag Doc Shepherd Follow-up Underway set.
2020-01-14
06 Tarek Saad IETF WG state changed to In WG Last Call from WG Document
2019-10-22
06 Tarek Saad
Writeup for draft-ietf-mpls-sfl-framework-05.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper …
Writeup for draft-ietf-mpls-sfl-framework-05.txt

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

Intended status: Informational indicated on the title page.
This RFC describes a Synonymous Flow Label framework for achieving flow identities within the MPLS architecture.

(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

From the Abstract:
  RFC 8372 describes the requirement for introducing flow identities
  within the MPLS architecture.  This document describes a method of
  accomplishing this by using a technique called Synonymous Flow Labels
  in which labels which mimic the behaviour of other labels provide the
  identification service.  These identifiers can be used to trigger
  per-flow operations on the packet at the receiving label
  switching router.
 
Working Group Summary

The Working Group has reached consensus that this document is useful and should be published.
This document went through multiple reviews within the working group over the course of its development.
The techniques defined in this document are useful in several applications, such as the
measurement of the number of received packets in a flow for performance monitoring,
triggering IPFIX inspection, triggering other types of Deep Packet
Inspection, or identification of the packet source.

   
Document Quality

Review was done by MPLS review-team (MPLS-RT) and from several members of the WG.
All comments have been addressed, and there are currently no open issues.

Personnel

Tarek Saad is the Document Shepherd.
Deborah Brungard 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.

The document shepherd has reviewed the specification during WG last call and subsequently
checked all diffs. Comments on the mailing list were addressed in the last version.

There are other companion drafts to this document that are progressing in parallel.
draft-ietf-mpls-rfc6374-sfl
and draft-bryant-mpls-sfl-control
The control plane draft  is optional and this technology could be deployed using SDN/controller based methods.

The document shepherd believes that this document is ready for publication.

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

The shepherd has no concerns about the depth and breadth of the reviews that were performed.

(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.

The document still needs to be reviewed by the relevant directorates.

(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.

Some discussions were triggered on the mailing list pertaining to the SFL Control message
exchange. These will be addressed/closed as part of draft-bryant-mpls-sfl-control.
The shepherd does not have any other concerns about this document.

(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. There were no specific discussions or conclusions in the WG.

(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 consensus of all people who have reviewed and contributed to the 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.

(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.

None errors found.

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

Appropriate MPLS expert reviews and WG reviews have been done.

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

None.

(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.

None.

(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 other documents when this document is published.

(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 draft makes no IANA requests.

(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 new IANA registries are being defined.

(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 formal reviews necessary.
2019-10-09
06 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-06.txt
2019-10-09
06 (System) New version approved
2019-10-09
06 (System) Request for posting confirmation emailed to previous authors: Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen
2019-10-09
06 Stewart Bryant Uploaded new revision
2019-10-08
05 Tarek Saad
Writeup for draft-ietf-mpls-sfl-framework-05.txt

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper …
Writeup for draft-ietf-mpls-sfl-framework-05.txt

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

Intended status: Informational indicated on the title page.
This RFC describes a Synonymous Flow Label framework for achieving flow identities within the MPLS architecture.

(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

From the Abstract:
  RFC 8372 describes the requirement for introducing flow identities
  within the MPLS architecture.  This document describes a method of
  accomplishing this by using a technique called Synonymous Flow Labels
  in which labels which mimic the behaviour of other labels provide the
  identification service.  These identifiers can be used to trigger
  per-flow operations on the packet at the receiving label
  switching router.
 
Working Group Summary

The Working Group has reached consensus that this document is useful and should be published.
This document went through multiple reviews within the working group over the course of its development.
The techniques defined in this document are useful in several applications, such as the
measurement of the number of received packets in a flow for performance monitoring,
triggering IPFIX inspection, triggering other types of Deep Packet
Inspection, or identification of the packet source.

   
Document Quality

Review was done by MPLS review-team (MPLS-RT) and from several members of the WG.
All comments have been addressed, and there are currently no open issues.

Personnel

Tarek Saad is the Document Shepherd.
Deborah Brungard 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.

The document shepherd has reviewed the specification during WG last call and subsequently
checked all diffs. Comments on the mailing list were addressed in the last version.
There are other companion drafts to this document that are progressing in parallel:
draft-ietf-mpls-rfc6374-sfl
and draft-bryant-mpls-sfl-control

The document shepherd believes that this document is ready for publication.

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

The shepherd has no concerns about the depth and breadth of the reviews that were performed.

(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.

The document still needs to be reviewed by the relevant directorates.

(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.

Some discussions were triggered on the mailing list pertaining to the SFL Control message
exchange. These will be addressed/closed as part of draft-bryant-mpls-sfl-control.
The shepherd does not have any other concerns about this document.

(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. There were no specific discussions or conclusions in the WG.

(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 consensus of all people who have reviewed and contributed to the 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.

(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.

None errors found.

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

Appropriate MPLS expert reviews and WG reviews have been done.

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

None.

(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.

None.

(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 other documents when this document is published.

(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 draft makes no IANA requests.

(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 new IANA registries are being defined.

(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 formal reviews necessary.
2019-10-08
05 Tarek Saad Notification list changed to Tarek Saad <tsaad.net@gmail.com>
2019-10-08
05 Tarek Saad Document shepherd changed to Tarek Saad
2019-07-29
05 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-05.txt
2019-07-29
05 (System) New version approved
2019-07-29
05 (System) Request for posting confirmation emailed to previous authors: Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen
2019-07-29
05 Stewart Bryant Uploaded new revision
2019-06-15
04 (System) Document has expired
2018-12-12
04 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-04.txt
2018-12-12
04 (System) New version approved
2018-12-12
04 (System) Request for posting confirmation emailed to previous authors: Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen
2018-12-12
04 Stewart Bryant Uploaded new revision
2018-06-18
03 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-03.txt
2018-06-18
03 (System) New version approved
2018-06-18
03 (System)
Request for posting confirmation emailed to previous authors: Gregory Mirsky , Siva Sivabalan , Stewart Bryant , George Swallow , mpls-chairs@ietf.org, Mach Chen , …
Request for posting confirmation emailed to previous authors: Gregory Mirsky , Siva Sivabalan , Stewart Bryant , George Swallow , mpls-chairs@ietf.org, Mach Chen , Zhenbin Li
2018-06-18
03 Stewart Bryant Uploaded new revision
2018-06-18
02 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-02.txt
2018-06-18
02 (System) New version approved
2018-06-18
02 (System)
Request for posting confirmation emailed to previous authors: Gregory Mirsky , George Swallow , Siva Sivabalan , Stewart Bryant , mpls-chairs@ietf.org, Mach Chen , …
Request for posting confirmation emailed to previous authors: Gregory Mirsky , George Swallow , Siva Sivabalan , Stewart Bryant , mpls-chairs@ietf.org, Mach Chen , Zhenbin Li
2018-06-18
02 Stewart Bryant Uploaded new revision
2018-01-29
01 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-01.txt
2018-01-29
01 (System) New version approved
2018-01-29
01 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , George Swallow , Siva Sivabalan , Stewart Bryant , Mach Chen , Zhenbin Li
2018-01-29
01 Stewart Bryant Uploaded new revision
2017-08-01
00 Loa Andersson This document now replaces draft-bryant-mpls-sfl-framework instead of None
2017-08-01
00 Stewart Bryant New version available: draft-ietf-mpls-sfl-framework-00.txt
2017-08-01
00 (System) WG -00 approved
2017-08-01
00 Stewart Bryant Set submitter to "Stewart Bryant ", replaces to draft-bryant-mpls-sfl-framework and sent approval email to group chairs: mpls-chairs@ietf.org
2017-08-01
00 Stewart Bryant Uploaded new revision