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

[Gyan Mishra <[e-mail]>]

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.

 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