Comments inline marked with HS>> Best, Haoyu
-----Original Message----- From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Tom Herbert Sent: Thursday, November 11, 2021 9:05 AM To: Tianran Zhou <zhoutian...@huawei.com> Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; i...@ietf.org Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark Tianran, I think you're dancing around the core problem. Hardware implementations didn't support Hop-by-Hop options because they contain TLVs which are considered to be hard to process in a high performance datapath hardware pipeline. RFC2460 did mandate that all intermediate nodes need to process the HBH options which left hardware vendors with three choices: 1) process them in a software slow path and adhere to RFC2460 2) ignore them altogether and violate RFC2460 3) drop the packet which technically adheres to RFC2460, but obviously kills any utility of feature. RFC8200 relaxed the requirement for all nodes to process HBH options and acknowledged that this is reality. From an application perspective, if the TLVs can't be processed in a "fast path" it is best to ignore the options. So the underlying problem is in fact the complexity of processing TLVs in hardware datapath. Just replicating the same TLV mechanism in more protocols like SRH does nothing to help solve the problem. Until this is solved I don't believe we'll ever see TLVs being productively used in L3 (I suppose this might the anticipated industry evolution to which you referred). On the other hand if the problem is solved and a deployable an economical solution is presented that hardware vendors would adopt, then the problem would be solved for a whole class of use case (i.e. the same basic TLV construct is used in HBH, DestOpts, SRH, TCP options, IP options, UDP options, etc.). HS>> TLVs are not inherently difficult to process in hardware. There are two parts of TLV processing. First is parsing. Yes it would need more clock cycles to parse a TLV than a normal header, but parser is not the performance bottleneck and the overhead is acceptable. The second part is actually performing the function dictated by the TLV. This depends highly on the nature of the function itself. If it's proper for efficient hardware implementation, then there's no problem to support it. So here I think the core issues are what kind of TLV function we should allow in hardware and how we would modify the standard rules to accommodate them in existing extension headers. If you're interested, I will be outlining the solution to this problem that we're working on in IPv6/v6ops meeting tomorrow. Tom > > Tom > > > > > Best, > > Tianran > > > > -----Original Message----- > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. > > Halpern > > Sent: Wednesday, November 10, 2021 10:38 AM > > To: Tianran Zhou <zhoutian...@huawei.com> > > Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; > > i...@ietf.org > > Subject: Re: [spring] A question for draft-fz-spring-srv6-alt-mark > > > > (Again, speaking as participant.) > > You seem to be assuming that devices (hard or soft) that support SRH will > > support this new TLV. It is not obvious that they will support any SRH > > TLVs. And if they do, they clearly will not support a not yet defined TLV. > > > > Yours, > > Joel > > > > On 11/9/2021 9:04 PM, Tianran Zhou wrote: > > > Hi Tom, > > > > > > All you arguments are correct. > > > If a network is built all by supportive devices (support HbH, DoH), there > > > is no doubt that 6man-alt-mk is a sound solution. > > > > > > However, existing network may consist many non-supportive devices. > > > These devices may 1. support SRH, but not HbH and DoH. This is the > > > current situation about most chip vendors. > > > 2. some vendors may not want to support HbH and DoH in near future. > > > > > > Then, how to deploy alt-mk in these network? > > > The way is to bypass those non-supportive nodes without packet drop. > > > > > > This is why SRH TLV based spring-srv6-alt-mark is proposed. > > > > > > Best, > > > Tianran > > > > > > -----Original Message----- > > > From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert > > > Sent: Tuesday, November 9, 2021 11:41 PM > > > To: Joel M. Halpern <j...@joelhalpern.com> > > > Cc: draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; > > > i...@ietf.org > > > Subject: Re: A question for draft-fz-spring-srv6-alt-mark > > > > > > On Tue, Nov 9, 2021 at 7:31 AM Joel M. Halpern <j...@joelhalpern.com> > > > wrote: > > >> > > >> Let me try phrasing the question about the SRH TLV in a different way. > > >> And this is as a participant, not as co-chair. > > >> Assumptions as I understand them: > > >> > > >> 1) The 6man draft requires support of both the HbH and DoH cases > > >> 2) Any node supporting the SRH altMarking can be assumed to also > > >> support the 6man altMark > > >> > > >> If assumption 2 is accurate, then it seems to me that adding the > > >> SRH TLV adds complexity to save a few bits without adding any capability. > > >> This strikes me as a bad trade. > > > > > > +1 > > > > > > Also, destination and hop-by-hop options have the advantage that they > > > work with any other extension header or protocol. SRH TLVs only work in > > > the narrow use case of SRv6 and don't help router headers that might be > > > defined. > > > > > > Tom > > > > > >> > > >> Yours, > > >> Joel > > >> > > >> On 11/8/2021 2:28 PM, Giuseppe Fioccola wrote: > > >>> Hi Greg, > > >>> > > >>> Yes, with DOH + SRH, the end node of a segment should still > > >>> conform to RFC8200, based on the discussion in 6MAN. > > >>> > > >>> The proposal to use HBH is also mentioned in > > >>> draft-ietf-6man-ipv6-alt-mark. > > >>> > > >>> Regards, > > >>> > > >>> Giuseppe > > >>> > > >>> *From:* Greg Mirsky <gregimir...@gmail.com> > > >>> *Sent:* Monday, November 8, 2021 6:17 PM > > >>> *To:* Giuseppe Fioccola <giuseppe.fiocc...@huawei.com> > > >>> *Cc:* draft-fz-spring-srv6-alt-m...@ietf.org; spring@ietf.org; > > >>> i...@ietf.org > > >>> *Subject:* Re: A question for draft-fz-spring-srv6-alt-mark > > >>> > > >>> Hi Giuseppe, > > >>> > > >>> thank you for the clarification. > > >>> > > >>> I was considering the DOH+SDH but am not sure if the end node of > > >>> a segment conforms to the note attributed to DOH in RFC 8200: > > >>> > > >>> note 3: for options to be processed only by the final destination > > >>> of > > >>> the packet. > > >>> > > >>> I recall the discussion in 6man WG but not the final conclusion of it. > > >>> > > >>> My proposal to use HbH EH included the use of the management > > >>> plane to explicitly enable AltMarking only on segment end-points > > >>> and keep it disabled on transit nodes. > > >>> > > >>> Regards, > > >>> > > >>> Greg > > >>> > > >>> On Mon, Nov 8, 2021 at 8:50 AM Giuseppe Fioccola > > >>> <giuseppe.fiocc...@huawei.com <mailto:giuseppe.fiocc...@huawei.com>> > > >>> wrote: > > >>> > > >>> Hi Greg, > > >>> > > >>> The use of HbH EH does not fit well in the case of SRH. Indeed, > > >>> with > > >>> the AltMark HbH Option, it is possible to monitor every router on > > >>> the path with feature enabled, so it potentially allows the > > >>> measurement to every nodes in the path and not only to the nodes > > >>> that are identities in the SR path. > > >>> > > >>> While, with the Destination Option preceding a Routing Header, it > > >>> is > > >>> possible to apply the measurement to every destination node in the > > >>> route list. This means that, whenthe AltMark Destination Option > > >>> precedes the SRH, it allows the measurement for all the nodes that > > >>> are identities in the SR path. > > >>> > > >>> The solution with SRH TLV is equivalent to DOH + SRH, but it can be > > >>> an optimized solution for SRH since it leverages the SRH TLV > > >>> capability, without adding an additional EH that can be a problem > > >>> in > > >>> some cases. > > >>> > > >>> Regards, > > >>> > > >>> Giuseppe > > >>> > > >>> *From:* Greg Mirsky <gregimir...@gmail.com > > >>> <mailto:gregimir...@gmail.com>> > > >>> *Sent:* Monday, November 8, 2021 2:57 PM > > >>> *To:* Giuseppe Fioccola <giuseppe.fiocc...@huawei.com > > >>> <mailto:giuseppe.fiocc...@huawei.com>> > > >>> *Cc:* draft-fz-spring-srv6-alt-m...@ietf.org > > >>> <mailto:draft-fz-spring-srv6-alt-m...@ietf.org>; spring@ietf.org > > >>> <mailto:spring@ietf.org>; i...@ietf.org <mailto:i...@ietf.org> > > >>> *Subject:* Re: A question for draft-fz-spring-srv6-alt-mark > > >>> > > >>> Hi Giuseppe, > > >>> > > >>> thank you for the detailed explanation of what the authors consider > > >>> as the problem. In the presentation, you've mentioned that the new > > >>> AltMark SRH TLV allows for better control of which nodes along an > > >>> SR > > >>> Policy participate in the measurement. I imagine that the HbH IPv6 > > >>> extension header that includes the AltMark TLV can be used to > > >>> achieve the same result if only SR nodes are enabled for the > > >>> AltMark > > >>> processing. What do you think of using the HbH EH? Am I missing > > >>> something? > > >>> > > >>> Regards, > > >>> > > >>> Greg > > >>> > > >>> On Mon, Nov 8, 2021 at 1:13 AM Giuseppe Fioccola > > >>> <giuseppe.fiocc...@huawei.com > > >>> <mailto:giuseppe.fiocc...@huawei.com>> > > >>> wrote: > > >>> > > >>> Hi Greg, > > >>> > > >>> Thank you for your comment. > > >>> > > >>> It is very good to have your support on this draft. > > >>> > > >>> draft-ietf-6man-ipv6-alt-mark defines the AltMark DOH. In case of > > >>> SRH, DOH + SRH can be used to implement the measurement for every > > >>> node that is an identity in the SR path. > > >>> > > >>> But, the approach with DOH + SRH requires two extension headers and > > >>> this can have operational implications. > > >>> > > >>> The goal of this draft is to find an optimized solution that best > > >>> suits for SRH. Therefore we propose to use the SRH TLV. If > > >>> accepted, > > >>> this document would update draft-ietf-6man-ipv6-alt-mark only for > > >>> SRv6: > > >>> > > >>> - in case of SRH there would be a single way to apply AltMark > > >>> through SRH TLV, > > >>> > > >>> - while for all the other cases with IPv6 data plane the use of the > > >>> HbH and DOH is the only choice to carry AltMark data fields. > > >>> > > >>> Regards, > > >>> > > >>> Giuseppe > > >>> > > >>> *From:* Greg Mirsky <gregimir...@gmail.com > > >>> <mailto:gregimir...@gmail.com>> > > >>> *Sent:* Sunday, November 7, 2021 9:01 PM > > >>> *To:* draft-fz-spring-srv6-alt-m...@ietf.org > > >>> <mailto:draft-fz-spring-srv6-alt-m...@ietf.org>; spring@ietf.org > > >>> <mailto:spring@ietf.org>; i...@ietf.org <mailto:i...@ietf.org> > > >>> *Subject:* A question for draft-fz-spring-srv6-alt-mark > > >>> > > >>> Dear Authors et al. > > >>> > > >>> thank you for this document. I am supporting and following the work > > >>> on the Alternate Marking method in various IETF WGs. What do you > > >>> see > > >>> as the benefits of defining a new SRH TLV for the Alternate Marking > > >>> method compared to solutions defined for IPv6 in > > >>> draft-ietf-6man-ipv6-alt-mark > > >>> > > >>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-ipv6-alt-mark%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637722471737333496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTX6zZJUosYEDB%2BIPBJuiDu32W5wSKvki3M2SVxiqX0%3D&reserved=0>? > > >>> > > >>> Regards, > > >>> > > >>> Greg > > >>> > > >>> > > >>> ---------------------------------------------------------------- > > >>> -- > > >>> -- IETF IPv6 working group mailing list i...@ietf.org > > >>> Administrative > > >>> Requests: > > >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F% > > >>> 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=04%7C01%7Cha > > >>> oyu.song%40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0f > > >>> ee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637722471737333496%7CUn > > >>> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 > > >>> Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V%2BW%2BlClfp%2BSGaU15lk > > >>> NYe3UN%2Fyfm4MxzVhg09RvOyiI%3D&reserved=0 > > >>> ---------------------------------------------------------------- > > >>> -- > > >>> -- > > >>> > > >> > > >> ----------------------------------------------------------------- > > >> -- > > >> - IETF IPv6 working group mailing list i...@ietf.org > > >> Administrative > > >> Requests: > > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > >> Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=04%7C01%7Chaoy > > >> u.song%40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0fee8 > > >> ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637722471737333496%7CUnknow > > >> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > > >> WwiLCJXVCI6Mn0%3D%7C3000&sdata=V%2BW%2BlClfp%2BSGaU15lkNYe3UN > > >> %2Fyfm4MxzVhg09RvOyiI%3D&reserved=0 > > >> ----------------------------------------------------------------- > > >> -- > > >> - > > > > > > ------------------------------------------------------------------ > > > -- IETF IPv6 working group mailing list i...@ietf.org > > > Administrative > > > Requests: > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > www.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=04%7C01%7Chaoyu. > > > song%40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0fee8ff2 > > > a3b240189c753a1d5591fedc%7C1%7C1%7C637722471737333496%7CUnknown%7C > > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > > > JXVCI6Mn0%3D%7C3000&sdata=V%2BW%2BlClfp%2BSGaU15lkNYe3UN%2Fyfm > > > 4MxzVhg09RvOyiI%3D&reserved=0 > > > ------------------------------------------------------------------ > > > -- > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Chaoyu.so > > ng%40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0fee8ff2a3b2 > > 40189c753a1d5591fedc%7C1%7C1%7C637722471737343453%7CUnknown%7CTWFpbG > > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > > 0%3D%7C3000&sdata=CfkmUJeMArNE%2B12mLy43DXUwulDdE2Zj%2BDvEZePrQh > > I%3D&reserved=0 > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list i...@ietf.org Administrative > > Requests: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=04%7C01%7Chaoyu.song > > %40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0fee8ff2a3b240 > > 189c753a1d5591fedc%7C1%7C1%7C637722471737343453%7CUnknown%7CTWFpbGZs > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% > > 3D%7C3000&sdata=6vpCFvUyAtCLolarN7ITrdefMaRt8E1g6El6bNBn2Rw%3D&a > > mp;reserved=0 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=04%7C01%7Chaoyu.song%40futurewei.com%7C397aedf2a2d040c0612f08d9a5358eee%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637722471737343453%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6vpCFvUyAtCLolarN7ITrdefMaRt8E1g6El6bNBn2Rw%3D&reserved=0 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
