Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Gyan Mishra <hayabusagsm@gmail.com> Sat, 28 November 2020 19:40 UTC

Return-Path: <hayabusagsm@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 7FF3E3A102D; Sat, 28 Nov 2020 11:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 QpObc36by6Pg; Sat, 28 Nov 2020 11:40:09 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 1E2123A102A; Sat, 28 Nov 2020 11:40:09 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id x24so7373625pfn.6; Sat, 28 Nov 2020 11:40:08 -0800 (PST)
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=PBmNyFNsm5YF1kn22w7cZFcwZVAWJUMhOcXOJTooVF4=; b=WHP4gu8TI7c6lIOuF6d+OUNKKdCm9hPvOvZnr3QhbKrx5oYSfjClMcBAKJ7T/fuNVj V5IbteWUdLGq0hAR9f6IM9oEX+0aqddEXJyiDcy2z/SlJMU3P2/+XjdIRVKC77F/30gX pKfwZoCutSvoE/5U89KoV/5x+RrkcOVozGK+f6mfa1o3HH89DgnWiZfN8bxlLmvwAs/b PYSGR22VZnBVUZrMex2thpw4ZXZxZob5inRUyJXcFrIr1P3zVHWa3198NqPUzfCxqnkN PnNtQQROwPBCn7QpGAmCudtzrdw+2LVbn5YTC+iMazXTullz9+fdImHkwrZI78/1qe2I Lcwg==
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=PBmNyFNsm5YF1kn22w7cZFcwZVAWJUMhOcXOJTooVF4=; b=M2cLdra9iY3IAHMU9wz+3W4a17nLuqUu0CpTz65QEENMPDflgitupdhJvR6R0FlAEa ELE+W/zXLPnG7/oUiMWcc//BvKTVypLnDBivetTeRZah0cFcp91YyYYtcycP9FhzDU1u loN2La2U4UEX3aEDYO33senxdi0EwbSwYP3WAxYWHWAtOkifTv8JaM7QQehmuv2M9FRo llOQgNTlS1Gcdk673eX4qkk5xrz53sPNDwg6e+C7l72BfWUbdQT50kRs8JZ+zsOtBj58 Lv+O5lAzzoN+HpFFjbLuwM0f8Z5MlPWXKJ5wdiskMAEdFz+lzUMrEb+Gje44VmX2yuz2 lP4A==
X-Gm-Message-State: AOAM532sNrphCaoAfoUQ0lsztas4TpgTw4kBF8jVVqnneQ6PkeSHzRKX MAdXJc22HchLEd9IEFkO/9Z24JPFl7JTrRBa7io=
X-Google-Smtp-Source: ABdhPJy7N7M9lGyZDXYyMzBeHqbyXeGoj1/XOJH5+I6wheW7NXGmwJ3JQDTWwCM2BDU669BnYYBWeJl0A5UC7pp+gHI=
X-Received: by 2002:a17:90a:6809:: with SMTP id p9mr4743784pjj.112.1606592408283; Sat, 28 Nov 2020 11:40:08 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <CABFReBoFMZwcPrROMB=RbE60TsP4uajUERbE7MVTQD9AjwJ4ag@mail.gmail.com> <CABNhwV3zOqmSetuB92M=8pFFgGmEyq3KvVWat87WfDoBH4j3bg@mail.gmail.com> <MN2PR05MB598132918AFF529C955B15D3D4FE0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2KOCHCAnFG0P-9V9g4rsz4e=aZ1WEcNSR6bTLW9OCO_A@mail.gmail.com> <MN2PR05MB5981922D4BDC641F5CF3CD20D4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV1NXz8NrEvP3GYLz2PKkGNOU__D7XOOZ6_tbM03xPcNSg@mail.gmail.com> <MN2PR05MB5981824AF7424761E656D36ED4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2nzBK7YDqBHrAt_3zAZiA7VDJmw-R=wOqTet6QS=Rg0g@mail.gmail.com> <MN2PR05MB5981AEC2E508A34919BBCE6AD4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV100P14rkQjqt-uNHLhcZCow6n2TL4CxReotkzVX=z-4g@mail.gmail.com> <MN2PR05MB5981E2599B59F35B6F880345D4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV25Aj3yQsa171+u=uVZ8fW5n8jWf2RyR_E1BcfZRfM9Pw@mail.gmail.com> <MN2PR05MB5981F0EE725D7C7C1F048462D4FC0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBoPR_KN66hh9s09AtHg5PVKJjKp7Uew6mV3Fe=nafj3MQ@mail.gmail.com> <BYAPR13MB2582AB90BCAFB158A69CBDA1F4F70@BYAPR13MB2582.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB2582AB90BCAFB158A69CBDA1F4F70@BYAPR13MB2582.namprd13.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 28 Nov 2020 14:39:56 -0500
Message-ID: <CABNhwV3QYbQS+VHgijxsUty9JvWK4OAXpgK8p73qpYECdGH2Dw@mail.gmail.com>
To: Michael McBride <michael.mcbride@futurewei.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Tony Przygienda <tonysietf@gmail.com>, draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>, "gjshep@gmail.com" <gjshep@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cb6d3105b52ff13b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/LWgewaAsoY8SXK9NY29WNfDmgyM>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
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: Sat, 28 Nov 2020 19:40:14 -0000

Hi Greg

Please respond to Mike’s email so that all authors and everyone in the WG
has a clear understanding of next steps.

Kind Regards

Gyan

On Sat, Nov 28, 2020 at 2:15 PM Michael McBride <
michael.mcbride@futurewei.com> wrote:

> Hi Greg,
>
> >Thank you Jeffrey and Gyan for sticking with the thread of the
> conversation to advance the discussion. It's clear now that all of the
> requirements >discussed so far can be addressed by the BIERin6 draft if we
> flesh out the discussed gaps.
>
> >I would like to see Jeffrey and Gyan take over as primary authors of
> >BIERin6 to include the gaps discussed here so that it fully encompases
> the requirements so far described, for WG adoption.
>
> I'm sure I'm misinterpreting. What it sounds like you are saying is "I
> want bierin6 to be adopted so let's fix the gaps so we can begin". Since
> both solutions meet the requirements, I'm hoping you meant "Let's fix the
> gaps in bierin6 so we can begin adoption calls for both bierv6 and
> bierin6".
>
> mike
>
>
> On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net>
> wrote:
>
> > Hi Gyan,
> >
> >
> >
> > Great that we reached consensus on BIERin6.
> >
> > Now there are two lingering points alluded to in this thread, but
> > given it’s been such a long and deeply nested tread, I’ll start a new
> > thread about it.
> >
> >
> >
> > Thanks.
> >
> > Jeffrey
> >
> >
> >
> > *From:* Gyan Mishra <hayabusagsm@gmail.com>
> > *Sent:* Monday, November 23, 2020 1:32 AM
> > *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> > *Cc:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> > EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
> > tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
> > draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
> >
> >
> >
> > *[External Email. Be cautious of content]*
> >
> >
> >
> > Hi Jeffrey
> >
> >
> >
> > That’s the last of my questions related to BIERin6.
> >
> >
> >
> > I thank you for taking the time to go over the BIERin6 draft in detail.
> >
> >
> >
> > We have reached consensus as well as are in sync,  and I now have a
> > better understanding of BIERin6.
> >
> >
> >
> > During the discussions I did mention that maybe in BIERin6 optional
> > IPv6 tunneling should be removed, as it seemed to create some
> > confusion, but now I am clear and as both the L2/tunnel and IPv6
> > L3/tunnel encapsulation single hop or multi hop tunnel both have the
> > clean BIER layering and complement each other I agree they belong
> together in the same draft.
> >
> > Even though L2/tunnel exists today as part of RFC8296 it makes sense
> > to be part of the overall BIERin6 solution.
> >
> >
> >
> > I am clear on the two IANA code points requests required for the
> > optional
> > IPV6 encapsulation option.
> >
> >
> >
> > Over the course of this thread we did touch on some technical reasons
> > why
> > IPV6 encapsulation is necessary which I you mentioned in some of your
> > responses.
> >
> >
> >
> > Overall throughout the discussions I agree that BIERin6 IPV6 tunnel
> > option and BIERv6 are not transitional and are long term solutions and
> > there are reasons why that we can add to the requirements draft as to
> > why IPV6 encapsulation is necessary below:
> >
> >
> >
> > - Operator requirement for IPV6 encapsulated packets  and not L2
> > encapsulation.
> >
> > -FRR
> >
> >
> >
> > I think we are all set to start updating the Requirements draft.
> >
> >
> >
> > In-line Gyan6>
> >
> >
> >
> > Kind Regards
> >
> >
> >
> > Gyan
> >
> >
> >
> > On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang <
> > zzhang@juniper.net> wrote:
> >
> > Gyan,
> >
> >
> >
> > Please see zzh6> below.
> >
> >
> >
> > *From:* Gyan Mishra <hayabusagsm@gmail.com>
> > *Sent:* Sunday, November 22, 2020 9:49 PM
> > *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> > *Cc:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> > EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
> > tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
> > draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
> >
> >
> >
> > *[External Email. Be cautious of content]*
> >
> >
> >
> >
> >
> > Hi Jeffrey
> >
> >
> >
> > Agreed we have reached a consensus.
> >
> >
> >
> >
> >
> > Few more questions to iron out understanding.
> >
> >
> >
> > In line gyan4>
> >
> >
> >
> > Zzh6> Apparently there are still disconnects 😊
> >
> >  Gyan> Thank you for all the detailed responses.  We are in sync now!
> >
> > On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang <
> > zzhang@juniper.net> wrote:
> >
> > Hi Gyan,
> >
> >
> >
> > Yes I believe we’ve reached consensus.
> >
> >
> >
> > Please see zzh5> below about some details.
> >
> >
> >
> > *From:* Gyan Mishra <hayabusagsm@gmail.com>
> > *Sent:* Sunday, November 22, 2020 4:19 PM
> > *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> > *Cc:* Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> > EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <
> > tonysietf@gmail.com>gt;; draft-ietf-bier-ipv6-requirements <
> > draft-ietf-bier-ipv6-requirements@ietf.org>gt;; gjshep@gmail.com
> > *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
> >
> >
> >
> > *[External Email. Be cautious of content]*
> >
> >
> >
> > Hi Jeffrey
> >
> >
> >
> > This has been a very informative exchange and extremely helpful for
> > all of us to get onto the same page from a basic understanding POV.
> >
> >
> >
> > Much appreciated all your help and feedback helping clarify my confusion.
> >
> >
> >
> > I am answering in-line but now connecting the dots how is in today’s
> > RFC
> > 8296 Non MPLS BIER Ethernet going to transport IPv6?
> >
> >
> >
> > From your answers below it cannot work as we need two IANA code point
> > one for IPv6 next header type and ICMPv6.
> >
> >
> >
> > Zzh5> The existing model/concept works except that we need to two code
> > points if IPv6 tunneling is used for either getting over non-BFRs or
> > for FRR. One may deem non-BFR as a short-term scenario but FRR will be
> > here for the long run.
> >
> >
> >
> >     Gyan4>I am a little confused here with the code points.  For
> > BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type
> 0xAB37.
> >
> >
> >
> > Ethernet -0xAB37 l BIER | IPv6 | payload
> >
> >
> >
> > Zzh6> Note that IPv6 header is not needed – it should be Ethernet
> > Zzh6> -0xAB37
> > l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6
> > header may be inserted between BIER and payload, only for the SRv6
> > style VPN purpose.
> >
> > Gyan> Understood
> >
> > Ethernet -0xAB37 l BIER l ICMPv6 | payload
> >
> >
> >
> > Zzh6> ICMP was mentioned not for encapsulation but for the following:
> >
> >  Gyan6>Understood
> >
> > Zzh6> 2.1.  IPv6 Options Considerations
> >
> >
> >
> >    For directly connected BIER routers, IPv6 Hop-by-Hop or Destination
> >
> >    options are irrelevant and SHOULD NOT be inserted by BFIR on the
> >
> >    BIERin6 packet.  In this case IPv6 header, Next Header field should
> >
> >    be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
> >
> >    multiple extension header where the last extension header has a
> > Next
> >
> >    Header field set to TBD, SHOULD be discard and the node should
> >
> >    transmit an ICMP Parameter Problem message to the source of the
> >
> >    packet (BFIR) with an ICMP code value of TBD10 ('invalid options
> > for
> >
> >    BIERin6').
> >
> >
> >
> > In this particular scenario where adjacent BFRs support Ethernet link
> > layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the
> > need for the next header code point above is the packet format:
> >
> >
> >
> > Excerpt from RFC 8296
> >
> >
> >
> >    Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet
> >
> >    header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332
> > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
> > defense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc5332__%3B!!
> > NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ8
> > 4ssHlj%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a34
> > 14dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> > C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8EiHsMns5Jut
> > 7s6EmZvJSxvEwUuJKdtE8PbMZyYRBiQ%3D&amp;reserved=0>].  IEEE
> >
> >    has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
> >
> >
> >
> >
> >
> > In the case of BIERin6 optional encapsulation option, in case where
> > operators requires packets forwarded in IPv6 or tunneling over Non BFR
> > packet format below:
> >
> >
> >
> > IPv6 outer header l BIER l Data
> >
> >
> >
> > So here the next header is BIER so corresponding next header code point.
> >
> >
> >
> >
> >
> > So below is for both cases IANA code point allocation for “L2” next
> > header where next header is IPv6 or ICMPV6, and then the optional IPv6
> > encapsulation option where the next header is BIER.
> >
> >
> >
> > Would those be two separate IANA code point requests I what I see from
> > the packet format.
> >
> >
> >
> > IANA L2 scenario:
> >
> > 2 code point requests for L2 for next header IPv6 and ICMP
> >
> >
> >
> > Zzh6> I don’t follow what you’re talking about. If BIER header follows
> > Zzh6> L2
> > header directly, no new code point is needed. It’s just “Ethernet
> > 0xAB37 | BIER | payload”.
> >
> >
> >
> >     Gyan6> Agreed.
> >
> >
> >
> > IANA optional IPv6 scenario:
> >
> > 1 code point request for IPv6 for next header BIER
> >
> >
> >
> > Zzh6> If IPv6 encapsulation is used, either on between directly
> > Zzh6> connected
> > BFRs or indirectly connected BFRs, a new “next header” code point is
> > needed for BIER.
> >
> >  Gyan6>Understood
> >
> >
> > 5
> > <
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-bier-bierin6-07*section-5__%3BIw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH%24&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C97b8a3414dbe40bd528708d892e35223%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637420852351965804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nEiVnnCjvgjBOe7cymYDxS784YHPeOpsWHsatN25kj0%3D&amp;reserved=0
> >.
> > IANA Considerations
> >
> >
> >
> >
> >
> >    IANA is requested to assign a new "BIER" type for "Next Header" in
> >
> >    the "Assigned Internet Protocol Numbers" registry.
> >
> >
> >
> >    IANA is requested to assign a new "BIERin6" type for "invalid
> >
> >    options" in the "ICMP code value" registry.
> >
> >
> >
> >    IANA is requested to assign a new "BIER IPv6 transportation
> > Sub-sub-
> >
> >    TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV"
> >
> >    Registry.
> >
> >
> >
> >    IANA is requested to set up a new "BIER IPv6 transportation
> > Sub-sub-
> >
> >    sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV"
> >
> >    Registry.
> >
> >
> >
> >
> >
> > My point is that the IANA allocation is different as the next header
> > is different for the L2 scenario where next header is IPv6 or ICMPV6,
> > and IPv6 encapsulation scenario where the next header is BIER.
> >
> >
> >
> > Zzh6> If BIER header follows L2 header directly, BIER Ethertype is
> > Zzh6> used
> > (assuming Ethernet is the L2).
> >
> >  Gyan>Understood
> >
> > Based on this point I am making could we just do a RFC8296 bis version
> > and add the IANA code points for IPv6 and ICMPv6.
> >
> >
> >
> > Zzh6> Given the confusion/contention that have happened in the last
> > Zzh6> two
> > years, it is much better to specifically have a spec dedicated to
> > supporting BIER in IPv6.
> >
> >  Gyan6> I think now looking at it holistically speaking I can now see
> > parity between the L2/tunnel and L3/tunnel both also having the clean
> > layering.  So I can see why adding existing L2/tunnel to BIERin6 even
> > though it already exists made sense to bundle into BIERin6 total solution
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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