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

[Benjamin Kaduk <[e-mail]>]

Hi Julien,

That's quite helpful; thanks again!

-Ben

On Wed, Jul 03, 2019 at 12:29:17PM +0200, [e-mail] wrote:
> 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.
>