Subject: [spring] FW: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 May 2020 13:56:03 +0000

Hello Spring WG,

You might be very interested in this ongoing WG adoption poll for the CRH proposal (what was previously introduced in Spring as part of the SRm6 proposal).

The authors are now claiming that theirs is a new IPv6 source routing proposal that is unrelated to work/charter of Spring WG and not Segment Routing [1] & [2].

The authors and 6man chairs seem to agree that this is not related to Spring [3].

However, following the conversations in 6man, it seems clear to me that this is indeed a new IPv6 data-plane proposal that builds on Spring work [RFC8402] but avoids attribution to it to give an illusion of it being a new standalone IPv6 Source Routing solution.

If you were looking for a document that describes the architecture, applicability, use-cases or requirements for this "new solution", well there isn't anything other than the CRH draft itself [4] (the new version does not talk about SRm6 anymore).

Just thought of letting know ... 

Thanks,
Ketan 

[1] https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/
[2] https://mailarchive.ietf.org/arch/msg/ipv6/acyQ6VoObjnUVk6oOz7RoVLNey8/
[3] https://mailarchive.ietf.org/arch/msg/ipv6/BMoJM1NfneU5o0KRKUCkCj96g8c/
[4] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22 

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 16 May 2020 03:44
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

This message starts a two-week 6MAN call on adopting:

 Title:          The IPv6 Compact Routing Header (CRH)
 Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
 File Name:      draft-bonica-6man-comp-rtg-hdr-21
 Document date:  2020-05-14

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr

as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.

Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.

This adoption call will end on 29 May 2020.

The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.

Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group
to work on this.

Regards,
Bob and Ole

---

From: Dirk Steinberg <[email-masked]>
Date: Fri, 29 May 2020 23:42:00 +0300

Hello,

looking at the draft what I see is a new data plane (incompatible with
anything else
that has existed as far) that semantically does the same what MPLS has been
doing for over 20 years: mapping a fixed-length label to some kind of
rewrite information.

While having a different encapsulation format it is semantically equivalent
to MPLS
and it also retains the biggest drawback of MPLS: being based on a mapping
table.
This implies that the mapping table needs to be disseminated (read:
protocol changes
in all protocols) while still not allowing aggregation and also not
providing any advantage
from an architectural point of view over existing solutions.

The fact that this encapsulation is IPv6-based is nothing new at all.
The equivalent semantics can be achieved using MPLS over UDP
that is already described in RFC 8663.

I fail to see any significant innovation that would justify the effort of
introducing a
new encapsulation and introducing changes to all routing protocols.

Therefore I do not support the adoption of draft-bonica-6man-comp-rtg-hdr
at present.

Cheers,
Dirk

On Thu, May 21, 2020 at 4:56 PM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> Hello Spring WG,
>
> You might be very interested in this ongoing WG adoption poll for the CRH
> proposal (what was previously introduced in Spring as part of the SRm6
> proposal).
>
> The authors are now claiming that theirs is a new IPv6 source routing
> proposal that is unrelated to work/charter of Spring WG and not Segment
> Routing [1] & [2].
>
> However, following the conversations in 6man, it seems clear to me that
> this is indeed a new IPv6 data-plane proposal that builds on Spring work
> [RFC8402] but avoids attribution to it to give an illusion of it being a
> new standalone IPv6 Source Routing solution.
>
> If you were looking for a document that describes the architecture,
> applicability, use-cases or requirements for this "new solution", well
> there isn't anything other than the CRH draft itself [4] (the new version
> does not talk about SRm6 anymore).
>
> [1]
> https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/
> [2]
> https://mailarchive.ietf.org/arch/msg/ipv6/acyQ6VoObjnUVk6oOz7RoVLNey8/
> [3]
> https://mailarchive.ietf.org/arch/msg/ipv6/BMoJM1NfneU5o0KRKUCkCj96g8c/
> as a working group item. Substantive comments regarding adopting this
> document should be directed to the mailing list.  Editorial suggestions can
> be sent to the authors.
>
> Please note that this is an adoption call, it is not a w.g. last call for
> advancement, adoption means that it will become a w.g. draft.  As the
> working group document, the w.g. will decide how the document should change
> going forward.
>
> The chairs note there has been a lot of discussions on the list about this
> draft.   After discussing with our area directors, we think it is
> appropriate to start a working group adoption call.  The authors have been
> active in resolving issues raised on the list.
>
> Could those who are willing to work on this document, either as
> contributors, authors or reviewers please notify the list.   That gives us
> an indication of the energy level in the working group
> to work on this.
>
> Regards,
> Bob and Ole
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>