|
From: Joe Clarke <jclarke@xxxxxxxxx>
Sent: Friday, May 5, 2017 10:41 AM To: ops-dir@xxxxxxxx Cc: idr@xxxxxxxx; draft-ietf-idr-sla-exchange.all@xxxxxxxx; ietf@xxxxxxxx Subject: Opsdir early review of draft-ietf-idr-sla-exchange-10 Reviewer: Joe Clarke
Review result: Has Issues I have been asked to do a review of this draft as a representative of OPS-DIR. This draft lays out a means to exchange SLA/QoS policies via BGP UPDATE messages. Overall, I found this draft a bit difficult to read. There are grammatical issues such as the user of "thru" instead of "through", odd commas, and missing articles. But this is not a grammatical overview. I think this draft would benefit from some examples that show what some practical QoS policies would look like that convey the required classes within the maximum BGP message size (that is, in section 7 add more specific examples of what policies may look like in the ADVERTISE messages). What do the authors feel typical uses of this would look like from the UPDATE message perspective? What kind of processing overhead can one typically expect if a router, for example, will be the QoS Attribute Speaker and SLA Consumer? Below are some specific per-section questions and issues: Section 2: You state that a BGP Speaker need not be a QoS Attribute Speaker, but even if the QoS data is opaque to the BGP Speaker, it would still need to know that the QoS Attribute Speaker exists and there is data to be added to the UPDATE. So why the two entities don't need to be co-resident in the same process, a BGP Speaker needs to be QoS aware to some extent in order for this exchange to work. Additionally, why are SLA Producer and Consumer broken out whereas QoS and BGP just have "speakers?" For consistency, maybe you just state that there exists an SLA-aware QoS Attribute Speaker. You do not define NLRI and AFI/SAFI in your terminology. === Section 3.2: Why the need to have the SLA SubType Flags be set to 0? Couldn't you just as easily set the Source AS and Destination AS Counts to 0? You state that a value of 0 for Source AS when flags are 1 is illegal, so I believe this would work. For SLA ID, you state: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. The SLA ID applies to aggregate traffic that shares the same SLA ID? This seems circular to me. I'm not really clear on how I would allocate an SLA ID and how I align that with the intended QoS policies. Would the intent of having a 0-length SLA Content be to remove the policy for the given prefixes? I'm not clear exactly as to that use case. I'm confused a bit as to how the Destination AS List works. Initially, I thought this would only be set by the sending AS to indicate to which external ASes the content applies. However, each QoS Attribute Speaker can update the Destination AS List. In Sections 4.1.2, 5.1 and 5.2 you attempt to address this, but it is still not clear what kind of updating or trimming of the Destination AS list should be done (and in Section 5.2 you allude to rules to trim the Destination AS List, but I did not see those rules). This could be clarified with an example of what can happen at various hops in the network. === Section 3.3: Related to a point above, if the SLA Content needs to be set per direction, would I use the same SLA ID to do that? I don't think that's clear enough in the current text. You state: Any Traffic Class Element advertised in the QoS Attribute only applies to the advertised AFI/SAFI NLRI within the BGP UPDATE message the QoS Attribute is contained in. However, if I understand correctly, I could specify IPFIX attributes of sourceIPv6Prefix and/or destinationIPv6Prefix that does not line up with the NLRIs, would that not constitute an error? Or Maybe my AFI/SAFI are 1/1, and I'm trying to match IPv6. This seems more like an error, but you only state what to do if the AFI/SAFI is not supported. === Section 3.3.2.2: Why have such a huge range for length here? I can specify that the number of bytes to specify the amount of L2 overhead to use is 255. Why not advise that length should be 4, and then use an IEEE FP number like you did for the TSPEC? At the very least, I think this should be reined in a bit. === Section 3.3.2.7: I think you have a typo in precedence. I think you want to say: - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over MAXRATE_IN_PROFILE_MARKING), - MAXRATE_IN_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING, and - MINRATE_OUT_PROFILE_MARKING takes precedence over MAXRATE_OUT_PROFILE_MARKING === Section 5.2 What I did not see is what the actual SLA Consumer should do after it processes the SLA Content. I realize this can delve into implementation details, but perhaps it's worth mentioning that the SLA Consumer can use protocols like NETCONF or RESTCONF to configure the policies on the necessary interfaces. |