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

[Stig Venaas <[e-mail]>]

I'm on holiday this week and haven't checked that carefully, but it looks
like several last call comments I made are not addressed. Apart from
editorial comments, I still think it is necessary to have some text about
there not being pim neighborships, what pim capabilities are assumed, and
that there are no asserts. I'll have a closer look later.

Stig


On Thu, Nov 21, 2019, 09:32 Toerless Eckert <[e-mail]> wrote:

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