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

From: Toerless Eckert <[email-masked]>
Date: Thu, 24 Oct 2019 17:24:01 +0200

Some high level comments/questions about this document:

It would be good to review/discuss the target scenarios to figure
out what text is missing.

1. IMHO, the first answer would be "SSM over a BIER-domain":

   FHR/LHR run this mechanism with PIM-SSM. transit routers do not
   need PIM anymore, just BIER. (Great showcase for BIER)

   Network needs to run a link-state-IGP (ISIS/OSPF), so that without change
   to the protocols on the wire the IGP on the LHR can calculate the
   IP address of the FHR, which in turn should be the BFIR IP
   address.

   If we agree on this, here are my thoughts about the gaps:

    - The doc never mentions SSM or PIM-SSM, it should.

    - It would be nice to mention not only SPF but the fact
      that a link-state IGP is required and a reminder hat BIER
      today is only defined to work with link-state protocols anyhow 
      (ISIS/OSPF).

    - The calculation of FHR (==BFIR) in the IGP on the LHR can
      likely be done without extensions to the on-the-wire-protocol,
      but in most enterprise or Data-Center networks, source networks
      are redundantly attached, and different LHR could calculate
      different FHR. This would lead to duplicate traffic in the BIER
      domain, and if one is unlucky, that duplicat traffic could even
      be duplicate on the same path-segments (based on how the 
      per-hop ECMP works in the IGP).

      I would suggest to define a simple rule that the SPF calculation
      MUST by default determine all ECMP FHR towards a router and
      then pick the one with the lowest router-ID.
      (would be good to hear an IGP coder chime in whether that
       calculation of the ECMP FHR is additional work in the existing
       implementation - as oppose dto just calculate the first FHR).

    - It would be helpfull to have a sentence explaining that the BFR-ID
      for the choosen FHR would be learned from the IGP BIER extension
      as defined in the ISIS/OSPF BIER extension docs (the two
      references are already in the doc but not used at all).

    - The document should make statements about the setting of the
      entropy field in the BIER data packets of individual (S,G) flows.
      Given the problem of using ECMP paths and the prevalence of few bis
      sources sending traffic for many SSM channels, i think the entropy
      should be calculated from both S and G (not only from S). Also,
      if there is no complete ECMP in the network, multiple FHR
      will potentially send the same traffic, and then that should
      flow as much as possible across different paths (so as not
      to overload a single link). 

      E.g.: something like (S XOR G XOR router-id) % 20
      might be a good recommendation for the entropy.

    2. The document mentions PIM-ASM, which is a term that AFAIK is
       undefined in any standards track RFC. I guess it meant to say ASM,
       but that could be PIM-SM, PIM-DM or Bidir-PIM.

       If its meant to describe PIM-SM, then i think there is
       the additional dependency of figuring out where RP information
       comes from. Assuming they are manually configured consistently
       is not a good expectation. Most PIM domains use either some old Cisco
       proporietary protocol, or BSR. Neither of these will work
       through this solution unless we add a solution to support
       flooding to all BFER that run PIM. I think that might have
       been the idea of defining the term BFT in the document, but
       that term is not used.

       - Even if we knew the PIM-SM RPs on the LHR, i do not like the resulting
       solution, because we would still require the RPT/SPT switchover
       signaling and tracking of both (S,G) and (*,G) LHR. I would
       be a lot more a fan of simply reusing RFC8364 and just use the
       BIER BFT to flood appropriate (S,G) active messages to all LHR.
       
       If you ask me, it would be good enough to finalize the doc for
       SSM and do a followup for ASM via SSM+(S,G)-active-signaling
       later.

   The other high level question is: What are the good reasons to use
   BIER to unicast the join/prune messages from LHR to FHR ? As opposed
   to use unicast messages. If there are benefits, they should be
   written down. 

   The related (but really independent) concern is: SHould we
   reintroduce NOW a scheme that uses unreliable datagram signaling
   for join/prune (across a potentially multi-hop WAN path), when we went
   through the exercise and concluded we need better: Aka: Original multicast
   VPN Default/Data-MDP used PIM (datagrams) and those packets got lost
   duing burst-collisions (such as reconvergence events etc.). BGP or PORT
   solve this issue.

   Aka: I would suggest to say the join/prune signaling should be via PORT.
   The PORT messaged can be over unicast or BIER based on the answer to
   above question. 

   If there is a (misguided ;-) mayority of folks thinking we do not
   need reliable join/prune signaling across this BIER solution even
   though we've recognized that need long time ago in prior solutions,
   then please write at least a section about the DiffServ requirements,
   aka: making sure these "signaling" BIER packets for join/prune get
   appropriate MPLS/EXP or DSCP in their according encap headers (there
   are standards for signaling EXP/DSCP).

Cheers
    Toerless

On Wed, Oct 03, 2018 at 09:35:55PM +0000, Antoni Przygienda 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: Stig Venaas <[email-masked]>
Date: Thu, 24 Oct 2019 10:07:41 -0700

Hi

A couple of quick comments on your email Toerless.

Using PORT may be a good idea. The join attribute defined here would
also work with PORT. PIM hellos are not sent over BIER so we have no
easy way of finding out whether routers support PORT though.

The draft draft-venaas-bier-pfm-sd-00 has a new solution for how to
determine whom to join. It would be easy to include capability here to
determine whether the router supports PORT etc.

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Oct 2019 12:32:02 +0200

