Re: G-SRv6 (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Tom Herbert <tom@herbertland.com> Tue, 26 May 2020 14:00 UTC

Return-Path: <tom@herbertland.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 A74443A0F7D for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 07:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 0PQ61y_YaBhb for <ipv6@ietfa.amsl.com>; Tue, 26 May 2020 07:00:55 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 5899C3A0F1D for <ipv6@ietf.org>; Tue, 26 May 2020 07:00:55 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id y13so1980621eju.2 for <ipv6@ietf.org>; Tue, 26 May 2020 07:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jLFYL64mG19HsQhtKt0K5NwqAzQs2EtN1f5WcsKL9k4=; b=JzgAQeOw6wt1IHQ5kZzeTEfVfKRw/haLoDJ+viA3uJic+dPhH45x6e0NMM4sLbsGSR na8lH5xogzW3zQT1OIjYCtzL4RuduPXYQNK4UfU6OX1QwIYkCjn4xmnek4Xzmqo9G3Ra w3FHUoun+rDrEuCrkJNIgeM1eb90tr9P+/+Qfnhz74RUJFqbkFaEQzqnmxm8F8c3ixpx RM3WgELhYbCTZ3aRYM5TiN5qGHsCaCd1RIB1N18P0KV0vrjPQWmnVicAXlg+ZqLzIXk7 R/908i8/CY4alPxIRhwjddrVaOre21WbT3lOGpG6Yhi5dIsZ0CXaoo9mrnmRdkw6Xaqi K0yA==
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=jLFYL64mG19HsQhtKt0K5NwqAzQs2EtN1f5WcsKL9k4=; b=pRNrXTlJn7+Bj62DZVhPWJCYGeBem4efGIfyn1reE71715Sl0ouGX57M4xVmF+BSjm K20KKYbwaxn4dZt6IdTbIhZ7KL3QrqzOYJWrdHX9f3/zHwWr2t2JAQrhy3Vac86pkoWD S7R2Qcvx98Xm/znHd4XQY2NmZ3qZcRHuXupm66hY1phQt16WHCYBlwEoCJSySQ0MSuxQ d1i+Zftl8nf0RxBZ0xFkV+uFBuKHngZkqiaTltpp9cgutmuWYgHauAQhO5un/K0xTsc1 Dp7yWNdCjtVC4UTJn+iiXuYymehy+Yp8zodusE7+bp1hca/EqS8vdXVQMx1OnRd5cObm 5Y6g==
X-Gm-Message-State: AOAM533hfOry0l1f54XA1ZMNDuE3c6yyitNC07/RTTgd18AqYOpanztv KFSCHbMgzOiPCka5epHXry2i3DGlb5oykItKScOq0w==
X-Google-Smtp-Source: ABdhPJxIlAAF5+gE1dF+JuVrWyxFdg3MLCYA6Xzt4ziGMYpulqa+WA0mlzdjiQLwjnMB87EbpN+54mFArNYXvdnN/Qs=
X-Received: by 2002:a17:906:3c4f:: with SMTP id i15mr1204666ejg.243.1590501652623; Tue, 26 May 2020 07:00:52 -0700 (PDT)
MIME-Version: 1.0
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <06CF729DA0D6854E8C1E5121AC3330DFAF64CF6F@dggemm509-mbx.china.huawei.com> <CALx6S36KMg3shUktDnBR0uD1XCEwqMRensDQ2x-0DC6=U22a4A@mail.gmail.com> <06CF729DA0D6854E8C1E5121AC3330DFAF64DB57@dggemm509-mbx.china.huawei.com>
In-Reply-To: <06CF729DA0D6854E8C1E5121AC3330DFAF64DB57@dggemm509-mbx.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 26 May 2020 07:00:41 -0700
Message-ID: <CALx6S35iv6SYDfz=i73nzstTf=t87_j=04tgym+VdzqV1UOF2A@mail.gmail.com>
Subject: Re: G-SRv6 (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")
To: Huzhibo <huzhibo@huawei.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000005069905a68d8662"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/v8ViFW8BrysHJ6NLnhtIoH-p3ZE>
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: Tue, 26 May 2020 14:00:59 -0000

On Mon, May 25, 2020, 7:41 PM Huzhibo <huzhibo@huawei.com> wrote:

> Hi Tom,
>
> With respect to that draft I have a few questions:
>
> 1. Doesn't G-SRv6 require a different routing type? I don't see how
> G-SRv6 compatible could be compatible with RFC8754 which clearly
> defines SIDs to be 128 bits.
> [Zhibo] No, we don't require a different routing type, because we don't
> modify the format of SRH. Segment Left points to a 128 bit SID, and it may
> contain multiple G-SIDs. The appearance of G-SID is indicated by COC Flavor.
>

Zhibo,

Thanks for the clarification, but it's still not clear to me exactly how
this works. Can you provide an example of what a SRH with G-SIDs looks
like? For instance, suppose there are one or two SIDs that can be
compressed to 16 bits-- this could be sent in an 8 byte CRH (4 bytes for
header and 4 bytes for two SIDs 2*2). Similarly, in a 16 byte CRH we can
encode 3, 4, 5, or 6 16 bit SIDs. Can you describe the analogous format and
header sizes for these scenarios in G-SRv6?

Also, how does segments left work if it only points to a 128 bit SID that
SID may itself be composed of multiple G-SIDs?


>
> 2. Where would the work for G-SRv6 be done? Since work for SRH was
> done in 6man, I tend to think G-SRv6 should also be in 6man.
> [Zhibo] Well, we think the architecture should be done in SPRING, because
> we need to define a new flavor of SIDs. Regarding the dataplane extension,
> it should be done in 6man.
>
> 3. Given that Flags, Tag, and TLVs are not critical and unused in the
> common case, and with no TLVs Last Entry is unnecessary, can't these
> fields simply be omitted in the compressed format to reduce overhead?
>
> [Zhibo] Of cause you can do that. Like CRH.  But we think Flags, Tag and
> TLVs are important since it provides flexibilities and programmability. We
> can use these fields to support many per-path of per-segment use cases. The
> value of them worth to get 32 bits.
>
> When considering overhead reducing, it is VERY IMPORTANT to not sacrifice
> features.
>
> Reducing overhead by deleting features  seems not clever.
>

It's not so much removing features as it is compressing out fields that are
not commonly used. I suspect the vast majority of SRH implementations send
zeros in these fields which make them a good candidate for compression.

Tom


>
>
> RH was defined in 6man.
>
> Thanks
> Zhibo Hu
>
> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Monday, May 25, 2020 10:35 PM
> To: Huzhibo <huzhibo@huawei.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>om>; IPv6 List <ipv6@ietf.org>
> Subject: G-SRv6 (was Re: Adoption Call for "The IPv6 Compact Routing
> Header (CRH)")
>
> On Mon, May 25, 2020 at 7:09 AM Huzhibo <huzhibo@huawei.com> wrote:
> >
> > Hi 6man,
> > I do not support the adoption.
> >
> >
> > I don't know what is the requirement of the CRH. If CRH is used for
> > steering SR-MPLS traffic over IP network, then RFC8663 has provided a
> > really good solution. If CRH is aiming to address the overhead problem
> > of SRv6, then it is recommended to define a mechanism under SRv6
> > framework, instead of inventing a huge set of control plane and data
> > plane solutions. Also, we think G-SRv6 for compression has solved the
> > overhead problem of SRv6.[1]
> >
> > Best regards,
> > Zhibo Hu
> >
> > [1]https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cm
> > pr-01
> >
> Hi Zhibo,
>
> With respect to that draft I have a few questions:
>
> 1. Doesn't G-SRv6 require a different routing type? I don't see how
> G-SRv6 compatible could be compatible with RFC8754 which clearly defines
> SIDs to be 128 bits.
> 2. Where would the work for G-SRv6 be done? Since work for SRH was done in
> 6man, I tend to think G-SRv6 should also be in 6man.
> 3. Given that Flags, Tag, and TLVs are not critical and unused in the
> common case, and with no TLVs Last Entry is unnecessary, can't these fields
> simply be omitted in the compressed format to reduce overhead?
>
> Tom
>
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
> > Sent: Saturday, May 16, 2020 6:14 AM
> > To: IPv6 List <ipv6@ietf.org>
> > Cc: Bob Hinden <bob.hinden@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
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>