Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Shraddha, Authors, et al.,
I apologize if my question has already been discussed. The unit for the
maximum link delay in the draft is a microsecond. There is a group of
services that require a highly accurate bounded delay. Have you considered
using a nanosecond as the unit for the link delay?

Regards,
Greg

On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde <shraddha=
40juniper.net@dmarc.ietf.org> wrote:

> Hi Pengshaofu,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
> *Sent:* Thursday, May 20, 2021 7:26 AM
> *To:* Shraddha Hegde <shraddha@juniper.net>
> *Cc:* acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-con@ietf.org
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Shraddha,
>
>
>
> Thanks. Actually, I don't really want to define other metric types.
>
> Let's go back to the bandwidth-metric related to bandwidth capability. My
> worry is that bandwidth-metric (whether it is automatically calculated or
> manually configured) is not cumulative in nature,
>
> <Shraddha> Yes that is correct.
>
> which is different from IGP default metric/TE metric/delay metric,
>
>
>
> so that SPF based on bandwidth-metric may get an unexpected path (see the
> example of the original mail).
>
> Can more text be added in the draft to describe why this can work ?
>
> <Shraddha> Knowing that metric derived inversely from the link bandwidth
> is not additive in nature, should set the expectation right. I can add some
> text in this regard.
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
> 原始邮件
>
> *发件人：*ShraddhaHegde
>
> *收件人：*彭少富10053815;
>
> *抄送人：*
> acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-con@ietf.org
> ;
>
> *日* *期* *：*2021年05月18日 13:01
>
> *主* *题* *：**RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> Hi Pengshaofu,
>
>
>
> If an operator wants to configure any other metric type draft provides a
> mechanism with generic metric.
>
> Generic metric allows any standard or user-defined type metric to be
> configured.
>
> The draft allows for any computing application such as Flex-algo, CSPF etc
> to make use of the
>
> Metric. The intention of the draft is that for a particular computation
> same metric-type is used
>
> throughout the network. If that is not clear, I’ll add some text in the
> draft.
>
>
>
> Using a combination of different metrics for a single computation would
> need significant change to SPF algorithm and it is not in the scope of the
> draft "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints".
>
>
>
> Hope that clarifies.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
> *Sent:* Monday, May 17, 2021 12:49 PM
> *To:* Shraddha Hegde <shraddha@juniper.net>
> *Cc:* acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-con@ietf.org
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Shraddha,
>
>
>
> The two methods of automatic generation of BW-metric introduced in the
> draft are also likely to be the method of manual configuration of BW-metric
> by operators. Operators can certainly manually configure any  BW-metric he
> wants to configure.
>
> However, the manually configured BW-metric cannot deviate from the actual
> bandwidth capacity of the link, otherwise it could be any other names such
> as BX-metric.
>
> For manual assignment, the problem may still exist We can find an example
> that  the accumulated bandwidth-metric on the path may offset the manually
> increased bandwidth-metric of links on the path.
>
> Combination of bandwidth attribute of link and other metric that is
> cumulative may be another co-exist way to completely address this issue.
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
>
>
>
>
> 原始邮件
>
> *发件人：*ShraddhaHegde
>
> *收件人：*彭少富10053815;
>
> *抄送人：*
> acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-con@ietf.org
> ;
>
> *日* *期* *：*2021年05月17日 12:15
>
> *主* *题* *：**RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> Hi Pengshaofu,
>
>
>
> I was suggesting to manually assign bandwidth metric which will override
> the automatic metric calculation
>
> as described in the draft section 5. Physically adding more fiber/capacity
> is not a feasible solution.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
> *Sent:* Monday, May 17, 2021 7:40 AM
> *To:* Shraddha Hegde <shraddha@juniper.net>
> *Cc:* acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-con@ietf.org
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Shraddha,
>
>
>
> Thanks for your rely.
>
> So it seems that the scheme may lead to the selection of links with less
> bandwidth. To address this point, the method as you described to assign
> more bandwidth to high bandwidth links seems not always possible, e.g,
> adding more fiber ?
>
> Can this point can be addressed by combination of bandwidth attribute of
> link and other metric that is cumulative ? IMO, bandwidth is not cumulative.
>
>
>
> Regards
>
> PSF
>
>
>
> 原始邮件
>
> *发件人：*ShraddhaHegde
>
> *收件人：*彭少富10053815;
>
> *抄送人：*
> acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-con@ietf.org
> ;
>
> *日* *期* *：*2021年05月13日 21:01
>
> *主* *题* *：**RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> Hi Peng shaofu,
>
>
>
> As per the draft, if automatic metric calculation with reference bandwidth
> method is used to calculate the metric
>
> Then as per your example s->D path will be chosen since metric is 10.
>
> Lets say operator wants to choose S->X1->X2-àX10->D path then operator
> can manually assign higher bandwidth
>
> Metric on S->D link which will ensure S->D path is not the least cost path.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
> *Sent:* Thursday, May 13, 2021 1:05 PM
> *To:* peng.shaofu@zte.com.cn
> *Cc:* acee=40cisco.com@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-con@ietf.org
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Sorry for spelling mistakens in the previous email.
>
> updated text:
>
>
>
>
>
> Hi WG,
>
>
>
> I have a little doubt about the scheme described in this document.
>
> See the following example:
>
>
>
> S ---- X1 ----- X2 ---- ... ... ----- X10 ----- D
>
>     \----------------------------------------------/
>
>
>
> Suppose the links in S---X1---X2...---D have the same bandwidth  10G, and
> the link S-D has bandwidth 1G.
>
> Suppose that we select "reference bandwidth = 100G", then,
>
> each link  in S---X1---X2...---D will have the same bandwidth-metric  10
> (i.e., 100/10)
>
> link S-D will have a bandwidth-metric 100 (i.e., 100/1)
>
>
>
> So flex-algo path from S to D based on bandwidth-metric will be S-D,
> not S---X1---X2...---D, because the later has a large cumulative
> bandwitdh-metric (i.e., 11*10).
>
> But our expect path should not be S-D, but S---X1---X2...---D, as it has
> large bandwidth.
>
> Do I misunderstand anything ?
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
>
>
>
>
> *发件人：*AceeLindem(acee)
>
> *收件人：*lsr@ietf.org;
>
> *抄送人：*draft-hegde-lsr-flex-algo-bw-con@ietf.org;
>
> *日* *期* *：*2021年05月13日 05:49
>
> *主* *题* *：**[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02*
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsL6l_0sA$>
>
> Esteemed Members of the LSR WG,
>
>
>
> This begins a 2 week WG adoption call for the following draft:
>
>
>
>      https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!TGikk55jVo2FINSWYcGBMe1xnCiMVRlVaOhe77F76PCVbDj893SQ5uuqsET5yKGD$>
>
>
>
>
> Please indicate your support or objection by May 27th, 2021.
>
>
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
>
>
> Thanks,
>
> Chris and Acee
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>