Thanks, Stig, that what i was suggesting for enabling ASM without
getting into any of the PIM-SM complexities.

How would we automatically determine the set of all BFR/PIM routers
automatically ? I'd hate to have solutions that only work with an
SDN controller provisioning consistently many parameters if we can
also (hopefully easily) automate it.

Also, it would be nice if we could not only have a single PIM domain
connect via a BIER domain, so that we could also use this for
slices or DC environments where there could easily be multiple instances.

The most logical solution for that seems (to me) to be an IGP
extension that tags onto the existing BIER IGP extensions and
attaches to the BFR extension the information:

  -> This BFR is member in the XXX PIM/BIER domain with label YYY

Then the data packets could use the same forwarding plane encap
as in BIER/VPN, aka: combination of BFR-ID and YYY identifies
an IP Multicast packet for domain XXX.

Cheers
    Toerless

On Thu, Oct 24, 2019 at 10:07:41AM -0700, Stig Venaas wrote:
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 29 Oct 2019 03:27:39 +0000

Adding the working group as well, inline HB2>

Regards

Hooman

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Monday, October 28, 2019 4:02 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

On Sat, Oct 26, 2019 at 08:34:01PM +0000, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:
> HB> The original idea was this be a generic procedure to tunnel pim joins and prunes through a BIER domain. It didn't really care about SSM or SM. As an example our testing showed that static RP worked with this mechanism.
> HB> that said if we feel we should specifically say this is SSM, I can add a sentence.

The main issue is whether we want the document to be a standalone document to define a working, implementable and interoperable solution, or if this should just be some protocol encodings, and there would be another document describing how to build a working interoperable solution from it.

If we stick we SSM, we have the smallest/easiest solution, and the document could be standalone. As soon as we think about ASM we get into the controversy between using the way PIM-SM/ASM is done in MVPN (which the document is currently hinting at) and newer mechanisms such as what i think Stig and I would favor/suggest.

HB2> sure as I mentioned no issue I will say this is SSM only. Should add the static RP case? Or do we want that in separate draft also? 

> HB> With regards to ECMP. We really left this open to the implementation. As an example when a route request is done for a source of an pim join, internal algorithms can decide which BFER it should be forwarded to. To us this like any other ECMP implementation and it should be open.
> HB> one implementation can decide the lower IP while the other would 
> HB> multihome base on (S,G)

Then the document should add a statement like this:
(using BFR or BBR terminology as you please).

This document does not specify mechanisms for different BFER to select a single BFIR for the same multicast traffic flow. When sources are redundantly attached via more than one BFIR, this can lead to more than one BFIR forwarding the same multicast traffic into the BIER domain - towards different set of BFER.

HB2> ok I will add the following text.

If the lookup for source results into multiple EBBRs, then the algorithm should ensure that all signaling for a particular (C-S, C-G) is forward to a single EBBR. How the this selection is done is application specific. As an example it can be round robin or smallest EBBR IP.

> HB> not sure if I understand. We defined an EBBR as egress BIER boundary router. Obviously a BIER router is bound by RFC 8279 and the IGP/BGP extensions.

Sure. There is just no text explaining how to stitch these things together.

I guess the idea is something like this:

HB2> have you looked at the appendix  A? it explains how to find the EBBR (aka BFIR) 

1. the BFER (iBBR) in question will look at the SPF from itself to the source of the multicast flow because this is what IGP SPF would calculate today. Right ?

2. It would then along the path try to find the first router (from
itself) that is announcing a BIER extension. From that it learns the BFR-ID to send the join to. Right ?

The problems i can think of apart from the aforementioned case of more than one BFIR because of ECMP:

a) Plotting a path from the BFER towards the source is reverse-path.
   whenever you have e.g.: a network with asymmetric metrics, then
   you may end up picking a wrong BFIR.

HB2> not really the EBBR tracks which IBBR is sending the pim signaling and stores the information in a table format as per section 3.3. If ECMP algorithm forward the (C-S, C-G) to a specific EBBR then that EBBR will note the BFR-ID of the IBBR and for that (C-S, C-G) it will always send the traffic back to that particular IBBR so even if the network is asymmetric EBBR knows how to forward the packet backward. 
 
   Aka: Correctly speaking, rule 1 is incorrect, and you would need
   instead to trace the path from the source towards ourselves (BFER).

   To the best of my knowledge, this reverse-path calculation can be
   done at the same cost as standard SPF calculation (simply by
   doing SPF calculation in a topology with all link interface metrics
   swapped), but for more than 20 years now i have not seen any
   IGP SPF implementation actually doing this. because even though its
   equally fast, it is still additional code that no developer wants
   to write as long as there is no big customer business case asking
   for it. And customers do not understand the problem until it is too
   late.

   Aka: unless there is an actually normative explanation of how
   to calculate the BFIR, we're again going to end up with all type
   of crappy half-hearted implementations in IGPs.

b) A BFR may have multiple BFIR-ID in different subdomains. The BFER
   can only bick a SD/BFR-ID combination for the BFIR in which itself
   has a BFR-ID, so that the BFER can actually address the BFER.

   If this matching results in more than one feasible SD/BFIR-ID
   combination, then we've again got the potential for (unnecessary)
   multiple copies of the packet to be sent.

Aka: would be good to have explanatory text about the implementation choice issues because otherwise we likely end up with non-interoperating implementations, or surprises by the amount of unnecessarily duplicated traffic with multiple BFIR, asymmetric path or multiple SD/BFR-ID combinations.

Btw: the document says:

| Addr Family:   BIER prefix address family as defined in [RFC7761]
| BIER Info:   IBBR Prefix (ipv4 or ipv6), SD, bfr-id

RFC7761 does not define a "BIER prefix address family". Google couldn't find me another document where this term is used, so i think THIS document will end up defining a PPIM BIER prefix address family, and right now IMHO its too terse. Should have some ascii picture. There is also an "encoding type" typically. Aka:
IMHO something missing here in definition.

HB2> ok Addr family is really the PIM address family, it is the incoming PIM address family that we are signaling over BIER. I will change it to
| Addr Family:   pim address family as defined in [RFC7761]
| BIER Info:   IBBR Prefix (ipv4 or ipv6), SD, bfr-id

> HB> again as per above explanation we feel ECMP is beyond this draft. It is really a bier transport problem and any other draft addressing this should be taken into consideration for PIM signaling also.

This was primarily about the setting of the entropy field. 
I take your point that e.g.: rfc8556 doesn't mention entropy at all, but that doesn't make both documents equally "good", but rathr our solution description equally incomplete and subject to surprises for operators.

> HB> so we have tried this solution with static RP and it is working.

Yes, this was not a concern about not working, but about not being able to make the solution look attractive to any operator who does not have an SDN controller that can automate configuration.

> HB> That said I have no issue removing PIM-SM from the draft and make it just SSM base and reintroduce SM in later draft, but as I pointed out previously we tried to keep the draft general to signal any pim join prune etc..

Definitely think its good to see that the signaling this draft defines can potentially support all PIM messages, but yes, i would prefer to decide later on an ASM solution. 

Cheers
    Toerless

--
---
[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Oct 2019 20:34:53 -0700

Hi

While we all know SSM simplifies things, I see no reason to restrict this
solution to SSM. Whether to implement or deploy only the SSM solution is up
to vendors or operators, but I see no reason to prohibit ASM. As mentioned,
it works just fine with static RP. It would be a shame to limit the scope.

Stig

On Mon, Oct 28, 2019, 20:27 Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Subject: Re: [Bier] WG LC on
> https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>
> > HB> The original idea was this be a generic procedure to tunnel pim
> joins and prunes through a BIER domain. It didn't really care about SSM or
> SM. As an example our testing showed that static RP worked with this
> mechanism.
> The main issue is whether we want the document to be a standalone document
> to define a working, implementable and interoperable solution, or if this
> should just be some protocol encodings, and there would be another document
> describing how to build a working interoperable solution from it.
>
> If we stick we SSM, we have the smallest/easiest solution, and the
> document could be standalone. As soon as we think about ASM we get into the
> controversy between using the way PIM-SM/ASM is done in MVPN (which the
> document is currently hinting at) and newer mechanisms such as what i think
> Stig and I would favor/suggest.
>
> HB2> sure as I mentioned no issue I will say this is SSM only. Should add
> the static RP case? Or do we want that in separate draft also?
>
> > HB> With regards to ECMP. We really left this open to the
> implementation. As an example when a route request is done for a source of
> an pim join, internal algorithms can decide which BFER it should be
> forwarded to. To us this like any other ECMP implementation and it should
> be open.
> This document does not specify mechanisms for different BFER to select a
> single BFIR for the same multicast traffic flow. When sources are
> redundantly attached via more than one BFIR, this can lead to more than one
> BFIR forwarding the same multicast traffic into the BIER domain - towards
> different set of BFER.
>
> If the lookup for source results into multiple EBBRs, then the algorithm
> should ensure that all signaling for a particular (C-S, C-G) is forward to
> a single EBBR. How the this selection is done is application specific. As
> an example it can be round robin or smallest EBBR IP.
>
>
> > HB> not sure if I understand. We defined an EBBR as egress BIER boundary
> router. Obviously a BIER router is bound by RFC 8279 and the IGP/BGP
> extensions.
>
> 1. the BFER (iBBR) in question will look at the SPF from itself to the
> source of the multicast flow because this is what IGP SPF would calculate
> today. Right ?
>
> HB2> not really the EBBR tracks which IBBR is sending the pim signaling
> and stores the information in a table format as per section 3.3. If ECMP
> algorithm forward the (C-S, C-G) to a specific EBBR then that EBBR will
> note the BFR-ID of the IBBR and for that (C-S, C-G) it will always send the
> traffic back to that particular IBBR so even if the network is asymmetric
> EBBR knows how to forward the packet backward.
>
> Aka: would be good to have explanatory text about the implementation
> choice issues because otherwise we likely end up with non-interoperating
> implementations, or surprises by the amount of unnecessarily duplicated
> traffic with multiple BFIR, asymmetric path or multiple SD/BFR-ID
> combinations.
>
> Btw: the document says:
>
> RFC7761 does not define a "BIER prefix address family". Google couldn't
> find me another document where this term is used, so i think THIS document
> will end up defining a PPIM BIER prefix address family, and right now IMHO
> its too terse. Should have some ascii picture. There is also an "encoding
> type" typically. Aka:
> HB2> ok Addr family is really the PIM address family, it is the incoming
> PIM address family that we are signaling over BIER. I will change it to
> > HB> again as per above explanation we feel ECMP is beyond this draft. It
> is really a bier transport problem and any other draft addressing this
> should be taken into consideration for PIM signaling also.
>
> I take your point that e.g.: rfc8556 doesn't mention entropy at all, but
> that doesn't make both documents equally "good", but rathr our solution
> description equally incomplete and subject to surprises for operators.
>
> Yes, this was not a concern about not working, but about not being able to
> make the solution look attractive to any operator who does not have an SDN
> controller that can automate configuration.
>
> > HB> That said I have no issue removing PIM-SM from the draft and make it
> just SSM base and reintroduce SM in later draft, but as I pointed out
> previously we tried to keep the draft general to signal any pim join prune
> etc..
>
> Definitely think its good to see that the signaling this draft defines can
> potentially support all PIM messages, but yes, i would prefer to decide
> later on an ASM solution.
>
> Cheers
>     Toerless
>
> > > 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
> > >
>
> --
> ---
> [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Oct 2019 23:51:09 -0400

Watching this interesting thread from the side I would like to second what
Stig just said.

In many enterprise deployments all sources are receivers and vice versa
hence support of ASM makes a lot of sense here.

Kind regards,
Robert.

On Mon, Oct 28, 2019, 23:35 Stig Venaas <[email-masked]> wrote:

>> The main issue is whether we want the document to be a standalone
>> document to define a working, implementable and interoperable solution, or
>> if this should just be some protocol encodings, and there would be another
>> document describing how to build a working interoperable solution from it.
>>
>> > HB> not sure if I understand. We defined an EBBR as egress BIER
>> boundary router. Obviously a BIER router is bound by RFC 8279 and the
>> IGP/BGP extensions.
>>
>> today.. Right ?
>> > HB> again as per above explanation we feel ECMP is beyond this draft.
>> It is really a bier transport problem and any other draft addressing this
>> > HB> so we have tried this solution with static RP and it is working..
>>
>> Yes, this was not a concern about not working, but about not being able
>> to make the solution look attractive to any operator who does not have an
>> SDN controller that can automate configuration.
>>
>> > HB> That said I have no issue removing PIM-SM from the draft and make
>> it just SSM base and reintroduce SM in later draft, but as I pointed out
>> Definitely think its good to see that the signaling this draft defines
>> can potentially support all PIM messages, but yes, i would prefer to decide

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 28 Oct 2019 22:54:58 -0700

Same here, I see lots of ASM in enterprise networks.

Regards,
Jeff

> On Oct 28, 2019, at 20:51, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Watching this interesting thread from the side I would like to second what Stig just said.
> 
> In many enterprise deployments all sources are receivers and vice versa hence support of ASM makes a lot of sense here.
> 
> Kind regards,
> Robert.
> 
> 
> 
>> While we all know SSM simplifies things, I see no reason to restrict this solution to SSM. Whether to implement or deploy only the SSM solution is up to vendors or operators, but I see no reason to prohibit ASM. As mentioned, it works just fine with static RP. It would be a shame to limit the scope.
>> 
>> Stig
>> 
>> 
>>> On Mon, Oct 28, 2019, 20:27 Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]> wrote:
>>> 1. the BFER (iBBR) in question will look at the SPF from itself to the source of the multicast flow because this is what IGP SPF would calculate today... Right ?
>>> 
>>> > HB> so we have tried this solution with static RP and it is working...
>>>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 29 Oct 2019 21:19:44 +0100

Well... how would you like to see ASM being done in this document ?
RPT+SPT or what you proposed in a separate document ???

If we document the RPT+SPT approach in this document, nobody will
implement the newer/better solution. We know that from experience
(whatever the worst solution to a problem is, thats what the industry
uses).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Tue, 29 Oct 2019 13:34:30 -0700

Hi

What already is in the document works for me, allowing any PIM J/P,
regardless of ASM or SSM. You are suggesting that it talks about high
level scenarios though, right? Perhaps it is worth adding a section or
two with scenarios. If only SSM scenario is discussed, then I think it
should be pointed out that the solution is not limited to SSM. But
perhaps both SSM and ASM section can be added?

Alternatively, and maybe better, keep this document mostly as it is,
and have a separate informational document that discusses use cases
for this, as well as other BIER overlay mechanisms?

Stig

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 29 Oct 2019 21:46:58 +0000

I think it would be better idea, to keep this document as is. and have independent informational draft covering other case. 

> On Oct 29, 2019, at 1:34 PM, Stig Venaas <[email-masked]> wrote:
> 
> Hi
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 30 Oct 2019 02:58:07 +0000

Thanks all!

So just to ensure I got all info

1. I will add a section for ECMP
If the lookup for source results into multiple EBBRs, then the 
algorithm should ensure that all signaling for a particular (C-S, 
C-G) is forward to a single EBBR. How the this selection is done is 
application specific. As an example it can be round robin or smallest EBBR IP

2. change the AF to PIM AF

3. I am also in the same mindset as Stig and Mankamana, I think we should make the document about signaling PIM J/P through a BIER and point out that for some of the more involved SM/ASM protocols like auto-RP etc.. there is a need for extensions which will be available in future text.

Regards

Hooman

-----Original Message-----
From: Mankamana Mishra (mankamis) <[email-masked]> 
Sent: Tuesday, October 29, 2019 5:47 PM
To: Stig Venaas <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; BIER WG <[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

>>> While we all know SSM simplifies things, I see no reason to restrict 
>>> this solution to SSM. Whether to implement or deploy only the SSM 
>>> solution is up to vendors or operators, but I see no reason to 
>>> prohibit ASM. As mentioned, it works just fine with static RP. It would be a shame to limit the scope.
>>> 
>>> Stig
>>> 
>>> 
>>>>> HB> The original idea was this be a generic procedure to tunnel 
>>>>> HB> pim
>>>> joins and prunes through a BIER domain. It didn't really care about 
>>>> SSM or SM. As an example our testing showed that static RP worked 
>>>> with this mechanism.
>>>>> HB> that said if we feel we should specifically say this is SSM, I 
>>>>> HB> can
>>>> add a sentence.
>>>> 
>>>> document to define a working, implementable and interoperable 
>>>> solution, or if this should just be some protocol encodings, and 
>>>> there would be another document describing how to build a working interoperable solution from it.
>>>> 
>>>> document could be standalone. As soon as we think about ASM we get 
>>>> into the controversy between using the way PIM-SM/ASM is done in 
>>>> MVPN (which the document is currently hinting at) and newer 
>>>> mechanisms such as what i think Stig and I would favor/suggest.
>>>> 
>>>> HB2> sure as I mentioned no issue I will say this is SSM only. 
>>>> HB2> Should add
>>>> implementation. As an example when a route request is done for a 
>>>> source of an pim join, internal algorithms can decide which BFER it 
>>>> should be forwarded to. To us this like any other ECMP 
>>>> implementation and it should be open.
>>>>> HB> one implementation can decide the lower IP while the other 
>>>>> HB> would multihome base on (S,G)
>>>> 
>>>> This document does not specify mechanisms for different BFER to 
>>>> select a single BFIR for the same multicast traffic flow. When 
>>>> sources are redundantly attached via more than one BFIR, this can 
>>>> lead to more than one BFIR forwarding the same multicast traffic 
>>>> into the BIER domain - towards different set of BFER.
>>>> 
>>>> If the lookup for source results into multiple EBBRs, then the 
>>>> algorithm should ensure that all signaling for a particular (C-S, 
>>>> C-G) is forward to a single EBBR. How the this selection is done is 
>>>> application specific. As an example it can be round robin or smallest EBBR IP.
>>>> 
>>>> 
>>>>> HB> boundary
>>>> router. Obviously a BIER router is bound by RFC 8279 and the 
>>>> IGP/BGP extensions.
>>>> 
>>>> HB2> have you looked at the appendix  A? it explains how to find 
>>>> HB2> the EBBR
>>>> (aka BFIR)
>>>> 
>>>> 1. the BFER (iBBR) in question will look at the SPF from itself to 
>>>> the source of the multicast flow because this is what IGP SPF would 
>>>> calculate today. Right ?
>>>> 
>>>> HB2> not really the EBBR tracks which IBBR is sending the pim 
>>>> HB2> signaling
>>>> and stores the information in a table format as per section 3.3. If 
>>>> ECMP algorithm forward the (C-S, C-G) to a specific EBBR then that 
>>>> EBBR will note the BFR-ID of the IBBR and for that (C-S, C-G) it 
>>>> will always send the traffic back to that particular IBBR so even 
>>>> if the network is asymmetric EBBR knows how to forward the packet backward.
>>>> 
>>>> Aka: would be good to have explanatory text about the 
>>>> implementation choice issues because otherwise we likely end up 
>>>> with non-interoperating implementations, or surprises by the amount 
>>>> of unnecessarily duplicated traffic with multiple BFIR, asymmetric 
>>>> path or multiple SD/BFR-ID combinations.
>>>> 
>>>> Btw: the document says:
>>>> 
>>>> RFC7761 does not define a "BIER prefix address family". Google 
>>>> couldn't find me another document where this term is used, so i 
>>>> think THIS document will end up defining a PPIM BIER prefix address 
>>>> family, and right now IMHO its too terse. Should have some ascii 
>>>> picture. There is also an "encoding type" typically. Aka:
>>>> HB2> ok Addr family is really the PIM address family, it is the 
>>>> HB2> incoming
>>>>> HB> again as per above explanation we feel ECMP is beyond this 
>>>>> HB> draft. It
>>>> is really a bier transport problem and any other draft addressing 
>>>> this should be taken into consideration for PIM signaling also.
>>>> 
>>>> I take your point that e.g.: rfc8556 doesn't mention entropy at 
>>>> all, but that doesn't make both documents equally "good", but rathr 
>>>> our solution description equally incomplete and subject to surprises for operators.
>>>> 
>>>>>       is not a good expectation. Most PIM domains use either some 
>>>>> old
>>>> Cisco
>>>>>       - Even if we knew the PIM-SM RPs on the LHR, i do not like 
>>>>> the
>>>> resulting
>>>> Yes, this was not a concern about not working, but about not being 
>>>> able to make the solution look attractive to any operator who does 
>>>> not have an SDN controller that can automate configuration.
>>>> 
>>>>> HB> That said I have no issue removing PIM-SM from the draft and 
>>>>> HB> make it
>>>> just SSM base and reintroduce SM in later draft, but as I pointed 
>>>> out previously we tried to keep the draft general to signal any pim 
>>>> join prune etc..
>>>> 
>>>> Definitely think its good to see that the signaling this draft 
>>>> defines can potentially support all PIM messages, but yes, i would 
>>>> prefer to decide later on an ASM solution.
>>>> 
>>>> Cheers
>>>>    Toerless
>>>> 
>>>>>   duing burst-collisions (such as reconvergence events etc.). BGP 
>>>>> or
>>>> PORT
>>>>>   solve this issue.
>>>>> 
>>>>>   Aka: I would suggest to say the join/prune signaling should be 
>>>>> via
>>>> PORT.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 30 Oct 2019 08:05:46 +0100

On Tue, Oct 29, 2019 at 01:34:30PM -0700, Stig Venaas wrote:
> regardless of ASM or SSM.

Describing the message encoding options is not the same
as specifying a protocol. Its like PIM-SM message format section
without the sections describing the protocol state machinery.

> You are suggesting that it talks about high
> level scenarios though, right?

In the past we called this just "protocols/protocol-options",
not "high-levels cenarios", but i take whatever the hip new term
is to ensure implementers and operators can develop and deploy
working solutions.
  
  - SSM: PIM-SSM with explicit neighbor tracking+BitString mapping

  - ASM:
    - PIM-SSM with explicit neighbor tracking+BitString mapping
      + flooding of active (S,G)
    - PIM-SM with explicit neighbor tracking+BitString mapping
      a) RPT only
      b) RPT + SPT switchover, no prune of RPT
      c) RPT + SPT switchover, prune of RPT

Btw: In the PIM-SSM solution for ASM, we do also have the issue
of getting the active (S,G) information to the BFIR that should
flood this information - in all cases where those BFIR are not
PIM FHR (connected to sources). Aka: must operate as RPs.

This stuff is all same or similar to MVPN issues, except that
i am sure we need a better standalone documentation of these
protocol details when we want to get PIM over BIER deployed
anywhere: Nobody who deploys MVPN (with BGP signaling) will use
PIM over BIER. SO its all going to be new/different customer spaces
(Enterprise etc.), and you can't tell them to just figure out
what they need to do by reading up on 20 years of MVPN documents.

If anyone goes for PIM over BIER instead of MVPN over BIER, then
only if its made simpler, and thats not achieved if customers
need to stitch together how to make it work from non-existing
documentation/protocol-descriptions.

> for this, as well as other BIER overlay mechanisms?

I certainly would not call it use-cases. To me this is just
protocol specification for the different ASM options, and
we need to decide if we want to describe all of them because
that would encourage all of them. But in any case, i would not like
to see ONLY the PIM-SM options described with the flooding of active
(S,G) option.

My proposal was to keep this document to:

I) Message encoding (supporting all possible PIM-(S)SM message options)
II) Describing how to do SSM service

Then another document could add description of the options for the
ASM service as listed above.

