Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

Tony Przygienda <tonysietf@gmail.com> Tue, 16 July 2019 15:29 UTC

Return-Path: <tonysietf@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414871206B8; Tue, 16 Jul 2019 08:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 Lj2lXa97CDP9; Tue, 16 Jul 2019 08:29:28 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 E0F81120155; Tue, 16 Jul 2019 08:29:27 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id d4so20636443edr.13; Tue, 16 Jul 2019 08:29:27 -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=NfHlhW75Iy0ozmv0B8QJ0awyMIuj7tn3sDklcMS8dBA=; b=GVand1XHjRoCvJsLzJkujJJPAsJ4c0ntfqBuphMk7ATg4lT34h5z2FzpTt7AQO9fv5 912+JdA2OQhDIN3iDSjLbY1uEeogOlWiRTfgtux9bkNtSdTXpZ2W7Ex4p2JfHQ83rC3b c6vYOoqfjeLCy4+649fcQPe7HvEP29+6tUtA/MA3j1tcVsjbVVw7b2fb0Otjhp20Asgg SV4yfODbOV21KNeDjBfA6m8QajZODKC9lUfXL3DOmR5XERAfWnaOktUD2phDRlrycMHk HX39iupuahd6rMN9NE8uQfXHygRT/MYnw3ROEQyURCOUGtVqFK86ueibNvs5lgfacidx cwLg==
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=NfHlhW75Iy0ozmv0B8QJ0awyMIuj7tn3sDklcMS8dBA=; b=qioQanWK0MUl7tFnpMKNVZ6AdxJvi9Tfl5R93pIUzoOB+QyjSs7ep4gH7tWZpOP4tC pbXL5SNttUykx7uO7AwEVxKLIY4yXQvmPP+MWEfjUOmDLxWs+VF726+rEtQFkQdhNQIy gxglwjssegUSyDMKA8yhcGoedaE4psBJW0TwO3v+m4ZGDshL5pVaza7IpwXJqHfw3Xo4 HogDWqF1/vMIjzHLTNRWsRE7cxz0baOjExbLvlabxZcrKoL6/Lw38Jlw5mfCFq1GM8Vx NOSnrMIUci3B0Knj/HRoZL4jf5GkX8JE5IMcrCbFdA5Vgv+dMEvYDAtbACEvAo2cZIBB quug==
X-Gm-Message-State: APjAAAX+M1r0i2yTjBfuD495lWNOX5d9eJ44DeU1wCrVme8012TlgKK9 XAGOnpvZD+L3Y1DkqO0GLbuFBqrUip+XrZVzvyY=
X-Google-Smtp-Source: APXvYqzmODwmziPqiRY3K/9l9xbzhsiaEZLorRevouOhJV4cLb7F2aByWoaizXFloECw7LB1hFG6lnpXrykTYgpu3q0=
X-Received: by 2002:a50:b13b:: with SMTP id k56mr30684152edd.192.1563290966458; Tue, 16 Jul 2019 08:29:26 -0700 (PDT)
MIME-Version: 1.0
References: <16253F7987E4F346823E305D08F9115AAB8DC468@nkgeml514-mbx.china.huawei.com> <DM5PR05MB3548E853C20E03CC58C7956BD4F10@DM5PR05MB3548.namprd05.prod.outlook.com> <MWHPR05MB32792FD6E09E4444B8DF45C3ACF30@MWHPR05MB3279.namprd05.prod.outlook.com> <16253F7987E4F346823E305D08F9115AAB8DD5B0@nkgeml514-mbx.china.huawei.com> <DM5PR05MB3548F4EFF3EFC0CCDA3FDE73D4F20@DM5PR05MB3548.namprd05.prod.outlook.com> <16253F7987E4F346823E305D08F9115AAB8DD87A@nkgeml514-mbx.china.huawei.com> <DM5PR05MB354819A911C930C1B8519CD4D4F20@DM5PR05MB3548.namprd05.prod.outlook.com> <DM5PR05MB3548637A9F8CBB1CB70BE3E6D4CD0@DM5PR05MB3548.namprd05.prod.outlook.com> <CAG9=0bJyYGhmLnm8CVk904EcouaW7VCP7KTvuciWc57NuiFDpQ@mail.gmail.com> <CA+wi2hNW4CbKgG1qgiaKqeGsz4GjS7hLkSDWH1yu4VFWfg2C5A@mail.gmail.com> <16253F7987E4F346823E305D08F9115AAB8EAFB1@nkgeml514-mbs.china.huawei.com> <CA+wi2hNZVEmUGBunc1YD5JAG7xtNnCf5hgzQ8FuSYOfJw2OcZg@mail.gmail.com> <16253F7987E4F346823E305D08F9115AAB8F1681@nkgeml514-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115AAB8F19ED@nkgeml514-mbs.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AAB8F19ED@nkgeml514-mbs.china.huawei.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Tue, 16 Jul 2019 08:28:50 -0700
Message-ID: <CA+wi2hM=xME5-nYCP1xkfMx7+SwSQUtSXqnywBaC9Vamx+rzEA@mail.gmail.com>
To: Xiejingrong <xiejingrong@huawei.com>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>, BIER WG <bier@ietf.org>, "draft-zhang-bier-bierin6@ietf.org" <draft-zhang-bier-bierin6@ietf.org>, Antoni Przygienda <prz@juniper.net>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc8acd058dce0aa7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/DBcUQOdiK065yW_XqsZwFGn5V08>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 15:29:38 -0000

To close this thread the discussion needs to focus on the requirements
draft during IETF and on this mailing list first and we see what comes out
of that and accordingly the drafts will evolve ...

I have many observations towards the req' draft and I expect a lively
discussion. If I find time I may fire off something to the list before IETF
along those lines ...

thanks

--- tony

On Tue, Jul 16, 2019 at 3:31 AM Xiejingrong <xiejingrong@huawei.com> wrote:

> Sorry, the picture didn’t show in the list.
>
> I re-write in text:
>
>
>
> -------Solution Using NH=BIER (draft-zhang-bier-bierin6)-------
>
> Result = FIB Lookup(DA)                            //Step 0
>
> Switch(Result)
>
>   Case Local Interface IPv6 Address:               //Step 1
>
>     If packet is (NH=BIER)                         //Step 2 (*A*)
>
>         Process it
>
>     Else if packet is (NH=a/b/c/d & Last_NH=BIER)  //Step 3
>
>         Process it
>
>     Else If packet is (NH=XXXX)                    //Step 4 (*B*)
>
>         Process it
>
>     Else if packet is (NH=a/b/c/d & Last_NH=XXXX)  //Step 5
>
>         Process it
>
>     Else If packet is (NH=YYYY)                    //Step 6 (*C*)
>
>         Process it
>
>     Else if packet is (NH=a/b/c/d & Last_NH=YYYY)  //Step 7
>
>         Process it
>
>     Else
>
>         Do normal things as usual                  //Step 8 (*D*)
>
>   Case Non-Local Routable IPv6 Address
>
>       Do normal routing and forwarding as usual.
>
>
>
> (A) need 2~3 steps!
>
> (B) need 4~5 steps!
>
> (C) need 6~7 steps!
>
> (D) need 8 steps!
>
>
>
>
>
> -------Solution Using EH and
> End.BIER(draft-xie-bier-ipv6-encapsulation)-------
>
> Result = FIB Lookup(DA)                                   //Step 0
>
> Switch(Result)
>
>   Case End.BIER:                                          //Step 1
>
>     IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4  //Step 2(A)
>
>          Process it
>
>     ELSE IF (NH=ICMPv6) or (NH=60 and Dest_NH=ICMPv6)
>
>          Send to CPU.
>
>     ELSE
>
>          Drop the packet.
>
>   Case End.XXXX:                                         //Step 1
>
>     IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4 //Step 2(B)
>
>         Process it
>
>     ELSE
>
>         Drop the packet
>
>  Case End.YYYY:                                          //Step 1
>
>     IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4 //Step 2(C)
>
>         Process it
>
>     ELSE
>
>         Drop the packet
>
>   Case Local Interface IPv6 Address:                     //Step 1
>
>         Do normal things as usual                        //Step 2(D)
>
>   Case Non-Local Routable IPv6 Address
>
>         Do normal routing and forwarding as usual.
>
>
>
> (A) need 2 steps!
>
> (B) need 2 steps!
>
> (C) need 2 steps!
>
> (D) need 2 steps!
>
>
>
>
>
> -------Repeat the advantages-------
>
> The least impact:  Switch-case by preceding FIB lookup doesn’t impact
> other cases.
>
> The most efficient:  Do not need walking through EH ---- only check the
> first EH.
>
> The most extensible to support features in the future:   Combine with
> Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER
> TLVs in a single Destination Options header. etc.
>
>
>
> Thanks
>
> Jingrong.
>
>
>
> *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Xiejingrong
> *Sent:* Tuesday, July 16, 2019 5:29 PM
> *To:* Tony Przygienda <tonysietf@gmail.com>; Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net>
> *Cc:* Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>; BIER WG <
> bier@ietf.org>; draft-zhang-bier-bierin6@ietf.org; Antoni Przygienda <
> prz@juniper.net>; Jeffrey (Zhaohui) Zhang <zzhang=
> 40juniper.net@dmarc.ietf.org>
> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>
>
>
> Hi Tony, Jeffrey:
>
> Let’s f2f in BIER session at Montreal.
>
> Here is a page I think useful to understand the difference between Layer-4
> solution(left) and Layer-3 solution(right).
>
> That’s why I think use of a preceding End.BIER is most efficient (for BIER
> forwarding), least impact (to exist functions), and most extensible for
> future functions.
>
>
>
> The least impact:  Switch-case by preceding FIB lookup doesn’t impact
> other cases.
>
> The most efficient:  Do not need walking through EH ---- only check the
> first EH.
>
> The most extensible to support features in the future:   Combine with
> Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER
> TLVs in a single Destination Options header. etc.
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Tony Przygienda [mailto:tonysietf@gmail.com <tonysietf@gmail.com>]
>
> *Sent:* Monday, July 15, 2019 11:58 PM
> *To:* Xiejingrong <xiejingrong@huawei.com>
> *Cc:* Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>; Jeffrey
> (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>; BIER WG <
> bier@ietf.org>; draft-zhang-bier-bierin6@ietf.org; Antoni Przygienda <
> prz@juniper.net>
> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>
>
>
>
>
>
>
> On Mon, Jul 15, 2019 at 12:39 AM Xiejingrong <xiejingrong@huawei.com>
> wrote:
>
> Please see my comments below:
>
>
>
> *From:* Tony Przygienda [mailto:tonysietf@gmail.com]
> *Sent:* Monday, July 15, 2019 3:04 PM
> *To:* Senthil Dhanaraj <senthil.dhanaraj.ietf@gmail.com>
> *Cc:* Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>;
> Xiejingrong <xiejingrong@huawei.com>; BIER WG <bier@ietf.org>;
> draft-zhang-bier-bierin6@ietf.org; Antoni Przygienda <prz@juniper.net>
> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>
>
>
> if your router can do BIER fast path IPv6 is not an interesting option no
> matter which draft.
>
> [XJR] That’s not true. The interest in BIER-IPv6-fast-path is strong.
> There is no problem of “interest” or “requirement”. The problem is the lack
> of convinced  “technology” or “solution”.
>
>
>
> enlighten me where you saw that except being personally convinced it's
> cool ... And what is the specific reason customer would want that
> complexity/cost of v6 option processing silicon compared to ether/mpls
> encaps.
>
>
>
> one would either carry native ether or MPLS rather than trying to build
> IPv6 fast path with header options @ arbitrary place,
>
> probably misaligning bitmasks and ultimately forcing 4K buffers on v6
> option processing in silicon which may be fun but it is expensive, complex
> fun.
>
> [XJR] The proposals are not as good as expected,  or could not do it in a
> simple and inexpensive way! I guess this is the point.
>
>
>
> yupp. MPLS/Ether will be as inexpensive as it can be and shares same
> processing block.
>
>
>
> [XJR] Well I think, using a preceding BIER-Specific IPv6 Address in IPv6
> DA can solve the problem perfectly.
>
> [XJR] This is the way SRv6/SRH do, *which first introduces the fast-path
> processing of extension header*, without recognition the pattern of the
> EHs and the TLVs, but simply ‘process the desired packet, and drop the
> undesired packet’!
>
>
>
> BIER is neither SRv6 nor SRH so your point here is?
>
>
>
> BIER is a L2.5 hop-by-hop multicast switching technology that should be
> tunneled otherwise. v6 enaps (where we really abuse v6 as L1 transport) is
> only justified if ether/mpls cannot be implemented but chips can do very
> simple v6 processing and there is not high throughput requirement (albeit
> one could build bierin6 fast-path in silicon obviously). Obviously bierin6
> gives you the nice trick to tunnel it to a v6 destination without
> establishing a real tunnel but it's really just a by-product and not its
> main goal
>
>
>
> --- tony
>
>
>