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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Stig

Thanks for the comments and taking time!

Inline HB>

Regards

Hooman

-----Original Message-----
From: BIER <[e-mail]> On Behalf Of Stig Venaas
Sent: Friday, October 12, 2018 8:16 PM
To: [e-mail]
Cc: BIER WG <[e-mail]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

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.

HB> the proposal is to keep the same header.

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.

HB> These info should be in the BIER header that incapsulates the signaling packet. 

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.

HB> as per draft this is just signaling and we are not trying to create neighboring, hence IMHO I don't see the benefit of adding more clarification. Also since it is signaling between IBBR and EBBR they it would also mean local processing at EBBR.
   "This tunneling is only done for signaling
   purposes and not for creating a PIM adjacency between the two
   disjoint pim domains through the bier domain."

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

HB> so this regular multicast FIB so an S,G is mapped to IIF and OIF where OIF can be a set of <SD, BFR-ID>. I think we are saying the same thing.
HB> please note the draft has point it out "and out going interface OIFs set as the <SD, BFR-ID>" which is your 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?

HB> again IMHO the security concerns for this draft is exactly the same as BIER and PIM. I personally can't think of a specific attack for this specific signaling. That said I am open to more text what do you suggest?

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.

HB> I think I have pointed this out before, trying to change the signalling term to match dataplane forwarding creates ambiguities in part of the drafts. We started with using the terms BFIR and BFER for signaling and the text was extremely confusing. 
HB> the main reason is that the draft proposes to encapsulate the signaling in BIER hence if use the same term (BFIR and BFER) for signaling also we get into situations that it is hard to distinguish between control and data packets.

Abstract is rather long.

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

s/dataplain/dataplane

HB> thank you!

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.

HB> Thank you!

Maybe similar changes for IBBR and EBBR?

HB> thank you!

s/bier/BIER

s/pim/PIM

s/Datapatah/Datapath

HB> Thank you!

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

HB> thank you!

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)?

HB> this section we are still assuming ssm. Yes S,G thanks!

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

HB> Thank you! So in short you feel all protocols should be in capital letters...

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

_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier