Skip to main content

RFC6374 Synonymous Flow Labels
draft-ietf-mpls-rfc6374-sfl-10

Revision differences

Document history

Date Rev. By Action
2021-03-26
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-03-24
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-03-24
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-03-24
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-03-24
10 (System) IANA Action state changed to In Progress from Waiting on WGC
2021-03-12
10 (System) IANA Action state changed to Waiting on WGC from In Progress
2021-03-08
10 (System) RFC Editor state changed to MISSREF
2021-03-08
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-03-08
10 (System) Announcement was received by RFC Editor
2021-03-08
10 (System) IANA Action state changed to In Progress
2021-03-05
10 (System) Removed all action holders (IESG state changed)
2021-03-05
10 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2021-03-05
10 Cindy Morgan IESG has approved the document
2021-03-05
10 Cindy Morgan Closed "Approve" ballot
2021-03-05
10 Cindy Morgan Ballot writeup was changed
2021-03-05
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-03-05
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-03-05
10 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-10.txt
2021-03-05
10 (System) Forced post of submission
2021-03-05
10 (System) Request for posting confirmation emailed to previous authors: George Swallow , Giuseppe Fioccola , Greg Mirsky , Mach Chen , Stewart Bryant
2021-03-05
10 Stewart Bryant Uploaded new revision
2021-03-05
09 Deborah Brungard Ballot writeup was changed
2021-03-05
09 Deborah Brungard Ballot approval text was changed
2021-03-04
09 Benjamin Kaduk
[Ballot comment]
Dropping from Discuss to No Objection based on edits staged in
the editor's copy.

Previous Discuss section:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
There may be a couple …
[Ballot comment]
Dropping from Discuss to No Objection based on edits staged in
the editor's copy.

Previous Discuss section:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
There may be a couple of internal (or external?) inconsistencies
lingering, and while my confidence level of that is not as high as it
often is, it's probably still worth checking.
Specifics in the COMMENT, but at a high level, do we use ACH value
0x000A (what's shown in Section 9) or the TBD IANA-allocated values; we
seem to refer to RFC 6374 as providing some things that I can't find in
it; and the IANA considerations registration request includes a "TLV
follows" column that does not appear to be present in the registry (and
does not appear to match the described behavior in the rest of the
document).  Perhaps this (the current registry state) is the result of
RFC 7026's actions, but I'm not entirely sure.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Previous Comment section:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
A bit more introduction about how the term "delay" is used as
effectively synonymous with "inter-packet gap" (for purposes of the
mechanisms presented in this document) would be appreciated.

Abstract, Introduction

(editorial) the phrases "general MPLS LSPs" and "general MPLS case",
while intended to contrast against RFC 6374's restriction to just
MPLS-TP, looks rather similar to "generalized MPLS" and could be a bit
confusing.  I'd suggest a phrasing like "the generic case of MPLS LSPs,
not limited to MPLS-TP".

Section 5

I'd suggest a legend that A/B are colors for loss measurement and C/D
are delay groups, and what is depicted is a time series of (the marking
of) packets transmitted.

  measurement types would be identical.  Thus, it is proposed that the
  two measurements are made relatively independent from each other.

How does this "proposed" relate to the simplifying rules in Section 6
that put some fairly strong dependencies on how delay measurements
relate to loss measurements?

Section 7.1

  The packet format of an RFC6374 Time Bucket Jitter Measurement
  Message is shown below:

It seems a little misleading to have "RFC6374" in the name here without
some classifier such as "framework" or "style", since the actual
structure does not appear in RFC 6374.
(Similarly for the other message formats.)

Section 7.2.1

  The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
  Session Identifier, and DS Fields are as defined in section 3.7 of
  RFC6374.  The remaining fields are as follows:

I don't see a Section 3.7 in RFC 6374.
This does, however, look like a lot like Section 3.3 thereof.

Section 7.4

  In this approach the packet is time-stamped at arrival and the
  Responder returns the sum of the time-stamps and the number of times-
  tamps.  From this the analytics engine can determine the mean delay.
  An alternative model is that the Responder returns the time stamp of
  the first and last packet and the number of packets.  This method has
  the advantage of allowing the average delay to be determined at a
  number of points along the packet path and allowing the components of
  the delay to be characterized.

This prose suggests that an implementation or deployment might choose
only one or the other of the "alternative model"s, but the packet layout
and accompanying field descriptions suggest that all fields are to be
populated, always.  Some clarity on whether it is permissible to select
only one of the alternatives would be welcome.

  The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
  Session Identifier, and DS Fields are as defined in section 3.7 of
  RFC6374.  The remaining fields are as follows:

(There is still no Section 3.7 in RFC 6374.)

Section 8

(editorial) The purpose of this section is somewhat unclear.  It seems
that the current text can (very roughly) be summarized as: "up until
now, we assume we measure every packet in a colored interval.  RFC 8321
did some other stuff; [details elided].  The RFC 8321 approach is not
impacted by ECMP effects."  Nowhere does it seem to say that the RFC
8321
approach is directly applicable to the RFC 6374-style packets
defined in this document, or some other reason why these facts are
noteworthy in the context of this document.

Section 9

Why do we only depict the use of ACH 0x000A (MPLS Direct Loss
Measurement) when we also perform delay measurement (which might use ACH
0x000C) and also seem to be allocating three additional codepoints that
would go in this range?

Should the figure still refer to an "RFC6374 Fixed Header" even though
we admit variable-length headers for some measurements?  (Also, it's a
bit surprising to use that terminology when RFC 6374 itself does not.)

  The RFC6374 measurement message consists of the three components, the
  RFC6374 fixed header as specified in [RFC6374] carried over the ACH
  channel type specified the type of measurement being made (currently:
  loss, delay or loss and delay) as specified in RFC6374.

It doesn't quite seem that "as specified in RFC 6374" applies, since
(IIUC) the "fixed header" is referring to the message formats from
Sections 7.1, 7.2.1, and 7.4 of this document.

  Two optional TLVs MAY also be carried if needed.  The first is the
  SFL TLV specified in Section 9.1.  This is used to provide the
  implementation with a reminder of the SFL that was used to carry the
  RFC6374 message.  This is needed because a number of MPLS
  implementations do not provide the MPLS label stack to the MPLS OAM
  handler.  This TLV is required if RFC6374 messages are sent over UDP
  [RFC7876].  This TLV MUST be included unless, by some method outside
  the scope of this document, it is known that this information is not
  needed by the RFC6374 Responder.

Is any entity tasked with ensuring consistency between the actual label
stack and the value in this TLV?

  otherwise MUST be carried.  The return address TLV is defined in
  RFC6378 and the optional UDP Return Object is defined in [RFC7876].

The Return Address TLV is specified in RFC 6374, not RFC 6378.

Section 9.1

  The required RFC6374 SFL TLV is shown in Figure 6.  This contains the

(nit) per the previous section, this TLV is only mostly required.

  SPL Index The index into the list of SFLs that were assigned
            against the FEC that corresponds to the SFL.

            Multiple SFLs can be assigned to a FEC each
            with different actions. This index is an optional
            convenience for use in mapping between the TLV
            and the associated data structures in the LSRs.

Is there any entity tasked with ensuring consistency between the index,
the SFL, and the batch?

Section 12

While I agree that there's not much new in this document, incorporating
by reference the considerations from (e.g.) 6374 and 8372, if not more,
seems in order.  If I understand correctly those would also pull in the
documentation of the generic privacy considerations with using user data
for monitoring.

One thing that might be new in this document is the potential for data
skew between the label stack and the SFL TLV, so that depending on one's
implementation the reported results would be different.  (Similarly for
batch/index/SFL relationships within the SFL TLV.)

Section 13.1

  As per the IANA considerations in [RFC5586], IANA is requested to
  allocate the following codeponts in the "MPLS Generalized Associated
  Channel (G-ACh) Type" registry, in the "Generic Associated Channel
  (G-ACh) Parameters" name space:

The only thing I see at
https://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml
that seems to match this description is written there as "MPLS
Generalized Associated Channel (G-ACh) Types (including Pseudowire
Associated Channel Types)".

I also don't see any "TLV follows" columns on that page, and don't
understand why "no" is listed for these, since Section 9 is clear that
the SFL TLV is mostly mandatory.

Section 16

If we are deferring to draft-bryant-mpls-sfl-control for the contents of
some protocol message fields, I can't see how it's anything other than a
normative reference.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2021-03-04
09 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-03-01
09 Wesley Eddy Closed request for Telechat review by TSVART with state 'Team Will not Review Version'
2021-03-01
09 Wesley Eddy Assignment of request for Telechat review by TSVART to Mirja Kühlewind was withdrawn
2021-02-25
09 (System) Changed action holders to Stewart Bryant, George Swallow, Mach Chen, Greg Mirsky, Giuseppe Fioccola (IESG state changed)
2021-02-25
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-02-25
09 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2021-02-25
09 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-02-25
09 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.

One minor nit:
  The document doesn't formally define the meaning of the reserved field in 7.2.1 and …
[Ballot comment]
Hi,

Thanks for this document.

One minor nit:
  The document doesn't formally define the meaning of the reserved field in 7.2.1 and 7.4.

Regards,
Rob
2021-02-25
09 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-02-25
09 Benjamin Kaduk
[Ballot discuss]
There may be a couple of internal (or external?) inconsistencies
lingering, and while my confidence level of that is not as high as …
[Ballot discuss]
There may be a couple of internal (or external?) inconsistencies
lingering, and while my confidence level of that is not as high as it
often is, it's probably still worth checking.
Specifics in the COMMENT, but at a high level, do we use ACH value
0x000A (what's shown in Section 9) or the TBD IANA-allocated values; we
seem to refer to RFC 6374 as providing some things that I can't find in
it; and the IANA considerations registration request includes a "TLV
follows" column that does not appear to be present in the registry (and
does not appear to match the described behavior in the rest of the
document).  Perhaps this (the current registry state) is the result of
RFC 7026's actions, but I'm not entirely sure.
2021-02-25
09 Benjamin Kaduk
[Ballot comment]
A bit more introduction about how the term "delay" is used as
effectively synonymous with "inter-packet gap" (for purposes of the
mechanisms presented …
[Ballot comment]
A bit more introduction about how the term "delay" is used as
effectively synonymous with "inter-packet gap" (for purposes of the
mechanisms presented in this document) would be appreciated.

Abstract, Introduction

(editorial) the phrases "general MPLS LSPs" and "general MPLS case",
while intended to contrast against RFC 6374's restriction to just
MPLS-TP, looks rather similar to "generalized MPLS" and could be a bit
confusing.  I'd suggest a phrasing like "the generic case of MPLS LSPs,
not limited to MPLS-TP".

Section 5

I'd suggest a legend that A/B are colors for loss measurement and C/D
are delay groups, and what is depicted is a time series of (the marking
of) packets transmitted.

  measurement types would be identical.  Thus, it is proposed that the
  two measurements are made relatively independent from each other.

How does this "proposed" relate to the simplifying rules in Section 6
that put some fairly strong dependencies on how delay measurements
relate to loss measurements?

Section 7.1

  The packet format of an RFC6374 Time Bucket Jitter Measurement
  Message is shown below:

It seems a little misleading to have "RFC6374" in the name here without
some classifier such as "framework" or "style", since the actual
structure does not appear in RFC 6374.
(Similarly for the other message formats.)

Section 7.2.1

  The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
  Session Identifier, and DS Fields are as defined in section 3.7 of
  RFC6374.  The remaining fields are as follows:

I don't see a Section 3.7 in RFC 6374.
This does, however, look like a lot like Section 3.3 thereof.

Section 7.4

  In this approach the packet is time-stamped at arrival and the
  Responder returns the sum of the time-stamps and the number of times-
  tamps.  From this the analytics engine can determine the mean delay.
  An alternative model is that the Responder returns the time stamp of
  the first and last packet and the number of packets.  This method has
  the advantage of allowing the average delay to be determined at a
  number of points along the packet path and allowing the components of
  the delay to be characterized.

This prose suggests that an implementation or deployment might choose
only one or the other of the "alternative model"s, but the packet layout
and accompanying field descriptions suggest that all fields are to be
populated, always.  Some clarity on whether it is permissible to select
only one of the alternatives would be welcome.

  The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
  Session Identifier, and DS Fields are as defined in section 3.7 of
  RFC6374.  The remaining fields are as follows:

(There is still no Section 3.7 in RFC 6374.)

Section 8

(editorial) The purpose of this section is somewhat unclear.  It seems
that the current text can (very roughly) be summarized as: "up until
now, we assume we measure every packet in a colored interval.  RFC 8321
did some other stuff; [details elided].  The RFC 8321 approach is not
impacted by ECMP effects."  Nowhere does it seem to say that the RFC
8321
approach is directly applicable to the RFC 6374-style packets
defined in this document, or some other reason why these facts are
noteworthy in the context of this document.

Section 9

Why do we only depict the use of ACH 0x000A (MPLS Direct Loss
Measurement) when we also perform delay measurement (which might use ACH
0x000C) and also seem to be allocating three additional codepoints that
would go in this range?

Should the figure still refer to an "RFC6374 Fixed Header" even though
we admit variable-length headers for some measurements?  (Also, it's a
bit surprising to use that terminology when RFC 6374 itself does not.)

  The RFC6374 measurement message consists of the three components, the
  RFC6374 fixed header as specified in [RFC6374] carried over the ACH
  channel type specified the type of measurement being made (currently:
  loss, delay or loss and delay) as specified in RFC6374.

It doesn't quite seem that "as specified in RFC 6374" applies, since
(IIUC) the "fixed header" is referring to the message formats from
Sections 7.1, 7.2.1, and 7.4 of this document.

  Two optional TLVs MAY also be carried if needed.  The first is the
  SFL TLV specified in Section 9.1.  This is used to provide the
  implementation with a reminder of the SFL that was used to carry the
  RFC6374 message.  This is needed because a number of MPLS
  implementations do not provide the MPLS label stack to the MPLS OAM
  handler.  This TLV is required if RFC6374 messages are sent over UDP
  [RFC7876].  This TLV MUST be included unless, by some method outside
  the scope of this document, it is known that this information is not
  needed by the RFC6374 Responder.

Is any entity tasked with ensuring consistency between the actual label
stack and the value in this TLV?

  otherwise MUST be carried.  The return address TLV is defined in
  RFC6378 and the optional UDP Return Object is defined in [RFC7876].

The Return Address TLV is specified in RFC 6374, not RFC 6378.

Section 9.1

  The required RFC6374 SFL TLV is shown in Figure 6.  This contains the

(nit) per the previous section, this TLV is only mostly required.

  SPL Index The index into the list of SFLs that were assigned
            against the FEC that corresponds to the SFL.

            Multiple SFLs can be assigned to a FEC each
            with different actions. This index is an optional
            convenience for use in mapping between the TLV
            and the associated data structures in the LSRs.

Is there any entity tasked with ensuring consistency between the index,
the SFL, and the batch?

Section 12

While I agree that there's not much new in this document, incorporating
by reference the considerations from (e.g.) 6374 and 8372, if not more,
seems in order.  If I understand correctly those would also pull in the
documentation of the generic privacy considerations with using user data
for monitoring.

One thing that might be new in this document is the potential for data
skew between the label stack and the SFL TLV, so that depending on one's
implementation the reported results would be different.  (Similarly for
batch/index/SFL relationships within the SFL TLV.)

Section 13.1

  As per the IANA considerations in [RFC5586], IANA is requested to
  allocate the following codeponts in the "MPLS Generalized Associated
  Channel (G-ACh) Type" registry, in the "Generic Associated Channel
  (G-ACh) Parameters" name space:

The only thing I see at
https://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml
that seems to match this description is written there as "MPLS
Generalized Associated Channel (G-ACh) Types (including Pseudowire
Associated Channel Types)".

I also don't see any "TLV follows" columns on that page, and don't
understand why "no" is listed for these, since Section 9 is clear that
the SFL TLV is mostly mandatory.

Section 16

If we are deferring to draft-bryant-mpls-sfl-control for the contents of
some protocol message fields, I can't see how it's anything other than a
normative reference.
2021-02-25
09 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-02-24
09 Murray Kucherawy [Ballot comment]
Please expand "PW" and "OAM" on first use (Section 1).
2021-02-24
09 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-02-24
09 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-02-24
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2021-02-24
09 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 5 ]

* "need to analyzed" -> "need to be analyzed", I suspect

* "need to considered" -> …
[Ballot comment]
[[ nits ]]

[ section 5 ]

* "need to analyzed" -> "need to be analyzed", I suspect

* "need to considered" -> "need to be considered", perhaps

[ section 7.1 ]

* "need to time intervals between buckets to be programmable" ->
  "need the time intervals between buckets to be programmable", maybe

[ section 12 ]

* "request.1" -> "request."
2021-02-24
09 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-02-24
09 Warren Kumari
[Ballot comment]
Much thanks to Sheng Jiang for the OpsDir review - due to time constraints I'm relying heavily on the directorate reviews this week. …
[Ballot comment]
Much thanks to Sheng Jiang for the OpsDir review - due to time constraints I'm relying heavily on the directorate reviews this week.

Thanks!
2021-02-24
09 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-02-24
09 Martin Duke
[Ballot comment]
- In Section 6, I understand the intent of #5 ("The duration of a second delay (D in Figure 1 batch must be …
[Ballot comment]
- In Section 6, I understand the intent of #5 ("The duration of a second delay (D in Figure 1 batch must be such
      that all packets from the packets belonging to a first delay
      batch (C in Figure 1)will have been received before the second
      delay batch completes.")

But given that this is a delay measurement, how can we ensure this property? Is this better formulated as "the sender will not stop sending for D until it receives feedback for C", or something to that effect?

