Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

[Stig Venaas <[e-mail]>]

Hi

The draft is almost ready, but some work is still needed IMO. Please
see below comments.

I'll start with the more serious issues.

What should the source and destination addresses of the pim joins
be? Should they be the BIER prefixes, so that a router can map
prefix to BFR-ID? For IPv6 a pim j/p is supposed to have link-local
source/destination addresses, I think an exception is needed here.
It might be nice if there was a way of encoding the senders SD and
BFR-ID of the sender in the join. This is needed for the tracking in 4.1.

In 3.3 it says:
   After receiving the BIER packet and determining this packet is a
   signaling packet, EBBR will remove the BIER header from PIM packet.
   It will do a route lookup for the source of the pim signaling packet.
   If the source is on a locally attach pim domain, it forwards the PIM
   packet toward the source.

I don't quite follow here. The join shouldn't be forwarded, it should
be processed locally, right? What do you mean by the source of the
signaling packet? Is it the source IP address, or a multicast source or
RP address inside the join? There may be multiple in one J/P packet though.

You should probably point out that the join should be accepted even
though it doesn't come from a pim neighbor.

In 4.1 it might seem like each OIF corresponds to a <SD, BFR-ID>, but
an implementation might have a single OIF for <SD, BIER set>, where
the set has multiple bits set (for multiple BFR-IDs).

Security considerations need more work. It should consider what are
potential new issues, not just refer to existing BIER and PIM
considerations. E.g. is it possible to send spoofed joins so that
packets are replicated to a large set of receivers?


Less important issues below.

I still find it confusing that IBBR and EBBR are from signaling
point of view. Generally with multicast and tunneling, the join
goes in the opposite direction and would go from the tunnel
egress router to the tunnel ingress. Please consider swapping the
terms so that the join goes from egress to ingress. From where a
data packet leaves the BIER domain to where it enters the domain.

Abstract is rather long.

Replace the term "draft" with for instace "document".

s/dataplain/dataplane

Regarding BBR definition:
          BIER Boundary router. The router between the PIM domain and

It would be better to say "A router", as there can be several.

Maybe similar changes for IBBR and EBBR?

s/bier/BIER

s/pim/PIM

s/Datapatah/Datapath

In section 3:
   The BBR will create pim adjacency between all
   the PIM routers attach to it on the pim domain.
Attached to it in the PIM domain

Instead when it determines that the PIM join or prune messages needs
                                                              ^^^^^^^

it will generate a pim signaling packet toward its attach pim domain.
                                                  ^^^^^^^^ attached

s/ibbr/IBBR

s/ebbr/EBBR

In 3.1
The IBBR will track all the PIM interfaces on the attach pim domain
                                           in     attached PIM

In 4.2 it is assumed (S,G), but could also be (*,G).
At the end of 4.2 it says (G), should that be (S,G)/(*,G)?

I feel MVPN is section 6 is a bit underspecified. Does this description
match what is in the BIER MVPN draft? I didn't check this.

s/thier/their

s/inline/in line/

s/Bier/BIER

Regards,
Stig

On Wed, Oct 3, 2018 at 2:36 PM Antoni Przygienda <[e-mail]> wrote:
>
> This thread initiates 2 weeks WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/ per request and consensus @ IETF 102 …
>
>
>
> --- tony
>
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier