Ethernet Traffic Parameters with Availability Information
draft-ietf-ccamp-rsvp-te-bandwidth-availability-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-08-15
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-06-18
|
16 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-06-07
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-05-16
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-05-15
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-05-15
|
16 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-05-15
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-05-08
|
16 | (System) | RFC Editor state changed to EDIT |
2019-05-08
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-08
|
16 | (System) | Announcement was received by RFC Editor |
2019-05-08
|
16 | (System) | IANA Action state changed to In Progress |
2019-05-08
|
16 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2019-05-08
|
16 | Cindy Morgan | IESG has approved the document |
2019-05-08
|
16 | Cindy Morgan | Closed "Approve" ballot |
2019-05-08
|
16 | Cindy Morgan | Ballot writeup was changed |
2019-05-08
|
16 | Deborah Brungard | Ballot approval text was changed |
2019-05-08
|
16 | Adam Roach | [Ballot comment] Thanks for addressing my DISCUSS! |
2019-05-08
|
16 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2019-05-04
|
16 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-16.txt |
2019-05-04
|
16 | (System) | New version approved |
2019-05-04
|
16 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2019-05-04
|
16 | Min Ye | Uploaded new revision |
2019-05-02
|
15 | Benjamin Kaduk | [Ballot comment] Thank you for resolving my discuss point about imposing requirements on implementations that do not implement this specification. I trust Adam to get … [Ballot comment] Thank you for resolving my discuss point about imposing requirements on implementations that do not implement this specification. I trust Adam to get the details right of the IEEE754 binary floating-point format language, and will clear on that point as well. |
2019-05-02
|
15 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-04-30
|
15 | Magnus Westerlund | Ballot comment text updated for Magnus Westerlund |
2019-04-30
|
15 | Magnus Westerlund | [Ballot comment] Thanks for addressing the precision question. Adam appears to have the issue that the definition is well defined so I cleared my discuss. |
2019-04-30
|
15 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2019-04-29
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-29
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-04-29
|
15 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-15.txt |
2019-04-29
|
15 | (System) | New version approved |
2019-04-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2019-04-29
|
15 | Min Ye | Uploaded new revision |
2019-04-11
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-04-11
|
14 | Alexey Melnikov | [Ballot comment] Thank you for a well written document. I have a few easy to address comments. Other people already commented on the lack of … [Ballot comment] Thank you for a well written document. I have a few easy to address comments. Other people already commented on the lack of reference for the float format. In the following text: When a node does not support the Availability TLV, the node SHOULD generate a PathErr message with the error code "Extended Class-Type Error" and the error value "Class-Type mismatch" (see [RFC2205]). When a node receives Availability TLVs which mixed of zero index and non-zero index, the message MAY be ignored and SHOULD NOT be What does “MAY ignore” mean here and what are the implications of not ignoring? I tend to think that this shoukd be MUST for interoperability, so either changing this to MUST or adding explanatory text for MAY would address my concern. propagated. When a node receives Availability TLVs (non-zero index) with no matching index value among the bandwidth-TLVs, the message MAY be ignored and SHOULD NOT be propagated. When a node receives Same comment as above. several pairs, but there're are extra bandwidth-TLVs without matching index Availability-TLV, the extra bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated. |
2019-04-11
|
14 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-04-10
|
14 | Adam Roach | [Ballot discuss] Thanks for everyone's work on this document. §3.1: > Availability (4 octets): a 32-bit floating point number describes > the decimal … [Ballot discuss] Thanks for everyone's work on this document. §3.1: > Availability (4 octets): a 32-bit floating point number describes > the decimal value of availability requirement for this bandwidth > request. The value MUST be less than 1and is usually expressed in > the value of 0.99/0.999/0.9999/0.99999. "32-bit floating point number" is not sufficiently precise to specify the encoding of this field. Presumably, this is intended to use IEEE 754-2008 32-bit binary interchange format. Please specify this, and add a normative citation for IEEE 754-2008. |
2019-04-10
|
14 | Adam Roach | [Ballot comment] §3.2: > When a node does not support the Availability TLV, the node SHOULD > generate a PathErr message with the error code … [Ballot comment] §3.2: > When a node does not support the Availability TLV, the node SHOULD > generate a PathErr message with the error code "Extended Class-Type > Error" and the error value "Class-Type mismatch" (see [RFC2205]). Presumably, this "SHOULD" is a restatement of behavior defined in RFC 2205? (I presume this because there's no way for this specification to retroactively impose requirements on implementations that don't support it.) If so, please remove the RFC-2119 language (or include it only as a direct quote from the RFC that defines the requirement in the first place). |
2019-04-10
|
14 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2019-04-10
|
14 | Suresh Krishnan | [Ballot comment] I support Ben's DISCUSS as well. * In addition, I could not find any reference to the Extended Class-Type Error and the error … [Ballot comment] I support Ben's DISCUSS as well. * In addition, I could not find any reference to the Extended Class-Type Error and the error value Class-Type mismatch even in the IANA registry at https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml Is this something you are defining in this document? If so, an entry in the IANA consideration section is warranted. * Section 7 The table seems to be off. Shouldn't this be? 400 99.99% 200 99.995% 100 99.999% |
2019-04-10
|
14 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-04-10
|
14 | Alvaro Retana | [Ballot comment] I also support Benjamin's DISCUSS. |
2019-04-10
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-04-10
|
14 | Alissa Cooper | [Ballot comment] I support Benjamin's DISCUSS point about the error handling. |
2019-04-10
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-04-09
|
14 | Warren Kumari | [Ballot comment] I must admit that I'm having a hard time understanding the utility of this, and how exactly systems are supposed to make a … [Ballot comment] I must admit that I'm having a hard time understanding the utility of this, and how exactly systems are supposed to make a reasonable decision based upon the information -- I don't **really** care that the probability of the link being at 100Mbps is 99.995%, what I care about is what the available bandwidth is *now*. When my device has a 123Mbps flow, it needs to decide what to do with it -- I get that this document describes how the bandwidth probability can be transmitted, but how should my device use this information? I'm also confused by the table: Sub-bandwidth (Mbps) Availability ------------------ ------------ 200 99.99% 100 99.995% 100 99.999% Is there an error here? I also support the DISCUSS on the floating-point issue -- perhaps this could be much more simply encoded with a table and some bits? E.G: 25%, 50%, 75%, 80%, 90%, 91%, 92%.. 99%. If > 99%, then the remaining gets used to encode the "number of nines" availability (5 == 5 nines). Edit: Also, thank you to Shwetha Bhandari for the useful OpsDir review. |
2019-04-09
|
14 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2019-04-09
|
14 | Warren Kumari | [Ballot comment] I must admit that I'm having a hard time understanding the utility of this, and how exactly systems are supposed to make a … [Ballot comment] I must admit that I'm having a hard time understanding the utility of this, and how exactly systems are supposed to make a reasonable decision based upon the information -- I don't **really** care that the probability of the link being at 100Mbps is 99.995%, what I care about is what the available bandwidth is *now*. When my device has a 123Mbps flow, it needs to decide what to do with it -- I get that this document describes how the bandwidth probability can be transmitted, but how should my device use this information? I'm also confused by the table: Sub-bandwidth (Mbps) Availability ------------------ ------------ 200 99.99% 100 99.995% 100 99.999% Is there an error here? I also support the DISCUSS on the floating-point issue -- perhaps this could be much more simply encoded with a table and some bits? E.G: 25%, 50%, 75%, 80%, 90%, 91%, 92%.. 99%. If > 99%, then the remaining gets used to encode the "number of nines" availability (5 == 5 nines). |
2019-04-09
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-04-09
|
14 | Roman Danyliw | [Ballot comment] (1) Section 3.2. Nit. s/When a node receives Availability TLVs which mixed of zero index and non-zero index/ When a node receives Availability … [Ballot comment] (1) Section 3.2. Nit. s/When a node receives Availability TLVs which mixed of zero index and non-zero index/ When a node receives Availability TLVs with both zero and non-zero indexes/ s/there’re are/there are/ (2) Section 4.0. Nit. s/Especially section 7.1.2 of [RFC5920] discuss/Section 7.1.2 of [RFC5902] discusses/ (3) Concur with secdir review/Magnus on the need to clarify the format of the availability field (is it IEEE754-2008?) If IEEE754 is used (as Ben/Ignas notes due to RFC8330), then the text should explicitly cite the constraints of the precision referenced by Magnus. |
2019-04-09
|
14 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-04-09
|
14 | Benjamin Kaduk | [Ballot discuss] As the genart review notes, when Section 3.2 says: When a node does not support the Availability TLV, the node SHOULD … [Ballot discuss] As the genart review notes, when Section 3.2 says: When a node does not support the Availability TLV, the node SHOULD generate a PathErr message with the error code "Extended Class-Type Error" and the error value "Class-Type mismatch" (see [RFC2205]). is attempting to place a normative requirement on implementations that do not implement this specification, which cannot possibly work. The appropriate thing to do here is to say something like "as described in Section Y of [RFC XXXX], a node that does not support the Availability TLV will [behave in this fashion]", with no normative language. (Also, the RFC 2205 reference is not very helpful to me; as far as I can tell it is just providing information about how to encode a PathErr but does not tell me anything about the specific error code and value indicated.) I'll also hold a placeholder discuss point to wait for the [IEEE754] reference for the floating-point format. (I think that format is not a great fit for this application, for many of the reasons that Magnus notes, but RFC 8330 has kind of forced us into keeping it.) |
2019-04-09
|
14 | Benjamin Kaduk | [Ballot comment] Section 1 If the bandwidth availability requirement is not specified in the signaling message, the bandwidth will be reserved as the … [Ballot comment] Section 1 If the bandwidth availability requirement is not specified in the signaling message, the bandwidth will be reserved as the highest bandwidth availability. [...] Is this the behavior mandated by RFC 3209/etc., or a new description in this document? Section 3.1 Type (2 octets): 0x04 I think this should really have been "0x04 (suggested; TBD by IANA)". The current text (both here and in Section 5.1) is very close to codepoint squatting. I have entered DISCUSS positions on documents in the past for codepoint squatting, but relucantly decline to do so here, since the IANA considerations do state that the indicated value is only a suggestion, and the registration procedure of Standards Action strongly limits the potential for a conflicting registration to be processing in parallel. When the Availability TLV is included, it MUST be present along with the Ethernet Bandwidth Profile TLV. If the bandwidth requirements in the multiple Ethernet Bandwidth Profile TLVs have nit: this is the first time we talk about "the multiple" TLVs; should we give it a less-subtle introduction, like "If there are multiple bandwidth requirements present (in multiple Ethernet Bandwidth Profile TLVs) and they have different [...]"? different Availability requirements, multiple Availability TLVs SHOULD be carried. In such a case, the Availability TLV has a one It's surprising to see this as a "SHOULD" (not "MUST")... to one correspondence with the Ethernet Bandwidth Profile TLV by having the same value of Index field. If all the bandwidth requirements in the Ethernet Bandwidth Profile have the same Availability requirement, one Availability TLV SHOULD be carried. In this case, the Index field is set to 0. ... and this extra complication seems like it might be premature optimization. A strict one-to-one matching requirement is easy to implement and easy to verify; the logic needed for this is more complicated and prone to error. Section 3.2 When two LSPs request bandwidth with the same availability requirement, contention MUST be resolved by comparing the node IDs, with the LSP with the higher node ID being assigned the reservation. This is consistent with general contention resolution mechanism provided in section 3.2 of [RFC3473]. It seems to me that Section 4.2 of RFC 3471 may be a better reference than Section 3.2 of RFC 3473, since the latter does not actually say anything about the higher node ID winning. Section 3.2 When a node receives Availability TLVs which mixed of zero index and non-zero index, the message MAY be ignored and SHOULD NOT be propagated. [...] How would such a message be processed if the MAY is ignored (i.e., the message is processed)? Perhaps this is better as a MUST? MAY be ignored and SHOULD NOT be propagated. When a node receives several pairs, but there're are extra nit: s/there're are/there are/ bandwidth-TLVs without matching index Availability-TLV, the extra bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated. This is perhaps an interesting recommendation to make, since it means that implementations that support this document will ignore the bandwidth-TLVs but implementations that do not support this document will process them, leading to different behavior in terms of how many reservations are actually made. (And the "SHOULD NOT be propagated" makes things highly path-dependent and possibly exciting to debug.) Section 4 Thank you for removing the "does not introduce any new security considerations" text as requested by the secdir reviewer, and adding the "closed network" discussion. That said, I expected to see some discussion about how the mechanisms defined in this document impose consistency requirements between Bandwidth TLVs and the newly defined Availability TLVs that can increase the risk of reservation requests being rejected. There could also be some text about the edge cases where behavior will differ, for a given request, when some/all of the nodes on the path do/don't support this extension. Section 5.1 I'm not sure why we need to mention the registration procedure for the registry -- we're not creating the registry, just allocating a codepoint from it. IANA will check/follow the required procedure, but the reader of this document doesn't need to care. Section 7 Thank you for this example, which really helps to clarify that the total bandwidth is allocated into *non-overlapping* segments with different max-availability metrics. (That is, that even though there is 400 Mbps capacity in clear weather, we don't report 400 Mbps at 99.99% availability, since we need to use some of that capacity for the higher availability levels.) I a little bit wonder if this could be reiterated in prose earlier in the document, but don't have any concrete suggestions for how to do so. |
2019-04-09
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-04-08
|
14 | Shwetha Bhandari | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Shwetha Bhandari. Sent review to list. |
2019-04-08
|
14 | Sandra Murphy | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Sandra Murphy. |
2019-04-08
|
14 | Ignas Bagdonas | [Ballot comment] A few nits: s3.1: Please indicate that float encoding is IEEE745 SP, same as in other GMPLS documents. s7: "demodulating to a lower … [Ballot comment] A few nits: s3.1: Please indicate that float encoding is IEEE745 SP, same as in other GMPLS documents. s7: "demodulating to a lower modulation level" - maybe change to "moving to a lower demodulation level", as it is the sender modulation scheme that defines what and how can be demodulated on the receiver side. |
2019-04-08
|
14 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-04-08
|
14 | Magnus Westerlund | [Ballot discuss] Section 3.1: Availability (4 octets): a 32-bit floating point number describes the decimal value of availability requirement … [Ballot discuss] Section 3.1: Availability (4 octets): a 32-bit floating point number describes the decimal value of availability requirement for this bandwidth request. The value MUST be less than 1and is usually expressed in the value of 0.99/0.999/0.9999/0.99999. It appears that this format has some very clear limitations when it comes to store availability numbers. Assuming that this 32-bit float is an IEEE-754 representation which should be explicitly stated. In that case representing availabilities higher than 0.999999 starts to introduce significant errors in relation to intended precision. Intended value Error Actual value 0.999999 -1.3278961181640625E-8 0.999998986721038818359375 0.9999999 -1.920928955078125E-8 0.99999988079071044921875 0.99999999 1E-8 1 (Which is not allowed) So at a minimal the limitations for what is practical to express needs to be provided. Secondly, are this range sufficient in all cases? |
2019-04-08
|
14 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2019-04-08
|
14 | Éric Vyncke | [Ballot comment] COMMENTS ======== C1) Section 3.1 "Availability TLV" is a little too generic IMHO, should rather be named "Bandwidth availability TLV" C2) Section 3.1, … [Ballot comment] COMMENTS ======== C1) Section 3.1 "Availability TLV" is a little too generic IMHO, should rather be named "Bandwidth availability TLV" C2) Section 3.1, the availability encoding by a float is possibly not the optimum one esp with 3 bytes 'reserved'. I would have expected something (perhaps too simple ?) such as one byte where 'n' means availability of 1-10**n (for example, 3 means 1-10**-3 == 0.999). But, this is a detail. NITS ==== N1) Section 3.1, s/MUST be less than 1and/MUST be less than 1 and/ |
2019-04-08
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-04-07
|
14 | Barry Leiba | [Ballot comment] — Section 3.1 — When the Availability TLV is included, it MUST be present along with the … [Ballot comment] — Section 3.1 — When the Availability TLV is included, it MUST be present along with the Ethernet Bandwidth Profile TLV. I had to read this a couple of time to get it. I suggest that this reads a bit better: NEW When the Availability TLV is included, the Ethernet Bandwidth Profile TLV MUST also be included. END There’s also a nit in the description of “Availability”: “1and” is missing a space. — Section 3.2 — When a node receives Availability TLVs which mixed of zero index and non-zero index, Nit: “...TLVs with a mix of zero index...” Nit later in the section: change “there're are” to “there are”. |
2019-04-07
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-03
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Shwetha Bhandari |
2019-04-03
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Shwetha Bhandari |
2019-04-03
|
14 | Mirja Kühlewind | [Ballot comment] Just one quick question I was wondering about in section 3.2.: "When a node receives several pairs, but there're are extra … [Ballot comment] Just one quick question I was wondering about in section 3.2.: "When a node receives several pairs, but there're are extra bandwidth-TLVs without matching index Availability-TLV, the extra bandwidth-TLVs MAY be ignored and SHOULD NOT be propagated." Why is that? Is it not valid to also send some requests without availability? I thought that would make sense because it's basically saying, "just give me whatever you have because I don't know the availability requirements anyway", no? |
2019-04-03
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-04-02
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-03-28
|
14 | Paul Kyzivat | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat. |
2019-03-28
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2019-03-28
|
14 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2019-03-22
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Sandra Murphy |
2019-03-22
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Sandra Murphy |
2019-03-20
|
14 | Cindy Morgan | Placed on agenda for telechat - 2019-04-11 |
2019-03-20
|
14 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-03-20
|
14 | Deborah Brungard | Ballot has been issued |
2019-03-20
|
14 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2019-03-20
|
14 | Deborah Brungard | Created "Approve" ballot |
2019-03-20
|
14 | Deborah Brungard | Ballot writeup was changed |
2019-03-06
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-03-06
|
14 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-14.txt |
2019-03-06
|
14 | (System) | New version approved |
2019-03-06
|
14 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2019-03-06
|
14 | Min Ye | Uploaded new revision |
2019-02-01
|
13 | Sandra Murphy | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Sandra Murphy. Sent review to list. |
2019-01-31
|
13 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-01-31
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13. 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-ccamp-rsvp-te-bandwidth-availability-13. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Ethernet Sender TSpec TLVs/Ethernet Flowspec TLVs on the Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters registry page located at: https://www.iana.org/assignments/gmpls-sig-parameters/ a single, new value is to be registered as follows: Type: [ TBD-at-Registration ] Description: Availability Reference: [ RFC-to-be ] IANA notes that the authors have suggested the value 0x04 for this value. The IANA Functions Operator understands that this is the only action 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. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-01-31
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-01-23
|
13 | Paul Kyzivat | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat. |
2019-01-17
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2019-01-17
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2019-01-17
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2019-01-17
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2019-01-17
|
13 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-01-17
|
13 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-01-31): From: The IESG To: IETF-Announce CC: Daniele Ceccarelli , ccamp-chairs@ietf.org, db3546@att.com, ccamp@ietf.org, … The following Last Call announcement was sent out (ends 2019-01-31): From: The IESG To: IETF-Announce CC: Daniele Ceccarelli , ccamp-chairs@ietf.org, db3546@att.com, ccamp@ietf.org, daniele.ceccarelli@ericsson.com, draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Ethernet Traffic Parameters with Availability Information) to Proposed Standard The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Ethernet Traffic Parameters with Availability Information' 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 ietf@ietf.org mailing lists by 2019-01-31. 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 A packet switching network may contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such links is sensitive to external environment (e.g., climate). Availability is typically used for describing these links when during network planning. This document introduces an optional Availability TLV in Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can be used to set up a Generalized Multi- Protocol Label Switching (GMPLS) Label Switched Path (LSP) using the Ethernet SENDER_TSPEC object. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2414/ |
2019-01-17
|
13 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-01-17
|
13 | Deborah Brungard | Last call was requested |
2019-01-17
|
13 | Deborah Brungard | Ballot approval text was generated |
2019-01-17
|
13 | Deborah Brungard | Ballot writeup was generated |
2019-01-17
|
13 | Deborah Brungard | IESG state changed to Last Call Requested from AD Evaluation |
2019-01-17
|
13 | Deborah Brungard | Last call announcement was generated |
2019-01-17
|
13 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-13.txt |
2019-01-17
|
13 | (System) | New version approved |
2019-01-17
|
13 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2019-01-17
|
13 | Min Ye | Uploaded new revision |
2019-01-16
|
12 | Deborah Brungard | IESG state changed to AD Evaluation from Expert Review |
2019-01-02
|
12 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-12.txt |
2019-01-02
|
12 | (System) | New version approved |
2019-01-02
|
12 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2019-01-02
|
12 | Min Ye | Uploaded new revision |
2018-12-10
|
11 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Matthew Bocci. |
2018-11-28
|
11 | Deborah Brungard | RTG DIR review: Matthew Bocci (by Dec. 7) |
2018-11-28
|
11 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2018-11-25
|
11 | Min Ye | Request for Last Call review by RTGDIR is assigned to Matthew Bocci |
2018-11-25
|
11 | Min Ye | Request for Last Call review by RTGDIR is assigned to Matthew Bocci |
2018-11-19
|
11 | Min Ye | Request for Last Call review by RTGDIR is assigned to Emmanuel Baccelli |
2018-11-19
|
11 | Min Ye | Request for Last Call review by RTGDIR is assigned to Emmanuel Baccelli |
2018-11-19
|
11 | Deborah Brungard | Requested Last Call review by RTGDIR |
2018-10-26
|
11 | Daniele Ceccarelli | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? >Proposed Standard. This is appropriate as extensions to RSVP-TE are defined and it is correctly indicated in the title page hearder. (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 A packet switching network may contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such links is sensitive to external environment. Availability is typically used for describing the link during network planning. This document introduces an optional Availability TLV in Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can be used to set up a Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Path (LSP) using the Ethernet SENDER_TSPEC object. Working Group Summary The document followed the regular process and no particular controversy was raised by any WG member. Document Quality The document is supported both by vendors and operators active in the working group. Personnel Document Shepherd: Daniele Ceccarelli Responsible Area Director: Deborah Brungard (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document is ready to be submitted to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? None (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. The document defines extensions to the RSVP-TE protocol. A routing area directorate review as per standard process should be sufficient. (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 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. Yes. All IPR declarations have been collected and stored in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/history/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. An IPR has been disclosed against the document in accordance with the process. No objection or issued raised by the WG. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document is relevant to particular area which is of interest of a portion of the working group. All the members of the WG interested in that area showed support for the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such a threat. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The document is clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. NO such reviews are needed for this document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (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 of any existing RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). All the protocol extensions are correctly associated with the appropriate IANA registry reservations. (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. The registration procedure for this registry is Standards Action as defined in [RFC8126]. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No such checks needed/performed. |
2018-10-26
|
11 | Daniele Ceccarelli | Responsible AD changed to Deborah Brungard |
2018-10-26
|
11 | Daniele Ceccarelli | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-10-26
|
11 | Daniele Ceccarelli | IESG state changed to Publication Requested |
2018-10-26
|
11 | Daniele Ceccarelli | IESG process started in state Publication Requested |
2018-10-26
|
11 | Daniele Ceccarelli | Changed document writeup |
2018-10-26
|
11 | Daniele Ceccarelli | Notification list changed to Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2018-10-26
|
11 | Daniele Ceccarelli | Document shepherd changed to Daniele Ceccarelli |
2018-10-21
|
11 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt |
2018-10-21
|
11 | (System) | New version approved |
2018-10-21
|
11 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2018-10-21
|
11 | Min Ye | Uploaded new revision |
2018-09-27
|
10 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-10.txt |
2018-09-27
|
10 | (System) | New version approved |
2018-09-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2018-09-27
|
10 | Min Ye | Uploaded new revision |
2018-09-06
|
09 | Daniele Ceccarelli | Changed consensus to Yes from Unknown |
2018-09-06
|
09 | Daniele Ceccarelli | Intended Status changed to Proposed Standard from None |
2018-09-06
|
09 | Daniele Ceccarelli | Last call IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/CljellvvYUya4k_aBhbhI4tfbQY AUTHORS Hao Long Email: longhao@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/0D1XDhyHYnbVXkdlzSPvhHF-5W4 Min Ye Email: amy.yemin@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/DltIhTLF-QOeobq6AKq2OIbQlqk Greg Mirsky Email: gregimirsky@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/Z86kjKth6-g3IV4EZtna7_QKlcM … Last call IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/CljellvvYUya4k_aBhbhI4tfbQY AUTHORS Hao Long Email: longhao@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/0D1XDhyHYnbVXkdlzSPvhHF-5W4 Min Ye Email: amy.yemin@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/DltIhTLF-QOeobq6AKq2OIbQlqk Greg Mirsky Email: gregimirsky@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/Z86kjKth6-g3IV4EZtna7_QKlcM Alessandro D'Alessandro Email: alessandro.dalessandro@telecomitalia.it https://mailarchive.ietf.org/arch/msg/ccamp/Q_qvDEkImaqPAQvuWTcvIM2NIrI Himanshu Shah Email: hshah@ciena.com https://mailarchive.ietf.org/arch/msg/ccamp/NsJMLy4usqEVco-Obmta6YKNKXE |
2018-07-23
|
09 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-09.txt |
2018-07-23
|
09 | (System) | New version approved |
2018-07-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2018-07-23
|
09 | Min Ye | Uploaded new revision |
2018-01-29
|
08 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-08.txt |
2018-01-29
|
08 | (System) | New version approved |
2018-01-29
|
08 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Alessandro D'Alessandro , Min Ye , Hao Long , Himanshu Shah |
2018-01-29
|
08 | Min Ye | Uploaded new revision |
2017-08-07
|
07 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-07.txt |
2017-08-07
|
07 | (System) | New version approved |
2017-08-07
|
07 | (System) | Request for posting confirmation emailed to previous authors: Gregory Mirsky , Min Ye , Alessandro D'Alessandro , Hao Long , Himanshu Shah |
2017-08-07
|
07 | Min Ye | Uploaded new revision |
2017-02-13
|
06 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-06.txt |
2017-02-13
|
06 | (System) | New version approved |
2017-02-13
|
06 | (System) | Request for posting confirmation emailed to previous authors: ccamp-chairs@ietf.org, "Alessandro D'Alessandro" , "Min Ye" , "Himanshu Shah" , "Gregory Mirsky" , "Hao Long" |
2017-02-13
|
06 | Min Ye | Uploaded new revision |
2016-08-19
|
05 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-05.txt |
2016-02-22
|
04 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-04.txt |
2015-10-18
|
03 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-03.txt |
2015-07-05
|
02 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-02.txt |
2015-03-05
|
01 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-01.txt |
2014-10-27
|
00 | Daniele Ceccarelli | IPR poll (Deborah) http://www.ietf.org/mail-archive/web/ccamp/current/msg16390.html Hao Long Email: longhao@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16411.html Min Ye Email: amy.yemin@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16409.html Greg Mirsky Email: gregory.mirsky@ericsson.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16408.html … IPR poll (Deborah) http://www.ietf.org/mail-archive/web/ccamp/current/msg16390.html Hao Long Email: longhao@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16411.html Min Ye Email: amy.yemin@huawei.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16409.html Greg Mirsky Email: gregory.mirsky@ericsson.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16408.html Alessandro D'Alessandro Email: alessandro.dalessandro@telecomitalia.it http://www.ietf.org/mail-archive/web/ccamp/current/msg16413.html Himanshu Shah Email: hshah@ciena.com http://www.ietf.org/mail-archive/web/ccamp/current/msg16406.html |
2014-10-24
|
00 | Lou Berger | This document now replaces draft-long-ccamp-rsvp-te-bandwidth-availability instead of None |
2014-10-08
|
00 | Min Ye | New version available: draft-ietf-ccamp-rsvp-te-bandwidth-availability-00.txt |