[Bier] Answer 20 to 30 marked as [XJR20] to [XJR30] //RE: comments for draft-xie-bier-ipv6-encapsulation-05.txt

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

Hi Toerless,



Please find below my answer 20-30 (for section 4 of this draft) marked as [XJR20] to [XJR30] in blue text.



Thanks

Jingrong





> 4.  BIERv6 Packet Processing

>    There is no BIER-specific processing,



? Unclear.

[XJR20] Editorial suggestion noted. Please allow me find some better text here.



>    and all the 8 steps in section

>    6.5 of RFC8279 apply to BIERv6 packet processing.  However, there are

>    some IPv6-specific processing procedures due to the base and general

>    procedures of IPv6.

>

>    On the overlay layer, when a multicast packet enters the BIER domain

>    in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the

>    multicast packet with a BIERv6 Header, transforming it to a BIERv6



Encapsulates instead of transform IMHO.

[XJR21] Editorial suggestion noted.



>    packet.  The BIERv6 header includes an IPv6 header and IPv6

>    Destination Options Header within a standard Non-MPLS BIER header.

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

>    IPv6 unicast address of the BFIR.  Destination Address field in the

>    IPv6 header is set to the End.BIER address of the next-hop BFR the

>    BIERv6 packet replicating to, no matter next-hop BFR is directly

>    connected (one-hop) or not directly connected (multi-hop).



I think it would be good to provide in a fitting place some good

justification/examples why especially BFR not acting as BFER  would

benefit from using any other addresses than the BIER prefix of the BFR.

[XJR22] Combining the BFR-prefix with the End.BIER address is the previous (before rev-04) proposal of this draft.

We change this for some reasons:

(1) Plan and allocate End.BIER of "all nodes" of a network from a block, so the ACL can be easily deployed on each node, as explained in chapter 5.

(2) Decouple the two for better management: network administrator may be used to configure a BFR-prefix from the loopback address that is used for BGP peer/Tunnel Endpoint, while End.BIER block is a different thing need care for secure deployment.



>    It is a local behavior to handle the combination of extension

>    headers, options and the BIER option(s) in destination options header

>    when a 'BIER Specific Handling' indication is got by the preceding

>    FIB lookup.  Early deployment of BIERv6 may require there is only one

>    BIER option TLV in the destination options header followed the IPv6

>    header.  How other extension headers or more BIER option TLVs in a

>    BIERv6 packet is handled is outside the scope of this document.



Typically AFAIK, the handling of option headers is not tied to a

avarying semantic of the destination address. I do understand that

IPv6 SIDs have semantic tied to them, but is there an example how such

a semantic would impact the handling of a particular destination option ?

If there is, then it would be good to cite such an SRv6 function as another

example of the desired behavior in this draft.

[XJR23] I agree with you that IPv6 option headers is not tied to a special destination address in IPv6 spec.

But that does not fit the "forwarding-plane-realities" for the past 25 years(see below pdf you co-authoring).

https://datatracker.ietf.org/meeting/104/materials/slides-104-wgtlgo-forwarding-plane-realities

"Processing that spans multiple headers increases complexity and eliminates opportunities for optimizations"

"don't assume complete processing flexibility."

I think the above text are saying the IPv6-spec next-header chain and option TLV chain that "not tied" to a specific destination address.

And that's why the preceding indication of "IPv6 DA" lookup is useful.

Once the "IPv6 DA" lookup of specific destination address determine that it is a special address (BIER-only address), then only the least thing is necessary, and "unexpected conditions" are all shortcut handled (see below XJR26 and XJR27).



I for once think that the idea of being able to modify the semantic

of option headers based on the address is potentially useful (would need

to figure out better examples), but:

[XJR24] I agree. Why not exploring ;-)



If there is a relevant customer community for BIERv6 that is not interested

in SRv6, it would be better if the base functionality would not rely

on SRv6 specific concepts, but if these SRv6/SID related options would be

part of a specific section in this document like "BIERv6 with SIDs" or so.

That way bot the IPv6, no SRv6 and IPv6+SRv6 customers would easier be

made happy.

[XJR25] I don't see how the "SRv6 specific concepts" affect the independency of BIERv6.

As stated before, SRv6 concept is only a thin layer over IPv6 to me.

It's all about forwarding-plane realities in my understanding!

Your thoughts?





>    A packet having a 'BIER Specific Handling' indication but not having

>    a BIER option is supposed to be a wrong packet or an ICMPv6 packet,

Explain the "ICMPv6 packet" ?

[XJR26] This is an exception-handling case. The "special handling indication" is got but the unexpected condition is encountered.

A packet having a 'BIER specific handling' but doesn't get the expected thing, then the 'exception handling' is triggered.

The above is such "exception handling", which can be discarding a packet, or checking further if it is ICMPv6 packet.





>    A packet not having a 'BIER Specific Handling' indication but having

>    a BIER option SHOULD be processed normally as unicast forwarding

>    procedures, which may be a behavior of drop, or send to CPU, or other

>    behaviors in existing implementations.



SHOULD be processed normally as unicast forwarding procedures AFTER

BIER replication ? E.g.: not quite sure which case yo're referring to here.

[XJR27] This is an exception-handling case. The "special handling indication" is got but the unexpected condition is encountered.

Seem as above.



>    The Destination Address field in the IPv6 Header MUST change to the

>    nexthop BFR's End.BIER Unicast address in BIERv6.

>

>    The Hop Limit field of IPv6 header MUST decrease by 1 when sending

>    packets to a BFR neighbor, while the TTL in the BIER header MUST be

>    unchanged on a Non-BIER router, or decrease by 1 on a BFR.



A non-BIER router would not operate on the BIER header or be addressed

by a BIERv6 packet, so the middle part should be deleted, as its confusing.

[XJR28] Please see explanation of [XJR3].



>    The BitString in the BIER header in the Destination Options Header

>    may change when sending packets to a neighbor.  Such change of

>    BitString MUST be aligned with the procedure defined in RFC8279.

>    Because of the requirement to change the content of the option when

>    forwarding BIERv6 packet, the BIER option type should have chg flag 1

>    per section 4.2 of RFC8200.



Maybe reorder these paragraphs in the order they are relevant, whereas

the BIER processing would preceed the unicast sending of copies.

[XJR29] Correct, the BIER processing would precede the sending of copies.



>    The procedures applies normally if a bit corresponding to the self

>    bfr-id is set in the bit-string field of the Non-MPLS BIER header of

>    the BIERv6 packet.  The node is considered to be an Egress BFR (BFER)

>    in this case.  he BFER removes the BIERv6 header, including the IPv6

>    header and the Destination Options header, and copies the packet to

>    the multicast flow overlay.  The egress VRF of a packet may be

>    determined by a further lookup on the IPv6 source address instead of

>    the upstream-assigned MPLS Label as described in [RFC8556].



Maybe you want to structure under subsections "BFIR", "BFR" and "BFER" behavior.

In the BFER behavior it should be said that the BFER behavior is in

addition to the unchanged BFER behavior and is based on creating another

copy of the packet based on the BFER bit set, and that copy is locally

consumed as follow..

[XJR30] Editorial suggestion noted.

End of answer so far.



Running out of time for now, hopefully can catch up with rest later.

Very good for the document to have what looks on browsing like a

comprehensive set of environmental sections below!





Thanks a lot for the documt

    Toerless





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