[Bier] Answer 10-19 marked as [XJR10] to [XJR19] //RE: comments for draft-xie-bier-ipv6-encapsulation-05.txt

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

Hi Toerless,



Please find below my answer 10-19 marked as [XJR10] to [XJR19] in blue text.



Thanks

Jingrong





> 3.2.  Multicast and Unicast Destination Address

>    BIER is generally a hop-by-hop and one-to-many architecture, and thus

>    the IPv6 Destination Address (DA) being a Multicast Address is a way

>    one may think of as an approach for both the two paradigms in BIERv6

>    encapsulation.



I think a better way to explain:

If an IPv6 (or IPv4) multicast group destination address is used as a

hop-by-hop forwarding key, then this requires hop-by-hop per-group forwarding state,

therefore, just because BIER is like IP multicast a (multi-)point-to-multipoint service,

it can not use IP multicast IP multicast group destination addresses. Instead

it requires per-hop unicast destination address forwarding.

[XJR10] I am not sure about the said "per-group forwarding state" above.

The early revision of this draft proposed to use one-group (for example, FF05::AB37) for all BIER packets.

A packet is like this: {IPv6 Hdr(SA=BFIR, DA=ff05::ab37), Dest-Option-Header(BIER), C-mcast-pkt(IPv4/IPv6/Ethernet)}.

There is only one MFIB entry added in every BFR: (*, ff05::ab37), and the entry is to tell the data-plane to do a further lookup of Dest-Option-Header(BIER) !

The forwarding plane receives a packet, classifier it as an IPv6 multicast packet, lookup MFIB entry, and assume some BIER specific action ----similar as using End.BIER unicast address ---- and then lookup the assumed BIER header in the extension header.

Please let me know if this explanation is clear to you.





>    However using a unicast address has the following benefits:

>    1.  Tunneling a BIERv6 packet over a non-BIER capable router.

>    2.  Fast rerouting a BIERv6 packet using a unicast by-pass tunnel.

Maybe more general "Using unicast FRR adjacencies to next-hop BFR".

[XJR11] Editorial suggestion noted.



>    3.  Forwarding a BIERv6 packet to one of the many BFR neighbors

>        connected on a LAN.



Well. AFAIK, all the BIER solutions as well as mLDP/RSVP-TE have rather the downside that they must create multiple copies across the same LAN as they have neighbors to send to, so this is not only a benefit. (Maybe mLDP does now standardize native link-local multicast with upstream assigned labels to leverage L2 multicast, not sure).

[XJR12] My understanding is that, BIER-MPLS and BIER-ETH will both use unicast destination address and will not create multiple copies across the same LAN.



>    4.  Connecting BIER domains, for example Data Center domains, in an

>        overlay manner.



Given the management considerations for the BIER addressing space, this is

a bit like saying the telephone allows people in different countries to

talk with each other. Aka: Higher layer problems non-withstanding.

[XJR13] the said "Data center domains" is managed by a single operator.

The Peering multicast case in <draft-geng-bier-ipv6-inter-domain> may be helpful to understand this.

Need a reference to that case and that draft here ?



IMHO, no need to create contention around point 3 and 4, its just a reqiurements

and it comes with undeniable benefits 1. and 2.

[XJR14] Given the above explanation, I think point 3 and point 4 are really different thing IMO (see above also). Your thoughts ?



>    Some of the above functions are assumed very basic requirements and

>    part of BIER architecture as described in [RFC8279].  This document

>    uses unicast address for both one-hop replication and multi-hop

>    replication.



Not sure if one-hop replication and multi-hop replication are well predefined terms

maybe better "BIER replication to subnet adjacent BFR and BIER replication to remote BFR".

[XJR15] Editorial suggestion noted.





>    The unicast address used in BIERv6 packet targeting a BFR SHOULD be

>    advertised as part of the BIER IPv6 Encapsulation.  When a BFR

>    advertises the BIER information with BIERv6 encapsulation capability,

>    an IPv6 unicast address of this BFR MUST be selected specifically for

>    BIERv6 packet forwarding.  Locally this "BIER Specific" IPv6 address

>    is initialized in FIB with a flag of "BIER specific handling",

>    represented as End.BIER function.



You should start explaining here, before you use the SR terminology (foo.bar),

that the semantic of the encapsulation addresses is explained in SR terminology

becuase it is desired for BIERv6 to be used inside an SRv6 network and

share its terminology. Right now you do it after using all the SR terminology

and pseudo code, which may ten confuse non-SRv6 aware readers.

[XJR16] Except the wording and terminology above, do you think it a heavy dependency of BIERv6 on any SRv6 ?

In my understanding, the SRv6 (at least used here in the document) is only a thin layer over IPv6, which includes only the paradigm of "initializing an FIB entry for a 128-bit IPv6 address" to guide the data-plane process.

Would you like to propose some text here ?



>    The following is an example pseudo-code of the End.BIER function:

>

>      1. IF NH = 60 and HopLimit > 0                               ;;Ref1

>      2.   IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2

>      3.     Lookup the BIER Header inside the BIER option TLV.

>      4.     Forward via the matched entry.

>      5.   ELSE                                                    ;;Ref3

>      6.     Drop the packet and end the process.

>      7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6)           ;;Ref4

>      8.   Send to CPU.

>      9. ELSE                                                      ;;Ref5

>     10.   Drop the packet.



I didn't try yet to understand all this text, and so might other non-SR knowledgable

readers, so i recommend to add a summary at the end that tries to explain non-SR

terms what specifically this example was doing.

[XJR17] Thanks for the comment. We will try, and highly appreciate if you or anyone could provide some text. Thanks in advance!



> 3.3.  BIERv6 Packet Format

>

>    examples in other RFCs.  [RFC6275] introduces how the order should be

>    when other extension headers carries along with Home address option

>    in a destination options header.  Similar to this example, this

>    document requires the Destination Options Header carrying the BIER

>    option MUST be placed as follows:

>    o  After the routing header, if that header is present

>    o  Before the Fragment Header, if that header is present

>    o  Before the AH Header or ESP Header, if either one of those headers

>       is present

>    Source Address field in the IPv6 header MUST be a routable IPv6

>    unicast address of the BFIR in any case.



Is it permitted by RFC8200 to lie about the source address when you

are a node operating on a destination option ? I don't know because

i am not an ordained priest of the church of RFC8200. I understand

you are allowed to keep the source address unchanged (and declare that

not to be a lie) when you rewrite the destination address as part of

being addressed by a routing header option, but i thought even in SRv6

when you do something like a binding-SID you would have to rewrite the

source address.



[XJR18] You understanding is correct - the draft proposes to keep the source address unchanged and rewrite the destination address as well as the DOH option data (BitString/TTL/etc) according to the DOH instead of a routing header, when the DA of packet is the node's IPv6 address.

We've thought and checked this carefully and found no harm for anything, and found no confliction with current IPv6 spec 8200 or so on.



We assume it is a situation that is beyond of the foresight of RFC8200 which is actually designed 25 years ago.

Just in case we are encountering a completely new requirements and situations ----

(1) The problem that traditional IP-multicast packet with multicast address are facing is highly recognized, and BIER is the latest and focusing interest.

(2) Use of multicast address as BIERv6 destination address had already considered and given up for reasons explained in section 3.2 of this document per the discussions in BIER discussions.

(3) Many network operators are moving to Native IPv6 for their new services or future architecture, with things of incremental-deployment, ease of maintaining as their outstanding concerns.



I think if the BIER WG accept such requirements and the situations, we can have more discussions focusing on the tech aspects ---- the benefit, the cost, the impact to IPv6, the alternatives, rather than individual's feelings that is pending.

Make sense ?



>    BFIR encodes the Non-MPLS BIER header in the above mentioned

>    encapsulation format and forwards the BIERv6 packet to the nexthop

>    BFR following the local BIFT table.



LCD Display ;-)

(Table is the last word in BIFT, no need to replicate).

[XJR19] Editorial suggestion noted.





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