Or delay the document further to add all the ASM options into this
document.

Cheers
    toerless

-- 
---
[email-masked]

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 30 Oct 2019 16:31:18 +0000

Ho Toerless,
Thanks for detail feedback.  My recommendation is

  *   Progress this document as is, may be add statement that detail ASM procedure would be out of scope for this document & it is going to be covered in next document.
  *   Lets meet in Singapore, and come up with overall framework to be covered in new document & publish new with more detail .

Since this document has already passed many stages, adding too much extra text is going to bring it back to start :) .

Mankamana

On Oct 30, 2019, at 12:05 AM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

 - ASM:

Cheers
   toerless

Stig

On Tue, Oct 29, 2019 at 1:19 PM Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
   Toerless

Stig

On Mon, Oct 28, 2019, 20:27 Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]<mailto:[email-masked]>> wrote:

Regards

Hooman

-----Original Message-----
From: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Sent: Monday, October 28, 2019 4:02 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WG LC on

On Sat, Oct 26, 2019 at 08:34:01PM +0000, Bidgoli, Hooman (Nokia -
CA/Ottawa) wrote:
HB> The original idea was this be a generic procedure to tunnel pim
joins and prunes through a BIER domain. It didn't really care about SSM or
SM. As an example our testing showed that static RP worked with this
mechanism.
HB> that said if we feel we should specifically say this is SSM, I can
add a sentence.

HB2> have you looked at the appendix  A? it explains how to find the EBBR
(aka BFIR)

2. It would then along the path try to find the first router (from
itself) that is announcing a BIER extension. From that it learns the
BFR-ID to send the join to. Right ?

The problems i can think of apart from the aforementioned case of more
than one BFIR because of ECMP:

Btw: the document says:

      is not a good expectation. Most PIM domains use either some old

      - Even if we knew the PIM-SM RPs on the LHR, i do not like the
resulting

Cheers
   Toerless

  The related (but really independent) concern is: SHould we
  reintroduce NOW a scheme that uses unreliable datagram signaling
  for join/prune (across a potentially multi-hop WAN path), when we went
  through the exercise and concluded we need better: Aka: Original
multicast
  VPN Default/Data-MDP used PIM (datagrams) and those packets got lost
  duing burst-collisions (such as reconvergence events etc.). BGP or
PORT
  solve this issue.

  Aka: I would suggest to say the join/prune signaling should be via
PORT.
  The PORT messaged can be over unicast or BIER based on the answer to
  above question.

Cheers
   Toerless

--- tony

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--
---
[email-masked]<mailto:[email-masked]>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--
---
[email-masked]<mailto:[email-masked]>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 30 Oct 2019 14:51:10 -0700

Hi Toerless, please see inline.

> without the sections describing the protocol state machinery.

I agree we need to specify the protocol in here. I mentioned some
missing parts in my review. It needs to state that there are no pim
hellos and what the expected capabilities are, since not announced by
hello. Also needs to mention that explicit tracking is done, and no
asserts.

> is to ensure implementers and operators can develop and deploy

I assumed you meant at a high level, because I don't see how we need
to explain SSM/ASM in the protocol.

