Re: [IPv6] [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <
>>>> [e-mail]> 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 <[e-mail]> *On Behalf Of *Ketan
>>>>> Talaulikar
>>>>> *Sent:* Friday, February 17, 2023 12:46 PM
>>>>> *To:* Joel Halpern <[e-mail]>
>>>>> *Cc:* SPRING WG List <[e-mail]>; 6man <[e-mail]>
>>>>> *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 <[e-mail]>
>>>>> 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
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>
>>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>> _______________________________________________
>>> spring mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>