Early Review of draft-ietf-idr-sla-exchange-10
review-ietf-idr-sla-exchange-10-opsdir-early-clarke-2017-05-05-00

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.