Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Wim

You mention SR-MPLS and SR-MPLS over IP as if they are two different
flavors of SR.  They are one and the same per RFC 8663.  Am I missing
something here?

SR-MPLS reuses the MPLS IPv4 LDPv4 data plane once LDPv4 is removed from
the network to provide a stateless SR-MPLS based on 4 byte MPLS shim now
containing new SRGB label range.

Are you referring to MPLSoUDP RFC 7510 or MPLS over GRE RFC 4023 and using
SR-MPLS reuse of MPLS data plane IPv4 and tunneling via GRE is UDP?

Not sure how that would work or make it similar to CRH.

I am not following how SR-MPLS is similar to CRH.

Please explain?

Gyan

On Tue, May 26, 2020 at 11:33 PM Henderickx, Wim (Nokia - BE/Antwerp) <
wim.henderickx@nokia.com> wrote:

> Gyan, if you look in the details of RFC8663, you can do all of the things
> you mentioned. You can do loose path which are connected via ipv6 island
> exactly like CRH is proposing and more. As said here is a misconception
> that RFC8663 is strictly MPLS and I have to repeat it is not. You can do
> all the things that are suggested with CRH and more, with the same
> addressing mechanism, etc that is proposed in CRH. On top you get the
> natural extensions we are defining for free.
>
> There is no need to reinvent the wheel here.
>
>
>
> *From: *Gyan Mishra <hayabusagsm@gmail.com>
> *Date: *Wednesday, 27 May 2020 at 01:41
> *To: *"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
> *Cc: *Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
> *Subject: *Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
>
>
> Wim
>
>
>
> SR-MPLS reuses the MPLS data plane.  That is a nice brown field migration
> option for MPLS customers that want to eliminate ldp state.
>
>
>
> Don’t get me wrong SR-MPLS has its place and its for brown field MPLS
> deployments and SRv6 has its place as well for cases mostly intra domain
> where you don’t have inter domain traffic steering with very long strict
> paths which run into SR-TE MSD issues.
>
>
>
> For deployments that want to use the IPv6 data plane and have ubiquitous
> use cases inter or intra domain and not have the extra baggage 🧳 of SRv6
> programming SID depth overhead with strict paths or  SR-MPLS - MPLS data
> plane which also has MSD SID depth issue with long strict paths = CRH
> shines and is the best solution
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Tue, May 26, 2020 at 10:27 AM Henderickx, Wim (Nokia - BE/Antwerp) <
> wim.henderickx@nokia.com> wrote:
>
> if you look into the details RFC8663 from a data-plane operation is very
> similar to CRH. It uses a tag and derives a destination ipv6 address from
> it.
> On top it if you look at the requirements which are discussed on the
> mailing list, the following is possible with RFC8663
>
> It can steer the packet through a specific path. Implementations exists
> which do well beyond 8
> No new VPN encapsulation is required
> No new service chaining needed and various options possible.
> Compliant to SPRING
> Uses MPLS but it is used here as a lookup tag, not any different than the
> CRH proposal. In essence if you look at the details you can implement this
> with a complete v6 infrastructure and use the tag as a steering function.
> And uses 32 bit.
>
> As such I don’t see why we need another encap to achieve something we
> already can do and is available in various implementations and is as
> efficient on the wire (looking at 32 bit, which is what people agree upon).
>
> So I would vote against adoption.
>
> On 16/05/2020, 00:14, "ipv6 on behalf of Bob Hinden" <
> ipv6-bounces@ietf.org on behalf of bob.hinden@gmail.com> wrote:
>
>     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
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD