Re: [spring] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/

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.ietf@gmail.com>
> wrote:
>
> Seems like a very useful feature indeed.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> On Feb 27, 2024, at 07:15, Ryan Hoffman <ryan.hoffman=
> 40telus.com@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 <zzhang@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$>
>
>