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

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

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 <[e-mail]> 
Sent: Wednesday, October 30, 2019 5:51 PM
To: Toerless Eckert <[e-mail]>
Cc: BIER WG <[e-mail]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Hi Toerless, please see inline.

On Wed, Oct 30, 2019 at 12:05 AM Toerless Eckert <[e-mail]> wrote:
>
> On Tue, Oct 29, 2019 at 01:34:30PM -0700, Stig Venaas wrote:
> > Hi
> >
> > What already is in the document works for me, allowing any PIM J/P, 
> > 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.

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.

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

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

>   - ASM:
>     - PIM-SSM with explicit neighbor tracking+BitString mapping
>       + flooding of active (S,G)

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

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

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 
> documentation/protocol-descriptions.
>
> > 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?
>
> 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
>
> > Stig
> >
> > On Tue, Oct 29, 2019 at 1:19 PM Toerless Eckert <[e-mail]> wrote:
> > >
> > > 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
> > >
> > > On Mon, Oct 28, 2019 at 08:34:53PM -0700, Stig Venaas wrote:
> > > > 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) 
> > > > < [e-mail]> wrote:
> > > >
> > > > > Adding the working group as well, inline HB2>
> > > > >
> > > > > Regards
> > > > >
> > > > > Hooman
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Toerless Eckert <[e-mail]>
> > > > > Sent: Monday, October 28, 2019 4:02 AM
> > > > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> > > > > <[e-mail]>
> > > > > 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 
> > > > > > 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.
> > > > >
> > > > > HB2> sure as I mentioned no issue I will say this is SSM only. 
> > > > > HB2> 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 
> > > > > > HB> other would 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.
> > > > >
> > > > >
> > > > > >     - 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).
> > > > > >
> > > > > > HB> not sure if I understand. We defined an EBBR as egress 
> > > > > > HB> 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 
> > > > > 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 ?
> > > > >
> > > > > 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 
> > > > > 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: 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 
> > > > > HB2> 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
> > > > >
> > > > > >     - 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.
> > > > > >
> > > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > >     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.
> > > > > >
> > > > > >
> > > > > > 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 
> > > > > > 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..
> > > > >
> > > > > 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
> > > > >
> > > > > >        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
> > > > > > >
> > > > >
> > > > > --
> > > > > ---
> > > > > [e-mail]
> > > > > _______________________________________________
> > > > > BIER mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/bier
> > > > >
> > >
> > > > _______________________________________________
> > > > BIER mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/bier
> > >
> > >
> > > --
> > > ---
> > > [e-mail]
> >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
>
> --
> ---
> [e-mail]