Hi Tal. Thanks for the review and comments. Please find Inline [AA]
From: Tal Mizrahi <tal.mizrahi....@gmail.com> Date: Tuesday, 15 March 2022 at 11:28 To: Ahmed Abdelsalam (ahabdels) <ahabdels=40cisco....@dmarc.ietf.org>, spring@ietf.org <spring@ietf.org>, i...@ietf.org <i...@ietf.org>, draft-filsfils-spring-path-trac...@ietf.org <draft-filsfils-spring-path-trac...@ietf.org> Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt Dear authors, Thanks for sharing this interesting draft. Per-hop measurement and reporting is a very important OAM tool, and there is quite a bit of ongoing / previously proposed work in the IETF about this topic. A few comments: 1. It looks like the draft defines two aspects: (a) the path tracing IPv6 option, which is not specific to segment routing, but is actually applicable to IPv6 routers in general, and (b) an SRH TLV. It seems like the SRH TLV could alternatively be defined as a generic IPv6 destination option. Is there anything that functionally limits this feature to networks that use segment routing? [AA] Path Tracing has been designed to work on segment routing networks. As such, it leverages a few SRv6 constructs: the binding SID (End.B6.TEF) at the sink node, some assumptions from SR networks that are particularly useful for security (i.e. the SR Domain) and others. 2. As Greg pointed out in a previous email, the functionality here seems very similar to IOAM. The PT option could actually be implemented by using an IOAM trace option: by defining a couple of new data fields you could get an equally compact number of bits as the PT option in the current draft. The SRH TLV could alternatively be defined as an IOAM Edge-to-edge option (again, maybe with a couple of new data fields). Is there a reason why this is a new protocol, rather than just defining new data field types in IOAM? [AA] We believe that PT and iOAM are tackling the problem from different angles. We don’t believe that IOAM with trace option could address our case (particularly, we have ensured that PT can be implemented at linerate across most silicon). 3. Time synchronization is defined as a 'MUST' in the draft, but it seems like you can benefit from path tracing even in cases where synchronization is not possible. Have you considered such use cases? [AA] I agree with you. For example, simply collecting the interface IDs is already valuable. However, it seems all the operators that would be interested in PT do have time synchronization in their network. Hence there seems to be no value on that. Any feedback is welcomed. 4. Regarding 'MCD.TTS (Truncated Timestamp)': rather than defining some of the bits to represent milliseconds and other bits to represent microseconds, it may be more hardware-friendly to define a subset of the bits of timestamp formats that are commonly implemented in hardware, such as the PTP timestamp format or the NTP timestamp format. [AA] We will clarify the text in the draft. What you are proposing is exactly how it works today. The TTS template defines the position of 8-bits to be selected from the node timestamp. The HW will just copy these bits into the HbH. Still, part of the selected bits can represent milliseconds and part can representing microseconds. For example, if the operator configures a template that selects bits 16 to 23, this means that 4 most significant bits are coming from the part carrying the milliseconds and the 4 least significant bits will be carrying fraction of millisecond (i.e., unit of microseconds) Thanks! Cheers, Tal. On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels) <ahabdels=40cisco....@dmarc.ietf.org> wrote: > > Dear SPRING WG, IPPM WG, > > > > We have submitted a new I-D for Path Tracing in SRv6 networks > (https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to > SPRING WG. > > > > We are looking for your feedback and comments. > > > > Path Tracing provides a record of the packet path as a sequence of interface > ids. In addition, it provides a record of end-to-end delay, per-hop delay, > and load on each egress interface along the packet delivery path to > facilitate operation of SR networks. > > > > Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop > extension header. > > > > We will present Path Tracing to the SPRING WG at next IETF > (https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) > > > > Thanks, > > Ahmed > > > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > Date: Friday, 4 March 2022 at 16:48 > To: Ahmed Abdelsalam (ahabdels) <ahabd...@cisco.com>, cf(mailer list) > <c...@cisco.com>, Mark Yufit <mark.yu...@broadcom.com>, Pablo Camarillo > (pcamaril) <pcama...@cisco.com>, Pablo Camarillo (pcamaril) > <pcama...@cisco.com>, Satoru Matsushima <satoru.matsush...@g.softbank.co.jp>, > Thomas.Graf <thomas.g...@swisscom.com>, Yuanchao Su > <yitai....@alibaba-inc.com> > Subject: New Version Notification for > draft-filsfils-spring-path-tracing-00.txt > > > A new version of I-D, draft-filsfils-spring-path-tracing-00.txt > has been successfully submitted by Pablo Camarillo Garvia and posted to the > IETF repository. > > Name: draft-filsfils-spring-path-tracing > Revision: 00 > Title: Path Tracing in SRv6 networks > Document date: 2022-03-04 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt > Status: > https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing > > > Abstract: > Path Tracing provides a record of the packet path as a sequence of > interface ids. In addition, it provides a record of end-to-end > delay, per-hop delay, and load on each egress interface along the > packet delivery path. > > Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- > by-Hop extension header. > > Path Tracing supports fine grained timestamp. It has been designed > for linerate hardware implementation in the base pipeline. > > > > > The IETF Secretariat > > _______________________________________________ > ippm mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
