Re: [Teas] <draft-sitaraman-sr-rsvp-coexistence-rec> -- Open Thread

[Vishnu Pavan Beeram <[e-mail]>]

Dhruv,

Please see inline (prefixed VPB)

Regards,
-Pavan

On Tue, Nov 15, 2016 at 12:47 AM, Dhruv Dhody <[e-mail]> wrote:

> Hi Pavan,
>
> Thanks for starting this thread. I think work in this space is needed. See
> inline..
>
> On Tue, Nov 15, 2016 at 10:20 AM, Vishnu Pavan Beeram <
> [e-mail]> wrote:
>
>> Folks, Hi!
>>
>> We presented <draft-sitaraman-sr-rsvp-coexistence-rec> in yesterday's
>> morning session. Unfortunately, we didn't have any time left to take
>> questions. So, I'm opening up a thread for folks to post their
>> questions/concerns.
>>
>> Dhruv (on cc) had a couple of questions and I'll start this thread with
>> responses to those --
>>
>> (1) Why can't you do only SR on the controller and leave RSVP-TE control
>> stay distributed?
>> The base requirement for this “co-existence arrangement” is to ensure
>> that the placement of SR LSPs in the same domain DOES NOT introduce any
>> inaccuracies in the TED that is used by distributed or centralized RSVP
>> Path computation engines. If your SR-LSPs are management by a
>> centralized controller and you don't have the SR utilization information
>> somehow reflected in the TED used by distributed RSVP-TE path
>> computation engines, it would result in the TED information being not
>> accurate.
>>
>
> ​[Dhruv]: I agree, you have a point here.
>  ​
>
>
>>
>> (2) With Option-5, wouldn't there be issues if not all nodes in the
>> network support the recommended procedure?
>> You do need the recommended procedure to be applied on all RSVP-TE nodes
>> in the domain. If not, the TED information would not be completely
>> accurate. This is TRUE for the other options as well -- the chosen option
>> would need to be uniformly applied to all relevant nodes in the network.
>>
>
> ​[Dhruv]: If you have to go and update all RSVP-TE nodes to use this
> procedure, then I would lean towards option #3 which was noted as "Flooding
> SR Utilization in IGP" in the presentation. Which does require updating
> path computation and IGP. But I am not sure why updating this is an issue,
> whereas, a new logic on every TE node to measure SR utilization and update
> bandwidth is not?
>

[VPB] Please note that the intent of the document is to just list all
available options and discuss the pros and cons of each approach (We are
not picking any winners -- at least for now).

In both options (#3 and #5), you do need to somehow decipher/measure SR
utilization on each TE link. In option #3, this utilization information is
flooded in IGP-TE (RFC7810 TLVs) and is taken into account by all ingress
path computation engines. This requires updating IGP-TE and
ingress-path-computation logic on all RSVP-TE nodes. In option #5, the SR
utilization information gets reflected in the max-reservable-bandwidth
attribute of the TE link. So, you end up not having to update IGP-TE and
ingress path-computation logic on all RSVP-TE nodes. We can debate which of
these 2 options is easy to implement and deploy, but I'm not sure if we can
reach any consensus on that.

Also, please do note that if an implementation is capable of streaming out
per-interface SR traffic statistics and provides a programmable interface
for updating the per-TE-link max-reservable-bandwidth, the entire procedure
outlined in Section 3.5 of the draft can be done off-box.



> Regards,
> Dhruv
>
>
>>
>> Regards,
>> -Pavan
>>
>> ps: I believe Rakesh (on cc) had a question as well, but couldn't get
>> his chance. @Rakesh -- Please do post your question here and we (the
>> authors) will respond to it.
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>>
>