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 <swallow.ietf@gmail.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Greg Mirsky <gregimirsky@gmail.com>, Mach Chen … Request for posting confirmation emailed to previous authors: George Swallow <swallow.ietf@gmail.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Greg Mirsky <gregimirsky@gmail.com>, Mach Chen <mach.chen@huawei.com>, Stewart Bryant <sb@stewartbryant.com> |
|
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 if/subset of … [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):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Loa Andersson <loa@pi.nu … The following Last Call announcement was sent out (ends 2021-01-26):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Loa Andersson <loa@pi.nu>, 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: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-mpls-rfc6374-sfl-08.txt> (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' <draft-ietf-mpls-rfc6374-sfl-08.txt> 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 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 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 <swallow.ietf@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Mach Chen <mach.chen@huawei.com>, Siva Sivabalan … Request for posting confirmation emailed to previous authors: George Swallow <swallow.ietf@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Mach Chen <mach.chen@huawei.com>, Siva Sivabalan <msiva@cisco.com>, mpls-chairs@ietf.org, Zhenbin Li <lizhenbin@huawei.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Stewart Bryant <stewart.bryant@gmail.com> |
|
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 <msiva@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Mach Chen … Request for posting confirmation emailed to previous authors: Siva Sivabalan <msiva@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Mach Chen <mach.chen@huawei.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, George Swallow <swallow.ietf@gmail.com>, Zhenbin Li <lizhenbin@huawei.com>, 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 <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky <gregimirsky@gmail.com>, George Swallow … Request for posting confirmation emailed to previous authors: Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky <gregimirsky@gmail.com>, George Swallow <swallow.ietf@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Mach Chen <mach.chen@huawei.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com> |
|
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 <giuseppe.fioccola@telecomitalia.it>, Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky … Request for posting confirmation emailed to previous authors: Giuseppe Fioccola <giuseppe.fioccola@telecomitalia.it>, Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky <gregimirsky@gmail.com>, mpls-chairs@ietf.org, George Swallow <swallow.ietf@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Mach Chen <mach.chen@huawei.com> |
|
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 <giuseppe.fioccola@telecomitalia.it>, Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky … Request for posting confirmation emailed to previous authors: Giuseppe Fioccola <giuseppe.fioccola@telecomitalia.it>, Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky <gregimirsky@gmail.com>, George Swallow <swallow.ietf@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Mach Chen <mach.chen@huawei.com> |
|
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 <giuseppe.fioccola@telecomitalia.it>, Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky … Request for posting confirmation emailed to previous authors: Giuseppe Fioccola <giuseppe.fioccola@telecomitalia.it>, Zhenbin Li <lizhenbin@huawei.com>, Siva Sivabalan <msiva@cisco.com>, Gregory Mirsky <gregimirsky@gmail.com>, George Swallow <swallow.ietf@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>, Mach Chen <mach.chen@huawei.com> |
|
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 <stewart.bryant@gmail.com>", replaces to (none) and sent approval email to group chairs: mpls-chairs@ietf.org |
|
2017-06-12
|
00 | Stewart Bryant | Uploaded new revision |