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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 14 Nov 2016 20:20:47 -0500

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.

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

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 15 Nov 2016 14:47:57 +0900

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 <[email-masked]
> wrote:

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

Regards,
Dhruv

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 15 Nov 2016 03:25:27 -0500

Dhruv,

Please see inline (prefixed VPB)

Regards,
-Pavan

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

> On Tue, Nov 15, 2016 at 10:20 AM, Vishnu Pavan Beeram <
> [email-masked]> wrote:
>
>> Folks, Hi!
>>
>> 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.
>>
>

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 15 Nov 2016 18:48:20 +0900

Hi Pavan,

For the option where max-res-bw is adjusted, it would be good to add in the
document what happens to Diff-Serve TE BC model RDM, MAM and MAR bandwidth
pools.

Thanks,
Rakesh

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 15 Nov 2016 16:32:20 -0500

Rakesh, Hi!

Thanks for bringing this up. We'll look at adding some text covering DS-TE
in the next version.

Regards,
-Pavan

On Tue, Nov 15, 2016 at 4:48 AM, Rakesh Gandhi <[email-masked]>
wrote:

> Hi Pavan,
>
> For the option where max-res-bw is adjusted, it would be good to add in
> the document what happens to Diff-Serve TE BC model RDM, MAM and MAR
> bandwidth pools.
>
> Thanks,
> Rakesh
>
>
>> somehow reflected in the TED used by distributed RSVP-TE path computation