From gurminderjit.bajwa@telus.com Wed Mar 13 13:41:12 2024 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB16C14F70E for ; Wed, 13 Mar 2024 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telus.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ-iNUradlu8 for ; Wed, 13 Mar 2024 13:41:08 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4B5C14F69A for ; Wed, 13 Mar 2024 13:41:08 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6e6c4c12dd2so323248b3a.0 for ; Wed, 13 Mar 2024 13:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.com; s=google; t=1710362468; x=1710967268; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QyActwipE02m5Rl3nnTRZEFGa8O1YiGgNb2tauJ5vrw=; b=0r/eTvvLDgZKEJlf0/z1UbF1TweU44S8CBtocdD8ueFhmydC/EmEiVAE4szOI5dSLY Ay7Fmrnuv35LZhHPaDlNLw2KuWDwCcY/n+CXqeMc2lnpQFqBnaUpIg1UKNMV7kYqTb6h ViDEGKrj9u3pkYoiliwRhU4O0ApEU4JGXkl6g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710362468; x=1710967268; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QyActwipE02m5Rl3nnTRZEFGa8O1YiGgNb2tauJ5vrw=; b=WcHUA8k8xJTvA+pcEpADhM7P+GiZvVfQTrrmJmLagQesbQ4pnHsA9/8nK/DGdZbwo6 Kwb+liO0N/oMZ64o7ErrXcQcVFmi8qEucOQbG1q8kxg1MAlEBbukToPfiJXDCoMfALeF b1hnHn1zMkIivvUVH5ACgJlOWaW9inTf11M+6GLVHN038Fg1QREORDGKJK2FEFVhoZTD CLyOHVyTw0b7lfok3ETZyk39hSO/1b73YRdN8TKCuD7NDqeAd0F9YpqmS5K1f+bETxIw MJyLeSZPk1q/9Cd4+1rBdddggf+sJGKIK/HwV9rG8ZpnzzL9ZcpH3uNqhXj1tPfGK/Ln 68Yw== X-Forwarded-Encrypted: i=1; AJvYcCUTDnuylhsq0DfweCIskxbnofYXGRubjxyLCKDUUZB8eosw8fJA2yZ+R3snQw6v06lh3Zx/ezdv/qIbmtNMcZ8= X-Gm-Message-State: AOJu0YwaJXG8Fn9lmlOTd+WJ+nw87bJkTW5bbaMCEScrSbDNskp7ZOBC 6mr2msmJCHyreNV21+QnCKn8gBerNs8JRiot+Scdry/U2V1YkabdIlQk35aNeqErJ7Pij5Mqaz0 B/tN/TZrcjDkMqeXZMXb11suHffvjREL2pU5Y2w== X-Google-Smtp-Source: AGHT+IHSpXn+lLG+JZisgGhOGb04bGQ76gD436oilGN0eXIxwd2triLNWPaLbf8Jqu7UDaLZTPEbVit3djqCSqS1EWI= X-Received: by 2002:a05:6a21:9216:b0:1a1:4ec7:d3fb with SMTP id tl22-20020a056a21921600b001a14ec7d3fbmr44468pzb.58.1710362467906; Wed, 13 Mar 2024 13:41:07 -0700 (PDT) MIME-Version: 1.0 References: <3187342B-DA67-4857-A4E6-926CF54861D2@gmail.com> In-Reply-To: From: Gurminderjit Bajwa Date: Wed, 13 Mar 2024 16:40:41 -0400 Message-ID: To: Joel Halpern Cc: "Jeffrey (Zhaohui) Zhang" , "spring@ietf.org" , "draft-zzhang-spring-microtap-segment@ietf.org" Content-Type: multipart/alternative; boundary="000000000000569bc3061390cb22" Archived-At: Subject: Re: [spring] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/ X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2024 20:41:12 -0000 --000000000000569bc3061390cb22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Joel, Please see comments below. 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? [GB] In the case of SR-MPLS, the microTap SID is allocated from the SRGB which makes it globally unique and helps avoid collision with any node 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? [GB] In the case of SRv6, microTap SID is advertised by the monitor node (i.e. a node connected to a monitor). Any node in the network that encounters the microTap SID would make a copy of the packet and send it to the monitor node. Does that answer your question? 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? [GB] That is the case for SRv6. Thanks, Gurminder On Fri, Mar 1, 2024 at 1:25=E2=80=AFPM Joel Halpern w= rote: > 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 befor= e > 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 > *Sent:* Friday, March 1, 2024 6:42 AM > *To:* Jeff Tantsura > *Cc:* Ryan Hoffman > ; Jeffrey (Zhaohui) Zhang > ; spring@ietf.org; > draft-zzhang-spring-microtap-segment@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 i= n > the normal traffic path encounters a microtap SID (which is not advertise= d > 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 =E2=80=9Cdefault=E2= =80=9D 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 happene= d, > 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 b= e > 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 place= s > (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 cop= y > for a particular packet. I also imagine that an ingress is likely > coordinating with the monitor when it places the MicroTap SID, even thoug= h > that=E2=80=99s 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=E2=80=AFAM Jeff Tantsura > wrote: > > Seems like a very useful feature indeed. > > > > Cheers, > > Jeff > > > > On Feb 27, 2024, at 07:15, Ryan Hoffman 40telus.com@dmarc.ietf.org> wrote: > > =EF=BB=BF > > TELUS intends to deploy this microTap segment feature once available in > vendor NOS after thorough testing in our lab. We'd expedite TELUS testin= g > 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=E2=80=AFPM Jeffrey (Zhaohui) Zhang > 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-slid= es-115-spring-microtap-segment-00 > > . > > Thanks. > Jeffrey > > Juniper Business Use Only > > _______________________________________________ > 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 > > > > _______________________________________________ > spring mailing listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/s= pring > > --000000000000569bc3061390cb22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Joel,

Please see comments below.
<= div>
In the case of SR-MPLS, will the micro-tap SID come from the b= lock associated with the processing node?=C2=A0 If so, how do we avoid coll= ision between the microtap SID and the node's own SIDs?
<= p>[GB] In the case of SR-MPLS, the microTap SID is allocated from the SRGB = which makes it globally unique and helps avoid collision with any node SIDs= .=C2=A0

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 advertis= ed by other nodes.=C2=A0 This seems to violate the rules for when a node pr= ocesses a SID in the SRv6 specifications?

[GB] In the case of SRv6, m= icroTap SID is advertised by the monitor node (i.e. a node connected to a m= onitor). Any node in the network that encounters the microTap SID would mak= e a copy of the packet and send it to the monitor node. Does that answer yo= ur question?

Also, the processing description seems to say taht the c= opy is made before the microTAP sid is removed.=C2=A0 Which seems to mean t= hat the microtap SID will be the topmost SID in the copy and be the basis f= or forwarding?

[GB] That is the case for SRv6.=C2=A0

Thanks,
Gurminde= r


On Fri, Mar 1, 2024 = at 1:25=E2=80=AFPM Joel Halpern <jmh@joelhalpern.com> wrote:
=20 =20 =20

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?=C2=A0 If so, how do we avo= id 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.=C2=A0 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.=C2=A0 Which seems to mean th= at 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:
=20 =20 =20

Hi Ed, Jeff,<= u>

=C2=A0=

Thanks for your comments.

Please see zzh> below.

=C2=A0=


Juniper Business Use Only

From: Eduard Metz <etmetz@gmail.com>
Sent: Friday, March 1, 2024 6:42 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Ryan Hoffman <ryan.hoffman=3D40telus.com@dmarc.ietf.org>; = Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; spring= @ietf.org; draft-zzhang-spring-microtap-segment@ietf.org Subject: Re: [spring] [WARNING: SUSPICIOUS SENDER] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-= spring-microtap-segment/01/

=C2=A0

[External Email. Be cautious of content]

=C2=A0

=C2=A0

I think this is a relevant use-case / feature.=C2=A0

=C2=A0

Few comments after first=C2=A0read:=

- 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=C2=A0nodes) a= nd indicate the parameter - this is the approach in the current draft if I understand correctly.

= =C2=A0

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 =E2=80=9Cdefault=E2=80=9D forwarding (of capable nodes).<= u>

= =C2=A0

- 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=C2=A0the packet=C2=A0be forwarded to the "monitor" node? T= his breaks the communication effectively, but not a drop at the node not supported MicroTAP.

= =C2=A0

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.=

= =C2=A0

- 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=C2=A0this, the MicroTAP SID would need to inserted=C2=A0on all relevan= t 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)

