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

From: Antoni Przygienda <[email-masked]>
Date: Wed, 3 Oct 2018 21:35:55 +0000

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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 3 Oct 2018 14:37:37 -0700

Yes/support

Cheers,
Jeff
On Oct 3, 2018, 2:36 PM -0700, Antoni Przygienda <[email-masked]>, wrote:
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Purkayastha, Debashish" <[email-masked]>
Date: Thu, 4 Oct 2018 16:43:00 +0000

Support

Debashish

From: BIER [mailto:[email-masked]] On Behalf Of Antoni Przygienda
Sent: Wednesday, October 3, 2018 5:36 PM
To: [email-masked]
Subject: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

--- tony

---

From: Nabeel Cocker <[email-masked]>
Date: Thu, 4 Oct 2018 23:54:49 -0400

Support. 

Regards,
Nabeel

> On Oct 3, 2018, at 5:35 PM, Antoni Przygienda <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Mon, 8 Oct 2018 08:42:32 +0800 (CST)

Support.

Thanks,

Sandy

原始邮件

发件人：AntoniPrzygienda <[email-masked]>
收件人：[email-masked] <[email-masked]>
日 期 ：2018年10月04日 05:36
主 题 ：[Bier] WG LC onhttps://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

 

--- tony

---

From: <[email-masked]>
Date: Mon, 8 Oct 2018 10:07:35 +0800 (CST)

support

Regards,

Ran

原始邮件

 

--- tony

---

From: Stig Venaas <[email-masked]>
Date: Fri, 12 Oct 2018 17:15:43 -0700

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

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sat, 13 Oct 2018 17:09:49 +0000

Hi Stig

Thanks for the comments and taking time!

Inline HB>

Regards

Hooman

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Stig Venaas
Sent: Friday, October 12, 2018 8:16 PM
To: [email-masked]
Cc: BIER WG <[email-masked]>
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.

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:

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?

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.

s/dataplain/dataplane

HB> thank you!

HB> Thank you!

HB> thank you!

s/bier/BIER

s/pim/PIM

s/Datapatah/Datapath

HB> Thank you!

In section 3:

HB> thank you!

s/ibbr/IBBR

s/ebbr/EBBR

In 3.1

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 <[email-masked]> 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
>
>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 14 Oct 2018 02:13:17 +0000

Please see my comments below.

> From: BIER <[email-masked]> On Behalf Of Bidgoli, Hooman (Nokia -
> CA/Ottawa)
> Sent: Saturday, October 13, 2018 1:10 PM
> To: Stig Venaas <[email-masked]>; Antoni Przygienda <[email-masked]>
> 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
> 
> 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.
> 

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

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 16 Oct 2018 09:30:46 -0700

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

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 16 Oct 2018 17:09:42 +0000

Hi Stig 

> On Oct 16, 2018, at 9:30 AM, Stig Venaas <[email-masked]> wrote:
> 
> Hi
> 

Do we need to say that this document would update RFC 7761 ? or only statement is enough ?

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Oct 2018 17:33:12 +0000

I think all of Stig's points (in both of his messages on this thread) 
are quite correct, and they should be resolved before the document advances.

On the terminology issue, it is perhaps a bit confusing that the BFIR 
for sending a control message is the BFER for receiving the data packets 
elicited by the control message.  But it still would be better to call 
that node the EBBR, preserving the usual directionality of the terms 
"egress" and "ingress".  Presumably the idea is to make things easier to 
understand, not to make them more difficult.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 16 Oct 2018 11:43:11 -0700

Hi

No, we shouldn't say that it updates it. The neighbor requirement in
7761 is only a SHOULD. It is OK to deviate from that in special cases
such as this.

Stig

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Oct 2018 00:52:53 +0000

> 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 

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 <[email-masked]> 
Sent: Saturday, October 13, 2018 10:13 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Stig Venaas <[email-masked]>; Antoni Przygienda <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: RE: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

> https://datatracker.ietf.org/doc/draft-ietf-bier-
> pim-signaling/
> 
> Hi Stig
> 
> 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 

> HB> These info should be in the BIER header that incapsulates the 
> HB> signaling
> packet.
> 
> In 3.3 it says:
> 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.

> HB> as per draft this is just signaling and we are not trying to 
> HB> create
> Also since it is signaling between IBBR and EBBR they it would also 
> mean local processing at EBBR.
> HB> so this regular multicast FIB so an S,G is mapped to IIF and OIF 
> HB> where OIF
> HB> please note the draft has point it out "and out going interface 
> HB> OIFs set as

Jeffrey

> HB> again IMHO the security concerns for this draft is exactly the 
> HB> same as BIER
> 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.
> 
> 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
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Oct 2018 01:13:13 +0000

By the way the other 2 points I am fine with new text  and will update the draft I think the biggest issue here is the IP header of the PIM signaling packet.

HB2> ok will change to "Received PIM join/prune Signaling packet is processed as if it were received from neighbors on a virtual interface, (i.e. as if the pim adjacency was presents, regardless of the fact there is no adjacency) 

HB2> Ok I am good thank you!

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

Jeffrey

---

From: Stig Venaas <[email-masked]>
Date: Tue, 16 Oct 2018 19:04:30 -0700

Hi

Regarding the source address to use for the pim join.

If the source address is not the BIER prefix of the sender, and you
don't put the prefix, or BFR-ID and SD, of the sender somewhere in the
J/P, then it is complicated to implement, because PIM will need to get
info from the BIER header. Depending on the implementation, it may not
be possible for PIM to get this information after decap. Or at least
it would require significant work. If the source address is the BIER
prefix, then one could make use of that, although I'm not sure how to
handle the SD. Another solution could be to use a Join attribute to
pass BFR-ID and SD.

When using a virtual interface for BIER, then I would think it makes
sense that the BIER prefix is the address assigned to this interface.
In that case, the BIER prefix would naturally be the source of the PIM
join. At least for IPv4.

For destinatinon address, you could use all-pim-routers, but what
about the JP target? That should probably be the BIER prefix of the
upstream neighbor.

Stig

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 17 Oct 2018 02:35:05 +0000

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) <[email-masked]> wrote:

> 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=3TD7ytrg8OlF3JNDtpFdDIvc_vjCAyuZkeFJiEUKwQk&s=-4bcSyoQs8RIIOJKXUFpTt7B2K56_ABNYZHBn_LqMBY&e=
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=3TD7ytrg8OlF3JNDtpFdDIvc_vjCAyuZkeFJiEUKwQk&s=EzsbqiV8BP4ybVUE3ikDdhR9JrtQor2o-l4RqAku1xQ&e=
>> pim-signaling/
>> 
>> Hi Stig
>>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Oct 2018 03:44:29 +0000

Agreed destination address well known multicast source BIER prefix of IBBR

All good?

Regards

Hooman

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

Sent from my iPhone

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

> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; 
> Stig Venaas <[email-masked]>; Antoni Przygienda <[email-masked]>
> 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=
> 
>> From: BIER <[email-masked]> On Behalf Of Bidgoli, Hooman 
>> (Nokia
>> -
>> CA/Ottawa)
>> 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
>> 
>> 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.
>>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Oct 2018 03:46:54 +0000

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

All good?

Regards

Hooman

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

Sent from my iPhone

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 18 Oct 2018 01:18:45 +0000

New draft uploaded, thanks all!

Regards

Hooman

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

Agreed

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

All good?

Regards

Hooman

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

Sent from my iPhone