Subject: [spring] SRv6 compression

From: Tony Li <[email-masked]>
Date: Mon, 26 Jul 2021 12:56:13 -0700

Hi,

The chairs ask that we opine on the mailing list, so I’m happy to kick things off.

As I noted within the WG meeting, my preference is that we deprecate SRv6. Compressing it then becomes moot and there is no issue.

Failing that, the WG needs to come to rough consensus on one mechanism.  That is the point of a standards effort.

Tony

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Jul 2021 21:09:54 +0100

> On 26 Jul 2021, at 20:56, Tony Li <[email-masked]> wrote:
> 
> As I noted within the WG meeting, my preference is that we deprecate SRv6.

+1

It is getting out of hand, and is not a good transport network solution.

Stewart

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 26 Jul 2021 20:19:20 +0000

Hi Tony,

Thanks you for your comments!

For sure, our goal is not to deprecate SRv6 but solving the overhead issue of SRv6 so that we can use it better.
That is why we made the effort in the past year and even longer. I believe we do not need to state the effort we made in the past many years to finish the standard work of SRv6. People know that.

IMHO, what we(our customers and over 10 vendor partners) need is an SRv6-capatible solution that is built based on the existing SRv6 tech with minor update.

Sure, different solution may have their own standard way and I believe this can be handled by the WGs. I respect this.

That is also the point of a standards effort.

Thanks,
Cheng

-----邮件原件-----
发件人: spring [mailto:[email-masked]] 代表 Tony Li
发送时间: 2021年7月27日 3:56
收件人: [email-masked]
主题: [spring] SRv6 compression

Hi,

Tony

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Jul 2021 21:27:04 +0100

> On 26 Jul 2021, at 21:19, Chengli (Cheng Li) <[email-masked]> wrote:
> 

RFC 8663 gives compact packets over an IPv6 network.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 26 Jul 2021 22:51:26 +0200

Hi Cheng,

I think the situation here is as follows. There are few groups of carriers
(SP, ISP, Enterprises):

- group A - cares highly about transport bandwidth efficiency - those will
continue to operate their transport over IPv4 and if needed to steer
packets will use SR-MPLS. For carrying services they can use SR-MPLS or
MPLS_over_IPv4UDP

- group B - does not care about capacity and complexity of the network. If
needed new capacity is added fast. Perhaps their focus is about single
control and data plane and the choice is IPv6. For those IPv6 SIDs with
SRv6 would work just fine and no compression is needed.

- group C - carriers which are coming from group A but willing to play role
in 5G transport or new types of sensor networks. So they are a bit stuck
and seek solutions like header compression of IPv6 as most 5G network
endpoints is using this as a transport. IPv4 there if at all is just an
overlay guest.

Personally I would vote for  variable length SIDs proposal we published
some time back:
https://datatracker.ietf.org/doc/html/draft-decraene-spring-srv6-vlsid-05,
but I guess without solid support from vendors no solution even if sound
matters in IETF nor has any chances to proceed fwd.

Kind regards,
Robert

On Mon, Jul 26, 2021 at 10:19 PM Chengli (Cheng Li) <[email-masked]> wrote:

> That is why we made the effort in the past year and even longer. I believe
> we do not need to state the effort we made in the past many years to finish
> the standard work of SRv6. People know that.
>
> IMHO, what we(our customers and over 10 vendor partners) need is an
> SRv6-capatible solution that is built based on the existing SRv6 tech with
> minor update.
>
> Sure, different solution may have their own standard way and I believe
> this can be handled by the WGs. I respect this.
>
> Compressing it then becomes moot and there is no issue.
>