Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)
draft-boucadair-connectivity-provisioning-protocol-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-10-19
|
22 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-09-21
|
22 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-08-20
|
22 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-06-29
|
22 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2020-06-29
|
22 | (System) | RFC Editor state changed to EDIT |
2020-06-29
|
22 | (System) | IANA Action state changed to In Progress |
2020-06-28
|
22 | Adrian Farrel | ISE state changed to Sent to the RFC Editor from In IESG Review |
2020-06-28
|
22 | Adrian Farrel | Sent request for publication to the RFC Editor |
2020-06-25
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-06-25
|
22 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-22.txt |
2020-06-25
|
22 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-06-25
|
22 | Mohamed Boucadair | Uploaded new revision |
2020-06-10
|
21 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-05-29
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-05-29
|
21 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-21.txt |
2020-05-29
|
21 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-05-29
|
21 | Mohamed Boucadair | Uploaded new revision |
2020-03-27
|
20 | (System) | IANA Review state changed to IANA OK - No Actions Needed |
2020-03-27
|
20 | Sabrina Tanamal | (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has reviewed draft-boucadair-connectivity-provisioning-protocol-20 and has the following comments: We understand that this document doesn't require any registry … (Via drafts-eval@iana.org): IESG/Authors/ISE: The IANA Functions Operator has reviewed draft-boucadair-connectivity-provisioning-protocol-20 and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-03-24
|
20 | Adrian Farrel | ISE state changed to In IESG Review from In ISE Review |
2020-03-24
|
20 | Adrian Farrel | IETF conflict review initiated - see conflict-review-boucadair-connectivity-provisioning-protocol |
2020-03-24
|
20 | Adrian Farrel | ISE state changed to In ISE Review from Response to Review Needed |
2020-03-24
|
20 | Adrian Farrel | draft-boucadair-connectivity-provisioning-protocol has been submitted to the ISE for publication as an Informational RFC on the Independent Submissions Stream. As can be seen from the version … draft-boucadair-connectivity-provisioning-protocol has been submitted to the ISE for publication as an Informational RFC on the Independent Submissions Stream. As can be seen from the version number, this document has been worked on quite a lot since the first version was posted in 2013. Many of the revisions were "keep-alive" postings, but a lot of work was also done over the years. The document specifies a protocol that can be used between a customer and a network provider to discuss the available connectivity services and to request provision of those services. The document references several pieces of related work, particularly RFC 8309 and various YANG models for the delivery of services. Along the way, this document was reviewed for the ISE by Luis Contreras and by an expert from the OPS Area who requested to remain anonymous. The ISE also provided reviews - the details of all shown below. The concern previously raised by the IESG about protocol specifications that use BCP14 language being mistaken by readers for IETF specifications is addressed as previously suggested by an AD with the inclusion of the following text: Note that this document is not on the IETF standards track. However, a conformant implementation is supposed to adhere to the specified behavior for security and interoperability reasons. This document uses BCP 14 to describe that necessary behavior. == Luis Contreras == Section 1 It would be convenient to add a reference for all the solutions mentioned here (by now, only few of them have a reference) -- Section 5 final paragraph A numbered bullet would be convenient also for this paragraph -- Section 6 bullet 1 It would be probably convenient to say that it is open the way in which the client associates with the servers (static configuration, discovery, etc). -- Section 7 para 4 Probably good to reformulate; suggestion -> "… assume that the Customer is the only one that can call for an agreement." -- Section 7 final para New versions are considered/expected? If not, probably it is better to reformulate; suggestion: "Means of how a client retrieves a list of active/agreed offers are not defined". -- Section 8.1 What could be the dynamic means? Can you provide an example? -- Section 8.1 CPNP_PORT What is the intended port? Should it be standardized / assigned by IANA? -- Figure 5 Where would it be here the interface with the CPNP client? -- Section 8.2 bullet 2 "The CPNP methods which can be automatically handled by the server or they are subject to one or several validation administrative checks can be configured on the server." I don't understand this sentence. -- 8.3 It could be required to have an identifier for both client and provider in order to handle the transactions in a unique manner. A client can maintain parallel sessions simultaneously with different providers, and vice versa. -- 8.3 Who stores these session entries? Is it the same information kept / maintained in both client and server? -- 8.3 s/5-uplet/5-tuple/ -- 8.3 Transaction-ID The transaction ID should be common. Better refer to 8.4. Section 9.1.3 can be removed and integrated in 8.4 if some text has to be maintained. -- 8.5 It should be clarified the relationship among these timers and the timers in sections 9.1.x. -- 8.5 Should be understood that this TIMER applies to both client and servers? -- 8.6 ACCEPT This could happen if there are not resources available. This will depend on the time passed between the offer and the provision. -- 8.6 ACK This is also sent after a PROCESSING operation -- Figure 6 These PROCESSING messages are not accompanied by ACK messages from the client. Is that correct? -- 8.8 Maybe this can be reformulated by saying that is deployment specific and providing this as a potential example. -- 8.9 This can produce a loop. A given client can negotiate with Provider A and Provider B. In case Provider B required from resources in Provider A, then in case of some failure in Provider A the client could be in troubles. Thus it would be required to indicate Provider B that it cannot use resources from Provider A (for instance by leveraging on the AS Number in provider's description as per 9.1.10.2) -- 8.10 Add billing -- Figure 8 I miss from here the ACTIVE state and the Update message. Should not be a WAIT state for representing something between CANCELLED and Created?? -- 8.10.2 AcceptAck This implies that an ACK is sent but also received. -- Figure 9 AcceptAck The procedure covers the negotiation but not the provisioning itself. After provisioning it would be necessary to confirm that the request is ready for service. Is that out of scope? -- Figure 9 The UPDATE operation is missing. -- Figure 9 The right part of the figure should be the same as in Fig. 8. However between ChildCreated and ChildPQOSent there is no AwaitingProcessing. -- Figure 9 It would be good to distinguish the direction of the operations considered (C->S or S->C) since sometimes is operations in both directions are considered explicitly while some other operations are not considered nor detailed. -- Section 9 s/favorite/preferred/ ? -- 9.1.2 This is because it has been initiated by the client, right? If so, maybe it is good to clarify. In case it is not included, is it set to 0, nothing is sent, ...? -- 9.1.3 This section does not provide meaningful information, better to remove to avoid go and back between sections. -- 9.1.5 It is not clear the purpose of this parameter from the description. -- 9.1.6 What are the timing units? Min, s, ms, , ...? -- 9.1.7 It is not the same as RESPONSE_TIMER but only for OFFER? Is it not redundant? -- 9.1.7 Then OFFER_TIME makes sense when OFFER_TIME > RESPONSE_TIME, right? If OFFER_TIME < RESPONSE_TIME, it can be ignored, or simply not set as attribute, right? -- 9.1.9.1 This implies that the Client has full visibility of the provider's network, except of this refers only to Client's information. But in that case, how the provider infers what should be connected? -- 9.1.10.3 It is not clear the purpose of these options with respect the operations in 9.2. -- 9.1.10.3 What could be the options to consider? -- 9.2 Afterwards, for the messages there is reference to METHOD CODE. Better to provide a uniform terminology. -- 9.2.1 What is the intended value? Is it the same of the list in 9.2? Maybe good to indicate that fact. -- 9.2.1 order identifier What is this? Is it the CUSTOMER_AGREEMENT_IDENTIFIER? -- 9.2.1 PQOSent ... in the client side. -- 9.2.2 VERSION What is this version? Version of CPNP protocol? If so, what is the intended version for this specification? This comment applies to all the messages in 9.2. -- 9.2.2 In all these interactions, is it incremented the Sequence_Number? -- Figure 11 MoreTime What is the interpretation of this time? Is it incremental to the original one, does it represent an absolute value? -- 9.2.5 This could be a possible way of DoS attack. -- 9.2.6 bullet 3 This will be the Agreed CPD in 8.7, right? -- 9.2.6 bullet 4 Also in the case of WITHDRAW message. -- 9.2.7 Why the PROVIDER_AGREEMENT_ID is not included here? In the DECLINE message it is included. -- 9.2.7 This could be a possible way of DoS attack. -- 9.2.8 This could be a possible way of DoS attack. -- 9.2.9 Should be added the AGREED_CPD? -- 9.2.9 In the DECLINE the Transaction ID is used to identify the Order, but here it is not the case. Does it actually make sense? -- 9.2.9 This could be a possible way of DoS attack. -- 9.2.9 FAIL But, is this done without performing the update? Then, how it can be related with the already existing service? -- 9.2.9 OFFER message Then, the OFFER is only sent if the Update service can be done? This implies that the Update is not negotiated at all. -- 9.2.10 bullets 2 and 3 This is the first time that something s said about Authorization or Authentication. Either Authorization or Authentication should happen for the client before being able to request services. -- 9.2.10 bullet 5 Maybe this could be reformulated: "... there are not enough resources, e.g. capacity". -- 9.2.10 bullet 6 What does it mean? -- 10.2 Are not validated neither the CANCEL nor FAIL messages? Because of the implications of those messages, it could be good to validate also them. -- 10.2 ACCEPT Linked to PROCESSING in Fig. 9. -- 10.2 UPDATE This state is not in Fig. 9. -- 10.2 WITHDRAW Same as before. -- 11.1.1 "(corrected)" With the error messages are they are now, there is no way of understanding what has failed -- 11.1.1 "ACCEPT message" How many retransmissions? -- 11.1.2 Cannot represent this a security issue? Would it not be better to ignore it after some number of retransmissions? -- 11.2.1 That is, despite the FAIL indication the server can yet send an offer, that will be discarded if it is not OK for the Client. However, to be consistent, the Client should send a DECLINE instead. -- 11.2.1 "Offer Sent" In Fig. 9 is "OfferProposed" Are these states similar to the ones in Fig. 8 and 9? It could be convenient to represent them also here, being the same or not, to make it more easy for the reader. -- 11.2.1 CANCEL Should it be WITHDRAW, right? If not, it has to be mentioned that CANCLE / DECLINE happen before of the completion of the order. -- 11.2.2 It would be convenient to indicate what code is it. -- 11.2.2 What is the intention of sending one empty CPD? Maybe the protocol can be alleviated by not sending anything. -- 11.2.3 Transaction ID also? -- 11.3 For retransmitted messages, the sequence number is incremented? What happens if two messages arrive with the same sequence number? Are the sequence numbers different Sequence number is in the registry? -- 11.4 "no additional feedback" Does it mean that the ACK messages are not retransmitted? "In addition, if the partner receives a re-sent last incoming packet, the partner can also send out the answer to the incoming packet with a limited frequency. If no answer was generated at the moment, the partner needs to generate a PROCESSING message as the answer." What does this mean? -- 12.2 s/&/and/ == Anonymous == My feeling the protocol is overdesigned or over engineered to address the problem space. CPP defined in RFC7297 is a useful profile and can be used to document various different sevice parameters assocaiated connectivity service and put them into different category. CPNP protocol defined in this document provides service parameter negotiation method. If my understanding is correct, the essence of CPNP is application layer policy control protocol, which is similar to COPS (defined in RFC2748) and other policy related protocol. I am not convinced why the existing protocols are not sufficient to support service parameter negotation, e.g., NETCONF provides capability negotation mechanism, YANG-Push Notification Capabilities draft provides a mechanism to advertise various capability. NETCONF+ customer facing service model(e.g.,L3SM) can also be used to negotiate various different service parameters.COPS can also be extended to support various different service parameters negotation. In addition, NETCONF provides complete transaction semantics and support Three-phase transaction. Why not leverage exsiting protocol to do this? I didn't see this document list NETCONF or RESTCONF as existing technology which is, in my opinion, unfair,:-). In addition, section 11.4 proposed define Message-Retransmission mechanism at new protocol level, I am wondering which transport protocol is used by CPNP protocol for reliable exchange of messages? If it is TCP, why not reuse TCP retransmission mechanism? == ISE Initial Review == Has it been implemented? What is the purpose of publication? Some comments about this in the Introduction would be valuable. --- 7297 should be a normative reference -- Section 1 It is out of the scope of this document to elaborate on the differences between CPNP and the aforementioned proposals. That is fair enough, but it does raise the question of why you feel the need for another protocol in this space. Can you add something about that? For example: "Careful examintion of these other proposals revealed in each case certain deficiencies that were easier to address through the creation of a new protocol than through modificaitons to the existing protocols." --- I am somewhat sceptical of including "cost" in this work. I first noticed this in section 3 where you have "request for quotation" and then in 9.1.10.3 where you give the ability to request cost and respond with the cost. But 9.1.10.3 seemed very uninformative, and I ownder whether the whole issue of cost and business models for services is just too complicated to be parameterised. I'd note that TMF have been trying to achieve this for around 30 years and have not made any meaningful progress. --- Does 8.10 need to talk about persistence of state? Since you are not session oriented, one might assume that state persists indefinitely, but two things: - When a message is unresponded (or not followed up). I know 8.5 talks about timers, but it is unclear what is subject to timers. Can a customer think about an offer without breaking the protocol? If the customer issues requests to a number of service providers, it may need to get all of the responses before it chooses. - When a computer (customer or service provider side) restarts, what happens to state that was in progress? Do we assume that the timers handle all of this? Probabaly would work OK, but must recall that either side might wake up to receive a message relating to a transaction it knows nothing about. Is that Nonce failure in 9.1.5? == ISE Final Review == The IESG has been pushing back on Independent Stream documents to make completely clear that, where they are protocol specifications, they do not appear to imply that they are IETF protocol specifications just because they show up in an RFC. On the whole, I don't think there is anything to worry about with your document, but one way we have recently handled this would be to add a paragraph to the end of section 2 as: OLD The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. NEW Note that this document is not on the IETF standards track. However, a conformant implementation is supposed to adhere to the specified behavior for security and interoperability reasons. This text uses BCP 14 to describe that necessary behavior. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. --- I would have been happier if you had made mention of RFC 8299 and RFC 8466 just by way of contrast and reference to relevant IETF work. You do reference draft-ietf-opsawg-l3sm-l3nm, and that's good. What about the corresponding draft-barguil-opsawg-l2sm-l2nm? Not essential to make any changes for this, but think about it. --- Section 8.2 mentions the "Network Provisioning Manager", but there is no real discussion of this external component. Do you have a reference you can point to? --- Section 8.8 made me wonder about whether the Client is made aware of the fact that the Server is has contacted (Server A) is using resources from another network (via Server B). Are there regulatory as well as contractual reasons why this might be important? --- Section 2 is the only place that makes any mention of contracts. I think it is probably important to say whether you expect CPNP to form part of contractual agreements or not. If so, then there are some important security concerns. --- 9.1.10.1 ::= [] [] ::= [] [] [ ...] This seems to allow and to be empty. Is that the intention? Similarly and in subsequent section. It's OK if that is the intention. --- The tables in 10.1 and 10.2 would look better if the text was left- justified so that the spaces are compressed. --- There are two mentions of timestamps for logging. Do you need to talk about formats and bases for them, or is it OK that they will be in local form? |
2020-03-24
|
20 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-20.txt |
2020-03-24
|
20 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-03-24
|
20 | Mohamed Boucadair | Uploaded new revision |
2020-03-06
|
19 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-19.txt |
2020-03-06
|
19 | (System) | New version approved |
2020-03-06
|
19 | (System) | Request for posting confirmation emailed to previous authors: Christian Jacquenet , Panos Georgatsos , Dacheng Zhang , Mohamed Boucadair |
2020-03-06
|
19 | Mohamed Boucadair | Uploaded new revision |
2020-01-12
|
18 | Adrian Farrel | Tag Awaiting Reviews cleared. |
2019-12-10
|
18 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-18.txt |
2019-12-10
|
18 | (System) | New version approved |
2019-12-10
|
18 | (System) | Request for posting confirmation emailed to previous authors: Mohamed Boucadair , Panos Georgatsos , Dacheng Zhang , Christian Jacquenet |
2019-12-10
|
18 | Mohamed Boucadair | Uploaded new revision |
2019-11-28
|
17 | Adrian Farrel | ISE state changed to Response to Review Needed from Finding Reviewers |
2019-11-22
|
17 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-17.txt |
2019-11-22
|
17 | (System) | New version approved |
2019-11-22
|
17 | (System) | Request for posting confirmation emailed to previous authors: Panos Georgatsos , Dacheng Zhang , rfc-ise@rfc-editor.org, Mohamed Boucadair , Christian Jacquenet |
2019-11-22
|
17 | Mohamed Boucadair | Uploaded new revision |
2019-11-21
|
16 | Adrian Farrel | Tag Awaiting Reviews set. |
2019-11-15
|
16 | Adrian Farrel | ISE state changed to Finding Reviewers from Submission Received |
2019-09-26
|
16 | Adrian Farrel | Notification list changed to Adrian Farrel <rfc-ise@rfc-editor.org> |
2019-09-26
|
16 | Adrian Farrel | Document shepherd changed to Adrian Farrel |
2019-09-26
|
16 | Adrian Farrel | ISE state changed to Submission Received |
2019-09-26
|
16 | Adrian Farrel | Intended Status changed to Informational from None |
2019-09-26
|
16 | Adrian Farrel | Stream changed to ISE from None |
2019-09-19
|
16 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-16.txt |
2019-09-19
|
16 | (System) | New version approved |
2019-09-19
|
16 | (System) | Request for posting confirmation emailed to previous authors: Panos Georgatsos , Dacheng Zhang , Mohamed Boucadair , Christian Jacquenet |
2019-09-19
|
16 | Mohamed Boucadair | Uploaded new revision |
2018-06-18
|
15 | (System) | Document has expired |
2017-12-15
|
15 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-15.txt |
2017-12-15
|
15 | (System) | New version approved |
2017-12-15
|
15 | (System) | Request for posting confirmation emailed to previous authors: Panos Georgatsos , Dacheng Zhang , Mohamed Boucadair , Christian Jacquenet |
2017-12-15
|
15 | Mohamed Boucadair | Uploaded new revision |
2017-11-18
|
14 | (System) | Document has expired |
2017-05-17
|
14 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-14.txt |
2017-05-17
|
14 | (System) | New version approved |
2017-05-17
|
14 | (System) | Request for posting confirmation emailed to previous authors: Panos Georgatsos , Mohamed Boucadair , Dacheng Zhang , Christian Jacquenet |
2017-05-17
|
14 | Mohamed Boucadair | Uploaded new revision |
2016-12-08
|
13 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-13.txt |
2016-12-08
|
13 | (System) | New version approved |
2016-12-08
|
13 | (System) | Request for posting confirmation emailed to previous authors: "Panos Georgatsos" , "Mohamed Boucadair" , "Dacheng Zhang" , "Christian Jacquenet" |
2016-12-08
|
13 | Mohamed Boucadair | Uploaded new revision |
2016-12-04
|
12 | (System) | Document has expired |
2016-06-02
|
12 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-12.txt |
2016-03-14
|
11 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-11.txt |
2015-09-16
|
10 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-10.txt |
2015-03-23
|
09 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-09.txt |
2014-09-30
|
08 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-08.txt |
2014-09-17
|
07 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-07.txt |
2014-09-02
|
06 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-06.txt |
2014-09-02
|
05 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-05.txt |
2014-06-27
|
04 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-04.txt |
2014-04-23
|
03 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-03.txt |
2014-03-31
|
02 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-02.txt |
2013-10-08
|
01 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-01.txt |
2013-05-29
|
00 | Mohamed Boucadair | New version available: draft-boucadair-connectivity-provisioning-protocol-00.txt |