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

[Robert Raszuk <[e-mail]>]

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
>>
>