>   - SSM: PIM-SSM with explicit neighbor tracking+BitString mapping

Yes, it needs to state that explicit tracking is done.

>       + flooding of active (S,G)

This doesn't change the pim protocol. For ASM you would still send PIM
registers.

>       c) RPT + SPT switchover, prune of RPT

This should be as today. Option a or c, depending on whether last-hop
switches to SPT.

> PIM FHR (connected to sources). Aka: must operate as RPs.

FHR sends registers as today. RP can be located anywhere. Registers
are sent as unicast and require no special handling.

> This stuff is all same or similar to MVPN issues, except that

I don't see how this is similar to MVPN. It is more like treating a
BIER domain as a LAN from PIM perspective. Except explicit tracking
and no asserts on the LAN.
This "BIER LAN" can be in the middle of some PIM domain, without
changing how PIM operates (except on that BIER LAN).

One issue worth pointing out though, is that we haven't defined how to
do BSR over BIER, but static RP configuration would work fine. Also
embedded-RP for IPv6.

Stig

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 31 Oct 2019 15:55:21 +0000

Stig/Toerless

Thanks for comments

So what I am hearing is that we will keep the document scope the same i.e."  This document describes the procedure needed for PIM J/P to be signaled through a BIER core.

That said I am still not 100% sure what we want to put in the section 5 PIM-SM behavior? Is the following sufficient?

This procedure can work with ASM as long as static RP or embedded RP for IPv6  is used. Future drafts would cover BSR and more complicated SM discovery mechanisms. 
It should be noted that this draft only signals PIM Joins and Prunes through the BIER domain and not any other PIM message types including PIM Hellos or Asserts. As such functionality related to these other type of massages will not be possible through a BIER domain with this draft and future drafts might cover these scenarios. 
As an example DR selection should be done in the PIM domain or if the PIM routers attached to IBBRs are performing DR selection there needs to be a dedicated PIM interface between these routers.

Regards

Hooman

-----Original Message-----
From: Stig Venaas <[email-masked]> 
Sent: Wednesday, October 30, 2019 5:51 PM
To: Toerless Eckert <[email-masked]>
Cc: BIER WG <[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

On Wed, Oct 30, 2019 at 12:05 AM Toerless Eckert <[email-masked]> wrote:
> Describing the message encoding options is not the same as specifying 
> a protocol. Its like PIM-SM message format section without the 
> sections describing the protocol state machinery.

I agree we need to specify the protocol in here. I mentioned some missing parts in my review. It needs to state that there are no pim hellos and what the expected capabilities are, since not announced by hello. Also needs to mention that explicit tracking is done, and no asserts.

> > You are suggesting that it talks about high level scenarios though, 
> > right?
>
> In the past we called this just "protocols/protocol-options", not 
> "high-levels cenarios", but i take whatever the hip new term is to 
> ensure implementers and operators can develop and deploy working 
> solutions.

I assumed you meant at a high level, because I don't see how we need to explain SSM/ASM in the protocol.

>       + flooding of active (S,G)

This doesn't change the pim protocol. For ASM you would still send PIM registers.

>       c) RPT + SPT switchover, prune of RPT

This should be as today. Option a or c, depending on whether last-hop switches to SPT.

> Btw: In the PIM-SSM solution for ASM, we do also have the issue of 
> getting the active (S,G) information to the BFIR that should flood 
> this information - in all cases where those BFIR are not PIM FHR 
> (connected to sources). Aka: must operate as RPs.

FHR sends registers as today. RP can be located anywhere. Registers are sent as unicast and require no special handling.

> This stuff is all same or similar to MVPN issues, except that

I don't see how this is similar to MVPN. It is more like treating a BIER domain as a LAN from PIM perspective. Except explicit tracking and no asserts on the LAN.
This "BIER LAN" can be in the middle of some PIM domain, without changing how PIM operates (except on that BIER LAN).

One issue worth pointing out though, is that we haven't defined how to do BSR over BIER, but static RP configuration would work fine. Also embedded-RP for IPv6.

Stig

