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

[Stig Venaas <[e-mail]>]

Hi

I would like to clarify my concern about PIM neighborship, and also a
couple of additional comments.

Regarding neighborship. It is fine to say that there is no adjacency,
but I think you may need to point this out a bit stronger since RFC
7761 says:

   In general, a PIM Join/Prune message should only be accepted for
   processing if it comes from a known PIM neighbor.  A PIM router hears
   about PIM neighbors through PIM Hello messages.  If a router receives
   a Join/Prune message from a particular IP source address and it has
   not seen a PIM Hello message from that source address, then the
   Join/Prune message SHOULD be discarded without further processing.

You should point out that accept and send join/prune messages without
requiring a known neighbor.
Hello messages are used for discovering capabilities. You should say
that the router is expected to
support RFC 7761, but it is assumed to not have additional
capabilities. E.g. you cannot assume
Bidir support, join attribute support etc. Or if there are any
capabilities we want to assume present,
then those need to be specified in this document.

You should point out that routers do explicit tracking, and that there
is no join suppression or prune
override.

Do you want to support asserts? Probably not, but it should be specified.

You should specify what the target address is for J/P messages.

I think you also need to discuss MTU. Ideally you want to know the
largest possible J/P message
that can be sent to the target so that you can send the smallest
amount of J/P message possible
when there is a lot of state.

Stig

On Sat, Oct 13, 2018 at 7:13 PM Jeffrey (Zhaohui) Zhang
<[e-mail]> wrote:
>
> Please see my comments below.
>
> > -----Original Message-----
> > From: BIER <[e-mail]> On Behalf Of Bidgoli, Hooman (Nokia -
> > CA/Ottawa)
> > Sent: Saturday, October 13, 2018 1:10 PM
> > To: Stig Venaas <[e-mail]>; Antoni Przygienda <[e-mail]>
> > Cc: BIER WG <[e-mail]>
> > Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-
> > pim-signaling/
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dpim-
> > 2Dsignaling_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=a6V2dfflSydnKxRixNK89T2oG-j3LgStm4m7QtrR5TI&s=4N9Ny2yWPzCV-
> > yRlZZ2jh0C1033qQGBZn-sgbDdCsPw&e=
> >
> > 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.
>
> Zzh> Stig has good points here. My understanding is that the source and destination addresses of the packet should be BFR prefixes, even for IPv6. Since we're "using PIM" as overlay signaling, we should point out the difference from regular PIM (this is also why we should point out that PIM adjacency is not needed).
>
> >
> > 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.
>
> Zzh> Good points. "forwards the PIM packet towards the source" is misleading. "lookup for the source of the PIM signaling packet" is also misleading. I think we should just say that received PIM packet is processed as if it were received from neighbors on a virtual interface (and as if the PIM adjacency was there).
>
> >
> > 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.
>
> Zzh> Stig's point is that the language itself is not very right, and I agree. Perhaps the following?
>
>    BFIR builds its (s,g) forwarding state with incoming interface (IIF) as the  RPF
>    interface (in PIM domain) towards the source and one of the outgoing interfaces
>    as for sending to tracked BFERs in the SD.
>
> Jeffrey
>
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dpim-
> > 2Dsignaling_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=a6V2dfflSydnKxRixNK89T2oG-j3LgStm4m7QtrR5TI&s=4N9Ny2yWPzCV-
> > yRlZZ2jh0C1033qQGBZn-sgbDdCsPw&e= per
> > > request and consensus @ IETF 102 …
> > >
> > >
> > >
> > > --- tony
> > >
> > >
> > >
> > > _______________________________________________
> > > BIER mailing list
> > > [e-mail]
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> > h0UjBXeMK-
> > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=a6V2dfflSydnKxRixNK89T2oG-
> > j3LgStm4m7QtrR5TI&s=bx3Tyr1fwfAMJiVWVxH6rEpvzvB5lDXk-
> > FsyZ9sPOKs&e=
> >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> > h0UjBXeMK-
> > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=a6V2dfflSydnKxRixNK89T2oG-
> > j3LgStm4m7QtrR5TI&s=bx3Tyr1fwfAMJiVWVxH6rEpvzvB5lDXk-
> > FsyZ9sPOKs&e=
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbf
> > h0UjBXeMK-
> > ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> > m=a6V2dfflSydnKxRixNK89T2oG-
> > j3LgStm4m7QtrR5TI&s=bx3Tyr1fwfAMJiVWVxH6rEpvzvB5lDXk-
> > FsyZ9sPOKs&e=