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

[Senthil Dhanaraj <[e-mail]>]

Hi Tony,
Pls see my comments inline !
Thanks,
Senthil

On Mon, Jul 15, 2019 at 12:34 PM Tony Przygienda <[e-mail]>
wrote:

> if your router can do BIER fast path IPv6 is not an interesting option no
> matter which draft.
>
SEN1// Why not? ref SRv6/SRH - could successfully do fast-path with IPv6 ?


> 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.
>
SEN1// Not at arbitrary places. draft-xie-bier-ipv6-encapsulation does
define some rules and assumption. We can continue to discuss and define the
rules/assumptions to facilitate fast path forwarding at chip. But
completely ruling out the presence of any EH in IPv6 BIER packet altogether
(or) ignoring the advantages brought by NP paradigm is harsh ?

if a router cannot do native fast path BIER but it can do simple v6 then it
> needs to throw off to slow-path and that is scenario on lots of low-end
> silicon in Wi-Fi and so on where multicast is needed but throughput does
> not have to be necessarily high.
>
SEN1// Agreed that, low cost devices, home networks does not require high
throughput and draft-zhang-bier-bierin6 could be an option for such
deployments. But again, even for such deployments we need to crack the
limitations (listed in my previous mail) that arises out of using "BIER as
payload of L3" ? Pls do let us know your thoughts.


> And yes, one could build v6 hop-by-hop tunnels everywhere to tunnel BIER
> over hop-by-hop without any drafts needed but obviously one can implement
> it simpler just like the market is liking the simplicity of v4ov6
> forwarding without tunnels ...
>
> --- tony
>
>
>
> On Sun, Jul 14, 2019 at 11:15 PM Senthil Dhanaraj <
> [e-mail]> wrote:
>
>> Hi Jeffrey, Jingrong, et.al
>>
>> The way IPv6 header [RFC8200] is defined, i believe we *cannot avoid*
>> walking through & process the chain of EHs in IPv6.
>> At best, what we can do (which is what i believe today's CHIP's do is),
>>
>> If NH=X -> process in fast path defined for hdr-type=x
>> else       -> process in slow path  (or drop - bad?)
>>
>> Above technique can be applied to both draft-zhang-bier-bierin6 &
>> draft-xie-bier-ipv6-encapsulation.
>>
>> Besides above, below are some of the broader points considered for
>> comparison, that are discussed with Tony/Ice/Sandy/.. during the course of
>> & after ietf104.
>> Sharing it in the list and we shall continue to discuss on the pros &
>> cons.
>>
>> *1. Change of source-address at each hop*
>>
>> draft-zhang-bier-bierin6:
>> Considering BIER as an L4 header, we are required to modify the source
>> address at each hop.
>> Loss of original source address (BFIR's SA) might impact source address
>> based filtering policies applied if any, breaks ICMP6 based error reporting
>> back to source etc
>> Yes, BFIR(source) can be identified from the bfir-id in BIER header.
>> But we may need to consider the cases where in the ICMP6 error packet
>> needs to be initiated by an non-BIER router based on IPv6 header alone.
>>
>> draft-xie-bier-ipv6-encapsulation:
>> RFC8200 allows us to change the content of a TLV (which is part of
>> extension header) without having to require changing the source-address.
>>
>> *2. Presence of AH/ESP headers*
>>
>> draft-zhang-bier-bierin6:
>> Requires re-hash(AH), re-encrypt(ESP) at each hop
>>
>> draft-xie-bier-ipv6-encapsulation:
>> Does not require hop-by-hop processing. Possible to employ E2E IPsec
>> protection..
>>
>> *3. Fragmentation*
>>
>> draft-zhang-bier-bierin6:
>> Requires hop-by-hop re-assembly and fragmentation ?
>> But IPv6 requires that only source node MUST fragment the packet &
>> intermediate nodes cannot fragment.
>> For draft-zhang-bier-bierin6, we shall consider that each hop
>> re-originates the packet (with self as source) and fragment afresh.
>> Again, this reminds us that, we cannot avoid changing the source address
>> of packet at each hop (point 1).
>>
>> draft-xie-bier-ipv6-encapsulation:
>> Does not require hop-by-hop fragmentation / re-assembly
>>
>> *4. Network programming *
>> (ex: See draft-xie-bier-ipv6-mvpn, Use FUNC part to identify the
>> vpn-instance instead of using MPLS style service labels)
>>
>> draft-zhang-bier-bierin6:
>> Because the source-address is required to change at each hop, we cannot
>> use this technique?
>>
>> draft-xie-bier-ipv6-encapsulation:
>> Can support.
>>
>> Thanks,
>> Senthil
>>
>> On Sat, Jul 13, 2019 at 5:48 AM Jeffrey (Zhaohui) Zhang <zzhang=
>> [e-mail]..org <[e-mail]>> wrote:
>>
>>> Let me ask it this way:
>>>
>>>
>>>
>>> What’s the difference between the following situation:
>>>
>>>
>>>
>>>    1. <some hop-by-hop or destination option hdr, NH=BIER> (per
>>>    draft-zhang-bier-bierin6-03)
>>>    2. <same hop-by-hop or destination option hdr, NH=<undefined> (per
>>>    RFC8200)
>>>
>>>
>>>
>>> If you have concern with #1, wouldn’t you have the same concern with #2?
>>>
>>>
>>>
>>> Jeffrey
>>>
>>>
>>>
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> *From:* Xiejingrong <[e-mail]>
>>> *Sent:* Friday, July 12, 2019 8:10 PM
>>> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Antoni Przygienda <
>>> [e-mail]>; [e-mail]; BIER WG <
>>> [e-mail]>
>>> *Subject:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>>>
>>>
>>>
>>> Pls See comments inline:
>>>
>>> *发件人：*Jeffrey (Zhaohui) Zhang <[e-mail]>
>>>
>>> *收件人：*Xiejingrong <[e-mail]>;Antoni Przygienda <
>>> [e-mail]>;[e-mail] <
>>> [e-mail]>;BIER WG <[e-mail]>
>>>
>>> *时间：*2019-07-13 07:43:22
>>>
>>> *主 **题：*RE: Questions regarding
>>>
>>>
>>>
>>> Please see zzh> below.
>>>
>>> Juniper Business Use Only
>>>
>>> *From:* Xiejingrong <[e-mail]>
>>> *Sent:* Friday, July 12, 2019 7:34 PM
>>> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Antoni Przygienda <
>>> [e-mail]>; [e-mail]; BIER WG <
>>> [e-mail]>
>>> *Subject:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>>>
>>> Hi Jeffrey,
>>>
>>> Please see my comments inline below
>>> ------------------------------
>>>
>>> *发件人**:* Jeffrey (Zhaohui) Zhang [[e-mail]]
>>> *发送时间**:* 2019年7月12日 22:27
>>> *收件人**:* Xiejingrong; Antoni Przygienda;
>>> [e-mail]; BIER WG
>>> *主**题**:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>>>
>>> I don’t have a good understanding about the writing in the latest email
>>> below, but for the following original comment that led to it:
>>>
>>> ·        [XJR Q6]: You have to walk the ext header chain and get the
>>> last NH to judge if this packet need to be discard, right? For example for
>>> an incoming packet(ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>), you have to
>>> walk the whole extension header chain until you know the last NH, to
>>> execute the above “discard” action. Right?
>>>
>>> What is the problem with that? This document is saying that for BIER
>>> packets, the only header that is expected is the TBD (for BIER) and
>>> otherwise you drop it. Normally, you would not have the
>>> (ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>) situation.
>>>
>>> [XJR] This document also said the following.
>>>
>>>  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').
>>>
>>> If the concern is that someone could maliciously inject that kind of
>>> packets for the purpose of slowing down a targeted BFR, then any of the
>>> following situation in RFC8200, independent of BIER, will have the same
>>> effect:
>>>
>>> [XJR] Right. There is also concern of injection of packets to slow down
>>> a targeted BFR. That may not the below case listed in RFC8200.
>>>
>>> Zzh> The RFC8200 text that I quoted would have the same concern – that’s
>>> my point and it’s not BIER specific. In other words, some one could
>>> maliciously construct some NON-BIER IPv6 packets with certain headers and
>>> slow down a router. Your concern with this draft would exist with RFC8200
>>> as well.
>>>
>>> [XJR] rfc8200 doesn't assume specific NH like BIER be processed in fast
>>> path. In real world, packets with any extension headers may be sent to CPU
>>> without "digging out some bier specific patterns and processing specially"
>>> and CPU can do that. They are always slow but doesn't walk the chain in
>>> chips.
>>>
>>> Jingrong
>>>
>>>
>>>
>>> Zzh> Jeffrey
>>>
>>> Also, there are concerns of flexibility as my comments before.
>>>
>>> For example:
>>>
>>> BIER may want to process a packet with IPv6 NH=BIER in fast-path, and
>>> drop IPv6 NH=xxx and Last_NH=BIER.
>>>
>>> BIER may want to process a packet with IPv6 NH=BIER or IPv6 NH=RH and
>>> RH_NH=BIER in fast-path, and drop IPv6 NH=xxx and Last_NH=BIER.
>>>
>>> a new feature, let's say REIB may have the similar requirements:
>>>
>>> REIB may want to process a packet with IPv6 NH=REIB in fast-path, and
>>> drop IPv6 NH=xxx and Last_NH=REIB.
>>>
>>> REIB may want to process a packet with IPv6 NH=REIB or IPv6 NH=RH and
>>> RH_NH=REIB in fast-path, and drop IPv6 NH=xxx and Last_NH=REIB.
>>>
>>> then I guess a lot of "walking through the EH chain" have to be executed
>>> like [XJR Q8].
>>>
>>> Thanks,
>>>
>>> Jingrong
>>>
>>>   If, as a result of processing a header, the destination node is
>>>
>>>   required to proceed to the next header but the Next Header value in
>>>
>>>   the current header is unrecognized by the node, it should discard the
>>>
>>>   packet and send an ICMP Parameter Problem message to the source of
>>>
>>>   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
>>>
>>>   type encountered") and the ICMP Pointer field containing the offset
>>>
>>>   of the unrecognized value within the original packet. The same
>>>
>>>   action should be taken if a node encounters a Next Header value of
>>>
>>>   zero in any header other than an IPv6 header.
>>>
>>> Jeffrey
>>>
>>> *From:* Xiejingrong <[e-mail]>
>>> *Sent:* Friday, July 12, 2019 7:20 AM
>>> *To:* Antoni Przygienda <[e-mail]>; Jeffrey (Zhaohui) Zhang <
>>> [e-mail]>; [e-mail]; BIER WG <
>>> [e-mail]>
>>> *Subject:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>>>
>>> Hi Tony,
>>>
>>> Exactly, the whole v6 extension headers(EH) and the v6 options
>>> consideration is basically a first stab!
>>>
>>> Once a judgement is based on the “Upper-layer Protocol”, the last next
>>> header of a chain, then a walk through the chain is unavoidable, to “dig
>>> out” the right format that need to be processed in fast-path.
>>>
>>> The difficulty with a “regular” IPv6 DA is that, normal things like
>>> TCP/UDP/ICMPv6 packet must be handled without much impact on it.
>>>
>>> Use a “XXX specific IPv6 DA” is not only the SRv6-NetworkProgramming
>>> concept, but also the ISO NSAP address as I learned from a book and found
>>> in the WIKI https://en.wikipedia.org/wiki/NSAP_address
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_NSAP-5Faddress&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=Rh1tyYzDzhRq7ymA_JEJduNT94j_xiGhiQ-QgbwQ9L4&e=>
>>> :
>>>
>>> The *NSEL* (Network-Selector) is a field in the NSAP address that
>>> identifies the network layer
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Network-5Flayer&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=CseHsrq8z_Cjx0ZsXzuYT3X9_3CMLv4SkB7Cs2nRPu0&e=>
>>> service to which a packet should be sent.
>>>
>>> BIER forwarding seems match very much a “network layer service” in my
>>> opinion, and the “AB37” in “2019::AB37” is very similar to a NSEL too.
>>>
>>> Thanks
>>>
>>> Jingrong
>>>
>>> *From:* Antoni Przygienda [mailto:prz@juniper..net <[e-mail]>]
>>> *Sent:* Friday, July 12, 2019 12:02 AM
>>> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Xiejingrong <
>>> [e-mail]>; [e-mail]; BIER WG <
>>> [e-mail]>
>>> *Subject:* Re: Questions regarding <draft-zhang-bier-bierin6-03>
>>>
>>> 2.1. IPv6 Options Considerations
>>>
>>>   RFC 8200 section 4, defines the IPv6 extension headers. Currently
>>>
>>>   there are two defined extension headers, Hop-by-Hop and Destination
>>>
>>>   options header, which can carry a variable number of options. These
>>>
>>>   extension headers are inserted by the source node.
>>>
>>>   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').
>>>
>>> [XJR Q6]: You have to walk the ext header chain and get the last NH to
>>> judge if this packet need to be discard, right? For example for an incoming
>>> packet(ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>), you have to walk the
>>> whole extension header chain until you know the last NH, to execute the
>>> above “discard” action. Right?
>>>
>>> *prz> topic for discussion. The whole v6 options consideration is
>>> basically a first stab. *
>>>
>>>   This also indicates that for disjoint BIER routers using IPv6
>>>
>>>   encapsulation, there SHOULD NOT be any IPv6 Hop-by-Hop or Destination
>>>
>>>   options be present in a BIERin6 packet.
>>>
>>> [XJR Q7]: What does “disjoint BIER router” mean?
>>>
>>> *prz> non-adjacent, good catch *
>>>
>>>
>>> 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
>>
>