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

[Stig Venaas <[e-mail]>]

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