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

[Toerless Eckert <[e-mail]>]

+1 now for handing to IESG.

On Fri, Nov 01, 2019 at 07:05:52PM +0000, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:
> Uploaded version 8 with the 3 new subjects discussed in this email.
> 
> 1. ECMP
> 2. PIM AF
> 3. SM clarification
> 
> Regards
> 
> Hooman
> 
> 
> -----Original Message-----
> From: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> Sent: Tuesday, October 29, 2019 10:58 PM
> To: Mankamana Mishra (mankamis) <[e-mail]>; Stig Venaas <[e-mail]>
> Cc: Toerless Eckert <[e-mail]>; BIER WG <[e-mail]>
> Subject: RE: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
> 
> 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) <[e-mail]>
> Sent: Tuesday, October 29, 2019 5:47 PM
> To: Stig Venaas <[e-mail]>
> Cc: Toerless Eckert <[e-mail]>; 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/
> 
> 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 <[e-mail]> wrote:
> > 
> > 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
> > 
> > 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 
> >>>>> 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.
> >>>> 
> >>>> 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 other 
> >>>>> HB> 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 BIER 
> >>>>> HB> 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 
> >>>> 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 ?
> >>>> 
> >>>> 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 the 
> >>>> HB2> 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 
> >>>>> HB> 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 
> >>>>> 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
> >>>> 
> >>>>>       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
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[e-mail]