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

[Jeff Tantsura <[e-mail]>]

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

Regards,
Jeff

> On Oct 28, 2019, at 20:51, Robert Raszuk <[e-mail]> 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.
> 
> 
> 
>> On Mon, Oct 28, 2019, 23:35 Stig Venaas <[e-mail]> 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
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier