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

[Gyan Mishra <[e-mail]>]

I support WG adoption.  The draft is clearly and succinctly written.

This draft will be very useful for SRv6 performance measurements for on
path IOAM telemetry.

Few questions.

Is the use and operation of the FlowMonID identical to how it’s described
in RFC 9343 and if so then it’s identical to the RFC 6437 20 bit IPv6
header Flow label which is based on the standard 5-tuple header keys used
in RFC 6437 for stateless load balancing on stateful signaling.

At the bottom of Section 1 page 5 describes the Data Field format.  At the
bottom it talks about how to guarantee uniqueness of the flow for
disambiguating the flow and that is the purpose of the 5-tuple header key
to identify and disambiguate the flow so it’s uniquely identified as done
with RFC 6437 stateless load balancing.

Use or SRH Alt Mark TLV - top of page 6
.. looks like a typo in the last sentence

Old text

Because SRv6 Is a routing header, destination options before the routing
header are processed by each destination in the routing list.

New text

Because the SRv6 SRH is a routing header, destination options are processed
by per RFC 8200 Section 4.1 Note 1 first destination that appears in the
IPv6 destination address field plus subsequent destinations listed in the
routing header.

As mentioned by others this drafts leverages use of SRH used by SRV6, new
SRH TLV used to encode the Alt Mark data fields to monitor every node along
the SRH path.

This is much more cost effective and optimal then adding additional EH DOH
or HBH to encode the Alt Mark which is significant overhead and use of SRH
TLV is most optimal for the Alt Mark PM encoding.

For SRv6 compression CSID draft as SRH is not used for Next SID flavor as
long as hops is less than 5 hops, which in many cases for loose hops that
is the case, maybe the Alt Mark meta data can be stored in a 16 bit service
SID LIB - Local SID  ID block for the PM on path telemetry.

https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/

I think an Operational Considerations section would be a good idea as
mentioned by others.

Thanks

Gyan
On Wed, Feb 1, 2023 at 7:44 PM 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
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*