Re: [Bier] What does BIERin6 propose to satisfy the requirements? //RE: draft-ietf-bier-ipv6-requirements-09

[Gyan Mishra <[e-mail]>]

On Wed, Nov 25, 2020 at 10:29 AM Gyan Mishra <[e-mail]> wrote:

>
> Please see Gyan2>
>
> On Wed, Nov 25, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <
> [e-mail]> wrote:
>
>> Please see zzh> below.
>>
>> -----Original Message-----
>> From: Xiejingrong (Jingrong) <[e-mail]>
>> Sent: Tuesday, November 24, 2020 10:27 PM
>> To: Gyan Mishra <[e-mail]>; Jeffrey (Zhaohui) Zhang <
>> [e-mail]>
>> Cc: BIER WG <[e-mail]>
>> Subject: What does BIERin6 propose to satisfy the requirements? //RE:
>> draft-ietf-bier-ipv6-requirements-09
>>
>> [External Email. Be cautious of content]
>>
>>
>> (to make clean, raise a new topic)
>>
>> I am confused too by the claiming a solution can do everything and it is
>> an "existing" solution, while requesting allocation of IPv6 Next Header /
>> IPv4 Protocol value which is non-trivial.
>>
>> Zzh> Comparing requesting a "next header" value for BIER, and specifying
>> an IPv6 DOH to encode BIER and standardizing draft-xie-bier-ipv6-mvpn,
>> which is more trivial?
>
>
>     Gyan2> BIERv6 follows RFC 8200 specification in using DOH to encode
> BIER for hop by hop en route processing.  MPLS BIER has an RFC 8556 for
> MVPN even though it follows standard MVPN procedures RFC 6513 6514.  Non
> MPLS BIER is not any different in that respect but also requires as in IPv6
> environment uses SRv6 BGP Overlay Service.  I think BIERin6 would require a
> draft as well for the optional IPv6 encapsulation for SRv6 environment as
> well.
>
>>
>> Zzh> I want to point out that w/o draft-xie-bier-ipv6-mvpn, BIERv6 is not
>> complete.
>
>
>     Gyan> In fact MVPN we all agreed is not a requirement as BIER can be
> used for single tenant global table multicast GTM as well.
>
>>
>>
>> We need to know, what does *the* BIERin6 draft propose, and how does
>> *the* BIERin6 draft satisfy the bier-ipv6-requirements.
>
> Take req-1 as an example, suppose there are PPP-over-SONET(POS, RFC2615)
>> links in an IPv6 network, can the existing RFC8296 solve ? What does *the*
>> BIERin6 draft propose to solve ?
>>
>> Zzh> How does IP work with POS? PPP header has a proto field - a new code
>> point would be assigned for BIER. That is not IPv6 specific.
>
>
>     Gyan2> Jingrong’s point is that when BFRs do not use L2 Ethernet
> “already defined solution” in RFC 8296, is when BIERin6 should be used is
> which defined IPv6 encapsulation one hop tunnels. The MAJOR problem we have
> with including an existing solution RFC 8296 L2 “Non MPLS BIER Ethernet” is
> that it is existing and thus overshadows a need for for IPv6 encapsulation
> and to use existing solution and as written in BIERin6 that IPv6
> encapsulation is “optional”.  Why should IPv6 encapsulation be optional
> with BIERin6?  The latter L2 solution has existed since Day 1.  We are
> defining a new solution for IPv6 environment with BIERin6.  The case and
> point here is that most operators in the last 15 years have decommissioned
> all TDM based with Metro Ethernet services.  So in essence with draft
> BIERin6 the way it is written IPv6 encapsulation single hop or multi hop
> tunnels would never be used by operators.
> So then you might as well remove IPv6 encapsulation from the draft as it’s
> an option that would never be used.  Once you do that you are left with RFC
> 8296 use case informational draft and questionable if that is even
> necessary.
>
> The way BIERin6 is written today it would be very difficult to advance for
> WG adoption.
>
>>
>>
>> Please note in my question the word *the* does not include anything that
>> RFC8296 can solve. Any existing RFC8296 solution is not belonging to *the*
>> BIERin6 proposal. Please tell us *the* BIERin6 proposal.
>>
>> Zzh> *The* BIERin6 proposal is BIER over L2 and/or tunnels (IPv6 or not).
>> In case of IPv6 tunnels, new code points are needed and that's why it needs
>> to be on standards track, as I already explained.
>
>
>     Gyan> The way it’s written IPv6 encapsulation one hop tunnels would
> never be used by operators as it’s overshadowed by RFC 8296.  The way
> BIERin6 reads it as L2 RFC 8296 can be used for multi hop funnels in case
> of Non BFRs as well.  Even if the operator requires BIER to be carried in
> IPv6 it would be doubtful that would get utilized for one hop tunnels as
> it’s easier to just use RFC 8296 L2 for one hop or tunnel.  In essence the
> IPV6 encapsulation would never be used by operators with BIERin6.
> If you think about it BIERIn6 is by definition an oxymoron.  Reason being
> is that with RFC 8296 included as part of BIERin6, BIER header is the outer
> envelope encapsulation so it would be more accurate to say “BIERout6” as
> IPv6 is the payload of BIER in L2 RFC 8296.  The only relevant piece that
> makes sense in every way to be part of BIERin6 is “in” being the keyword
> where the outer encapsulation is IPv6 and BIER is next header thus the “in”
> in BIERin6.
>
>>
>> Zzh> I had also explained already, why BIERin6 needs to explicitly spell
>> out using *existing* solution (concept, not code point) for IPv6 network -
>> we've wasted two years on this.
>
>
>     Gyan> Well hopefully we don’t waste another 2 year on BIERin6 or I
> guess really should be called BIER-in-out-6.
>

      Gyan2> Another clever way to look at is that BIER-in-out-6 is a way
to squash IPv6 encapsulation with smoke and mirrors as if a there is in a
pretentious way a néw solution is being developed, where in essence we are
actually quite the contrary, as this is the trickery game  “optional”
verbiage to provide a lead on “carrot” if you will that IPv6 encapsulation
is in the spec but really in all truthfulness let it be told the spec is
really BIERout6.

>
>  I am not in favor of adoption of  BIERin6 the way the draft is written
> today.  We really have to remove the references to RFC 8296 to make this
> draft even viable.
>
>>
>>
>> Thanks
>> Jingrong
>>
>> -----Original Message-----
>> From: Gyan Mishra [mailto:[e-mail]]
>> Sent: Wednesday, November 25, 2020 9:34 AM
>> To: Jeffrey (Zhaohui) Zhang <[e-mail]>
>> Cc: Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>;
>> [e-mail] <[e-mail]>; Tony Przygienda <
>> [e-mail]>; draft-ietf-bier-ipv6-requirements <
>> [e-mail]>; [e-mail]
>> Subject: Re: draft-ietf-bier-ipv6-requirements-09
>>
>> Jeffrey
>>
>> About the two lingering points it does shed light on something that has
>> been disturbing me with the BIERin6 solution.
>>
>>
>> I thought about this some more and I think what creates a lot of
>> confusion in my mind with BIERin6 solution is the L2/tunnel component.
>>
>> As the main reason is that the L2/tunnel exists today with RFC 8296 “Non
>> MPLS BIER Ethernet” with the special allocated next header code point to
>> account for BIER next header 0xAB37.
>>
>> I honestly think the L2 should be removed from the BIERin6 draft so that
>> the optional IPV6 encapsulation is no longer “optional” in the draft as
>> that now is the draft.
>>
>> This also provides the “IPv6 encapsulation” commonality with BIERv6 at
>> least showing clearly that their is a strive for commonality and parity
>> between the two solutions.
>>
>> Also the “muddying” of the water is eliminated by removing L2 making the
>> solution crystal clear to operators.
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>> Juniper Business Use Only
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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