Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

[Gyan Mishra <[e-mail]>]

On Thu, Mar 26, 2020 at 4:08 AM <[e-mail]> wrote:

> Hi Gyan,
>
>
> Thank you very much for your comments!
>
> Sorry for the late response.
>
> Please find my answer with [Sandy] inline. :-)
>
>
> Thanks,
>
> Sandy
>
>
> 原始邮件
> *发件人：*GyanMishra <[e-mail]>
> *收件人：*Tony Przygienda <[e-mail]>;
> *抄送人：*6MAN <[e-mail]>;BIER WG <[e-mail]>;张征00007940;
> *日 期 ：*2020年03月25日 08:36
> *主 题 ：**Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04*
> Tony & Sandy
>
> So is the idea proposed in the two drafts mentioned for BIER IPv6 support
> of encoding the BIER header up to 256 bit mask for BFER encoding schema
> supporting up to I believe 128 BFERs per set - to encode the BIER header
> into the DO EH -  and then for directly connected neighbor the outer header
> IPv6 encapsulation 1 hop tunnel used link local source and destination -
> for non directly connected neighbors IPv6 encapsulation use multi hop
> tunnel with GUI SA and DA.  In both tunnel cases being mutually exclusive
> the link local tunnel would have TTL 1 and multi hop would have appropriate
>  >1 ttl.
>
> So this is 2 different solutions for 2 different use cases.  Correct?
>
> [Sandy]: Sorry. No. The two solutions are used to solve one use case. And
> there is no relationship between the Bitstringlength in BIER header and the
> position in IPv6 header.
>
    Gyan> Ok.  The one use case is for being able to tunnel over hardware
not supporting BIER and so for that you have the two tunnel options.  The
two tunnel types are link local or GUA and both are multi hop tunnels -
Correct?

> If all the routers support ethernet type 0xAB37, the ethernet
> encapsulation will be used for BIER forwarding without IPv6 encapsulation.
>
But in fact, it takes time that all types of silicon chip to support BIER
> ethernet encapsulation. In the network which is IPv6-only, there are still
> some routers can't support BIER ethernet recognition.
>
> For these router which can support BIER forwarding in "software layer",
> not in "silicon layer", we need IPv6 encapsulation for BIER travelling.
>
> But some routers may not even support BIER forwarding in "software layer"
> (section 6.9, RFC8279), in order to travel across the these routers, tunnel
> with wider range address than LL is used.
>
> Gyan> So the crux of the issue is it may take some time for hardware to
> catch up to support BIER forwarding.
>
>
> ========================================================================================================================
> Just as with BIER IPv4 with BIER IPv6, the IGP extensions would flood the
> BIER info to build BIFT forwarding table to build the stateless MDT trees.
> In the case of SRv6 with disjoint BIER where traffic steering is required
> to signal SRV6 topology the last header would be set to TBD.  So that last
> header would in non SRv6 IPv6 topology the Last header would be the DO EH
> with the BIER header encoded. So with SRv6 how is the BIER header encoded?
> For SRv6 support I am guessing we have to update the programming draft for
> an end type sid instantiation flavor variation for a new BIER SID?
>
> [Sandy]: In fact, there is no relationship with SRv6 and BIER. But
> definitely they can be used together.
>
>    Gyan>. Understood

> I think you mean that we travel BIER packet across the non-BIER-capable
> routers with SRv6 forwarding, right?
>

     Gyan> Correct.

> In this case, the encapsulated packet is: IPv6 header+SRH EH+BIER
> header+payload.
>
> The only thing we need to do is define a new BIER EH. So in the Next
> header field of SRH, the BIER EH type indicates that there is a BIER packet
> which follows SRH.
>
    Gyan> Understood

> When the packet arrives the BIER-capable router which is also the last
> Segment in SRH, the BIER header will be executed correctly.
>
> So there is no need to apply for a new function for this case.
>
> Gyan> so then no update necessary for Programming draft.
>
>
> ======================================================================================================================
> I am just thinking comparing BIER for v4 to BIER for v6 is there any way
> you could accomplish the same with v6 and not do any IPv6 tunneling and
> just add the L 2 1/2 BIER header and propagate the BIER header info into
> the IGP to build the BIFT forwarding table just as you do with BIER v4.
> I can see for egress node BFER support the intermediate nodes and maybe
> even end  node may not have to support BIER - but now if tunneling is used.
>
> Is that the business justification for tunneling or maybe some other
> reason intrinsic to IPv6 I am missing.
> Am I totally off base??
>
> [Sandy]: Yes. If all the silicon chips support BIER ethernet recognition
> in the network, we do not need any tunneling.
>

    Gyan> Makes sense

> The IPv4/IPv6 BFR-prefix flooding in IGP is used to build BIER forwarding
> table. Tunnel is only used for travel across the non-BIER-capable router.
>

   Gyan> Understood

>
> Gyan
>
> On Sun, Mar 22, 2020 at 11:24 PM Tony Przygienda <[e-mail]>
> wrote:
>
>> That's a currently ongoing discussions between the auhtors (cc:'ing bier
>> as well)
>>
>> LL has advantages
>> * the packet cannot "escape" even if it has TTL > 1
>> * such a scheme can work purely with ND
>> * it's hard to "send out the wrong interface" albeit v6 allows AFAIR to
>> have same link local on multiple interfaces
>>
>> Originally the draft did not even allow for global addressing (since we
>> want to use v6 as L2-substitute here just like MPLS & non-MPLS
>> encapsulations are used in BIER) but this has a nice side effect of
>> allowing to "jump over non-BIER routers" if addressed to bier prefix (which
>> I personally think should be the only allowed global v6 used, otherwise we
>> may end up with BIER frames in funky places and possible "holes" in the
>> replication fabric). Obviously strictly speaking it's not necessary since
>> BIER can be carried in plethora of normal unicast tunnels  but bunch of
>> co-auhtors joined and the consensus was to allow it
>>
>> --- tony
>>
>>
>>
>> On Sun, Mar 22, 2020 at 8:15 PM <[e-mail]> wrote:
>>
>>> Hi Xuesong,
>>>
>>>
>>> Thank you for your question!
>>>
>>> The LL address is used by direct connected neighbor.
>>>
>>> For the neighbor which is not direct connected, the wider range address
>>> should be used.
>>>
>>>
>>> Thanks,
>>>
>>> Sandy
>>>
>>>
>>> 原始邮件
>>>
>> *发件人：*Gengxuesong(GengXuesong) <[e-mail]>
>>> *收件人：*张征00007940;[e-mail] <[e-mail]>;
>>> *日 期 ：*2020年03月23日 11:03
>>> *主 题 ：**RE: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04*
>>>
>> Hi Sandy and authors of draft-zhang-bier-bierin6:
>>>
>>>
>>>
>>> I have some questions about the section 2 when reading the draft. It is
>>> mentioned that:
>>>
>>> “If... The destination address in IPv6 header SHOULD be the neighbor's
>>> link-local address.
>>>
>>> Otherwise... the destination address SHOULD be the BIER prefix of the
>>> BFR neighbor.”
>>>
>>> Seems like the draft proposes 2 methods of IPv6 header encapsulation.
>>>
>>> Could these 2 methods be combined ? If not, what's the use case and
>>> design consideration for each method?
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Xuesong
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* ipv6 [mailto:[e-mail]]*On Behalf Of *
>>> [e-mail]
>>> *Sent:* Saturday, March 21, 2020 1:43 PM
>>> *To:* [e-mail]
>>> *Subject:* Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04
>>>
>>>
>>>
>> Hi,
>>>
>>> As co-author of BIERin6 (draft-zhang-bier-bierin6-04), before you read
>>> the draft, please let me introduce BIER technology to you at first:
>>>
>>> BIER technology, as defined in RFC8279, it's a new multicast technology.
>>> The principle is achieving multicast forwarding by hop-by-hop execution.
>>>
>>> BIER is a transport protocol, not just a function. As defined in
>>> RFC8296, BIER has it's own ethernet encapsulation with ethernet type
>>> 0xAB37, and also it can be travelled by MPLS encapsulation.
>>>
>>> BIER has it's own OAM function, ECMP function and traceability. etc.
>>> through BIER header defined in RFC8296.
>>>
>>>
>>>
>>> For travelling through IPv6 only enviroment, we'd like to travel BIER
>>> packet by IPv6 encapsulation.
>>>
>>> In draft-zhang-bier-bierin6-04, we want to just use a new Next Header
>>> type for BIER header carrying.
>>>
>>> We want to bring the minimum impact on IPv6 existed execution, and the
>>> maximum flexibility for header interoperability.
>>>
>>> So if you have any question about draft-zhang-bier-bierin6-04, or about
>>> BIER technology itself, please tell me. I'am glad to explain them to you.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Sandy
>>>
>>>
>>>
>> 原始邮件
>>>
>> *发件人：*TonyPrzygienda <[e-mail]>
>>>
>>> *收件人：*Michael McBride <[e-mail]>;
>>>
>> *抄送人：*[e-mail] <[e-mail]>;
>>>
>> *日 期 ：*2020年03月19日 01:12
>>>
>>> *主 题 ：Re: BIER in IPv6*
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>> <BIER WG chair hat on>
>>>
>>>
>>>
>>> The specific ask here is for the 6man to look over both drafts, i.e.
>>>
>>>
>>>
>>> draft-zhang-bier-bierin6
>>>
>>>
>>>
>>> and
>>>
>>>
>>>
>>> draft-xie-bier-ipv6-encapsulation
>>>
>>>
>>>
>>> and verify whether they conform to published IPv6 standards or raise
>>> objections/concerns.
>>>
>>>
>>>
>>> The requirements document is currently under active work/comments and
>>> does not represent any final or wide-consensus state so an opinion on its
>>> state is appreciated but it should not be used as any final or binding list
>>> of requirements as to the targeted solution in BIER WG
>>>
>>>
>>>
>>> thanks
>>>
>>>
>>>
>>> --- tony
>>>
>>>
>>>
>>> On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <
>>> [e-mail]> wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> The bier wg could use your ipv6 recommendations. We’ve worked on various
>>> solutions to transport a bier header in ipv6. We decided to pause and
>>> create a requirements document (draft-ietf-bier-ipv6-requirements) to help
>>> steer us towards the right solution(s). In that drafts appendix we have a
>>> fairly good summary of the various solutions.
>>>
>>>
>>>
>>> We’ve started to rally behind two solutions which meet the majority of
>>> the requirements: draft-xie-bier-ipv6-encapsulation (bier header in ipv6
>>> EH) and draft-zhang-bier-bierin6 (bier header as payload using ipv6 NH).
>>> The bier chairs today asked to punt the bierv6 topic to 6man for advice
>>> before adopting any of these solutions.
>>>
>>>
>>>
>>> So here we are seeking your advice. The most simple approach would
>>> probably be to give
>>> https://datatracker.ietf.org/doc/draft-ietf-bier-ipv6-requirements/ a
>>> look and scroll down to the appendix to see a summary of the various
>>> solutions we’ve been considering.
>>>
>>>
>>>
>>> thanks!
>>>
>>> mike
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]