[Bier] Answer 1-9 marked as [XJR1] to [XJR9] //RE: comments for draft-xie-bier-ipv6-encapsulation-05.txt

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Toerless,



Please find below my answer 1-9 marked as [XJR1] to [XJR9] in blue text.



Thanks

Jingrong





> 1.  Introduction

> 2.  Terminology

> 3.  BIER IPv6 Encapsulation



I think it would be good to write introductory text here explaining the

overall approach of this encapsulation, e.g: BFIR running this option

encapsulate the target IP multicast payload (IPv6, IPv6, ethernet packet)

into a BIERv6 packet, which is an IPv6 packet with the new BIERv6 header.

This packet is then hop-by-hop IPv6 forwarded with the BIER replication

semantic defined by the BIERv6 header and decapsulated on the BFERs.

[XJR1] I understand it as an editorial suggestion. Correct me if I am wrong



> 3.1.  BIER Option in IPv6 Destination Options Header

>         BSL: See Section 2.1.2 of RFC 8296.

>         Entropy: See Section 2.1.2 of RFC 8296.

>         OAM: See Section 2.1.2 of RFC 8296.

>         Rsv: See Section 2.1.2 of RFC 8296.



Is there anything up to here that is different from what RFC8296 for non-MPLS

networks ? If there are new things here, they are hard to identify,

so it might be better to eliminate all requirments that can be found in

RFC8296 2.2 and only describe any changes.

[XJR2] Editorial suggestion taken.



>         DSCP: SHOULD be set to binary value 000000 upon transmission and

>         MUST be ignored upon reception.  In IPv6 BIER encapsulation,

>         uses highest 6-bit of Traffic Class field of IPv6 header to hold

>         a Differentiated Services Codepoint [RFC2474].



Given how this draft suggests to verbatim reuse the quite long RFC8296

forwarding header (like other proposals for BIER with IPv6 too), i think

the hope is that it can leverage as much as possible existing BIER

forwarding logic to ease adoption. It is therefore not clear to me if

it is prudent to force the forwarding plane to use the DSCP from the IPv6

header instead of the BIER header. I would suggest to say that  the BFIR uses

the same DSCP for both the IPv6 and BIER header so that forwarding plane

can use either field, which ever is easier to impleemnt. Else, it would be

good o have an explanation in the text why the above described approach

is superior.

[XJR3] I think I agree with most of the words here, while there are technical design considerations for DSCP/TC/TTL/Entropy for some important scenarios.



In RFC8296, TC/TTL is designed for BIER-MPLS, and when the BIER-MPLS over P2P-LSP is used for bypassing Non-BFR routers, the TC/TTL will works in pipe-mode or uniform-mode.

While in BIERv6 design, the TC/TTL in BIER-hdr and TC/HopLimit in IPv6-hdr can both stand for its own purpose: the former is used for BIER-aware routers(BFRs), and the later is used for BIER-unaware routers(Non-BFRs)!

It is also useful for diagnose by network administrator to know how many Non-BFRs and BFRs in the path be checking the HopLimit in IPv6-Hdr and TTL in BIER-Hdr on the BFER.



So does Entropy in BIER-hdr and FlowLabel in IPv6-hdr: the FlowLabel can be used for load-balance when forwarding a BIERv6 packet from A(BFR)----B(NonBFR)====C(BFR) where B can use, and BIER Entropy can be used by BFR A.

That shows an advantage of BIERv6 proposal than BIER-MPLS: BIER-MPLS over P2P-LSP may be difficult to support load-balance since the Non-BFR can't read through a BIER header to get a hash value through inner IP header.



This kind of advantage matches the design target of BIERv6 ---- for smooth and ease of deployment in IPv6 network where Non-BFR is very common and likely to be continuing for a very long time.



>            Use Next Header value 4, 41 and TBD0 for IPv4 packet, IPv6

>            packet and Ethernet packet respectively,



In general, this document might not constrain itself to specific code

points but just allow all the code-points that users want and are

defined by IANA. IPv4 and IPv6 of course can be explicitly listed

maybe even with requirements levels.



Rewrite text for TBD0 to instead say "code point for ethernet from <srv6 reference-doc>",

so this doc wouldn't need to wait for it.

[XJR4] This problem has been addressed in the rev-06. I suppose you started this review quite a few days before I post the rev-06. Thanks for this thorough review!



>            and use Proto value

>            TBD1 indicating "Delivering the data packet with VRF lookup

>            in IPv6 source address".



I am right now not on top of how BIER in MPLS networks supports the more complex

forms of VRFs, e.g.: extranet VRFs, but i thought it was through additional

labels after the BIER header. Logically a BFIR might only have one

address in VRF0, so it could be problematic to expect for BIER to

assume per-VRF addresses as source addresses.



[XJR5] I think you are right. Currently the BIER are using the "BIER Proto" mechanism excessively in my mind. Allow me to explain the "excessively" here:



(1) To support IPv4/IPv6/Ethernet multicast packet, BIER Proto=3/4/6 are defined, but won't support VRF function.

(2) To support VRF, the most common design (as used in RFC8556) is an upstream-assigned VPN Label following the BIER header, and BIER Proto=2 is defined, but it heavily depend on the Context in the BIER header, and when the BIER-MPLS PHP is proposed, it doesn't work.

(3) Alternative of supporting VRF is using an domain-wide unique VPN Label following the BIER header, and BIER Proto=1 is defined, but it does not support RPF function (which is an essential function to MVPN), or it need another Per-Ingress domain-wide unique MPLS label, and change the RPF function implementation to another way that is completely different than BIER Proto = 2.

(4) There are also other proposals of BIER Proto value, for example, there is proposal of BIER Proto=7/8/9 for VXLAN/NVGRE/GENEVE, which can be used to support VRF function, while all these seems not likely to support RPF function.

(5) Totally there are 8 types of BIER Proto value, and 5 types of different overlay headers (upstream-assigned MPLS Label, downstream-assigned MPLS label stack, VXLAN, NVGRE, GENEVE), but none of them can fulfill a Whole function that proposed so far ---- VRF, RPF, PHP.  Not to mention that, each type of BIER Proto and each type of overlay header means chip effort to support. Remember that each encoding of overlay header means a whole different handling, not only the VRF information, but every bits in an encoding need to be handled.



Why is that ? I think a most useful design principle is lost in the Proto chain design ---- Optimizing for the most common or important case!

What's the most common and import for multicast then ? ---- I think VRF and RPF are two of them.



To my best understanding, the design of "BIER Proto" brings much flexibility surely, but excessively use of BIER Proto brings big interoperability challenge. More likely to me, it is a thing that BIER itself lacks!



However, built on the IPv6 internet-layer (L3), forwarding packet without changing the IPv6 source address, BIERv6 can bring this benefit:

(1) The global identifier of VRF, that is easy to get (enough bit width to allocate, no new type identifier).

(2) The global identifier of Ingress PE for MVPN RPF function.

The design to use per-VRF address solves the above 2 essential functions in a direct way.

It uses only one BIER Proto (with 3 well-known Next Header value of course) and none of extra encoding of overlay header.



What problem do you see for a per-VRF address allocation ---- the waste of IPv6 address ?





Maybe it would be easier to move the VRF support into a separate document.

[XJR6] See above. I haven't seen how to leave this essential design of BIERv6, related to the combination use of IPv6 Next Header and BIER Proto value, can be move to a separate document.



Seems to me as if it would make sense to figure out if BIER with v6

could be combined with some subset of SRv6 that includes the destination

(BFER) related SIDs, most of which seem to be about VRF selection.

[XJR7] My understanding is that it will make the BFRs aware of VRF. Am I correct ?



That would make inclusion of BIER into SRv6 deployment easier. And

i am guessing that customers who insist on hop-by-hop IPv6 forwarding

across their core would likely minimize differences to SRv6 too.

[XJR8] Using per-VRF IPv6 source addressing is completely different than SRv6, just like the upstream-assigned VPN Label used in BIER-MVPN is completely different than MPLS-VPN.

We can have more discuss if you still have concern about the relationship of BIERv6 and SRv6, or we can move this discussion later together with some other text.



>            Allocation of Next Header value TBD0 for Ethernet packet is

>            applying in [I-D.ietf-spring-srv6-network-programming] and

>            will not be listed in the IANA considerations section of this

>            document.



With above change referring only to that doc, not he actual code-point, this paragraph could go away. Of course, once the code point is IANA assigned, you can simply use it in the text and remove the reference.

[XJR9] Yes we have removed the reference already since the code point is already IANA assigned (value 143).





-----Original Message-----
From: BIER [mailto:[e-mail]] On Behalf Of Toerless Eckert
Sent: Thursday, March 12, 2020 12:24 PM
To: [e-mail]
Subject: [Bier] comments for draft-xie-bier-ipv6-encapsulation-05.txt



Comments on subject document inline. Thanks a lot for the work.