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

[Rakesh Gandhi <[e-mail]>]

Ok, thanks Pavan.

On Sat, Mar 25, 2017 at 6:38 PM, Vishnu Pavan Beeram <[e-mail]>
wrote:

> Rakesh, Hi!
>
> Thanks for going through the latest set of diffs.
> Please see inline for responses (prefixed VPB)
>
> Regards,
> -Pavan
>
> On Wed, Mar 22, 2017 at 4:06 PM, Rakesh Gandhi <[e-mail]>
> wrote:
>
>> 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?
>>
> [VPB] As stated in the draft, the bandwidth constraints for class-types
> are updated based on operator policy. As per policy (for RDM), bc0 gets
> adjusted first. The adjustment in bc0 may result in other "bc"s also
> getting adjusted (if needed). If bc1 is found to be greater than the
> adjusted-bc0 then bc1 is set to the same value as the adjusted-bc0 (same
> applies for other “bc”s). So, in your example, bc1 would also become 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).
>>
> [VPB] If the policy (for MAM) is to adjust all BCs by an equal amount,
> then for your example -- bc0 would be 6 and bc1 would be 3. The overbooking
> would remain the same (6+3-6=3).
>
>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>