Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
Toerless Eckert <tte@cs.fau.de> Tue, 29 October 2019 20:19 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4A11200E3 for <bier@ietfa.amsl.com>; Tue, 29 Oct 2019 13:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVUPmBrHX3WH for <bier@ietfa.amsl.com>; Tue, 29 Oct 2019 13:19:51 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1D012001E for <bier@ietf.org>; Tue, 29 Oct 2019 13:19:50 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B7C37548026; Tue, 29 Oct 2019 21:19:44 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B1F5E440015; Tue, 29 Oct 2019 21:19:44 +0100 (CET)
Date: Tue, 29 Oct 2019 21:19:44 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Stig Venaas <stig@venaas.com>
Cc: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, BIER WG <bier@ietf.org>
Message-ID: <20191029201944.GE24806@faui48f.informatik.uni-erlangen.de>
References: <20191024152401.GA24806@faui48f.informatik.uni-erlangen.de> <DB7PR07MB47454939E389C61D765EA35891640@DB7PR07MB4745.eurprd07.prod.outlook.com> <20191028080131.GC24806@faui48f.informatik.uni-erlangen.de> <DB7PR07MB4745D595FB417013F944018F91610@DB7PR07MB4745.eurprd07.prod.outlook.com> <CAHANBt+fa_P8PDrczXEwYqMCNtoU3_pzFZA2UYXdr4aoU57W0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHANBt+fa_P8PDrczXEwYqMCNtoU3_pzFZA2UYXdr4aoU57W0g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/nYjIIy8lujI7T6RARUumHYQNgOg>
Subject: Re: [Bier] WG LC on https://datatracker.ietf.org/doc/draft-ietf-bier-pim-signaling/
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 20:19:55 -0000
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) < > hooman.bidgoli@nokia.com> wrote: > > > Adding the working group as well, inline HB2> > > > > Regards > > > > Hooman > > > > > > -----Original Message----- > > From: Toerless Eckert <tte@cs.fau.de> > > Sent: Monday, October 28, 2019 4:02 AM > > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com> > > 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 > > > > > > > > -- > > --- > > tte@cs.fau.de > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de
- [Bier] WG LC on https://datatracker.ietf.org/doc/… Antoni Przygienda
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeff Tantsura
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Dolganow, Andrew (Nokia - SG/Singapore)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Purkayastha, Debashish
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nabeel Cocker
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nagendra Kumar Nainar (naikumar)
- Re: [Bier] WG LC onhttps://datatracker.ietf.org/d… zhang.zheng
- [Bier] 答复: WG LC onhttps://datatracker.ietf.org/d… chen.ran
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeffrey (Zhaohui) Zhang
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Eric Rosen
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeffrey (Zhaohui) Zhang
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Eric Rosen
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Greg Shepherd
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nabeel Cocker
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeffrey (Zhaohui) Zhang
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Robert Raszuk
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Jeff Tantsura
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Toerless Eckert
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Stig Venaas
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Greg Shepherd
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Greg Shepherd
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Mankamana Mishra (mankamis)
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Nabeel Cocker
- Re: [Bier] WG LC on https://datatracker.ietf.org/… Bidgoli, Hooman (Nokia - CA/Ottawa)