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

Gyan Mishra <> Wed, 18 November 2020 22:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FB683A0DBA; Wed, 18 Nov 2020 14:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7eygwkY5sBYl; Wed, 18 Nov 2020 14:18:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A49E33A0D9B; Wed, 18 Nov 2020 14:18:58 -0800 (PST)
Received: by with SMTP id w4so2274760pgg.13; Wed, 18 Nov 2020 14:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Na/za6zoqxzW6oXvNnoeqiY5kG++X4J/6i5YvDmy+U8=; b=qCRVHUgzrfcUxe3Ln49g5Va7QSuw+JlYh1fhJDsMjf1orrylYOC6m6sZEJFXwpypdj BXllhpodF2pmTXj1Led5AiIpN2xG42KAnCVv30U2CPaq8U80KRqGlWrw+BT35s9YANty sh159BMVxoPWjRdekprkeigus82NEjr6PegJl8/C+MslkzPXKw+lkJT3JUn3mkcx++v7 oJzt55+6Jk+BZsu1lFXRsTYpvhUMBOzOc1/332ne0UZwY1po/265Ncnler8iAztdLjPj W4amQzSarNN8pFUfpX+50BJ+mpIHZq3Q2PvESE5JbeJUvycmYu2AjYugCcW23kcv68Wl jJww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Na/za6zoqxzW6oXvNnoeqiY5kG++X4J/6i5YvDmy+U8=; b=gUhVSSPh+H1dExJFY2u6jRKjwpOh4tE3gQSA6xloSfB4sUvhRylfzmHVLK6MwGS40L WCqg9AaQJj3fJlrt/NYl33Xzl5J1ulncm3if8EYqhP5n3cL8oU4zplkAoZDX438oFhEz XEGSG81N/nxDNg830YyjxNjXNzUuJ1W1+rmHBesr5aNgkpBj0m7AiKpdTvrHt9s9K+Ng SU8kWfVuWuWHzQPXUpgyU6WkzDAeT5MXONO6rmi8pURMWBGiWRffaJZ582cDSuKRRc7S o+ju6NLHd6KEcNPGf1nzEtupcidkdDuY6yUrrzQpcn1pNZ7I+0OeeAaoYnOGSt8P/Q6y xl8g==
X-Gm-Message-State: AOAM530fal1lyNa+p4w+1ArL7UWprkhka9YVRUA+TyKiCsS4ktPy/BaM vy+UZJXqIvGWhu0J5YkoGEpu7FGRWwKkQz7FkXQ=
X-Google-Smtp-Source: ABdhPJw+Y+IMWu/t5JCtsmiAlRlenrTzjWMPeUmgMc0Bq4F9qZ/xLZuIqLS156T9NLl48RQ9ian0y32QW+M0u1iNnn4=
X-Received: by 2002:a17:90a:178b:: with SMTP id q11mr1083912pja.132.1605737938001; Wed, 18 Nov 2020 14:18:58 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Wed, 18 Nov 2020 17:18:36 -0500
Message-ID: <>
To: "Jeffrey (Zhaohui) Zhang" <>
Cc: Alvaro Retana <>, BIER WG <>, "" <>, Greg Shepherd <>, Tony Przygienda <>, draft-ietf-bier-ipv6-requirements <>
Content-Type: multipart/related; boundary="000000000000662bf005b468ff16"
Archived-At: <>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Nov 2020 22:19:01 -0000

Hi Jeffrey

Please see in-line below

On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang <>

> Hi Gyan,
> Please see zzh> below.
> *From:* Gyan Mishra <>
> *Sent:* Wednesday, November 18, 2020 10:14 AM
> *To:* Alvaro Retana <>om>; BIER WG <>rg>;
> Greg Shepherd <>om>; Jeffrey (Zhaohui) Zhang <
>>gt;; Tony Przygienda <>om>;
> draft-ietf-bier-ipv6-requirements <
>>gt;; <
> *Subject:* draft-ietf-bier-ipv6-requirements-09
> *[External Email. Be cautious of content]*
> 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.
> 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.
> 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.  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.
> Zzh> First of all, the requirement draft does **not** mention SRv6 **at
> all**, and that’s a draft that have been worked on for almost two years.
     Gyan>As we worked on the revision 7 we did discuss SRv6, however we
did not add to the draft as a requirement because it’s supported today with
BIER Ethernet which is my point as to the “why” do we need Non MPLS BIER in
IPV6 environment.  Also in IPV6 environment since SRV6 uses the IPV6
forwarding plane there should not be any issue with it working.  We can
revisit if we want to add as a requirement and I think their is merit to

> Zzh> Secondly, SRv6 will still be on top of L2 links (whatever modern or
> graveyard L2 links). When BIER can work over L2 links directly, why bother
> add another layer.

     Gyan>Agreed.  That is my point why do we need IP encapsulation is the
big question we need to answer in the draft.

> Zzh> Finally, even if one wants to do SRv6 between BFIR and BFER just
> because SRv6 is taking over the world, it can be done with clean layering.
> Taking MVPN/EVPN with SRv6 as an example, you can first put on SRv6 header
> with a well-known multicast locator and a func/arg portion identifying the
> VPN. You can do fragmentation/ESP/whatever with it and then hand it to BIER
> for replication across the network, just like how you send an SRv6 packet
> across L2 links. This will avoid the problem of having to use the source
> address for identifying VPNs (I’ll follow up on my previous comments on
> draft-xie-bier-ipv6-mvpn).

    Gyan> Agreed.  We have to work on BIER IPv6 MVPN draft.

> Zzh> Notice that this transporting SRv6 multicast over BIER (L2.5) just
> like transporting SRv6 unicast over L2.
    Gyan> Agreed.  I don’t see any issue with SRv6 with BIERin6 independent

> Zzh> Then, when BIER needs to go over non-BFRs and IPv6 tunnels are used
> for that, BIER itself can be over IPv6 tunnels (just like over any other
> tunnels like MPLS or even L2TP if one will). That’s the beauty of clear and
> independent layering.
> Gyan> Agreed
> 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.
> Zzh> It’s more like why we need to require IP encapsulation.
>  Gyan> As IPv4 is being eliminated from the core as we speak with
> proliferation of IPv6 in the core even before SRv6,  LDPv6 and SR-MPLSv6
> the direction is softwire mesh framework v4 or v6 edge over a v6 core.  So
> if we are now or future it’s more like IPv6 not IP which implies IPv4
> implicitly but could mean either IPv4 or IPv6.  I have a draft in BESS that
> eliminates IPv4 at the edge using RFC 5549 next hop encoding vendor
> consortium of interoperability testing so IPv4 will be soon eliminated from
> P core and PE edge.

So that’s the million $$ question we are trying to solve here with the
> requirements draft.
> 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.
> Zzh> BIERv6 **can** be make to work, but at this time many of us are not
> convinced that it is needed, and it does have its complications (both at
> BIER layer itself and at flow overlay layer like with MVPN/EVPN – we can
> have separate discussion on that). There are many 6MAN people with
> different opinions – some say BIERv6 is good (from IPv6 point of view) and
> some others will point out its problems even just from IPv6 point of view
> (even when not considering BIER/MVPN).
> Gyan> I have discussed BIERv6 with many folks on 6MAN as well and the
> response is the solution is  sound no issues.  We can discuss on separate
> thread.
> 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.
> Zzh> I actually don’t think L2 link types is a key issue. Whatever modern
> L2 links that an operator wants to use, it’ll need to be supported both by
> IPv6 and BIER, and it is as simple as adding a codepoint for the L2 header
> to indicate whether the next header is IP/MPLS/BIER/whatever (again – the
> beauty of clear and independent layering).
>  Gyan> I don’t think Alvaro was saying there was any issue but just
> pointing out that we did not specify which link types.  We can discuss with
> authors what link types we should add explicitly.
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.
> Zzh> Shouldn’t we just list the requirements in the requirements section,
> and then evaluate different solutions using the requirements draft as
> guidance?
>  Gyan>  Greg and Tony can correct me but from what I heard is that we need
> to answer the “why” do we need Non MPLS BIER solution in an IPV6
> environment as we already have the L2 Non MPLS BIER Ethernet solution that
> will work for any next header encapsulation type and will support IPv6.  So
> that goes for any IPv6 environment solution including BIERin6 - why do we
> need it.  So I and some of the other authors agree that is missing so we
> need to add verbiage around that which is separate from the requirements
> section.
> 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.
> <;!!NEt6yMaO-gk!TOnu1Jmv8QPEdOl5pPzFJK-hl8nqGL6C2I94f4HdluKFdjsXQOc5-qph9Dk4t1B7$>
> 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.
> Zzh> After almost two years of requirement work, we’ve identified a set of
> mandatory/optional requirements. My presentation aims at showing that
> BIERin6 addresses all those requirements with the **existing** solution
> so it is good for the WG to adopt the mature solution, instead of leaving
> people an impression that we don’t have a solution.

     Gyan> Given what Greg and Tony stated as far as the requirements draft
as what is missing related to the “why” we need any IPv6 environment
solution I think “any” means any which include BIERin6.  We may need some
clarification from the chairs on this.

> Zzh> As for BIERv6, maybe after additional requirements work we’ll
> eventually agree that there is a need for it and then it could be adopted
> at that time. That should not block the progressing of BIERin6 until we
> find a need for BIERv6 😊
    Gyan> My POV is the requirements draft applies to both solutions on the
table.  So if we have not answered the why how can we have any solution let
alone adopt any.  It does sound like a setback but it could easily be a
quick silver lining that immediately moves both drafts to WG adoption.  I
think if we update the introduction section to answer the “why” question
and then maybe a round of cleanup of the requirements section I think we
can move the ball forward on the requirements draft and that would allow
both solutions drafts to adopted.

My take is I don’t think the BIERin6 is exempt from having to meet the
requirements laid out in the requirements draft which includes “why” have
we spent 2 years developing a solution which we don’t even know why we need
it.  I would say both solutions are in the same boat.

Zzh> With the above consideration, I would say the “suggested next steps”
> in my presentation is quite reasonable.
> Gyan> Let’s have the chairs and AD chime in on this thread.

> 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.
> Zzh> As I mentioned in my presentation, additional solutions can be
> pursued but only if they offer significant advantages. Otherwise, why
> should IETF/vendors/operators spend time on them? So we indeed have a “why”
> question – why BIERv6.
>  Gyan> Agreed.  But I still think we have the which comes first the
> chicken or the egg.  The chicken being BIERin6 or the egg being finalizing
> the requirements draft.  I am not trying to hold up BIERin6 from WG
> adoption but that is my take from the chairs.
> Zzh> Thanks.
> Zzh> Jeffrey
> Kind Regards
> Gyan
> --
> <,+MD?entry=gmail&source=g>
> [image: Image removed by sender.]
> <;!!NEt6yMaO-gk!TOnu1Jmv8QPEdOl5pPzFJK-hl8nqGL6C2I94f4HdluKFdjsXQOc5-qph9DU3E7y5$>
> *Gyan Mishra*
> *Network Solutions Architect *
> *M 301 502-1347 13101 Columbia Pike
> <,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <,+MD?entry=gmail&source=g>
> Juniper Business Use Only


*Gyan Mishra*

*Network Solutions A**rchitect *

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