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

[tom petch]

From: Lsr  on behalf of gregory.mir...@ztetx.com 

Sent: 25 May 2021 22:02

Inline under 
Tom Petch

Hi Tony,

thank you for clarifying your view on this. Please find my notes in-line below 
under the GIM>> tag.


Regards,

Greg Mirsky


Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]  [cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com
www.zte.com.cn
Original Mail
Sender: TonyLi
Date: 2021/05/25 09:52

Hi Greg,

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 
nanoseconds or 100 nanoseconds.

Ok.  The specific precision isn’t particularly relevant to me.  The real 
questions are whether microseconds are the right base or not, and whether we 
should shift to floating point for additional range or add more bits.

To Tony's question, the delay is usually calculated from the timestamps 
collected at measurement points (MP). Several formats of a timestamp, but most 
protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits 
represent seconds and 32 bits - a fraction of a second. As you can see, the 
nanosecond-level resolution is well within the capability of protocols like 
OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of 
the packet delay metric, I can think of URLLC in the MEC environment. I was 
told that some applications have an RTT budget of in the tens microseconds 
range.

It’s very true that folks have carried around nanosecond timestamps for a long 
time now.  No question there. My question is whether it is actually useful. 
While NTP has that precision in its timestamps, the actual precision  of NTP’s 
synchronization algorithms aren’t quite that strong.  In effect, many of those 
low order bits are wasted.

GIM>> What I see from deployment of active measurement protocols, e.g., TWAMP 
and STAMP, is the strong interest in using PTP, i.e. IEEE 1588v2, timestamp 
format in the data plane. And the requirement (actually, there are different 
profiles) for the quality of clock synchronization for 5G is, as I understand 
it, achievable with PTP. I have no information if that is the case with NTP.

That’s not a big deal, but when we make the base more precise, we lose range.  
If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 
seconds. Tolerable, but it will certainly disappoint Vint and his 
inter-planetary Internet. :-)

GIM>> Agree. I would propose to consider 100 usec as a unit, which gets close 
to 7 minutes.

We could go with 64 bits of nanoseconds, but then we’ll probably only rarely 
use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the 
expense of having fewer significant bits in the mantissa.

Personally, I would prefer to stay with 32 bits, but I’m flexible after that.

GIM>> I think that we can stay with a 32 bit-long field and get better 
resolution at the same time.



A related item.  I was looking at draft-ietf-detnet-yang which uses uint32 
nanoseconds for latency so that is another where nanoseconds can be found.

Tom Petch

Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Lizhenbin]

Hi All,

I do not support the adoption. I am concerned that we are in the danger of 
re-inventing IGP multi-topology with Flex-Algo. I do not think it is necessary. 
If we have the requirements, we can either directly use the multi-topology or 
extend Flex-Algo without change its principle.


Best Regards,
Zhenbin (Robin)




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi Peter,

Thanks for your reply. Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, May 28, 2021 4:10 PM
> To: Dongjie (Jimmy) ; Christian Hopps
> ; lsr@ietf.org
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jimmy,
> 
> please see inline:
> 
> On 28/05/2021 05:39, Dongjie (Jimmy) wrote:
> > Hi,
> >
> > I don't support the adoption of this document.
> >
> > It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS,
> its typical use case is to provide protection path with Flex-Algo constraints 
> for
> Adj-SID of a particular Flex-Algo, which is described in the case 3 of 
> section 3.
> >
> > However, section 3 and section 5 shows that it also aims to introduce 
> > further
> changes to the usage and operation of Flex-Algo, which is to provide resource
> reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves
> further discussion and is not only related to the per Flex-Algo Adj-SID
> extension.
> 
> personally, I consider use case 3 (per algo protected Adj SID) the main reason
> we need this draft.

I share the similar opinion with you. 


> I don't care much about the other use cases to be honest, but I see no reason
> why an implementation can not associate local resources on a per algo basis.
> Sure, algo is not in the packet, but there are various indirect ways of doing 
> that.
> All local behavior.

If all of these are local behavior, IMO they do not need to be described in 
this draft. 

> > Here are some comments about this change to Flex-Algo:
> >
> > 1. Flex-Algo defines the constraints for path computation in a distributed
> manner, it is not for resource reservation.
> >
> > 2. Reserving resources for each Flex-Algo on a link does not make sense. The
> correlation between Flex-Algo and the network links is based on administrative
> groups (color), and the color of the link may or may not be included in the
> Flex-Algo definition. To follow the color based link correlation, a more 
> practical
> approach would be to use Flex-Algo with L2 bundle as defined in
> draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
> and
> the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo
> resource reservation.
> 
> "correlation between Flex-Algo and the network links is based on
> administrative groups" - that's one way of doing so. There are others.

OK, my point is Flex-Algo uses link constraints (color, SRLG, bandwidth 
constraint, etc.) in the FAD to associate it with a set of links, rather than 
configuring the Flex-Algo ID explicitly on the links. 


> >
> > 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE
> attributes are shared by all Flex-Algos which include the link according to 
> the
> FAD, and based on previous discussion, it seems there is no intention to
> introduce per Flex-Algo ID link attributes.
> 
> that's right, but I see no direct relationship with the above.

Thanks for confirming that there is no intention to introduce per Flex-Algo ID 
link attributes. Taking this and the above item into consideration, I assume 
the current Flex-Algo model does not support per Flex-Algo ID based queue and 
bandwidth configuration on a link.

> 
> Anyway, I'm not a big fun of IETF documents describing local behaviors
> which are not needed for interoperability, so keeping these things out
> of the draft would be fine with me.

Agreed, removing those use cases and operation text which are not related to 
Flex-Algo interoperability would make this document simpler. 

Best regards,
Jie

> 
> 
> 
> thanks,
> Peter
> 
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> >> Sent: Thursday, May 27, 2021 4:57 AM
> >> To: lsr@ietf.org
> >> Cc: cho...@chopps.org
> >> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID
> >> Advertisement"
> >>
> >>
> >> Hi Folks,
> >>
> >> This begins a 2 week WG Adoption Call for the following draft:
> >>
> >>
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-si
> d
> >> /
> >>
> >> Please indicate your support or objections by June 9th, 2021
> >>
> >> Authors, please respond to the list indicating whether you are aware of any
> IPR
> >> that applies to this draft.
> >>
> >> Thanks,
> >> Acee and Chris.
> >>
> >> ___
> >> Lsr mailing list
> >> Lsr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lsr
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> >

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Peter Psenak]

Hi Jimmy,

please see inline:

On 28/05/2021 05:39, Dongjie (Jimmy) wrote:

Hi,

I don't support the adoption of this document.

It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its 
typical use case is to provide protection path with Flex-Algo constraints for 
Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 
3.

However, section 3 and section 5 shows that it also aims to introduce further 
changes to the usage and operation of Flex-Algo, which is to provide resource 
reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further 
discussion and is not only related to the per Flex-Algo Adj-SID extension.


personally, I consider use case 3 (per algo protected Adj SID) the main 
reason we need this draft.


I don't care much about the other use cases to be honest, but I see no 
reason why an implementation can not associate local resources on a per 
algo basis. Sure, algo is not in the packet, but there are various 
indirect ways of doing that. All local behavior.





Here are some comments about this change to Flex-Algo:

1. Flex-Algo defines the constraints for path computation in a distributed 
manner, it is not for resource reservation.

2. Reserving resources for each Flex-Algo on a link does not make sense. The 
correlation between Flex-Algo and the network links is based on administrative 
groups (color), and the color of the link may or may not be included in the 
Flex-Algo definition. To follow the color based link correlation, a more 
practical approach would be to use Flex-Algo with L2 bundle as defined in 
draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
and the L2 member link to a Flex-Algo, this avoids the extension for 
per-FlexAlgo resource reservation.


"correlation between Flex-Algo and the network links is based on 
administrative groups" - that's one way of doing so. There are others.





3. The Flex-Algo link TE attributes are advertised using ASLA, the TE 
attributes are shared by all Flex-Algos which include the link according to the 
FAD, and based on previous discussion, it seems there is no intention to 
introduce per Flex-Algo ID link attributes.


that's right, but I see no direct relationship with the above.

Anyway, I'm not a big fun of IETF documents describing local behaviors 
which are not needed for interoperability, so keeping these things out 
of the draft would be fine with me.




thanks,
Peter



Best regards,
Jie


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Thursday, May 27, 2021 4:57 AM
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
Advertisement"


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid
/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR
that applies to this draft.

Thanks,
Acee and Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr