Hi Robert/Authors, Thanks for sharing that perspective. It would be very helpful if the authors can share their perspective as well and update the draft (especially with challenges/issues that they have found with the RFC9343 approach).
Thanks, Ketan On Sat, Feb 18, 2023 at 3:03 AM Robert Raszuk <rob...@raszuk.net> wrote: > Hi Greg, > > It all depends on the hardware support. > > Some may support SRH parsing and processing, but may choose not to support > DOH or HbH v6 headers extensions parsing and processing. > > Some may be fine to process SRH in line card's CPU or in smart NICs while > may in the same time not choose to do the same parsing of extensions to DOH > or HbH headers. > > So you are all correct that the operator is enabled to control this per > node and per flow. But they may not always be able to assure that all IPv6 > headers are up to speed with all IETF extensions in running nodes. > > Bottom line is that if we just look at this IETF aspect the spec surely > looks redundant. But if we extend the view to practical field deployments > we may see the value. > > Cheers, > Robert > > > > On Fri, Feb 17, 2023 at 10:25 PM Greg Mirsky <gregimir...@gmail.com> > wrote: > >> Hi Robert, >> I think that the solution defined in RFC 9343 can operationally achieve >> everything that is suggested in this draft. Consider an SRv6 domain. I >> imagine that the support of on-path telemetry, whether IOAM or Alternate >> Marking, is controlled per node over the management plane. Furthermore, it >> seems like such control is granular, i.e., per a flow (definition of a flow >> can be further discussed). If my assumptions are correct, an operator can >> enable the support of the Alternate Marking on-path telemetry collection >> using RFC 9343 solution on either all nodes within the SRv6 domain or on >> any sub-set, e.g., nodes that terminate route segments. Hence, I believe >> that RFC 9343 already defines what is required to use the Alternate Marking >> method in an SRv6 domain. Do you see that I've missed anything? >> >> Regards, >> Greg >> >> On Fri, Feb 17, 2023 at 8:20 AM Robert Raszuk <rob...@raszuk.net> wrote: >> >>> Hey Ketan, >>> >>> > The encodings are exactly identical - zero difference (from a quick >>> read). Am I missing something? >>> >>> It looks like RFC9343 is defining extension to IPv6 Options Header while >>> the subject draft is defining an extension to SRH. >>> >>> So while data fields look indeed identical the intended placement of >>> this seems very different. >>> >>> In fact one could envision that there is indeed a class of applicability >>> for various measurements which is sufficient to be done only on SRH parsing >>> segment endpoints, hence I find this draft actually pretty useful. >>> >>> Cheers, >>> Robert. >>> >>> >>> On Fri, Feb 17, 2023 at 3:50 PM Ketan Talaulikar <ketant.i...@gmail.com> >>> wrote: >>> >>>> Hi Giuseppe, >>>> >>>> To clarify, I was looking for some text that explains the need for this >>>> draft given RFC9343. The proposal first needs to provide a new/different >>>> functionality or one that is more efficient (just an example) that is not >>>> provided by RFC9343. >>>> >>>> The encodings are exactly identical - zero difference (from a quick >>>> read). Am I missing something? >>>> >>>> Deployment aspects come into play later. >>>> >>>> Given that it is the same author team, I am more curious to know if you >>>> have found any challenges with what's in RFC9343 for SRv6 deployments which >>>> require you to come up with these new encoding. >>>> >>>> Will await the document update. >>>> >>>> Thanks, >>>> Ketan >>>> >>>> PS: You would have seen similar questions being asked all the time ;-) >>>> >>>> >>>> On Fri, Feb 17, 2023 at 8:00 PM Giuseppe Fioccola < >>>> giuseppe.fiocc...@huawei.com> wrote: >>>> >>>>> Hi Ketan, >>>>> >>>>> Thank you for your comments. >>>>> >>>>> I plan to revise the draft and add a new section on deployment >>>>> recommendations. >>>>> >>>>> Anyway, I think that the choice between DOH and SRH TLV may be a more >>>>> general decision that should be taken by SPRING and 6MAN. Indeed, the same >>>>> concern involves all the telemetry techniques, e.g. for IOAM the same two >>>>> mechanisms have been proposed: see draft-ietf-ippm-ioam-ipv6-options and >>>>> draft-ali-spring-ioam-srv6 >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> Giuseppe >>>>> >>>>> >>>>> >>>>> *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Ketan >>>>> Talaulikar >>>>> *Sent:* Friday, February 17, 2023 12:46 PM >>>>> *To:* Joel Halpern <j...@joelhalpern.com> >>>>> *Cc:* SPRING WG List <spring@ietf.org>; 6man <i...@ietf.org> >>>>> *Subject:* Re: [spring] [IPv6] WG Adoption call for Segment Routing >>>>> Header encapsulation for Alternate Marking Method >>>>> >>>>> >>>>> >>>>> Hi Joel/All, >>>>> >>>>> >>>>> >>>>> I share some of the questions and concerns of the chairs and other WG >>>>> members. >>>>> >>>>> >>>>> >>>>> Perhaps we need to give more time to the authors to add clarifying >>>>> text to the draft (what has been said on the list). >>>>> >>>>> >>>>> >>>>> I suggest a dedicated section towards the start of the document that >>>>> *only* focuses on why this mechanism is needed in addition to RFC9343. It >>>>> would be interesting if there is any analysis from the >>>>> implementation/deployment of RFC9343 that has shown it to be not suitable >>>>> for SRv6 deployments. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Ketan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 2, 2023 at 6:14 AM Joel Halpern <j...@joelhalpern.com> >>>>> wrote: >>>>> >>>>> This call is for the draft at: >>>>> https://datatracker.ietf.org/doc/draft-fz-spring-srv6-alt-mark >>>>> >>>>> This email starts the WG adoption call for the subject draft (as >>>>> requested by the authors, with apologies from the WG chairs for how >>>>> long >>>>> it has taken to kick this out.) This call will run through the end of >>>>> the day on Feb 16. Pleaes read the whole email as there are a few >>>>> points, and it is not that long. >>>>> >>>>> Please comment on whether you think this topic is something you think >>>>> the spring WG should work, whether you think this draft is a good >>>>> starting point for such work, any issues or concerns you have, and >>>>> whether you would be willing to help be contributing and / or >>>>> reviewing >>>>> the work if the WG does choose to work on it. >>>>> >>>>> 6man is copied for their information, as this is different from but >>>>> related to an extension header proposal in front of 6man. >>>>> >>>>> Authors and named contributors, please confirm to the list that all >>>>> known, relevant, IPR has been disclosed. If it has note, please >>>>> remedy >>>>> this gap. >>>>> >>>>> The spring chairs have noted one aspect of this draft that caught our >>>>> eye, and we would appreciate WG members who comment on the adoption to >>>>> consider, and if possible opine, on this. As we read this draft, as >>>>> distinct from the related 6man extension header work, this causes the >>>>> recorded altmarks to only be updated at routers identified in the SRH >>>>> segment list. (We presume this would include all identified points in >>>>> a >>>>> compressed container.) We could not tell from the document what the >>>>> value was for this as distinct from getting the measurements at all >>>>> routers. Do WG members understand and agree that it does have value? >>>>> >>>>> As a lesser point, we consider that one quote in the draft is >>>>> misleading >>>>> and will likely need to be reworded in the near future. The draft say >>>>> "SRH TLV can also be used to encode the AltMark Data Fields for SRv6 >>>>> and >>>>> to monitor every node along the SR path." It is unclear if these was >>>>> intended to mean all routers (most of which would not see this TLV) or >>>>> if it was intended to refer to only those routers identified in the >>>>> SRH, >>>>> in which case we presume it will be reworded. >>>>> >>>>> Thank you, >>>>> >>>>> Joel >>>>> >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> i...@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>>> -------------------------------------------------------------------- >>>> 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
