Subject: [Idr] Opsdir early review of draft-ietf-idr-sla-exchange-10

From: Joe Clarke <[email-masked]>
Date: Fri, 05 May 2017 09:41:03 -0700

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.

---

From: Shitanshu Shah <[email-masked]>
Date: Sun, 7 May 2017 16:24:51 +0000

________________________________
From: Joe Clarke <[email-masked]>
Sent: Friday, May 5, 2017 10:41 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Opsdir early review of draft-ietf-idr-sla-exchange-10

Reviewer: Joe Clarke

Section 2:

===

Section 3.2:

For SLA ID, you state:

===

Section 3.3:

You state:

===

Section 3.3.2.2:

===

Section 3.3.2.7:

===

Section 5.2

---

From: Joe Clarke <[email-masked]>
Date: Sun, 7 May 2017 17:53:24 -0400

[Correcting typo for idr@]

Thank you for your reply, Shitanshu.

Re-adding authors and WG.  Please see my inline comments below.

On 5/7/17 13:29, Shitanshu Shah wrote:
> messages).
> ##svshah, The moment we get into defining QoS policies, it gets into
> vendor specifics. The draft purposefully, as one of its motivation,
> wants to stay away from vendor specifics in SLA exchange. Is there
> anything in specific you have in mind without getting into
> implementation or vendor specifics?

I thought the purpose of the draft was to provide a vendor-neutral way
of exchanging QoS/SLA policies.  What I was specifically asking for is
an example of what the fields within the packets may look like for a
given exchange.  That is, take some of the IPFIX parameters and specify
a specific example exchange of attributes.  I don't see how doing this
would be vendor-specific.

> 
> 
>   What do the authors feel typical uses of this would look
> ##svshah, one possible implementation can be is to asynchronously
> enqueue/dequeue messages from QoS Attribute Speaker to actual QoS
> functional component and thus limiting inline processing overhead to
> simply forming or parsing of QoS Attribute messages. Parsing of messages
> would be function of scale and frequency of SLA policy updates in a
> use-case. Not sure if this answers your question?

My overall point was that I feel some text should be added to the draft
to help an operator know what they might expect from added overhead.
Given that there are operators as authors of this draft, perhaps there
are recommendations to implementors of what operators expect for the
overhead involved with this capability.

> ##svshah, The intention is to have a logical separation, that defines
> functional responsibility separation, between BGP Speaker and QoS
> Attribute Speaker. It does not necessarily mandate them to be in a
> separate process. With appropriate modularity, they can reside in a same
> process for a given implementation.

I completely understand that.  My point was that a BGP Speaker does need
to be _aware_ of a QoS Attribute Speaker.

> ##svshah, Producer and Consumer are broken out to explicitly define
> function of QoS Attribute Speaker at the node that is creating and
> sending a message vs at the node that is receiving and consuming a message.

Understood.  I just thought it was odd to specifically list those two
when you could have done the same for QoS Attribute Speaker.  This isn't
a big deal, mainly semantics, but I wanted to point it out.

> ##svshah, Taking an example, what it means to suggest is that if a
> Source AS first had advertised an SLA with SLA ID s1 for prefix x.x.x.x.
> And then later some time if same Source AS advertises SLA ID s1 for
> prefix x.x.y.y then SLA for ID s1 is applicable to the aggregate traffic
> x.x.x.x+x.x.y.y

Got it.  This is the kind of thing adding a specific example of the
packet contents would help clarify.  Still, I think the wording is
confusing.  Perhaps you want to say something like:

Using a common SLA ID allows traffic with a given AFI/SAFI from
different prefixes to be treated as an aggregate.

> ##svshah, We provide a provision of removing SLA content if there need
> to be. I personally do not have any specific use-case where SLA to be
> removed once established. May be a QOS SLA Producer implement
> modification in two steps which removes followed by an addition?

It could be that one AS no longer trusts another in terms of SLA.  In
any event, what is the intent of having a 0-length SLA Content?

> ##svshah, ok. we will take a look at to address it.

Thanks.

> with the NLRIs, would that not constitute an error?
> 
> ##svshah, we do not define that as an error. This is a QoS Producer
> defined SLA and if content of produced SLA is no-op or how meaningful it
> is, is completely scope of QOS SLA Producer. The SLA exchange mechanism
> does not need to read SLA content to validate meaning of the SLA content.

But given your text that if my QoS Attribute traffic class definition
uses prefixes that are out of range from the NLRI, that would be an error?

> ##svshah, sure. Infact this field is changed based on comments/feed-back
> from David's review. And in the new definition of that field, we
> have/will take care of as per your suggestion.

Thanks.

