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

[Stig Venaas <[e-mail]>]

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