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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Sat, 25 March 2017 22:38 UTC

Return-Path: <vishnupavan@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F3128796 for <teas@ietfa.amsl.com>; Sat, 25 Mar 2017 15:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-5ey2bSzjo0 for <teas@ietfa.amsl.com>; Sat, 25 Mar 2017 15:38:15 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3691277BB for <teas@ietf.org>; Sat, 25 Mar 2017 15:38:15 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id r69so20368277vke.2 for <teas@ietf.org>; Sat, 25 Mar 2017 15:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GHYbduB1/EwFgxvAbp7LFJb6elAXJkAVPgJ738WopKU=; b=OXQMQPoSsHQTvhIqJN7rdwDqmYfxarz+l5tXNu1huPVTIBDPu8OXd8PfvvSOWy423M tenYUZl5lostaUErU7YQqoAbESSHb4Ay+t5vKP2TxSmUppCw4Syk/bv1MaJhMC3/eiBW oR9XQgs6FqijC0riek7ycsuzeRmofs7AVNbnPSD99yhmMRmy9cS74yB5mZlpdTn7trsh uLzdFzFtciW5ZCdMJT59/V4aTsD3hCLx7nsuHt0YCAg0CYOD2XdkRPiNc+nLzsF1fPWL CgmClLaJ4RzlMPtzw5W3SCvq8VqhWA4fA8bjMUMYWqC6rHH9ijtx7j3aIwPzMlsuHPdj psNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GHYbduB1/EwFgxvAbp7LFJb6elAXJkAVPgJ738WopKU=; b=W7WfDlykTCaQmxo27Jm8U0bXR1O3i5+NX3QrDEJzwo2hp9dw2dX9IVtxvObPYZWezB BbdDR3Ddt/KstpLrHuVdCkrjSJU8IinPbkorNZ7I5gQSwVy4RTtre6a0IcFhKHaxug7m ic97r5hdMQb2WHpfT2jIpSuw98mqIPHOADEmAcjk3C+Hr3/MRnkCGAPqY1GZnAsXaIvM xULeVTglF4Dhi/iJ88Bd1AE8W8K8wx55t3GJ2UrxfvGRsXH0/DiwmGYGWM7f4QuEeGjR H4u7S+Hc89teizFlbf1rXToXE01N/dk3TuDUmE5QS6YQlh+YwUEhtqmV0TxesFcGnk8I cMwg==
X-Gm-Message-State: AFeK/H2BWYMQ+AChJE0ezAlL6HagArafzk0CSCm71FvPlBo05cf6SjhiaBRdSOG/Y7zGV130NQ4H22T6ltmtIw==
X-Received: by 10.176.85.75 with SMTP id u11mr7047227uaa.36.1490481494341; Sat, 25 Mar 2017 15:38:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.159.143 with HTTP; Sat, 25 Mar 2017 15:38:13 -0700 (PDT)
In-Reply-To: <CAMZsk6eUf-ECCdbL-iMQyrdhxDBe2BBWL8T3rbVKCYks602x1A@mail.gmail.com>
References: <CA+YzgTvPTRAxMK5EGCF1Y2nsSZZhyW_Rq1gQPvieMdCB70c04w@mail.gmail.com> <CAMZsk6cQRvCNC1ob3Y3TD5aXMsOpkbVT9-Qi9B2=LD84GmS5oQ@mail.gmail.com> <CA+YzgTu=GQciOt79DqaN3P=krfDmsB3fYRthqtLknSF29E3D4w@mail.gmail.com> <CA+YzgTtj5SiZXyc26RF6ifW_1hCGegoc0awXTWfsX+D97n0G5w@mail.gmail.com> <CAMZsk6eUf-ECCdbL-iMQyrdhxDBe2BBWL8T3rbVKCYks602x1A@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Sat, 25 Mar 2017 18:38:13 -0400
Message-ID: <CA+YzgTs-Q_Ab-TMrFosBRmGonXXN0SEJ8DjurJ=bgwSCDjuL-g@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Cc: "teas@ietf.org" <teas@ietf.org>, "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>, Dhruv Dhody <dhruv.dhody@huawei.com>
Content-Type: multipart/alternative; boundary="f403045e296603c099054b95c4cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1z8EktAStJWbjssHBOOtDAVy_54>
Subject: Re: [Teas] <draft-sitaraman-sr-rsvp-coexistence-rec> -- Open Thread
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Mar 2017 22:38:18 -0000

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 <rgandhi.ietf@gmail.com>
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 <
> vishnupavan@gmail.com> 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 <
>> vishnupavan@gmail.com> 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 <rgandhi.ietf@gmail.com>
>>> 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 <
>>>> vishnupavan@gmail.com> 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
>>>>> Teas@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>
>>>>>
>>>>
>>>
>>
>