Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

[Tony Przygienda <[e-mail]>]

concur, I see a longish discussion there ...

My usual prescient co-chair arranged accordingly I see ;-)

--- tony


On Tue, Jul 16, 2019 at 1:01 PM Greg Shepherd <[e-mail]> wrote:

> Thanks Mike. That's exactly what I had in mind. Take a look at the draft
> agenda I just sent.
>
> On Tue, Jul 16, 2019 at 12:17 PM Michael McBride <
> [e-mail]> wrote:
>
>> We better ask for a bit more time for bier-ipv6-requirements discussion
>> then. Perhaps put it at the end again and we will use whatever time is
>> available. I’ll lead it.
>>
>>
>>
>> Thanks,
>>
>> mike
>>
>>
>>
>> *From:* Tony Przygienda <[e-mail]>
>> *Sent:* Tuesday, July 16, 2019 8:29 AM
>> *To:* Xiejingrong <[e-mail]>
>> *Cc:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Senthil Dhanaraj <
>> [e-mail]>; BIER WG <[e-mail]>;
>> [e-mail]; Antoni Przygienda <[e-mail]>;
>> Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>
>> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>>
>>
>>
>> To close this thread the discussion needs to focus on the requirements
>> draft during IETF and on this mailing list first and we see what comes out
>> of that and accordingly the drafts will evolve ...
>>
>>
>>
>> I have many observations towards the req' draft and I expect a lively
>> discussion. If I find time I may fire off something to the list before IETF
>> along those lines ...
>>
>>
>>
>> thanks
>>
>>
>>
>> --- tony
>>
>>
>>
>> On Tue, Jul 16, 2019 at 3:31 AM Xiejingrong <[e-mail]>
>> wrote:
>>
>> Sorry, the picture didn’t show in the list.
>>
>> I re-write in text:
>>
>>
>>
>> -------Solution Using NH=BIER (draft-zhang-bier-bierin6)-------
>>
>> Result = FIB Lookup(DA)                            //Step 0
>>
>> Switch(Result)
>>
>>   Case Local Interface IPv6 Address:               //Step 1
>>
>>     If packet is (NH=BIER)                         //Step 2 (*A*)
>>
>>         Process it
>>
>>     Else if packet is (NH=a/b/c/d & Last_NH=BIER)  //Step 3
>>
>>         Process it
>>
>>     Else If packet is (NH=XXXX)                    //Step 4 (*B*)
>>
>>         Process it
>>
>>     Else if packet is (NH=a/b/c/d & Last_NH=XXXX)  //Step 5
>>
>>         Process it
>>
>>     Else If packet is (NH=YYYY)                    //Step 6 (*C*)
>>
>>         Process it
>>
>>     Else if packet is (NH=a/b/c/d & Last_NH=YYYY)  //Step 7
>>
>>         Process it
>>
>>     Else
>>
>>         Do normal things as usual                  //Step 8 (*D*)
>>
>>   Case Non-Local Routable IPv6 Address
>>
>>       Do normal routing and forwarding as usual.
>>
>>
>>
>> (A) need 2~3 steps!
>>
>> (B) need 4~5 steps!
>>
>> (C) need 6~7 steps!
>>
>> (D) need 8 steps!
>>
>>
>>
>>
>>
>> -------Solution Using EH and
>> End.BIER(draft-xie-bier-ipv6-encapsulation)-------
>>
>> Result = FIB Lookup(DA)                                   //Step 0
>>
>> Switch(Result)
>>
>>   Case End.BIER:                                          //Step 1
>>
>>     IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4  //Step 2(A)
>>
>>          Process it
>>
>>     ELSE IF (NH=ICMPv6) or (NH=60 and Dest_NH=ICMPv6)
>>
>>          Send to CPU.
>>
>>     ELSE
>>
>>          Drop the packet.
>>
>>   Case End.XXXX:                                         //Step 1
>>
>>     IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4 //Step 2(B)
>>
>>         Process it
>>
>>     ELSE
>>
>>         Drop the packet
>>
>>  Case End.YYYY:                                          //Step 1
>>
>>     IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4 //Step 2(C)
>>
>>         Process it
>>
>>     ELSE
>>
>>         Drop the packet
>>
>>   Case Local Interface IPv6 Address:                     //Step 1
>>
>>         Do normal things as usual                        //Step 2(D)
>>
>>   Case Non-Local Routable IPv6 Address
>>
>>         Do normal routing and forwarding as usual.
>>
>>
>>
>> (A) need 2 steps!
>>
>> (B) need 2 steps!
>>
>> (C) need 2 steps!
>>
>> (D) need 2 steps!
>>
>>
>>
>>
>>
>> -------Repeat the advantages-------
>>
>> The least impact:  Switch-case by preceding FIB lookup doesn’t impact
>> other cases.
>>
>> The most efficient:  Do not need walking through EH ---- only check the
>> first EH.
>>
>> The most extensible to support features in the future:   Combine with
>> Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER
>> TLVs in a single Destination Options header. etc.
>>
>>
>>
>> Thanks
>>
>> Jingrong.
>>
>>
>>
>> *From:* BIER [mailto:[e-mail]] *On Behalf Of *Xiejingrong
>> *Sent:* Tuesday, July 16, 2019 5:29 PM
>> *To:* Tony Przygienda <[e-mail]>; Jeffrey (Zhaohui) Zhang <
>> [e-mail]>
>> *Cc:* Senthil Dhanaraj <[e-mail]>; BIER WG <
>> [e-mail]>; [e-mail]; Antoni Przygienda <
>> [e-mail]>; Jeffrey (Zhaohui) Zhang <zzhang=
>> [e-mail]>
>> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>>
>>
>>
>> Hi Tony, Jeffrey:
>>
>> Let’s f2f in BIER session at Montreal.
>>
>> Here is a page I think useful to understand the difference between
>> Layer-4 solution(left) and Layer-3 solution(right).
>>
>> That’s why I think use of a preceding End.BIER is most efficient (for
>> BIER forwarding), least impact (to exist functions), and most extensible
>> for future functions.
>>
>>
>>
>> The least impact:  Switch-case by preceding FIB lookup doesn’t impact
>> other cases.
>>
>> The most efficient:  Do not need walking through EH ---- only check the
>> first EH.
>>
>> The most extensible to support features in the future:   Combine with
>> Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER
>> TLVs in a single Destination Options header. etc.
>>
>>
>>
>> Thanks
>>
>> Jingrong
>>
>>
>>
>> *From:* Tony Przygienda [mailto:[e-mail] <[e-mail]>]
>>
>> *Sent:* Monday, July 15, 2019 11:58 PM
>> *To:* Xiejingrong <[e-mail]>
>> *Cc:* Senthil Dhanaraj <[e-mail]>; Jeffrey
>> (Zhaohui) Zhang <zzhang=[e-mail]>; BIER WG <
>> [e-mail]>; [e-mail]; Antoni Przygienda <
>> [e-mail]>
>> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jul 15, 2019 at 12:39 AM Xiejingrong <[e-mail]>
>> wrote:
>>
>> Please see my comments below:
>>
>>
>>
>> *From:* Tony Przygienda [mailto:[e-mail]]
>> *Sent:* Monday, July 15, 2019 3:04 PM
>> *To:* Senthil Dhanaraj <[e-mail]>
>> *Cc:* Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>;
>> Xiejingrong <[e-mail]>; BIER WG <[e-mail]>;
>> [e-mail]; Antoni Przygienda <[e-mail]>
>> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>>
>>
>>
>> if your router can do BIER fast path IPv6 is not an interesting option no
>> matter which draft.
>>
>> [XJR] That’s not true. The interest in BIER-IPv6-fast-path is strong.
>> There is no problem of “interest” or “requirement”. The problem is the lack
>> of convinced  “technology” or “solution”.
>>
>>
>>
>> enlighten me where you saw that except being personally convinced it's
>> cool ... And what is the specific reason customer would want that
>> complexity/cost of v6 option processing silicon compared to ether/mpls
>> encaps.
>>
>>
>>
>> one would either carry native ether or MPLS rather than trying to build
>> IPv6 fast path with header options @ arbitrary place,
>>
>> probably misaligning bitmasks and ultimately forcing 4K buffers on v6
>> option processing in silicon which may be fun but it is expensive, complex
>> fun.
>>
>> [XJR] The proposals are not as good as expected,  or could not do it in a
>> simple and inexpensive way! I guess this is the point.
>>
>>
>>
>> yupp. MPLS/Ether will be as inexpensive as it can be and shares same
>> processing block.
>>
>>
>>
>> [XJR] Well I think, using a preceding BIER-Specific IPv6 Address in IPv6
>> DA can solve the problem perfectly.
>>
>> [XJR] This is the way SRv6/SRH do, *which first introduces the fast-path
>> processing of extension header*, without recognition the pattern of the
>> EHs and the TLVs, but simply ‘process the desired packet, and drop the
>> undesired packet’!
>>
>>
>>
>> BIER is neither SRv6 nor SRH so your point here is?
>>
>>
>>
>> BIER is a L2.5 hop-by-hop multicast switching technology that should be
>> tunneled otherwise. v6 enaps (where we really abuse v6 as L1 transport) is
>> only justified if ether/mpls cannot be implemented but chips can do very
>> simple v6 processing and there is not high throughput requirement (albeit
>> one could build bierin6 fast-path in silicon obviously). Obviously bierin6
>> gives you the nice trick to tunnel it to a v6 destination without
>> establishing a real tunnel but it's really just a by-product and not its
>> main goal
>>
>>
>>
>> --- tony
>>
>>
>>
>> _______________________________________________
>> BIER mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>