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

Gyan Mishra <hayabusagsm@gmail.com> Fri, 20 November 2020 20:00 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 EBC973A1322; Fri, 20 Nov 2020 12:00:48 -0800 (PST)
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 2vQBIfQJJFAr; Fri, 20 Nov 2020 12:00:45 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 BC2863A129C; Fri, 20 Nov 2020 12:00:31 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id d17so5406977plr.5; Fri, 20 Nov 2020 12:00:31 -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=QchY3IFRfXnuDu89RDOpzf/LQ9n22zs3TBoiHMkfv9c=; b=YHXW97n11DZFGL0Pf1oZv4BuBsVS/60DhjvMyyur/+be90bjdvEJCTtDqFQfszwcPN n1S4gX0MmBHtzomKYmGjkv0O3dFsN0RPA+OKjS/8Q1uPlMxS4XORQKOLiNHsaPNr1HZ8 n/Ea7gMQR0AStTGgCd9cUE+UIlX9zAIKQNlLtz6TjeInwUHBWZ8/QNdccSZVsexyhPeS Uh7p3MVMuCqAr3qXThxWvAyb/bzn8PKnTS1IXKcY8CzUvSHerPMrEuiBsSs4uB3Twqpz qU7NTRr47bT4WRidTRIpllq5n7aHf5Ae1fjT56Et+d+CG1ZOQekuqzR4rtscqlld8lyp +z3Q==
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=QchY3IFRfXnuDu89RDOpzf/LQ9n22zs3TBoiHMkfv9c=; b=UnKPTNYCD/rAXgZZ8JHc+70Vs/MQ49wbisvy03NoN9BSqssN4cVg1/atdxa1hLjdUq DayuKE6XsCNPJ0thJr2Owkuz0lP0WAd/mElavj5szOge9fa0q4p1w1x368/kCjPnOysd +5lEaP3iUmJsh8sxM8GwfP7uQU0UMuMHhuw4UnSul1bH9YDHXKodTZfoxWiFT/7BKYVI H8jKaGfvjF7s2JVU2+DMY5qaUbH5D7PdcmcXdBWwqngRHJ8e7fHVdHAHSFgHH6sbBvT1 Snt32sS3WiGxVEXDdLkLxEo4i1z6Ypjdko0qF6JI3GeHXpjAjed0RLQmHBMb2v76382l uyyQ==
X-Gm-Message-State: AOAM532lTWeg1m8hosckWcbh7NKA9hl48SrWL00OW2d5Ph8Z+FVGqV+P dWEdW828uOj8Zp3mrhACirsOE+4l6+0i5nnpiv8=
X-Google-Smtp-Source: ABdhPJza2fvggIgG+3/yK9AyHV6+OQAKxsmwvKKc9BRsNyXhsVzPS9Wx4/OI5vWIRhumaFiFfCq6i8h1zdBeiCfjBss=
X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr15767189pll.22.1605902431076; Fri, 20 Nov 2020 12:00:31 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <CABFReBoFMZwcPrROMB=RbE60TsP4uajUERbE7MVTQD9AjwJ4ag@mail.gmail.com>
In-Reply-To: <CABFReBoFMZwcPrROMB=RbE60TsP4uajUERbE7MVTQD9AjwJ4ag@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 20 Nov 2020 15:00:19 -0500
Message-ID: <CABNhwV3zOqmSetuB92M=8pFFgGmEyq3KvVWat87WfDoBH4j3bg@mail.gmail.com>
To: gjshep@gmail.com
Cc: Alvaro Retana <aretana.ietf@gmail.com>, BIER WG <bier@ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Tony Przygienda <tonysietf@gmail.com>, draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>, "zhang.zheng" <zhang.zheng@zte.com.cn>
Content-Type: multipart/alternative; boundary="000000000000f2c6b105b48f4bc1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/mdFzJpSJ8EeM0XEolrTdn8vgqw4>
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: Fri, 20 Nov 2020 20:00:53 -0000

Hi Greg

In-line

Thank you again both you and Tony and Alvaro for all your guidance to help
right the ship!!

I will by “first round” when we meet in person — some day!!👍😁- maybe even
second and third - or the night is on me if we can get this behind us. 😀

Thanks
On Thu, Nov 19, 2020 at 12:22 PM Greg Shepherd <gjshep@gmail.com> wrote:

> GS - inline:
>
> On Wed, Nov 18, 2020 at 7:14 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>> All
>>
>> I would like to thank the Greg, Tony and Alvaro on their pointers and
>> guidance this morning to help move the ball forward with the requirements
>> draft.
>>
>
> Thank you for your help.
>

     Gyan> Welcome

>
>
>> What I heard from Greg which rang out loud and clear and I mentioned to
>> the requirements authors that today we have BIER MPLS where the BIER header
>> is encoded into MPLS label stack layer 2 1/2 and we also have non MPLS BIER
>> Ethernet ether type 0xAB37.
>>
>
> GS - No, the BIER header is NOT 'encoded' in MPLS. MPLS encapsulates the
> BIER packet. Yes, the outer label included BIER specific information
> (Set-ID) with the intent of streamlining the forwarding process but without
> creating a dependency. We mirrored the format for Eth encap to ensure a
> single header format for the BIER architecture standard. It's important to
> mention there that the process to get to this point involved a 3-day
> design-team meeting where we worked hard, transparently and together and
> managed to conclude with a solution which resolved any conflict, satisfied
> everyone's concerns, and resulted in a clean, consistent message from a
> Working Group that was working under the 'experimental' banner. We moved
> from 'experimental' to standards track by listening to all the reasons we
> were started out as 'experimental' in the first place - ie This is the
> forwarding plane and will require new HW so the work from the WG must
> justify a new forwarding model and produce clear standards to follow.
>

   Gyan> Thank you for clarification on BIER MPLS and important history on
the BIER encapsulation types and how they came about and the evolution from
Experimental to Standards Track.  I can see the simplicity single header
format beauty behind the BIER architecture.

>
>
>> So why do we need non MPLS BIER encapsulation in an IPV6 environment as
>> that IPv6 environment can be supported by non MPLS BIER Ethernet.  The case
>> and point here is that eventually just as ATM and Frame Relay now live in
>> the technology graveyard so will at some point in time as SRv6 matures will
>> become the end all be all “core transport” mechanism for all operators.
>>
>
> GS - This is an opinion and not a technical argument. BTW, it is MY
> opinion that the largest early adopters for BIER will be financial
> networks, and more specifically financial trading floors. These networks
> are dedicated, high-speed, multipoint networks that will never adopt SRv6.
> Remember the IETF is to create standards that work best for everyone, not
> just to solve our individual network issues or vision.
>

    Gyan> Understood.

>
>
>> So that being said we need a another encapsulation method to carry BIER ,
>> and per RFC 8296 that gap is filled with Non MPLS BIER Ethernet
>> encapsulation today which will work for future SRv6 transport once MPLS
>> goes by the wayside.
>>
>
> GS - Just for clarity, RFC8296 works today regardless of any
> perceived transport wars. That's because a proper layered architecture
> avoids layer dependencies.
>
>
     Gyan> Understood.  The BIER encapsulations types MPLS and Non MPLS
defined in RFC 8296 works well with the RFC 8279 BIER 3 layer architecture,
underlay, BIER layer, overlay which are independent of each other.  Makes
sense.

At the beginning of the presentation Greg corrected me and stated that that
>> after the BIERin6 independent model draft was published, that the
>> requirement draft came about to build a set of requirements as to the “why”
>> we need BIER to work in a non MPLS BIER in an IPv6 environment when we
>> already have the BIER Ethernet encapsulation that fits the bill and works.
>>
>
> GS - Not exactly... Let me clarify:
>   BIERin6 first published in Oct 2017. I think the primary interest at the
> time was Homenet. The WG had no issues with the solution, but then neither
> had many members stepping up to help. Our AD's (and through extension the
> IAB) ingrained in us the need to remain diligent in the publication of our
> standards and only progress work that remained consistent with our existing
> work and showed community support. The first was true, the second was a
> little slight at the time.
>
>   April 2018 - the BIER Encap (misnomer) draft was published. It was
> pointed out from the beginning that there is a stark difference between
> encap and encode and that the WG has already published standards for
> encode. So the question was asked, why do you need a new encoding and
> encap. The answer given at the time was that there was a need to address
> non-BIER routers in the network and that this solution would be
> transitional. The WG pushed back that ANY transition mechanisms MUST NOT
> require HW changes. We also heard things like:
> "integrated into IPv6" - not true, it's merely BIER information encoded
> into extension headers. Operationally this is identical to BIERin6 encap,
> except that the former would require new HW, something our AD's made clear
> needs to be justified before progressing.
> "fast-path" - not true.
> I/We continued to ask questions trying to understand what benefits could
> be implied by encoding the BIER header into an IPv6 extension header rather
> than to just encap the BIER packet? And ultimately what is to be
> accomplished with any new encap now that we have RFC8296? The WG decided we
> needed a problem statement and requirements draft to guide any work in this
> space.
>
> The reqs draft was heavily weighted by BIEREncode draft authors and showed
> significant effort to direct the conversation. The WG was largely silent on
> any support either way. Mike came to me frustrated that nobody is stepping
> up to help. My reply was that if the WG doesn't show interest in the work,
> maybe that's your answer. Since then, more authors have been added.
>

    Gyan> Thank you for the important clarification on history of how
things transpired and how the requirements draft came about.  As well as
history of BIERin6 and BIERv6.  Makes perfect sense as what triggered the
requirements draft was the second solution BIERv6.

Operationally as you stated as well as from the BIER layering perspective 2
out of the 3 layers ar identical as both have underlay and overlay and thus
are mirrored on the encapsulation in the layering.
As you mentioned the stark difference comes is the “BIER” layer where with
BIERin6 it fits right in the middle of the inner and outer layer “encap”
where with BIERv6 the additional encoding of the BIER header was the tricky
part for sure.

We leveraged following verbatim the IPv6 specification RFC 8200 to encode
the BIER header in the DOH extended header for en route hop by hop BIFT
processing very similar to hbh header processing.

So there being the stark difference where BIERin6 was “encap” based and
BIERv6 was “encap” + additional “encode” based, thus the pushback as to
giving concrete reasoning for having a solution that requires the
additional “encode”.  Agreed.

Our answer as you stated has been that BIERv6 solution would be a
transitional solution to accommodate “Non BFR” routers and that is still
the case.  As stated with the BIERv6 integrated solution , the key problem
that has to be solved to make that solution viable is where to put the BIER
header.

As “encap” was not an option as that would literally make BIERv6 identical
to BIERin6 - thus the MAJOR challenge as to where to put the BIER header as
there really is no other place other then in an extension header.  Another
option that is still another viable option is picking a different header
such as hbh to encode the BIER header.  We chose DOH as it had the options
flag value option 3 for en route so at the time it made sense to go with
DOH.  With many drafts looking at hbh for performance measurements in-situ
hbh processing in the fast path, it is possible that hbh could still be a
viable alternative.

One other significant difference between BIERin6 and BIERv6 is that BIERin6
is to some degree a “pseudo” IPV6 environment solution as L2 links direct
Non MPLS Ethernet encapsulation can be used to transport BIER packets.  So
this is HUGE has far as stark difference and major advantage of BIERin6
over BIERv6.

So with BIERin6 in an IPv6 environment, the IPv6 tunnel encapsulation and
decapsulation for HBH BIFT processing only needs to be done in case of “Non
BFR” routers present in “transitionary method”.

“Between two BFRs,either a L2 link can be used directly or any tunnel
(IPv6 or not) can be used for BIER transport.”


    One example of this model is defined in [I-D.zhang-bier-bierin6
<https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-08#ref-I-D.zhang-bier-bierin6>],

   where the BIER header and the payload following it are L2 payload
   when feasible (e.g.  when two BFRs are directly connected) or IPv6
   payload when IPv6 transport is needed/desired (e.g. when two BFRs are
   not directly connected).  This is indicated by either a 0xAB37
   Ethertype allocated to BIER or a new IPv6 Next-Header value to be
   allocated by IANA.


This does give BIERin6 significant advantage over BIERv6 that in a IPV6
environment as BIERin6 can leverage existing RFC 8296 encapsulation non
MPLS BIER Ethernet solution already in place today

So to state differently how BIERin6 is envisioned as a “pseudo” IPv6
encapsulation solution is that in Green field deployments we would only use
L2 to connect BFRs via non MPLS BIER Ethernet ether type Oxab37 which then
this would be case and point that you don’t need the BIERin6 solution to
accomplish as that exists in RFC 8296.  Was this done on purpose- I think
so as why reinvent the wheel so to speak.  Makes sense to me.

BIERin6 using IPv6 encapsulation and decapsualation technique for BIER
header transport would only be used in transition where non BFRs exist to
tunnel unicast over for backwards compatibility for existing old hardware.
Once all brown field Non BFR routers are upgraded in essence we are back to
the original RFC 8296 non MPLS BIER Ethernet solution.

So as we don’t want to reinvent the wheel as we already have a solution for
IPV6 environment, these two solutions are transitional “interim” stop gap
measures bandaid if you will to get to the end state solution we already
have today for IPV6 environments.

So I think it’s fair to state and please let me know if my extrapolation is
way off base!

As I stated earlier that in BIERin6 solution makes this crystal clear that
we already have a solution for transporting BIER packets in a Non MPLS BIER
IPV6 environment using RFC 8296 non MPLS BIER Ethernet ether type 0xab37.

As the big million $$ - why do we need another solution for IPv6
environment-  the answer is and correct me if I am off base = “we don’t”

Both BIERin6 “encap” solution and BIERv6 “encap” + “encode” solution would
only be used for brown field transitional sense and never was meant to be a
long term - shall we say alternative solution to carry BIER packets.  Point
being is we already have a solution so why reinvent the wheel.

As far as IPV6 extended header usage and processing see below:

With graconian routers of the past with extended header processing and on
6man and v6ops there have been many drafts written for best practices to
not drop extended headers with fear of dos attack on the control plane but
impacting legitimate customer traffic that used extended headers. Modern
router processing of extension headers has advanced quite significantly
over the past 20 years being able to process hbh as well as doh en route
hop by hop at line rate in the forwarding plane fast path.  No new hardware.

>
>
>> So that’s the million $$ question we are trying to solve here with the
>> requirements draft.
>>
>
> GS - Yes, but redefined as per my explanation above.
>
>
>> As for the IPV6 6MAN questions, I was brought on board by Mike McBride as
>> the IPv6 SME as well as multicast SME - but point being member of 6MAN for
>> many years so a go between liaison with 6MAN related to any questions
>> regarding following the IPV6 specification for extension header usage per
>> RFC 8200.  Both solutions drafts had been reviewed by myself and 6MAN and
>> no technical issues were found regarding the solutions.
>>
>
> GS - Thank you.
>

    Gyan> Welcome

>
>
>> Alvaro mentioned as far as the list of requirements that they were fairly
>> basic but maybe needed some more meat behind it such as the “support
>> various L2 link types” but we did not specify.  In previous versions we
>> stated L2 agnostic and then switched to various but being vague on which
>> L2.  Alvaro also mentioned why OAM should be a requirement.  We may want to
>> add a sentence on justification as to why we picked BIER IPv6 requirements
>> as required versus optional.
>>
>> We need to add some more meat in the introduction or maybe even a
>> separate section as to what gap is being filled by non MPLS BIER in IPv6
>> environment using IPv6 encapsulation and encoding the BIER header versus
>> Non MPLS BIER Ethernet.  Also maybe use the requirements section to see if
>> a new requirement that maybe a gap that is not covered by non MPLS BIER
>> Ethernet that can be covered by non MPLS BIER in an IPv6 environment.
>>
>> At the end of the call when we rolled through the last two drafts and
>> went into overtime I heard the ask for call for adoption for BIERin6
>> independent model.
>>
>
> GS - Both v6 draft presentations asked for adoption. One of them had
> technical arguments for doing so. The other was list of grievances.
>

     Gyan> Understood and duly noted

>
>
>> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/
>>
>> I would not think we are ready to adopt any non MPLS BIER in IPV6
>> environment solution if we still do not have the requirements set as to the
>> gap that is being filed and problem being solved that cannot be done today
>> with non MPLS BIER Ethernet.
>>
>
> GS - Agree.
>

    Gyan> Agreed.  So to reiterate once we complete the requirements draft
and then if both fit the Bill of the requirements draft, we can ask for
Adoption of both drafts at once.

>
>
>> The flip side of the comment above is that if we are ready to adopt and
>> we decided we can skip answering the “why” questions, so then do we need
>> the requirements draft at all if that’s the case as we have made the
>> decision to go with a single solution and are closing the door on any other
>> options.  If the latter then we hang tight on any adoption of any solution
>> and wait till the requirements draft is completed and adopted followed by
>> moving forward with adopting any solutions.
>>
>
> GS - Agree. And my suggestion for new authors on the reqs draft still
> stands. I'm not demanding, I'm suggesting, based on the document's history.
> Your presentation of the history of the draft made it clear that there has
> been little direction, less clarity, and potentially an excessive amount of
> motivation to justify one solution over the other, leaving us with the
> mushy reqs draft we have today. Let's get this draft right, then we will
> have the guidance to address any potential solutions.
>

    Gyan> Agreed on all points.  I will captain and right the ship and get
out of muddy waters to a crystal clear draft that can provide concrete
guidance on a solution.   Please see my points above on the transitional
aspects of this solution and if in the end state we would use the existing
RFC 8296 Non MPLS BIER Ethernet in an IPV6 environment then that provides a
lot of clarity to the team as to direction.  So that million $$ question
goes away in essence as we have already answered our own question due to
transitional nature of this IPV6 environment solution we are developing now
with these two “non end state” transitional only solutions.

>
> Thanks,
> Greg
>
>
>> Kind Regards
>>
>> Gyan
>>
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+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