> ##svshah, yeah, as you state it, this would get into implementation
> details. Besides netconf/restconf, infact implementations may be in the
> NOS itself (it does not necessarily need netconf/restconf interface)
> just like it can be in the case of flow-spec implementations.

Can you add a small bit of text to this effect?  To me, I read through
this whole draft and was surprised there wasn't any direct mention of
what is done with the processed SLA.

Thanks.

Joe

---

From: Shitanshu Shah <[email-masked]>
Date: Mon, 8 May 2017 02:35:07 +0000

Hi Joe,

Please find response inline ##svshah2

________________________________
From: Joe Clarke <[email-masked]>
Sent: Sunday, May 7, 2017 3:53 PM
To: Shitanshu Shah
Cc: [email-masked]; [email-masked]
Subject: Re: Opsdir early review of draft-ietf-idr-sla-exchange-10

##svshah2, got it. I think example in this form certainly can be added.

##svshah2, sure, we can add such a text. Do you have suggestion on exactly which section should such a text go to?

##svshah2, sounds good. thanks for the suggested text.

##svshah2, sorry, I realize that my previous response did not address your original question completely.

Regarding intent of having 0-legnth SLA content,
If Producer (a specific Source AS) had advertised SLA ID s1, with SLA content, to a specific prefix before. And now, if same Producer intents to advertise exact same SLA ID s1 for additional prefix, then Producer should not require to send SLA content again which was already sent before. 0-length SLA content exactly achieves the same.

Thanks.

##svshah2, Just taking an example if Producer advertises SLA where traffic class definition is for prefix 172.x.x.x for the NLRI meant for  152.x.x.x, then that has no operational effect in actual forwarding. This kind of things can be categorized into what we would typically call "mis-configuration" in the Producer's SLA definition. We don't want to look into decoding valid/invalid meaning of such SLA content. Another example, if SLA content definition was to advertised a rate that is higher than actual underlying forwarding interface rate (where SLA is received from).  so forth.

Thanks.

##svshah2, We have intended to highlight the scope in the 4th paragraph in the Introduction section. The SLA by the Consumer may be processed to implement forwarding policy or Consumer may do something less or more than that. It is not scope of this document though. Hopefully, the highlighted paragraph is clearer in that.

Regards,
Shitanshu

Thanks.

Joe

---

From: Joe Clarke <[email-masked]>
Date: Mon, 8 May 2017 10:00:25 -0400

> ##svshah2, got it. I think example in this form certainly can be added.

Excellent.  Thanks!

> ##svshah2, sure, we can add such a text. Do you have suggestion on
> exactly which section should such a text go to?

This could fit in Deployment Considerations, IMHO.

> If Producer (a specific Source AS) had advertised SLA ID s1, with SLA
> content, to a specific prefix before. And now, if same Producer intents
> to advertise exact same SLA ID s1 for additional prefix, then Producer
> should not require to send SLA content again which was already sent
> before. 0-length SLA content exactly achieves the same.

Ah!  Now I follow, especially with your clarification around SLA ID.  I
think that perhaps the text might be clearer here.  Additionally, what
would be the purpose of _never_ sending SLA Content.  That is, what did
you mean by:

If there does not exist any prior SLA
Content to relate to the advertised SLA ID, then receiver, SLA
Consumer, can ignore the SLA advertisement and it may simply
update Destination AS count and Destination AS list.

Why wouldn't this be an error?

> ##svshah2, Just taking an example if Producer advertises SLA where
> traffic class definition is forprefix 172.x.x.x for the NLRI meant
> for  152.x.x.x, then that has no operational effect in actual
> forwarding. This kind of things can be categorized into what we would
> typically call "mis-configuration" in the Producer's SLA definition. We
> don't want to look into decoding valid/invalid meaning of such SLA
> content. Another example, if SLA content definition was to advertised a
> rate that is higher than actual underlying forwarding interface rate
> (where SLA is received from).  so forth.

I'm clear on your latter example.  However, for the former, since you
have text that explicitly states:

I feel you should address what an SLA Consumer would do with such a
mismatch.  And that could account for your latter example as well.  If
the SLA Consumer is instructed simply to throw away such
mis-configurations, I think that would be acceptable.

> ##svshah2, We have intended to highlight the scope in the 4th paragraph
> in the Introduction section. The SLA by the Consumer may be processed to
> implement forwarding policy or Consumer may do something less or more
> than that. It is not scope of this document though. Hopefully, the
> highlighted paragraph is clearer in that.

I vaguely remember that paragraph :-).  I re-read the introduction, and
you also mention the vendor-specific configuration in the second
paragraph.  This is sufficient.

Joe