- Sec 9.1: What does it mean that SPL Index is an "optional convenience"? Is the sender required to set it properly, but the receiver is free to ignore it if unneeded? Or is this optional for the sender somehow as well?
2021-02-24
09 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-02-24
09 Roman Danyliw
[Ballot comment]
Thank you to David Mandelberg for the SECDIR review.

* Section 12.  The cautions described in RFC6374 seem to largely apply here too.  …
[Ballot comment]
Thank you to David Mandelberg for the SECDIR review.

* Section 12.  The cautions described in RFC6374 seem to largely apply here too.  Please note that.
2021-02-24
09 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-02-24
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2021-02-22
09 Alvaro Retana
[Ballot comment]
draft-ietf-mpls-sfl-control (I-D.bryant-mpls-sfl-control) should be a Normative reference as one of the fields in the SF TLV depends on it.


[nits]

s/subset …
[Ballot comment]
draft-ietf-mpls-sfl-control (I-D.bryant-mpls-sfl-control) should be a Normative reference as one of the fields in the SF TLV depends on it.


[nits]

s/subset if/subset of

s/to analyzed/to be analyzed

s/to considered/to be considered

s/request.1/request.
2021-02-22
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-02-16
09 Wesley Eddy Request for Telechat review by TSVART is assigned to Mirja Kühlewind
2021-02-16
09 Wesley Eddy Request for Telechat review by TSVART is assigned to Mirja Kühlewind
2021-02-10
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-02-10
09 Cindy Morgan Placed on agenda for telechat - 2021-02-25
2021-02-10
09 Deborah Brungard Ballot has been issued
2021-02-10
09 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2021-02-10
09 Deborah Brungard Created "Approve" ballot
2021-02-10
09 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2021-02-10
09 Deborah Brungard Ballot writeup was changed
2021-02-10
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-02-10
09 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-09.txt
2021-02-10
09 (System) New version accepted (logged-in submitter: Stewart Bryant)
2021-02-10
09 Stewart Bryant Uploaded new revision
2021-02-02
08 Elwyn Davies Request for Last Call review by GENART Completed: Not Ready. Reviewer: Elwyn Davies. Sent review to list.
2021-01-29
08 Sheng Jiang Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Sheng Jiang. Sent review to list.
2021-01-26
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-01-25
08 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-01-25
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mpls-rfc6374-sfl-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mpls-rfc6374-sfl-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the MPLS Generalized Associated Channel (G-ACh) Types (inclGeneric Associated Channel (G-ACh) Parameters including Pseudowire Associated Channel Types) registry on the Generic Associated Channel (G-ACh) Parameters registry page located at:

https://www.iana.org/assignments/g-ach-parameters/

three new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: RFC6374 Bucket Jitter Measurement
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: RFC6374 Multi-Packet Delay Measurement
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: RFC6374 Average Delay Measurement
Reference: [ RFC-to-be ]

Second, in the MPLS Loss/Delay Measurement TLV Object registry also on the Generic Associated Channel (G-ACh) Parameters registry page located at:

https://www.iana.org/assignments/g-ach-parameters/

a single, new registration is to be made as follows:

Type: [ TBD-at-Registration ]
Description: Synonymous Flow Label
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 4 for this registration.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-01-25
08 Mirja Kühlewind Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Mirja Kühlewind. Sent review to list.
2021-01-24
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg. Submission of review completed at an earlier date.
2021-01-21
08 Wesley Eddy Request for Last Call review by TSVART is assigned to Mirja Kühlewind
2021-01-21
08 Wesley Eddy Request for Last Call review by TSVART is assigned to Mirja Kühlewind
2021-01-17
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: David Mandelberg.
2021-01-15
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2021-01-15
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2021-01-15
08 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2021-01-15
08 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2021-01-15
08 Mohit Sethi Assignment of request for Last Call review by GENART to Mohit Sethi was rejected
2021-01-14
08 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2021-01-14
08 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2021-01-14
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2021-01-14
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2021-01-12
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-01-12
08 Amy Vezza
The following Last Call announcement was sent out (ends 2021-01-26):

From: The IESG
To: IETF-Announce
CC: Loa Andersson , db3546@att.com, draft-ietf-mpls-rfc6374-sfl@ietf.org, loa@pi.nu, …
The following Last Call announcement was sent out (ends 2021-01-26):

