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 SID
Hi Robert,
Juniper Business Use Only
From: Robert Raszuk
Sent: Friday, March 1, 2024 12:14 PM
To: Jeffrey (Zhaohui) Zhang
Cc: Eduard Metz ; Jeff Tantsura ;
Ryan Hoffman ; spring@ietf.org;
draft-zzhang-spring-microtap-segm...@ietf.org
Subject: Re: [spring] Request comments/feedback on
https:
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
Hi Ed, Jeff,
Thanks for your comments.
Please see zzh> below.
Juniper Business Use Only
From: Eduard Metz
Sent: Friday, March 1, 2024 6:42 AM
To: Jeff Tantsura
Cc: Ryan Hoffman ; Jeffrey (Zhaohui)
Zhang ; spring@ietf.org;
draft-zzhang-spring-microtap-segm...@ietf.org
Subject: Re: [spring] [
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
