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= 40cisco....@dmarc.ietf.org> 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]. > > 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 <ipv6-boun...@ietf.org> On Behalf Of Bob Hinden > Sent: 16 May 2020 03:44 > To: IPv6 List <i...@ietf.org> > Cc: Bob Hinden <bob.hin...@gmail.com> > 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 > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
