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

[Rakesh Gandhi <[e-mail]>]

Hi Pavan,

Thanks for adding the following text in the document. I have couple of
examples below for discussion.


"A DS-TE LSR that advertises Bandwidth Constraints TLV should update the
bandwidth constraints for class-types based on operator policy. For
example, when Russian Dolls Model (RDM) [RFC4127] is in use, then only BC0
may be updated. Whereas, when Maximum Allocation Model (MAM) [RFC4125] is
in use, then all BCs may be updated equally such that the total value
updated is equal to the newly calculated SR traffic average."

For RDM, if we take an example where max-res-bw is configured as 10, bc0
as10 and bc1 as 8. If max-res-bw is reduced by 4, then max-res-bw and bc0
will become 6. What about bc1 which is 8 and now > max-res-bw of 6?

For MAM, if we take an example where max-res-bw is configured as 10, bc0 as
8 and bc1 as 5 (BC pools have over-booking of (8+5-10=3) but max-res-bw is
the limit enforced on the link). If we reduce the max-res-bw by 4 to new
value 6, we may still keep the bc0 and bc1 as is (but now over-booking is
more (8+5-6=7) but max-res-bw is still the limit enforced on the link).

Thoughts?

Thanks,

Rakesh

On Tue, Feb 28, 2017 at 2:50 PM, Vishnu Pavan Beeram <[e-mail]>
wrote:

> Rakesh,
> We recently posted a new revision for this draft (
> https://tools.ietf.org/html/draft-sitaraman-sr-rsvp-coexistence-rec-02).
> This new version addresses all comments related to DS-TE.
>
> WG,
> Please do let us know if there are any further questions/comments. At this
> juncture, we would like to request this draft to be considered for adoption.
>
> Regards,
> -Pavan (as a co-author)
>
>
>
> On Tue, Nov 15, 2016 at 4:32 PM, Vishnu Pavan Beeram <
> [e-mail]> wrote:
>
>> 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 <[e-mail]>
>> 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
>>>
>>>
>>> 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.
>>>>
>>>> (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.
>>>>
>>>> _______________________________________________
>>>> Teas mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>
>>>>
>>>
>>
>