Zzh2> For comparison, the method in the draft is that an additional microtap SID is inserted after S2: (S1, S2, Tm, S3, S4). Tm is the microtap SID advertised by the node connecting to the monitor.
Indeed, I was suggesting something like: S1, S2’, S3, S4, for SRv6, where "Tm" is encoded in the argument of S2' Or S1, S2’, Tm, S3, S4; where S2' points to the microtap function in N2 (and takes Tm as the "argument") Zzh2> Not due to the SID type, but due to the fact that the SID is simply an IPv6 address, so a less specific route may be matched Understood, this is what I would expect for SRv6. And for SR-MPLS the desired behaviour is that "Tm" will be installed only by nodes with microtap capability, based on the advertised type of the "Tm" SID? cheers, Eduard On Sun, Mar 3, 2024 at 2:06 PM Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> wrote: > Hi Eduard, > > > > Please see zzh2> below. > > > > Juniper Business Use Only > > *From:* Eduard Metz <etm...@gmail.com> > *Sent:* Sunday, March 3, 2024 7:14 AM > *To:* Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> > *Cc:* Jeff Tantsura <jefftant.i...@gmail.com>; Ryan Hoffman <ryan.hoffman= > 40telus....@dmarc.ietf.org>; 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]* > > > > > > 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. > > > > Zzh2> The microtap SID from the node that connects to the monitor does > explicitly point to the microtap function on each tapping node. That is > analogues to that a prefix SID from a node has a function on each node as > “forward to the prefix”. > > Zzh2> If I understand you correctly, let’s say if the normal explicit path > is (S1, S2, S3, S4) where each Sx is a node SID for a node Nx, you’d use > S1, S2’, S3, S4 when you want N2 to tap it, where S2’ is N2’s microtap SID > for a particular monitor. > > Zzh2> This means that each tapping-capable node needs to advertise an > additional SID. That may not be desired, but we can discuss if that should > be a preferred solution or an alternative. > > Zzh2> For comparison, the method in the draft is that an additional > microtap SID is inserted after S2: (S1, S2, Tm, S3, S4). Tm is the microtap > SID advertised by the node connecting to the monitor. > > - 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. > > Zzh2> Not due to the SID type, but due to the fact that the SID is simply > an IPv6 address, so a less specific route may be matched. > > Zzh2> Thanks! > > Zzh2> Jeffrey > > > > > > - 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
