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.