Hi,

At this point of time new ethertype buys us nothing then disturbance.

If anything is here to discuss is the question if in the cases of using
C-SID/uSID hosts talking native SRv6 and using more then one uSID should
also use additional 40 octets of IPv6 extra header or not.

It could be optional in nature and enabled/activated only when end to end
connectivity issue due to checksum errors are reported.

And that is all in line of RFC8200 or all SRv6 RFCs so far published to
date.

Thx a lot,
Robert


On Thu, Mar 28, 2024 at 4:03 PM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> Alvaro and all,
>
> Regarding the proposal for using a dedicated Ethertype for SRv6:
>
> Please note that RFC explicitly “introduces two data-plane instantiations
> of SR: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6)” and defines SRv6
> as the instantiation of SR on the IPv6 data plane.
>
>
>
> From my POV using a dedicated Ethertype for SRv6 would directly contradict
> these definitions.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Alvaro Retana
> *Sent:* Thursday, March 28, 2024 2:03 PM
> *To:* SPRING WG List <spr...@ietf.org>
> *Cc:* spring-cha...@ietf.org
> *Subject:* [EXTERNAL] [spring] Separating Threads
> (draft-ietf-spring-srv6-srh-compression)
>
>
>
> Dear WG:
>
> While the chairs strongly appreciate the engagement in the discussions
> around the SRv6 compression draft, several topics have gotten tangled,
> and the subject lines do not help track the conversation. Following
> this note will be two messages intended to serve as an anchor for
> separate aspects of the discussion related to this document.  If we
> get the descriptions wrong, please correct us.  If there are other
> concerns (quite likely, given the engagement), please start separate
> threads.
>
> One discussion aspect has been whether SRv6 should have a distinct
> Ethertype. The intarea WG has discussed an existing proposal [1]. To
> avoid fragmentation, please move the discussion on this topic to the
> intarea mailing list. Copying spring and 6man is appropriate. We note
> that various descriptions on email have been unclear as to what is
> required of whom ([1] has a specific proposal). Please be clear about
> what is proposed/requested.
>
> Thanks!
>
> Alvaro
> -- for spring-chairs
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/
>
> _______________________________________________
> spring mailing list
> spr...@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> _______________________________________________
> spring mailing list
> spr...@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to