Thanks, see inline / below. /Eduard
> > > 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). > > > [EM] Makling a copy based on the microtap SID (instead of simply forwarding it) is what I referred to as an integrated capabiltiy of the basic SR forwarding. In SRv6 alternatively one could add a SID that points (explicitly) to the microtap (replication) function (with the reference to the microtap SID as the argument) , instead of triggering a different behaviour based on the value of a SID. > - 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. > [EM] Ah, this is due to the SID type? Some clarification would be useful indeed. > > > - 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? > [EM] I wondered whether the sequence ID would be sufficient or additional info is needed, e.g. to identify a tapped traffic stream and establish if all tapped packets have been received at the monitor. At the source one may want to add additional information anyway to identify a tapped traffic stream, e.g. to combine and/or demultiplex packets at the monitor. > Zzh> Thanks. > > Zzh> Jeffrey > > > > cheers, > > Eduard > > > > > > On Wed, Feb 28, 2024 at 4:52 AM Jeff Tantsura <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> 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> > 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 > 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 > 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 https://www.ietf.org/mailman/listinfo/spring
