I am not saying alt mk, but generic case. I know major chip vendors can support srh but not support hbh nor doh.
That’s why hbh packets easily to be dropped. This is consensus in my opinion. ________________________________ Sent from WeLink 发件人： Greg Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 收件人： Tianran Zhou<zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> 抄送： Joel M. Halpern<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>;Giuseppe Fioccola<giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com>>;draft-fz-spring-srv6-alt-mark<draft-fz-spring-srv6-alt-m...@ietf.org<mailto:draft-fz-spring-srv6-alt-m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;ipv6<i...@ietf.org<mailto:i...@ietf.org>> 主题： Re: [spring] A question for draft-fz-spring-srv6-alt-mark 时间： 2021-11-09 23:57:14 Hi Tianran, such a combination seems very strange to me. A vendor decides to support the AltMarking in SRv6 (SRH TLV) but not in IPv6? Possible but, IMHO, unlikely decision. Regards, Greg On Tue, Nov 9, 2021 at 7:39 AM Tianran Zhou <zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> wrote: Assumption 2 is not correct. We assume there are nodes support srh but not hbh and doh. Best, Tianran ________________________________ Sent from WeLink 发件人： Joel M. Halpern<j...@joelhalpern.com<mailto:j...@joelhalpern.com>> 收件人： Giuseppe Fioccola<giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com>> 抄送： draft-fz-spring-srv6-alt-mark<draft-fz-spring-srv6-alt-m...@ietf.org<mailto:draft-fz-spring-srv6-alt-m...@ietf.org>>;spring<spring@ietf.org<mailto:spring@ietf.org>>;ipv6<i...@ietf.org<mailto:i...@ietf.org>> 主题： Re: A question for draft-fz-spring-srv6-alt-mark 时间： 2021-11-09 23:31:20 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. 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<mailto:gregimir...@gmail.com>> > *Sent:* Monday, November 8, 2021 6:17 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 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> > <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> > <mailto:gregimir...@gmail.com>> > *Sent:* Monday, November 8, 2021 2:57 PM > *To:* Giuseppe Fioccola > <giuseppe.fiocc...@huawei.com<mailto: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> > <mailto:draft-fz-spring-srv6-alt-m...@ietf.org>; > spring@ietf.org<mailto:spring@ietf.org> > <mailto:spring@ietf.org>; i...@ietf.org<mailto: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> > <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> > <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> > <mailto:draft-fz-spring-srv6-alt-m...@ietf.org>; > spring@ietf.org<mailto:spring@ietf.org> > <mailto:spring@ietf.org>; i...@ietf.org<mailto: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://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/>? > > Regards, > > Greg > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org<mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
