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?
>

   Good catch!  Sorry I glanced over missed it!

>
>
> 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