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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Stig

Inline (HB>)

Regards

Hooman

-----Original Message-----
From: Stig Venaas <[e-mail]> 
Sent: Monday, December 9, 2019 1:13 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
Cc: Toerless Eckert <[e-mail]>; Mankamana Mishra (mankamis) <[e-mail]>; BIER WG <[e-mail]>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/

Hi

I offered to provide text on some details related to how there are no hellos and asserts etc. But I also see that many (none?) of the WGLC comments I provided on September 24th have been addressed in revision 08. Can the authors please try to address those first? The authors know pim quite well, and should be able to improve the document. I'll help provide some text if needed though.

I think my main pim issues are:

o The text makes it look like joins are forwarded rather than sent hop-by-hop.

HB> I am not sure if I understand this point? The joints are not send hop-by-hop they are forwarded encapsulated in BIER through the BIER domain. 

o RFC 7761 requires pim hellos, so it must be pointed out clearly that joins are sent to unknown neighbors, and also that it is assumed that the neighbors support join attributes without relying on hellos to determine this. Are there other capabilities we are assuming? They should be listed.

HB> again I think in section 3 we have clearly documented the purpose of this document, it is not to crate PIM adjacency through a BIER domain as per paragraph below

" The BBR will create PIM adjacency between all
   the PIM routers attached to it on the PIM domain. That said the BBR
   does not propagate all PIM packets natively into the BIER domain.
   Instead when it determines that the PIM join or prune messages needs
   to be signaled through the BIER domain it will tunnel the PIM packet
   through the BIER network. This tunneling is only done for signaling
   purposes and not for creating a PIM adjacency between the two
   disjoint PIM domains through the BIER domain."

HB> again in section 5
" It should be noted that this draft only signals PIM Joins and Prunes
   through the BIER domain and not any other PIM message types including
   PIM Hellos or Asserts."

HB> IMO these 2 paragraphs are very Clear, this is why I am suggesting if you or any other of the authors have any specific text in mind please provide the text and I will add it to the next revision. 


o Should point out that explicit tracking is always done, there is no join override, and no asserts.

HB> ok let work on this one

Stig



Stig

On Wed, Nov 27, 2019 at 3:32 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]> wrote:
>
> Hi Stig
>
> Much appreciated!
>
> Regards
>
> Hooman
>
> Get Outlook for iOS
> ________________________________
> From: Stig Venaas <[e-mail]>
> Sent: Tuesday, November 26, 2019 11:37:34 PM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
> Cc: Toerless Eckert <[e-mail]>; Mankamana Mishra (mankamis) 
> <[e-mail]>; BIER WG <[e-mail]>
> Subject: Re: [Bier] WG LC on 
> https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>
> Hi
>
> It does partly address them. I still think a bit more detail is needed since pim normally relies on neighborships, and hello options for capabilities. I'll try to propose some text next week when back from vacation.
>
> Stig
>
>
> On Tue, Nov 26, 2019, 22:37 Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]> wrote:
>
> Hi Stig
>
>
>
> Please read the latest uploaded draft…
>
>
>
> For pim neighborships is the blow text in draft sufficient?
>
>
>
>    “That said the BBR
>
>    does not propagate all PIM packets natively into the BIER domain.
>
>    Instead when it determines that the PIM join or prune messages 
> needs
>
>    to be signaled through the BIER domain it will tunnel the PIM 
> packet
>
>    through the BIER network. This tunneling is only done for signaling
>
>    purposes and not for creating a PIM adjacency between the two
>
>    disjoint PIM domains through the BIER domain.”
>
>
>
>
>
> For PIM Asserts and SM please read the PIM-SM behavior
>
>
>
> It should be noted that this draft only signals PIM Joins and Prunes
>
>    through the BIER domain and not any other PIM message types 
> including
>
>    PIM Hellos or Asserts.
>
>
>
> Do these address your concerns? If not could you please suggest a text? Thanks in advance.
>
>
> Regards
>
>
>
> Hooman
>
>
>
> From: Stig Venaas <[e-mail]>
> Sent: Monday, November 25, 2019 11:39 PM
> To: Toerless Eckert <[e-mail]>
> Cc: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; 
> Mankamana Mishra (mankamis) <[e-mail]>; BIER WG 
> <[e-mail]>
> Subject: Re: [Bier] WG LC on 
> https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
>
>
>
> 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 
> > >>>>> HB> 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 
> > >>>>> HB> 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.
> > >>>> 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 
> > >>>>> HB> 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 
> > >>>> HB2> 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 
> > >>>> 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 
> > >>>>> HB> 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
> >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
>
> --
> ---
> [e-mail]