Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Ben,

Would this address your previous comment? (Please see the text in brackets.)

   The semantic of the LOAD-BALANCING object is not changed.  When the
   bandwidth can be summarized into scalars (e.g., for circuit-switched
   technologies, Traffic Parameters express detailed container
   requirements implicitly mapping to a well-defined bandwidth), if a
   PCC requests the computation of a set of TE-LSPs so that the total of
   their generalized bandwidth is X, the maximum number of TE-LSPs is N,
   and each TE-LSP must at least have a bandwidth of B, it inserts a
   BANDWIDTH object specifying X as the required bandwidth and a
   LOAD-BALANCING object with the Max-LSP and Min Bandwidth Spec fields
   set to N and B, respectively.

Thanks,

Julien


On 02/07/2019 18:51, Benjamin Kaduk wrote:
> On Mon, Jul 01, 2019 at 11:45:04AM +0200, [e-mail] wrote:
>> Hi Ben,
>>
>> Thank you for following up. Please see [JM] below.
>>
>>
>> On 29/06/2019 02:51, Benjamin Kaduk wrote:
>>> Hi Julien,
>>>
>>> On Fri, Jun 28, 2019 at 03:26:33PM +0200, [e-mail] wrote:
>>>> Hi Ben,
>>>>
>>>> Apologies for the late response.
>>> I probably wouldn't have been able to reply much before now anyway -- I've
>>> been quite busy (and have some other documents' authors waiting for
>>> feedback as well).
>>>
>>>> Let us focus on your first DISCUSS comment which is the main one. You
>>>> raised a legitimate point that we acknowledge. After discussion, we
>>>> propose to modify the end of section 2.4 as follows:
>>>>
>>>> OLD
>>>>
>>>>    The semantic of the LOAD-BALANCING object is not changed.  If a PCC
>>>>    requests the computation of a set of TE-LSPs so that the total of
>>>>    their generalized bandwidth is X, the maximum number of TE-LSPs is N,
>>>>    and each TE-LSP must at least have a bandwidth of B, it inserts a
>>>>    BANDWIDTH object specifying X as the required bandwidth and a LOAD-
>>>>    BALANCING object with the Max-LSP and Min Bandwidth Spec fields set
>>>>    to N and B, respectively.
>>>>
>>>> NEW
>>>>
>>>>    The semantic of the LOAD-BALANCING object is not changed.  When the
>>>>    bandwidth can be expressed as scalars (e.g., for circuit-switched
>>>>    technologies), if a PCC requests the computation of a set of TE-LSPs
>>>>    so that the total of their generalized bandwidth is X, the maximum
>>>>    number of TE-LSPs is N, and each TE-LSP must at least have a
>>>>    bandwidth of B, it inserts a BANDWIDTH object specifying X as the
>>>>    required bandwidth and a LOAD-BALANCING object with the Max-LSP and
>>>>    Min Bandwidth Spec fields set to N and B, respectively.
>>>>
>>>>    For technologies based on statistical multiplexing (e.g., InterServ,
>>>>    Ethernet), the exact bandwidth management (e.g., Ethernet's Excessive
>>>>    Rate) is left to the PCE's policies, according to the operator's
>>>>    configuration. If required, further documents may introduce a new
>>>>    mechanism to finely express complex load balancing policies within
>>>>    PCEP.
>>>>
>>>>
>>>> Would that update address that part of your DISCUSS? (The remaining
>>>> parts will be straightforward once this one is resolved.)
>>> I seem to have forgotten some of the details of what fields are in the
>>> various objects, but let's see what I can say regardless of that.
>>> I think the general approach of specifying behavior when there's an obvious
>>> scalar bandwidth and leaving the choice to the PCE in other cases is a good
>>> approach.
>>>
>>> For the specifics, we probably don't want to say "when the bandwidth can be
>>> expressed as a scalar" and "for technologies based on statistical
>>> multiplexing" just in case there ends up being some third category, so the
>>> second paragraph could start off as something like "In all other cases,
>>> including for technologies based on statistical multiplexing [...]".
>> [JM] You're right. That's a safer wording, easy to include.
>>
>>> It also seems like for the first case, we would be able to use the
>>> un-modified RFC 5440 BANDWIDTH and not need the generalized form?  But
>>> perhaps I misremember/misunderstand...
>> [JM] This is indeed what the current wording suggests, so I propose to
>> change "expressed by scalars" with "summarized into scalars". The idea
>> here is to accommodate existing constructs from RSVP-TE signaling, which
>> are compound objects allowing to specify more detailed information than
>> aggregated values. E.g., a single 10 Gb/s circuit vs. a group of 4 x 2.5
>> Gb/s containers.
>> That would lead us to the following text:
>>
>>    The semantic of the LOAD-BALANCING object is not changed.  When the
>>    bandwidth can be summarized into scalars (e.g., for circuit-switched
>>    technologies), if a PCC requests the computation of a set of TE-LSPs
>>    so that the total of their generalized bandwidth is X, the maximum
>>    number of TE-LSPs is N, and each TE-LSP must at least have a
>>    bandwidth of B, it inserts a BANDWIDTH object specifying X as the
>>    required bandwidth and a LOAD-BALANCING object with the Max-LSP and
>>    Min Bandwidth Spec fields set to N and B, respectively.
>>
>>    In all other cases, including for technologies based on statistical
>>    multiplexing (e.g., InterServ, Ethernet), the exact bandwidth
>>    management (e.g., Ethernet's Excessive Rate) is left to the PCE's
>>    policies, according to the operator's configuration. If required,
>>    further documents may introduce a new mechanism to finely express
>>    complex load balancing policies within PCEP.
>>
>> Is it better?
> That is better; thank you.
>
> The only other comment I have would be to ask if it's worth saying
> something in the first paragraph about how "other link-technology-specific
> parameters are not included in the bandwidth calculation" (with my
> apologies for probably using the wrong terminology; this is not my area of
> expertise).
>
> -Ben


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.