= =C2=A0

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=E2=80=99s outside the scope of this draft.=

Zzh> Can you explain the implications for the use of IOM header?

Zzh> Thanks.

Zzh> Jeffrey

=C2=A0

cheers,

=C2=A0 Eduard

=C2=A0

=C2=A0

On Wed, Feb 28, 2024 at 4:52=E2=80=AFAM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

Seems like a very useful feature indeed.

=C2=A0

Cheers,

Jeff



O= n Feb 27, 2024, at 07:15, Ryan Hoffman <ryan.hoffman=3D40telus.com@dmarc.ietf.org> wrote:

=EF=BB=BF

TELUS intends to deploy this microTap segment feature once available=C2=A0in vendor NOS after thorough testing in our lab.=C2=A0 We'd expedite TEL= US testing and deployment when available from vendors, as this is a much needed feature in our network.

=C2=A0

Thanks,

Ryan Hoffman=

=C2=A0

On Wed, Apr 5, 2023 at 3:28=E2=80=AFPM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:

Hi,

The authors of this draft would like to get your feedback on this draft.

=C2=A0 =C2=A0This document specifies a microT= ap segment that can be used to
=C2=A0 =C2=A0instruct a transit node to make = a copy of a segment-routed packet and
=C2=A0 =C2=A0deliver it to a specified node f= or the purpose of network monitoring,
=C2=A0 =C2=A0trouble shooting, or lawful inte= rcept.

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.

Thanks.
Jeffrey

Juniper Business Use Only

______________________________= _________________
spring mailing list
spring@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spring

______________________________________= _________
spring mailing list
spring= @ietf.org
https://ww= w.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
spring@ietf.org
=
https://www.ietf.org/mailman/listinfo/spring
--000000000000569bc3061390cb22--