Dear Authors, 6man and SPRING community, I have read this draft and have several comments I want to share with you. The draft is well-written and I appreciate the work authors put into it. OAM is the essential element of any networking technology and I believe it is important that this document will be published soon after the publication of RFC 8754. Below, please find my comments and questions, some are just an editorial while some may have more technical impact on the document. I appreciate your kind consideration.
- As I understand the document, it consists of two parts - informational and standardization. The informational part explains how existing mechanisms like ICMPv6 can be applied in the SRv6 environment. Also, the applicability of RFC 8403 is explained. In the standardization part, the O-flag is defined and its processing described. I am concerned that that part of the draft is significantly underdeveloped as the threats that are created by the introduction of the O-flag are not identified and protection mechanisms are not sufficiently discussed, specified. As it appears, the O-flag use in SRv6 is very much similar to what already and for a long time has been achieved by using ACLs - sampling data flows. Though managing ACL may be operationally intensive, that is a well-secured process. Using O-flag that can be exploited by an attacker without sufficient protection, as currently defined in the draft, is risky and raises the question of benefit vs. risk. It might be that the benefit of the O-flag is marginal comparing to the risk and complexity its introductions brings in SRv6. - in the Introduction section, you've noted that the document "... includes illustrations of pinging an SRv6 SID for the SID connectivity checks and to validate the availability of a SID ..." We know of two modes of path verification - continuity check (CC) and connectivity verification (CV). The former demonstrates whether there is a path between two network systems. The latter - is to verify that only packets transmitted on that particular connection reach the system. If these commonly accepted definitions of CC and CV also applicable in this document, what is verified by "SID connectivity check"? Also, can you point to the definition of availability metric that, according to the statement, is being validated by pinging a SID? - if "classic IPv6 loopback address", as the document suggests is "2001:DB8:A:k::/128", perhaps you can point out a document that established that tradition. - The O-flag has been introduced as The O-flag in SRH is used as a marking-bit in the user packets to trigger the telemetry data collection and export at the segment endpoints. I think that the definition leaves an open question of whether the O-flag can be set in a test packet originated in the SRv6 domain. For example, can the O-flag be set on BFD control packets periodically transmitted by the SRv6 node? - Pseudocode S01.1 suggests that an implementation that supports the O-flag makes a copy of the marked packet and punts that copy to the control plane. Such processing seems to create a new DoS attack vector even though the Security Considerations section does not acknowledge that. It appears that that part of processing should be discussed in the Security Considerations section and mechanisms to mitigate the threat explained. - In the explanation of traceroute through the reference model some entity is referenced as hop2. What is it? - Perhaps s/SRv6 capable/SRv6-capable/ - Section 3.2.2 describes SID tracing using UDP transport for a test packet. I couldn't find information on the selection of the destination UDP port number for tracing SID. What is it? - Should note that the method to sample a data flow, described in Section 3.3, is similar to what can be achieved using IOAM's Direct Export trace type <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>. Also, the Hybrid Two-Step method of collecting the telemetry information <https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/> may result in fewer additional packets and simplify the correlation of the collected data. Regards, Greg
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
