Hi Greg, That’s a very fair question and not one that has been discussed.
Do we have that kind of accuracy from any of our measurement tools? Is that even on the horizon? I haven’t seen that… If it is time for nanosecond level measurement, then is it time to shift to floating point to give us more range? Tony > On May 23, 2021, at 1:04 PM, Greg Mirsky <[email protected]> wrote: > > 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 > <[email protected] <mailto:[email protected]>> > wrote: > Hi Pengshaofu, > > > > Pls see inline.. > > > > > > Juniper Business Use Only > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: Thursday, May 20, 2021 7:26 AM > To: Shraddha Hegde <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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; > > 抄送人：[email protected];[email protected];[email protected] > > <mailto:[email protected];[email protected];[email protected]>; > > 日 期 ：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: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: Monday, May 17, 2021 12:49 PM > To: Shraddha Hegde <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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; > > 抄送人：[email protected];[email protected];[email protected] > > <mailto:[email protected];[email protected];[email protected]>; > > 日 期 ：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: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: Monday, May 17, 2021 7:40 AM > To: Shraddha Hegde <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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; > > 抄送人：[email protected];[email protected];[email protected] > > <mailto:[email protected];[email protected];[email protected]>; > > 日 期 ：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: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: Thursday, May 13, 2021 1:05 PM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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) > > 收件人：[email protected] <mailto:[email protected]>; > > 抄送人：[email protected] > <mailto:[email protected]>; > > 日 期 ：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 > [email protected] <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
