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