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

[Gyan Mishra <[e-mail]>]

On Wed, Dec 2, 2020 at 4:29 PM Greg Mirsky <[e-mail]> wrote:

> Hi Adrian,
> you've said:
>
> This deployment case is somewhat niche: multicast is a bit rare, BIER is
> not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous,
> bridging over IPv6 is a subset of BIER.
>
> I've paused on the second sentence. As I understand it, BIER is designed
> specifically for multicast. Perhaps it is not yet as widely deployed
> comparing to the overall multicast deployments but I cannot name what else
> would benefit from BIER as much as multicast. Is my interpretation close to
> the idea of that sentence?
>

    My comment  on IPv6 not yet ubiquitous.

Granted IPv6 is not yet ubiquitous, however as the many benefits to be
realized with SRv6, operators are pushing fast to upgrade to RFC 5565
softwire mesh framework v4v6 edge over a v6 only core. As operators shift
there core to IPv6 over the next few years BIER x-PMSI MVPN over SRv6 core
will soon be ubiquitous and a reality.  We are not to far off from a
complete paradigm shift from v4 core to ubiquitous v6 core.  This will
happen much sooner then of course the actual proliferation of IPv6 traffic
worldwide which may take a lifetime.  Although with 5G and network slicing
that in itself will be a paradigm shift and also toward IPv6 only mobile
and fixed 5G.

>
>
> Regards,
> Greg
>
> On Mon, Nov 30, 2020 at 3:22 AM Adrian Farrel <[e-mail]> wrote:
>
>> Hey Jeffrey,
>>
>> It may be because I'm late to the discussion, but when you say...
>>
>> > With the above, there is simply no need for another solution in my view.
>>
>> ...this seems to suggest that there is already a solution.
>> AFAICS, while you might support only one of the two solutions, there are
>> two solutions. Neither has been adopted and neither has been "selected".
>>
>> You might have better phrased this as "this is simply no need for two
>> solutions." It might be true that most people agree with that, but since
>> they will only agree if their preferred solution is chosen, it is possibly
>> not very helpful.
>>
>> However, you go on...
>>
>> > Of course the WG can continue discussing BIERv6 and may determine that
>> it is
>> > nice to have BIERv6 as well, but we should not bundle them together
>> when it
>> > comes to adoption.
>>
>> ...which seems to suggest that you don't think it is harmful to discuss
>> two solutions.
>> Since the adoption of one on its own is likely to reduce the chances of
>> adoption of the other, not bundling the adoptions might be a little
>> simplistic. I am not proposing that we poll the adoption of either solution
>> first. Nor am I suggesting making it an either/or adoption poll.
>>
>> So how about this?
>>
>> - BIER has a history of starting with Experimental work and seeing how it
>> develops
>> - This deployment case is somewhat niche: multicast is a bit rare, BIER
>> is not widely deployed for multicast, IPv6 is still (sadly) not ubiquitous,
>> bridging over IPv6 is a subset of BIER.
>> - Why not adopt both approaches as Experimental and set some clear terms
>> for the experiment?
>>
>> Cheers,
>> Adrian
>>
>> -----Original Message-----
>> From: BIER <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang
>> Sent: 28 November 2020 21:54
>> To: Michael McBride <[e-mail]>; [e-mail]
>> Cc: BIER WG <[e-mail]>; Gyan Mishra <[e-mail]>;
>> draft-ietf-bier-ipv6-requirements <
>> [e-mail]>; [e-mail] <
>> [e-mail]>; Alvaro Retana <[e-mail]>
>> Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
>>
>> To clarify, there is no gap in the BIERin6 solution (besides the new
>> "next header" code point). It's just that some text are needed to explain
>> how the requirements are met with the BIERin6 solution - whether it is a
>> requirement already listed in the current requirements draft, or have been
>> brought up in recent mailing list discussions (I know of two in recent
>> discussions).
>>
>> BIERin6 is based on RFC 8296 (plus the new "next header" code point for
>> IPv6 encapsulation), and is a generic solution with the following
>> properties:
>>
>> 1. clean layering - BIER over L2/tunnel and it can carry different
>> payload types including SRv6
>> 2. IPv4/IPv6 independent (of course you need different signaling)
>> 3. L2 independent - as long as the L2 header can indicate with a code
>> point that a BIER header follows
>> 4. tunnel type independent - as long as the tunnel header can indicate
>> with a code point that a BIER header follows
>> 5. can work one-hop or multi-hop tunnels nicely
>> 6. can work with SRv6 based services nicely
>>
>> With the above, there is simply no need for another solution in my view.
>> Of course the WG can continue discussing BIERv6 and may determine that it
>> is nice to have BIERv6 as well, but we should not bundle them together when
>> it comes to adoption. That's why I suggested in the last BIER session the
>> following:
>>
>> - Adopt BIERin6
>> - Discuss BIERv6 further
>>
>> Jeffrey
>>
>> -----Original Message-----
>> From: Michael McBride <[e-mail]>
>> Sent: Saturday, November 28, 2020 2:15 PM
>> To: [e-mail]; Jeffrey (Zhaohui) Zhang <[e-mail]>
>> Cc: Gyan Mishra <[e-mail]>; Alvaro Retana <
>> [e-mail]>; BIER WG <[e-mail]>;
>> [e-mail] <[e-mail]>; Tony Przygienda <
>> [e-mail]>; draft-ietf-bier-ipv6-requirements <
>> [e-mail]>
>> Subject: RE: draft-ietf-bier-ipv6-requirements-09
>>
>> [External Email. Be cautious of content]
>>
>>
>> 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 <
>> [e-mail]>
>> 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 <[e-mail]>
>> > *Sent:* Monday, November 23, 2020 1:32 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
>> >
>> >
>> >
>> > *[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 <
>> > [e-mail]> wrote:
>> >
>> > Gyan,
>> >
>> >
>> >
>> > Please see zzh6> below.
>> >
>> >
>> >
>> > *From:* Gyan Mishra <[e-mail]>
>> > *Sent:* Sunday, November 22, 2020 9:49 PM
>> > *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
>> >
>> >
>> >
>> > *[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 <
>> > [e-mail]> wrote:
>> >
>> > Hi Gyan,
>> >
>> >
>> >
>> > Yes I believe we’ve reached consensus.
>> >
>> >
>> >
>> > Please see zzh5> below about some details.
>> >
>> >
>> >
>> > *From:* Gyan Mishra <[e-mail]>
>> > *Sent:* Sunday, November 22, 2020 4:19 PM
>> > *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
>> >
>> >
>> >
>> > *[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://urldefense.com/v3/__https://nam11.safelinks.protection.outloo
>> > k.com/?url=https*3A*2F*2Furl__;JSUl!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetp
>> > u3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PLU1AClK$
>> > 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://urldefense.com/v3/__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__;JSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XqcOU1H95lz8ueSP2Cetpu3B5ldFgwQpw2JZW7s_KsspK1DsMPGcaKe-PHwxls5N$
>> >.
>> > 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
>>
>> Juniper Business Use Only
>> _______________________________________________
>> BIER mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>> _______________________________________________
>> BIER mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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