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

[Shitanshu Shah <[e-mail]>]

Hi Joe,


Please find response inline ##svshah2


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

[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:
>
> 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).
>
> ##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.

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

>
>
>   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?
>
> ##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.

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

>
>
>
> 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.
>
> ##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.

>
>
>
> 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.
>
> ##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.

> 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.
>
> ##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.

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

>
>
> 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.
>
> ##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?

##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.


> 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.
>
> ##svshah, ok. we will take a look at to address it.

Thanks.

> 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?
>
> ##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?

##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.


> 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.
>
> ##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.

>
> 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.
>
> ##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.

##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