Subject: [Bier] FYI: draft-eckert-bier-te-arch-00.txt

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Mar 2015 10:19:07 -0800

In Milan, someone raised the question if BIER could do traffic
engineering..

I have posted a draft proposing on how one could do traffic engineering with
BIER  (explicit  hop-by-hop paths, FRR). The goal of course is to
stick to the principles of BIER. 

Please let me know what you think.  Of course this is just a -00,
any feedback welcome!

Thanks
    Toerless

In-Reply-To: <[email-masked]>

On Fri, Mar 06, 2015 at 10:09:25AM -0800, [email-masked] wrote:
> 
> A new version of I-D, draft-eckert-bier-te-arch-00.txt
> has been successfully submitted by Toerless Eckert and posted to the
> IETF repository.
> 
> Name:		draft-eckert-bier-te-arch
> Revision:	00
> Title:		Traffic Enginering for Bit Index Explicit Replication BIER-TE
> Document date:	2015-03-05
> Group:		Individual Submission
> Pages:		21
> URL:            http://www.ietf.org/internet-drafts/draft-eckert-bier-te-arch-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-eckert-bier-te-arch/
> Htmlized:       http://tools.ietf.org/html/draft-eckert-bier-te-arch-00
> 
> 
> Abstract:
>    This document proposes an architecture for BIER-TE: Traffic
>    Engineering for Bit Index Explicit Replication (BIER).
> 
>    BIER-TE shares part of its architecture with BIER as described in
>    [I-D.wijnands-bier-architecture].  It also proposes to share the
>    packet format with BIER.
> 
>    BIER-TE forwards and replicates packets like BIER based on a
>    BitString in the packet header but it does not require an IGP.  It
>    does support traffic engineering by explicit hop-by-hop forwarding
>    and loose hop forwarding of packets.  It does support Fast ReRoute
>    (FRR) for link and node protection and incremental deployment.
>    Because BIER-TE like BIER operates without explicit in-network tree-
>    building but also supports traffic engineering, it is more similar to
>    SR than RSVP-TE.
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Mar 2015 01:07:11 +0000

Read it up. Smart. In fact, I think the LFA/FRR  should/may be somehow plugged outside this work and make independent piece encouraging fast-failover to provide BTAFTs no matter whether we talk about centralized controllers or each IGP doing their thing. 

Only fairly obvious observation I would have is that the #bits without SIs and the fact that bits represent adjacencies is a fairly restrictive scaling limitation compared to bit per BFER. 

Thanks 

--- tony 

There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: Friday, March 06, 2015 10:19 AM
> To: [email-masked]
> Subject: [Bier] FYI: draft-eckert-bier-te-arch-00.txt
> 
> In Milan, someone raised the question if BIER could do traffic engineering..
> 
> BIER  (explicit  hop-by-hop paths, FRR). The goal of course is to stick to the
> principles of BIER.
> 
> Please let me know what you think.  Of course this is just a -00, any feedback
> welcome!
> 
> Thanks
>     Toerless
> 
> > A new version of I-D, draft-eckert-bier-te-arch-00.txt has been
> > successfully submitted by Toerless Eckert and posted to the IETF
> > repository.
> >

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 13 Mar 2015 15:55:32 -0400

> stick to the principles of BIER.

Tell me if I'm understanding the scheme correctly.

It seems like what you are proposing is a way to encode the entire 
multicast tree in the BitString. One way to think of it is that the 
BFR-ids are not assigned to BFRs, but to pairs of BFRs.  That is, a 
BFR-id represents a <BFR, BFR-next-hop> pair.  The basic problem of 
course is that if each BFR has an average of n BFR neighbors, you need 
approximately n times the number of bits you need in the non-TE case. 
This is further compounded by the fact that each packet needs to hold 
the entire tree, so you can't really make use of the SI mechanism.

I suppose you could break a tree into k sub-trees, make k copies of the 
packet, and then unicast each copy to the root of one sub-tree. However, 
mixing TE with IR in that way would be a bit unusual.

Or you could use the sub-domain concept to assign each tree its own 
sub-domain, and then use bit positions that are unique only for that 
particular tree.  But if you did that, the MPLS label would identify the 
tree, you could eliminate the BitString altogether, and it wouldn't be 
BIER any more.

The draft does propose a number of optimizations that allow a given 
BFR-id (i.e., a given position in the BitString) to represent different 
BFR pairs in different contexts.  The acceptability of the scheme is 
going to be a matter of whether one can apply enough of those 
optimizations to encode the entire tree in each packet, without creating 
any ambiguity in the interpretation of the bits.

Question regarding the paragraph:

    All leaf-BFIR in a BIER-TE domain can share a single BitPosition.
    This is possible because the BitPosition for the adjacency to reach
    the BFIR can be used to distinguish whether or not packets should
    reach the BFIR.

I think you actually mean "BFER" not "BFIR", but even so, I don't 
understand how this works.  Doesn't the previous hop reset the 
"BitPosition for the adjacency to reach the BF[E]R"?  So how does a 
particular Leaf-BFER know that the packet is for itself?  I guess if a 
particular BFER is a Leaf-BFER for every traffic engineered tree to 
which it belongs, then it could assume that any BIER-TE packet it 
receives with an all-zero BitString is for itself. But is it realistic 
to suppose that a leaf on one tree is also a leaf on all the others?  Or 
am I missing the point?