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> 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> > *收件人： *Giuseppe Fioccola<giuseppe.fiocc...@huawei.com> > *抄送： *draft-fz-spring-srv6-alt-mark<draft-fz-spring-srv6-alt-m...@ietf.org > >;spring<spring@ietf.org>;ipv6<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> > > *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 > <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 <gregimir...@gmail.com>>> > > *Sent:* Monday, November 8, 2021 2:57 PM > > *To:* Giuseppe Fioccola <giuseppe.fiocc...@huawei.com > > <mailto:giuseppe.fiocc...@huawei.com <giuseppe.fiocc...@huawei.com> > >> > > *Cc:* draft-fz-spring-srv6-alt-m...@ietf.org > > <mailto:draft-fz-spring-srv6-alt-m...@ietf.org > <draft-fz-spring-srv6-alt-m...@ietf.org>>; spring@ietf.org > > <mailto:spring@ietf.org <spring@ietf.org>>; i...@ietf.org < > mailto:i...@ietf.org <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 > <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 <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 > <draft-fz-spring-srv6-alt-m...@ietf.org>>; spring@ietf.org > > <mailto:spring@ietf.org <spring@ietf.org>>; i...@ietf.org < > mailto:i...@ietf.org <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 > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > _______________________________________________ > 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
