[Bier] Compare BIER-TE (was: Re: Call for adoption: draft-eckert-bier-te-arch)

[Toerless Eckert <[e-mail]>]

[ Sorry for long response. Greg brings up an aspect that we had long discussions
about outside the IETF and for which we could not find so far a good place to document
or discuss in the IETF. ]

Hi Greg

Can you point to any documents describing the solutions you suggest ?
I am not aware of any IETF drafted descriptions.

Discussing your points:

1. I am not sure how an RSVP-TE (RFC3209) solution could work. If you mean
an RSVP-TE/P2MP (RFC4857) based solution:

  - BIER-TE like BIER is meant to be more lightweight, it does not have tree state
    in the network. For example, different BIER-TE bitstrings can deliver traffic
    over paths not used by existing bitstrings without the need to signal and the
    need for new state for such bitstrings. In RSVP-TE/P2MP, using any such
    paths would require new signaling=load=delay=tracking amount of total state
    across trees in the network.

  - AFAIK, RSVP-TE/MP2MP was not worked out as an RFC (due to complexity),
    so one needs to be aware that you need the more state the more BFIR (ingres
    routers) you want to support. Aka: one RSVP-TE/P2MP tree per BFIR. No
    ability to share a common MP2MP tree. There is no such limitation
    and scale issue in BIER and BIER-TE.

  - Integrating RSVP-TE/P2MP with BIER would IMHO require additional
    extensions to RSVP-TE/P2MP: For example, you would signal for each leaf
    a bit index, and then the LSRs could calculate which bitset to send to
    which branch.

  - In summary: If you like RSVP-TE/P2MP adnd you just need a way to have an option
    of determining on a per-packet basis which subset of leaf LSR of an existing
    tree this backet needs to be delivered, then yes. That can be done. But
    thats a fundamentally different solution approach from what BIER-TE is
    supporting.

2. Using SR: The goal of BIER-TE was to come up with an equivalent lightweight
   solution compared to RSVP-TE/P2MP as SR is in relationship to RSVP-TE/P2P.
   Aka: BIER-TE is meant to be the best BIER multicast style equivalent to SR.
   And this search for simplicity was not based on "Must be BIER". Instead,
   using bitstrings and calling it BIER-TE just resulted from a broader look
   at the solution space:

   The "natural" approach to creating a multicast equivalent to SR would have
   been to create a label stack that included all replicating and leaf LSR
   as well as the sequencing of those LSR (aka: the whole tree graph).
   As it turns out, if you want to do this, you end up trying to compress this
   description more and more - creating really hard to look up and process
   compressed label-tree stacks... to finally arrive at the conclusion that its all either
   too complex to parse or does not scale to enough nodes - until you finally
   come to the conclusion that individual bits for repplication and receiver
   nodes is about the best solution both for processing simplicity and scale.
   And that in result makes it a BIER style solution because it shares a most
   in forwarding and architecture details with BIER.

3. You can of course explicitly configure multipoint trees with label swap and
   replicate if you do have some controller system and label forwarding
   programmability with replication (last time i looked i could not find replication
   in IETF drafts, but it should obviously be there.). The way i understand it, this
   approach has been demonstrated by a vendor and called "spray multicast".

   If i where to characterize it:

   - There will be like with RSVP-TE per-tree state ("labels") in the network,
     every new tree, receiver(branch) change, path change requires signaling.
     The state in the forwarding plane would be pretty similar to RSVP-TE/P2MP
     (in terms of labels).
   
   - Because the forwarding state would (from my best guess) be most likely 
     equivalent to RSVP-TE/P2MP with loose EROs, this is (IMHO) really NOT
     a solution what i thought to understand to be in the spirit of SR:
     simplify/remove state and signaling from the network by making it source label
     stack driven: In fact, as explained above, i could rather
     call BIER-TE "SR-P2MP with maximum compressed labels"  because
     it really is in this respect a multicast equivalent of to the spirit
     of unicast SR.
   
   - Now, one needs to understand that the fact that this solution does not
     take the signaling out of the network but instead moves it from the ingres LSR
     to a controller has some key implications:
     - In RSVP-TE, re-computation happens in parallel on ingres LSR. In the "SR"
       solution it likely would be all in the controller. The signaling then 
       would have also a different RTT profile than coming from all the ingres LSR.
     - On the good side, with this approach it would be quite easy to construct
       MP2MP trees, something that was difficult (and AFAIK therefore not standardized
       in RSVP-TE).

4. I am not aware what a "PCE" solution without the above mentioned
   RSVP-TE/P2MP or "Label-programmed-trees(SR)"  would be. In my understanding,
   a PCE is optional with RSVP-TE/P2MP but would be pretty much the mandatory
   piece in the "label-programmed-trees(SR)" approach as it is in BIER-TE
   (unless you want to manually configure label P2MP-PVCs, something i've stopped doing
    when i quit using X.25 23 years ago ;-).

5. The BIER-TE FRR draft attempts to address the comparisons of the different
   resilience solutions with BIER-TE. Of course, resilience could also be added
   to BIER. I would be happy to help getting that documented if the WG has interest.
   It seems you might be interested in that ? I am not clear whether it should be
   in a different document from BIER-TE-FRR or if we rather should expand the
   scope of BIER-TE-FRR to BIER-(TE)-FRR to avoid duplication of description of
   common approaches (like using RFC4090). I think a single document could be more
   comprehensive in relating/comparing the properties of the different options.

   Would you be interested in co-authoring either approach ?

So, in summary:

- Thanks for bringing up the thought of comparing with other solution approaches.

- I hope my reply shows and explains the unique nature of BIER-TE in comparison
  to other (AFAIK not documented) possible alternatives and the value it can bring
  to deployments interested in the simplicy of BIER but with TE features in the spirit of SR.

- I would be happy about any advice how to better document comparisons
  both of the multipoint solutions ass well as redundancy options.

Cheers
    Toerless

On Mon, Aug 07, 2017 at 01:59:54PM -0700, Greg Mirsky wrote:
> Dear WG Chairs, Authors, et.al,
> when I read a draft brought to a WG adoption call I try to answer these
> three questions:
> 
>    1. Is the draft reasonably well written?
>    2. Does the problem the draft addresses closes technological and/or
>    functional gap?
>    3. Is the proposed solution viable, technically sound?
> 
> I found the both drafts very well written.
> I believe that what being proposed by BIER-TE already can be achieved by
> overlaying BIER domain over traffic engineered, RSVP-TE, PCE or Segment
> Routing, transport network. And that transport network can be sufficiently
> resilient through use of RSVP-TE local protection (RFC 4090),  end-to-end
> protection of recovery schemes, including 1+1, m:n, and shared mesh
> protection.
> For the #3, I agree, that the proposed solution is viable but I cannot see
> why it is needed when the same result, multicast distribution over traffic
> engineered tree, can already be achieved.
> 
> Regards,
> Greg
> 
> On Tue, Aug 1, 2017 at 7:02 PM, Greg Shepherd <[e-mail]> wrote:
> 
> > We had solid support in the room in Prague to adopt this work. So let's
> > get a vote from the list. Please read and respond for or against adopting
> > this as a WG document:
> >
> > https://datatracker.ietf.org/doc/draft-eckert-bier-te-arch/
> > https://datatracker.ietf.org/doc/draft-eckert-bier-te-frr/
> >
> > Cheers,
> > Greg