Looking at this draft, I am trying (as a participant) to understand the
SIDs as they will appear in packets.
In the case of SR-MPLS, will the micro-tap SID come from the block
associated with the processing node? If so, how do we avoid collision
between the microtap SID and the node's own SIDs?
In the case of SRv6, it appears that the microTap SID will be an IPv6
address that is not advertisedby the node, and is in fact advertised by
other nodes. This seems to violate the rules for when a node processes
a SID in the SRv6 specifications?
Also, the processing description seems to say taht the copy is made
before the microTAP sid is removed. Which seems to mean that the
microtap SID will be the topmost SID in the copy and be the basis for
forwarding?
Yours,
Joel
On 3/1/2024 11:51 AM, Jeffrey (Zhaohui) Zhang wrote:
Hi Ed, Jeff,
Thanks for your comments.
Please see zzh> below.
Juniper Business Use Only
*From:*Eduard Metz <etm...@gmail.com>
*Sent:* Friday, March 1, 2024 6:42 AM
*To:* Jeff Tantsura <jefftant.i...@gmail.com>
*Cc:* Ryan Hoffman <ryan.hoffman=40telus....@dmarc.ietf.org>; Jeffrey
(Zhaohui) Zhang <zzh...@juniper.net>; spring@ietf.org;
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/
*[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> 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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
