Just to be clear, while the chairs have not yet discussed the question
of changing the intended status of this document, the fact that 9341 and
9342 are standards track has no implication on the intended status for
the SRH TLV proposal.
Yours,
Joel
On 2/20/2023 2:21 AM, Giuseppe Fioccola wrote:
Hi Greg,
RFC 9341 and RFC 9342 were already elevated from experimental to
standards track. So I don’t think we can propose it as an experimental
document. If adopted, we may have instead a temporary TLV allocation
to demonstrate its value.
Regards,
Giuseppe
*From:* Greg Mirsky <gregimir...@gmail.com>
*Sent:* Friday, February 17, 2023 10:39 PM
*To:* Robert Raszuk <rob...@raszuk.net>
*Cc:* Ketan Talaulikar <ketant.i...@gmail.com>; Giuseppe Fioccola
<giuseppe.fiocc...@huawei.com>; 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 Robert,
I think you've brought up an excellent point. Perhaps this proposal
can be discussed as an experimental document. WDYT?
Regards,
Greg
On Fri, Feb 17, 2023 at 1:33 PM 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
--------------------------------------------------------------------
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
