Subject: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10

From: Ron Bonica <[email-masked]>
Date: Thu, 16 Feb 2017 17:56:24 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document:  draft-ietf-idr-sla-exchange-10
Reviewer: Ron Bonica
Review Date:  2/16/2017
IETF LC End Date: TBD 
Intended Status: Standards Track

Summary: 

I have some minor concerns about this document that I think should be resolved before publication.

Comments: 

Major Issues: 

This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces. I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver? When a route flaps? How does the router protect itself

In the Security Considerations section, I am concerned about the possibility of intermediate AS's modifying the SLA Exchange Attribute. It seems that you need to have some degree of trust in every AS on the path (not only those included in the attribute)

Minor Issues: 

In Section 3.2, is the flag really needed? Doesn't an AS list containing only the receivers AS have exactly the same meaning?

Nits: 

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
     does not include the phrase in its RFC 2119 key words list.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC2434' is defined on line 1279, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6793' is defined on line 1301, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

  ** Downref: Normative reference to an Informational RFC: RFC 4272

  ** Downref: Normative reference to an Informational RFC: RFC 7132

  == Outdated reference: draft-ietf-netconf-restconf has been published as
     RFC 8040

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Feb 2017 14:55:30 -0500

Ron: 

Thank you for the review.  I will let authors respond to you.   

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, February 16, 2017 12:56 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-10

Hello,

Summary: 

Comments: 

Major Issues: 

Minor Issues: 

Nits: 

Miscellaneous warnings:

  == Outdated reference: draft-ietf-netconf-restconf has been published as
     RFC 8040
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Shitanshu Shah <[email-masked]>
Date: Fri, 17 Feb 2017 06:01:56 +0000

Thank you Ron Bonica for spending time for the review,

Please find response inline ##svshah

Regards,
Shitanshu

________________________________
From: Ron Bonica <[email-masked]>
Sent: Thursday, February 16, 2017 10:56 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RtgDir review: draft-ietf-idr-sla-exchange-10

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Summary:

Comments:

Major Issues:

This document might benefit from discussion of operational issues. I assume that when a BGP listener learns a route with the SLA Exchange Attribute, it provisions class of service forwarding classes on interfaces.

##svshah, though this is one desired use of exchanging SLA content, the draft focuses on transporting SLA content from the SLA Producer to the SLA Consumer. Processing of the QoS attribute content, at the SLA Consumer, is outside the scope of this document.

##svshah, Let me know if you have a suggestion to make description clearer in Section 1 and 2 to highlight this.

I also assume that a) it takes time to provision class of service forwarding classes and b) the number of forwarding classes that can be provisioned are finite. What does the BGP listener do when the number of forwarding classes requested exceeds its capacity to deliver?

##svshah, Since scope of the document is to transport SLA content from the SLA Producer to the SLA Consumer, the document considers error handling in the context of transporting data and thus any formating errors and semantics errors within that context. Any errors in the context of processing QoS attribute content at the SLA Consumer is outside the scope of the document.

When a route flaps? How does the router protect itself

##svshah, As highlighted in section 4, some sort of SLA policy change may be considered for SLA advertisement. That approach should protect from route flaps. did I understand your question correct? If not please clarify.

##svshah, it is correct that "Deployment considerations mainly target use of QoS Attribute and SLA SubType in managed networks and those where a trust relationship is in place (Customer to Provider, or Provider to Provider).  It is NOT RECOMMENDED to enable this attribute at the scale of the Internet unless if means to prevent leaking sensitive information are enforced." [from the Security section].

do you suggest any more clarity on this statement?

Minor Issues:

##svshah, We find it very helpful to keep implementations simple for the ones that would want to support SLA Exchange only for peer receivers and thus making availability of this option.

Nits:

##svshah, will take care of all the nits.

Thank you,

Miscellaneous warnings:

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 Feb 2017 17:06:36 +0000

Hello,

The draft is internally consistent. But given what is left out of scope, I wonder if the new attributes will ever be widely deployed.

                                                                                Ron

---

From: Shitanshu Shah <[email-masked]>
Date: Fri, 24 Feb 2017 09:31:38 +0000

Hi Ron,

To break it down in two point response,

1) This draft is not changing how SLA is established at first place. The draft is providing a method to convey this a priori established SLA to help reduce lot of manual complexities and errors to admin. Thus given a knowledge of what SLA is established, in general devices should be capable to support that established SLA.

2) If there still are any issues in implementing exchanged SLA in forwarding, we think they either are implementation specific or of temporary nature where for example enough resources not available at any specific point of a time.

We feel that in current state of the draft, it can be largely useful in deployments.

One can imagine though even establishment of SLA also can be done via exchanging it over bgp. However, negotiation of SLA does not have to be clubbed with exchange of SLA. Negotiation of SLA is not in this scope.

Regards,
Shitanshu

________________________________
From: Ron Bonica <[email-masked]>
Sent: Thursday, February 23, 2017 10:06 AM
To: Shitanshu Shah; [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-idr-sla-exchange-10

Hello,

                                                                                Ron