Hi Robert,
Juniper Business Use Only From: Robert Raszuk <rob...@raszuk.net> Sent: Friday, March 1, 2024 12:14 PM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> Cc: Eduard Metz <etm...@gmail.com>; Jeff Tantsura <jefftant.i...@gmail.com>; Ryan Hoffman <ryan.hoff...@telus.com>; spring@ietf.org; draft-zzhang-spring-microtap-segm...@ietf.org Subject: Re: [spring] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/ [External Email. Be cautious of content] Hi Jeffrey, I have a question here ... Are you completely dismissing the case where monitor itself may be microTAP SR capable or that microTAP capable node may simply IP encapsulate interesting traffic to monitor node which in turn would be just reachable in the IGP and not connected directly to any SR/MicroTAP capable node ? Zzh> No, we’re not. Any node, say A, may be directly or indirectly connected to a monitor. It could advertise a MicroTap SID that any tapping-capable node, say B, can use to send a tapped copy to A. How A sends the copy to the monitor does not matter. Zzh> Yes, any tapping-capable node can advertise a MicroTap SID for itself and then tunnel the tapped copy to a monitor. That is still within the framework of this draft, though we do want to allow the tapping node to be different from the owner of the MicroTap SID. Zzh> If that is what Eduard meant, I missed that. You seems to be highlighting in both draft and below responses that monitor must be directly connected to SR node ... which is surely possible but IMO it limits the deployment options. Zzh> No, that’s not the case – even though I might have given the impression. The owner of the MicroTap SID only needs a way to get the packet (tapped by any tapping-capable node) to the monitor – however that is done does not matter. Zzh> Thanks! Zzh> Jeffrey Many Thx, Robert On Fri, Mar 1, 2024 at 5:51 PM Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> wrote: Hi Ed, Jeff, Thanks for your comments. Please see zzh> below. Juniper Business Use Only From: Eduard Metz <etm...@gmail.com<mailto:etm...@gmail.com>> Sent: Friday, March 1, 2024 6:42 AM To: Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> Cc: Ryan Hoffman <ryan.hoffman=40telus....@dmarc.ietf.org<mailto:40telus....@dmarc.ietf.org>>; Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; spring@ietf.org<mailto:spring@ietf.org>; draft-zzhang-spring-microtap-segm...@ietf.org<mailto:draft-zzhang-spring-microtap-segm...@ietf.org> Subject: Re: [spring] [WARNING: SUSPICIOUS SENDER] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/__;!!NEt6yMaO-gk!H7NdCJE-fzviBa5X6lM5Fe-ECUX0_0V7KZRKqoVf17UrQb890mvDxroR0noMEHJFT_dItxFrgD0PgB0v$> [External Email. Be cautious of content] I think this is a relevant use-case / feature. Few comments after first read: - For SRv6 the procedure may be slightly different, ie steer traffic via MicroTAP capable node or have MicroTAP as integrated capability of "default" forwarding (of capable nodes) and indicate the parameter - this is the approach in the current draft if I understand correctly. Zzh> The microtap segment belongs to the node connected to the monitor, which is typically not in the path of most traffic. When a capable node in the normal traffic path encounters a microtap SID (which is not advertised by that node), it makes a copy and send the copy to the owner of the microtap SID (while continue to forward the original copy after removing the microtap SID). Zzh> Therefore, it is not an integrated capability of “default” forwarding (of capable nodes). - Section 2.3 describes that if a MicroTAP SID becomes the active on the a node not supporting the MicroTAP capability, the packet would be dropped. I wondered if this is correct? Wouldnt the packet be forwarded to the "monitor" node? This breaks the communication effectively, but not a drop at the node not supported MicroTAP. Zzh> A node not supporting MicroTAP will not advertise its capability or install the forwarding state for MicroTAP SIDs (advertised by the nodes connected to the monitors). Zzh> As a result, other nodes SHOULD NOT place a MicroTap SID after the node/adj SID for the incapable node. In the unlikely case if that happened, in the case of MPLS the packet will simply be dropped (there is no corresponding state). In the case of SRv6, there might not be a corresponding IPv6 route either and traffic will also be dropped. But if there is a less specific route covering that MicroTap SID, then it will be forwarded accordingly. We will add that clarification. - In general, or least for intercept, one would be interested in both directions of a traffic stream (e.g to / from a specific IP). To address this, the MicroTAP SID would need to inserted on all relevant ingresses. And the monitor may receive packets from different MicroTAP capable nodes. This may have implications for the use of IOM header (e.g. to avoid duplicate sequence ids) Zzh> A monitor is going to receive tapped packets from all over the places (it all depends on which packets carry the MicroTap SID and where in the SID list), but unless a MicroTap SID is repeated (in different places of the SID list) in the packet, the monitor will only receive one tapped copy for a particular packet. I also imagine that an ingress is likely coordinating with the monitor when it places the MicroTap SID, even though that’s outside the scope of this draft. Zzh> Can you explain the implications for the use of IOM header? Zzh> Thanks. Zzh> Jeffrey cheers, Eduard On Wed, Feb 28, 2024 at 4:52 AM Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>> wrote: Seems like a very useful feature indeed. Cheers, Jeff On Feb 27, 2024, at 07:15, Ryan Hoffman <ryan.hoffman=40telus....@dmarc.ietf.org<mailto:40telus....@dmarc.ietf.org>> wrote: TELUS intends to deploy this microTap segment feature once available in vendor NOS after thorough testing in our lab. We'd expedite TELUS testing and deployment when available from vendors, as this is a much needed feature in our network. Thanks, Ryan Hoffman On Wed, Apr 5, 2023 at 3:28 PM Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>> wrote: Hi, The authors of this draft would like to get your feedback on this draft. This document specifies a microTap segment that can be used to instruct a transit node to make a copy of a segment-routed packet and deliver it to a specified node for the purpose of network monitoring, trouble shooting, or lawful intercept. Due to the limit of Spring WG session time we have not been able to present it but we submitted slides before: https://datatracker.ietf.org/meeting/115/materials/slides-115-spring-slides-115-spring-microtap-segment-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/115/materials/slides-115-spring-slides-115-spring-microtap-segment-00__;!!NEt6yMaO-gk!EKhg-4oZEfTFYJNmgp8IGr1V5a4BR45VWyFGE1yjXKX5wyy_b1J1I5V1a1TwceJBWn4B_S11vdYmbIo$>. Thanks. Jeffrey Juniper Business Use Only _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!EKhg-4oZEfTFYJNmgp8IGr1V5a4BR45VWyFGE1yjXKX5wyy_b1J1I5V1a1TwceJBWn4B_S11CmS-d-Q$> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!EKhg-4oZEfTFYJNmgp8IGr1V5a4BR45VWyFGE1yjXKX5wyy_b1J1I5V1a1TwceJBWn4B_S11CmS-d-Q$> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!H7NdCJE-fzviBa5X6lM5Fe-ECUX0_0V7KZRKqoVf17UrQb890mvDxroR0noMEHJFT_dItxFrgNKWd-X0$>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