> i am sure we need a better standalone documentation of these protocol 
> details when we want to get PIM over BIER deployed
> anywhere: Nobody who deploys MVPN (with BGP signaling) will use PIM 
> over BIER. SO its all going to be new/different customer spaces 
> (Enterprise etc.), and you can't tell them to just figure out what 
> they need to do by reading up on 20 years of MVPN documents.
>
> If anyone goes for PIM over BIER instead of MVPN over BIER, then only 
> if its made simpler, and thats not achieved if customers need to 
> stitch together how to make it work from non-existing 
> > two with scenarios. If only SSM scenario is discussed, then I think 
> > it should be pointed out that the solution is not limited to SSM. 
> > But perhaps both SSM and ASM section can be added?
> >
> I certainly would not call it use-cases. To me this is just protocol 
> specification for the different ASM options, and we need to decide if 
> we want to describe all of them because that would encourage all of 
> them. But in any case, i would not like to see ONLY the PIM-SM options 
> described with the flooding of active
> (S,G) option.
>
> Then another document could add description of the options for the ASM 
> service as listed above.
>
> > > (whatever the worst solution to a problem is, thats what the 
> > > industry uses).
> > >
> > > Cheers
> > >     Toerless
> > >
> > > > While we all know SSM simplifies things, I see no reason to 
> > > > restrict this solution to SSM. Whether to implement or deploy 
> > > > only the SSM solution is up to vendors or operators, but I see 
> > > > no reason to prohibit ASM. As mentioned, it works just fine with static RP. It would be a shame to limit the scope.
> > > >
> > > > Stig
> > > >
> > > >
> > > > On Mon, Oct 28, 2019, 20:27 Bidgoli, Hooman (Nokia - CA/Ottawa) 
> > > > < [email-masked]> wrote:
> > > >
> > > > > > HB> The original idea was this be a generic procedure to 
> > > > > > HB> tunnel pim
> > > > > joins and prunes through a BIER domain. It didn't really care 
> > > > > about SSM or SM. As an example our testing showed that static 
> > > > > RP worked with this mechanism.
> > > > > > HB> that said if we feel we should specifically say this is 
> > > > > > HB> SSM, I can
> > > > > add a sentence.
> > > > >
> > > > > The main issue is whether we want the document to be a 
> > > > > standalone document to define a working, implementable and 
> > > > > interoperable solution, or if this should just be some 
> > > > > protocol encodings, and there would be another document describing how to build a working interoperable solution from it.
> > > > >
> > > > > If we stick we SSM, we have the smallest/easiest solution, and 
> > > > > the document could be standalone. As soon as we think about 
> > > > > ASM we get into the controversy between using the way 
> > > > > PIM-SM/ASM is done in MVPN (which the document is currently 
> > > > > hinting at) and newer mechanisms such as what i think Stig and I would favor/suggest.
> > > > >
> > > > > implementation. As an example when a route request is done for 
> > > > > a source of an pim join, internal algorithms can decide which 
> > > > > BFER it should be forwarded to. To us this like any other ECMP 
> > > > > > HB> one implementation can decide the lower IP while the 
> > > > > > HB> other would multihome base on (S,G)
> > > > >
> > > > > This document does not specify mechanisms for different BFER 
> > > > > to select a single BFIR for the same multicast traffic flow. 
> > > > > When sources are redundantly attached via more than one BFIR, 
> > > > > this can lead to more than one BFIR forwarding the same 
> > > > > multicast traffic into the BIER domain - towards different set of BFER.
> > > > >
> > > > > algorithm should ensure that all signaling for a particular 
> > > > > (C-S, C-G) is forward to a single EBBR. How the this selection 
> > > > > is done is application specific. As an example it can be round robin or smallest EBBR IP.
> > > > >
> > > > >
> > > > > > HB> not sure if I understand. We defined an EBBR as egress 
> > > > > > HB> BIER boundary
> > > > > HB2> have you looked at the appendix  A? it explains how to 
> > > > > HB2> find the EBBR
> > > > > (aka BFIR)
> > > > >
> > > > > 1. the BFER (iBBR) in question will look at the SPF from 
> > > > > itself to the source of the multicast flow because this is 
> > > > > what IGP SPF would calculate today. Right ?
> > > > >
> > > > > itself) that is announcing a BIER extension. From that it 
> > > > > learns the BFR-ID to send the join to. Right ?
> > > > >
> > > > > and stores the information in a table format as per section 
> > > > > 3.3. If ECMP algorithm forward the (C-S, C-G) to a specific 
> > > > > EBBR then that EBBR will note the BFR-ID of the IBBR and for 
> > > > > that (C-S, C-G) it will always send the traffic back to that 
> > > > > particular IBBR so even if the network is asymmetric EBBR knows how to forward the packet backward.
> > > > >
> > > > > implementation choice issues because otherwise we likely end 
> > > > > up with non-interoperating implementations, or surprises by 
> > > > > the amount of unnecessarily duplicated traffic with multiple 
> > > > > BFIR, asymmetric path or multiple SD/BFR-ID combinations.
> > > > >
> > > > > Btw: the document says:
> > > > >
> > > > > couldn't find me another document where this term is used, so 
> > > > > i think THIS document will end up defining a PPIM BIER prefix 
> > > > > address family, and right now IMHO its too terse. Should have 
> > > > > some ascii picture. There is also an "encoding type" typically. Aka:
> > > > > HB2> ok Addr family is really the PIM address family, it is 
> > > > > HB2> the incoming
> > > > > > HB> again as per above explanation we feel ECMP is beyond 
> > > > > > HB> this draft. It
> > > > > is really a bier transport problem and any other draft 
> > > > > addressing this should be taken into consideration for PIM signaling also.
> > > > >
> > > > > I take your point that e.g.: rfc8556 doesn't mention entropy 
> > > > > at all, but that doesn't make both documents equally "good", 
> > > > > but rathr our solution description equally incomplete and subject to surprises for operators.
> > > > >
> > > > > Yes, this was not a concern about not working, but about not 
> > > > > being able to make the solution look attractive to any 
> > > > > operator who does not have an SDN controller that can automate configuration.
> > > > >
> > > > > > HB> That said I have no issue removing PIM-SM from the draft 
> > > > > > HB> and make it
> > > > > just SSM base and reintroduce SM in later draft, but as I 
> > > > > pointed out previously we tried to keep the draft general to 
> > > > > signal any pim join prune etc..
> > > > >
> > > > > defines can potentially support all PIM messages, but yes, i 
> > > > > would prefer to decide later on an ASM solution.
> > > > >
> > > > > Cheers
> > > > >     Toerless
> > > > >
> > > > > https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling
> > > > > / per request and consensus @ IETF 102 ???
> > > > > > >
> > > > > > > --- tony
> > > > > > >
> > > > >
> > > > > --
> > > > > ---
> > > > > [email-masked]