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

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

Let me put it in bullet form for more clarity

Agreed
1.	destination address well known multicast
2.	source address bier prefix of IBBR


-----Original Message-----
From: BIER <[e-mail]> On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Tuesday, October 16, 2018 11:44 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Stig Venaas <[e-mail]>; BIER WG <[e-mail]>; Antoni Przygienda <[e-mail]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Agreed destination address well known multicast source BIER prefix of IBBR

All good?

Regards

Hooman

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Tuesday, October 16, 2018 10:35 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
Cc: Stig Venaas <[e-mail]>; Antoni Przygienda <[e-mail]>; BIER WG <[e-mail]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Perhaps I spoke too soon for destination address but the source address should be the BIER prefix, right?

Sent from my iPhone

On Oct 16, 2018, at 8:53 PM, Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]> wrote:

>> 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).
> 
> HB2> I am not sure what will be the benefit of changing the PIM src/dst IP to be the BFR prefix address. If anything the well know multicast IP destination is more beneficial for extracting after the bier header is removed. As you remember Jeffrey you wanted us to keep the BIER protocol IP because you pointed out it is more beneficial to pop the BIER header and process the payload as IP, hence the well known multicast IP is needed. Again if there is no PIM adjacency I don't see the significant why the src/dst IP should be prefix address.
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <[e-mail]>
> Sent: Saturday, October 13, 2018 10:13 PM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; 
> Stig Venaas <[e-mail]>; Antoni Przygienda <[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=HAkYuh63rsuh
> r6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2I
> DAzeZqE&m=3TD7ytrg8OlF3JNDtpFdDIvc_vjCAyuZkeFJiEUKwQk&s=-4bcSyoQs8RIIO
> JKXUFpTt7B2K56_ABNYZHBn_LqMBY&e=
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeM
>> K-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=3TD
>> 7ytrg8OlF3JNDtpFdDIvc_vjCAyuZkeFJiEUKwQk&s=EzsbqiV8BP4ybVUE3ikDdhR9Jr
>> tQor2o-l4RqAku1xQ&e=
>> 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 
>> HB> 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 
>> HB> 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 
>> HB> 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 
>> HB> 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 
>> HB> 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 
>> HB> 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 
>> HB> 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=
_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier