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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 27 May 2020 04:16 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EB03A0E0A for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 21:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8oKym8heR-r for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 21:16:18 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B538F3A0968 for <ipv6@ietf.org>; Tue, 26 May 2020 21:16:18 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id c20so22740007ilk.6 for <ipv6@ietf.org>; Tue, 26 May 2020 21:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pRJUxRVeM4IwRqNGliWZy1GKT7VCGHzLKeNK8bLlbHQ=; b=J7HpMGBvKvMh8qzzFSNRVV7OwGmmCO2gvLLJb9/pr1yi1ka8wk95zV01UabQXa+i61 plVXNhiwjUMbSzToJOMKDthm77Guh0+bkWFdlCAvYLx44L6yOPLrriwntzfTtvXkyOib 15Y6mrWmp6lJuooQ9KmVHU3OySqxYu8NjEeLT5DwJZgHwkR66Dl6czePe3N6OxFg+g9x OPcasU+WVYoqf10Q7x01JX/yxiFLSYdWoHdmvSCYHiCyHDYOwTXYdUFaLGx6A4WY1EJX R/jJVctLrQYA/mdIO1ydBYUw8IarBuN9U9COFEaj9kGK5FpSyGUna+MiMOT3sszRY5Fv I2Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pRJUxRVeM4IwRqNGliWZy1GKT7VCGHzLKeNK8bLlbHQ=; b=mVaHfIpDIbyg2U356To28NETxfRo6Wg2KfwTIl/bXqQDXF3IIs70K5dYsrh3mOJaai E52QSNjR2eKPVk8d6S/QzEjIe+r12mKSMfVJGaMdxacYFeDWcsIGmW6WgJF0ZIWAdjRK 3SHNB6dBZkFcMwITdp9hQMZ//RS3MupByOma7RlVHtBMBT9b+lnE+Tmf85+q3xSytA/b giZPVD/cO8c9aNOMlcqK2KL28Cyhe4V5ZhmIVbPgb0UQ+11yVPNGs4V2bkN9XDgEATFm bGcBqZl7qo6slgFDse1/3fFFoz1xB2TgTmm4/bpLlHke0rWoXFHRBp6BYmzaus+UziB9 f6BQ==
X-Gm-Message-State: AOAM532YuV4ODyyKaofCbjEKIBYeUxEf6VDROjRjU01i/1u82zlT0g2J GfsnBu7OD1BxZu3k5d1QeqH8aYkGr/Sz0mwIWufgs6eNMKo=
X-Google-Smtp-Source: ABdhPJwxIXe94JYkCLRrbSuDl5gIaxdfYDvcHVEWSqyBcgCRAT6GXKbescFJ39UkjnTbqKmqAuuhy350iJ48oTFTWDc=
X-Received: by 2002:a92:c948:: with SMTP id i8mr4242674ilq.258.1590552976919; Tue, 26 May 2020 21:16:16 -0700 (PDT)
MIME-Version: 1.0
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <79A95CE5-20AE-4CD0-B237-FFD86106A435@nokia.com> <CABNhwV1E68e-j+cWViR_zKx6YcwpYxQpHmdgiBRTn7-a7oCN3w@mail.gmail.com> <DF8882BB-8409-47C8-B9F5-9FBB4E5BDE0E@nokia.com>
In-Reply-To: <DF8882BB-8409-47C8-B9F5-9FBB4E5BDE0E@nokia.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 27 May 2020 00:16:05 -0400
Message-ID: <CABNhwV2czHRnUX-thsFaAU=G4Gv7Mx7qJcxMgEK1BA=APezUVw@mail.gmail.com>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002f929d05a699790c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gCCJahw_L9orLfpRHbF6XUUj1X0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2020 04:16:21 -0000

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>om>, 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