From: The IESG
To: IETF-Announce
CC: Loa Andersson , db3546@att.com, draft-ietf-mpls-rfc6374-sfl@ietf.org, loa@pi.nu, mpls-chairs@ietf.org, mpls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RFC6374 Synonymous Flow Labels) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'RFC6374 Synonymous Flow Labels'
  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 2021-01-26. 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 describes a method of making RFC6374 performance
  measurements on flows carried over an MPLS Label Switched path.  This
  allows loss and delay measurements to be made on multi-point to point
  LSPs and allows the measurement of flows within an MPLS construct
  using RFC6374.




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


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

  https://datatracker.ietf.org/ipr/2706/
  https://datatracker.ietf.org/ipr/2989/
  https://datatracker.ietf.org/ipr/2991/





2021-01-12
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-01-12
08 Deborah Brungard Last call was requested
2021-01-12
08 Deborah Brungard Last call was requested
2021-01-12
08 Deborah Brungard Ballot approval text was generated
2021-01-12
08 Deborah Brungard Ballot writeup was generated
2021-01-12
08 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2021-01-12
08 Deborah Brungard Last call announcement was generated
2020-12-28
08 Andy Smith Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Andy Smith. Sent review to list.
2020-12-14
08 Min Ye Request for Last Call review by RTGDIR is assigned to Andy Smith
2020-12-14
08 Min Ye Request for Last Call review by RTGDIR is assigned to Andy Smith
2020-12-14
08 Min Ye Assignment of request for Last Call review by RTGDIR to Dave Sinicrope was rejected
2020-12-14
08 Min Ye Request for Last Call review by RTGDIR is assigned to Dave Sinicrope
2020-12-14
08 Min Ye Request for Last Call review by RTGDIR is assigned to Dave Sinicrope
2020-12-10
08 Deborah Brungard Requested Last Call review by RTGDIR
2020-12-09
08 Loa Andersson

The MPLS Working Group requests that

                  RFC6374 Synonymous Flow Labels
            …

The MPLS Working Group requests that

                  RFC6374 Synonymous Flow Labels
                    draft-ietf-mpls-rfc6374-sfl

are published as an RFC on the Standards Track.

(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 should be published as a Proposed Standard, it specifies
  protocoal and proceedures.
 

(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 extends the OAM procedures defined in RFC 8372 (for
  p2p and p2mp LSPs only), to include how to do Loss Measurment and
  Delay Measurement for the normal packet MPLS LSPs (mp2p). It also
  introduces a number of more sophisticated measurements that are
  applicable to p2p, p2mp and mp2p. The document addresses a
  number of problems that may lead to significant packet accounting
  problems, e.g. when the network uses ECMP.


Working Group Summary:

  The working group process has been smooth, it was unfortunately been
  delayed between the wglc and requesting publication, due to a
  misunderstanding where the authors and chairs were waiting and
  authors were waiting for eachother, and the state of the working
  group process were incorrectly captured in the in the data
  tracker.


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, YANG 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?

  We currently do not know of impleentations, but we have sent out an
  implementtion poll and will update the shepherds write-up as soon as
  we get more information.

  On the other hand the discussion that took place during the
  development of this docuement revealed that at least 3-4 companies
  intend to implement.

  No MIB Doctor, YANG Doctor, Media Type or other expert review outside
  the working group is necesarry for this document.

Personnel:

  Deborah Brungard is the responsible AD
  Loa Andersson is the Document Shepherd

(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 discussion of Synonymous Flow Labels, the shepherd as been part
  the discussion all the time since it was first brought to the
  working group (actually I think that the document lead discussed
  this we the shepherd prior to posting of the first draft).

  The document shepherd has read every document version and
  commented when becessary.

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

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

  During the life of a draft the MPLS wg does two IPR polls, one
  at the adoption on the document as a working group document and
  one at wglc. All authors and contributors has stated that they
  are unaware of any other IPRs than those disclosed to the IETF.

(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 three (3) IPR disclosures against this docuemnt,
  existing IPR disclosures are beought to the notice of the
  working group at WGAP and WGLC. There have been no comments
  received. which traditionally is interpreted as that there
  are no concerns.

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

  This is an extesion to MPLS that is widely understodd to
  be a good approach to meet operatro requirements. Given the
  general acceptance of the SFL approach the document becomes
  obvious. However, it is still necessary, for inter-operability
  reasons, to formally document exactly how SFLs are applied to
  RFC 6374. Hence there is a strong backing from all over the
  working group.

(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 http://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.

  The document shepherd has no discovered any further nitss.


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

    No such reviews necessary.

(13) Have all references within this document been identified as either normative or informative?

    Yes, the references ae correctly split in normative and 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 the normative references are to existing 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.

    All the normative referneces are to Standard Track RFCs

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

  The publication of this document will not change the status the
  status of any other 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 8126).

  The IANA section is fairly simple, 4 new code point from two existing
  registries. The section has been reviewed continiously, in fact version
  -08 was triggered by shepherd comments on the IANA section.

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

  Mo new IANA registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  No such automated reviews necessary

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The document does not contaim a YANG module.

2020-12-09
08 Loa Andersson Responsible AD changed to Deborah Brungard
2020-12-09
08 Loa Andersson IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-12-09
08 Loa Andersson IESG state changed to Publication Requested from I-D Exists
2020-12-09
08 Loa Andersson IESG process started in state Publication Requested
2020-12-09
08 Loa Andersson Changed consensus to Yes from Unknown
2020-12-09
08 Loa Andersson Intended Status changed to Proposed Standard from None
2020-12-09
08 Loa Andersson Tag Other - see Comment Log cleared.
2020-12-09
08 Loa Andersson IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2020-12-09
08 Loa Andersson

The MPLS Working Group requests that

                  RFC6374 Synonymous Flow Labels
            …

The MPLS Working Group requests that

                  RFC6374 Synonymous Flow Labels
                    draft-ietf-mpls-rfc6374-sfl

are published as an RFC on the Standards Track.

(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 should be published as a Proposed Standard, it specifies
  protocoal and proceedures.
 

(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 extends the OAM procedures defined in RFC 8372 (for
  p2p and p2mp LSPs only), to include how to do Loss Measurment and
  Delay Measurement for the normal packet MPLS LSPs (mp2p). It also
  introduces a number of more sophisticated measurements that are
  applicable to p2p, p2mp and mp2p. The document addresses a
  number of problems that may lead to significant packet accounting
  problems, e.g. when the network uses ECMP.


Working Group Summary:

  The working group process has been smooth, it was unfortunately been
  delayed between the wglc and requesting publication, due to a
  misunderstanding where the authors and chairs were waiting and
  authors were waiting for eachother, and the state of the working
  group process were incorrectly captured in the in the data
  tracker.


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, YANG 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?

  We currently do not know of impleentations, but we have sent out an
  implementtion poll and will update the shepherds write-up as soon as
  we get more information.

  On the other hand the discussion that took place during the
  development of this docuement revealed that at least 3-4 companies
  intend to implement.

  No MIB Doctor, YANG Doctor, Media Type or other expert review outside
  the working group is necesarry for this document.

Personnel:

  Deborah Brungard is the responsible AD
  Loa Andersson is the Document Shepherd

(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 discussion of Synonymous Flow Labels, the shepherd as been part
  the discussion all the time since it was first brought to the
  working group (actually I think that the document lead discussed
  this we the shepherd prior to posting of the first draft).

  The document shepherd has read every document version and
  commented when becessary.

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

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

  During the life of a draft the MPLS wg does two IPR polls, one
  at the adoption on the document as a working group document and
  one at wglc. All authors and contributors has stated that they
  are unaware of any other IPRs than those disclosed to the IETF.

(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 three (3) IPR disclosures against this docuemnt,
  existing IPR disclosures are beought to the notice of the
  working group at WGAP and WGLC. There have been no comments
  received. which traditionally is interpreted as that there
  are no concerns.

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

  This is an extesion to MPLS that is widely understodd to
  be a good approach to meet operatro requirements. Given the
  general acceptance of the SFL approach the document becomes
  obvious. However, it is still necessary, for inter-operability
  reasons, to formally document exactly how SFLs are applied to
  RFC 6374. Hence there is a strong backing from all over the
  working group.

(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 http://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.

  The document shepherd has no discovered any further nitss.


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

    No such reviews necessary.

(13) Have all references within this document been identified as either normative or informative?

    Yes, the references ae correctly split in normative and 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 the normative references are to existing 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.

    All the normative referneces are to Standard Track RFCs

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

  The publication of this document will not change the status the
  status of any other 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 8126).

  The IANA section is fairly simple, 4 new code point from two existing
  registries. The section has been reviewed continiously, in fact version
  -08 was triggered by shepherd comments on the IANA section.

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

  Mo new IANA registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  No such automated reviews necessary

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  The document does not contaim a YANG module.

2020-12-07
08 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-08.txt
2020-12-07
08 (System) New version accepted (logged-in submitter: Stewart Bryant)
2020-12-07
08 Stewart Bryant Uploaded new revision
2020-07-28
07 Loa Andersson Shepherd will write the Shepherd Write-Up.
2020-07-28
07 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2020-07-02
07 Loa Andersson IETF WG state changed to In WG Last Call from WG Document
2020-06-30
07 Loa Andersson Notification list changed to Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, draft-ietf-mpls-rfc6374-sfl@ietf.org from Loa Andersson <loa@pi.nu>
2020-06-08
07 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-07.txt
2020-06-08
07 (System) New version accepted (logged-in submitter: Stewart Bryant)
2020-06-08
07 Stewart Bryant Uploaded new revision
2020-06-04
06 Loa Andersson 2020-05-04: This document is in IPR poll before wglc.
2020-06-04
06 Loa Andersson Tag Other - see Comment Log set.
2020-06-04
06 Loa Andersson Notification list changed to Loa Andersson <loa@pi.nu>
2020-06-04
06 Loa Andersson Document shepherd changed to Loa Andersson
2020-05-26
06 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-06.txt
2020-05-26
06 (System) New version approved
2020-05-26
06 (System)
Request for posting confirmation emailed to previous authors: George Swallow , Greg Mirsky , Mach Chen , Siva Sivabalan , mpls-chairs@ietf.org, Zhenbin Li , …
Request for posting confirmation emailed to previous authors: George Swallow , Greg Mirsky , Mach Chen , Siva Sivabalan , mpls-chairs@ietf.org, Zhenbin Li , Giuseppe Fioccola , Stewart Bryant
2020-05-26
06 Stewart Bryant Uploaded new revision
2020-04-07
05 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-05.txt
2020-04-07
05 (System) New version approved
2020-04-07
05 (System)
Request for posting confirmation emailed to previous authors: Siva Sivabalan , Greg Mirsky , Stewart Bryant , Mach Chen , Giuseppe Fioccola , George Swallow …
Request for posting confirmation emailed to previous authors: Siva Sivabalan , Greg Mirsky , Stewart Bryant , Mach Chen , Giuseppe Fioccola , George Swallow , Zhenbin Li , mpls-chairs@ietf.org
2020-04-07
05 Stewart Bryant Uploaded new revision
2020-01-30
04 (System) Document has expired
2019-07-29
04 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-04.txt
2019-07-29
04 (System) New version approved
2019-07-29
04 (System)
Request for posting confirmation emailed to previous authors: Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen …
Request for posting confirmation emailed to previous authors: Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen , Giuseppe Fioccola
2019-07-29
04 Stewart Bryant Uploaded new revision
2019-06-15
03 (System) Document has expired
2018-12-12
03 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-03.txt
2018-12-12
03 (System) New version approved
2018-12-12
03 (System)
Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Zhenbin Li , Siva Sivabalan , Gregory Mirsky , mpls-chairs@ietf.org, George Swallow , …
Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Zhenbin Li , Siva Sivabalan , Gregory Mirsky , mpls-chairs@ietf.org, George Swallow , Stewart Bryant , Mach Chen
2018-12-12
03 Stewart Bryant Uploaded new revision
2018-06-20
02 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-02.txt
2018-06-20
02 (System) New version approved
2018-06-20
02 (System)
Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant …
Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen
2018-06-20
02 Stewart Bryant Uploaded new revision
2018-06-08
01 (System) Document has expired
2017-12-05
01 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-01.txt
2017-12-05
01 (System) New version approved
2017-12-05
01 (System)
Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant …
Request for posting confirmation emailed to previous authors: Giuseppe Fioccola , Zhenbin Li , Siva Sivabalan , Gregory Mirsky , George Swallow , Stewart Bryant , Mach Chen
2017-12-05
01 Stewart Bryant Uploaded new revision
2017-10-25
00 Loa Andersson This document now replaces draft-bryant-mpls-rfc6374-sfl instead of None
2017-06-12
00 Stewart Bryant New version available: draft-ietf-mpls-rfc6374-sfl-00.txt
2017-06-12
00 (System) WG -00 approved
2017-06-12
00 Stewart Bryant Set submitter to "Stewart Bryant ", replaces to (none) and sent approval email to group chairs: mpls-chairs@ietf.org
2017-06-12
00 Stewart Bryant Uploaded new revision