Re: [Bier] Comment on BIER-TE

Toerless Eckert <tte@cs.fau.de> Tue, 08 August 2017 17:09 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 A45C313267B for <bier@ietfa.amsl.com>; Tue, 8 Aug 2017 10:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dXCw4kBRcGeI for <bier@ietfa.amsl.com>; Tue, 8 Aug 2017 10:09:03 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C40132672 for <bier@ietf.org>; Tue, 8 Aug 2017 10:09:03 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B78CB58C4BC; Tue, 8 Aug 2017 19:08:59 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 985CAB0C816; Tue, 8 Aug 2017 19:08:59 +0200 (CEST)
Date: Tue, 08 Aug 2017 19:08:59 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: hu.fangwei@zte.com.cn
Cc: bier@ietf.org
Message-ID: <20170808170859.GA24983@faui40p.informatik.uni-erlangen.de>
References: <201708021139076906483@zte.com.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201708021139076906483@zte.com.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/zK3aUq90YXqP_fc478DfBNp1bgM>
Subject: Re: [Bier] Comment on BIER-TE
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Aug 2017 17:09:06 -0000

sorry, clearing up backlog...

Good question,

I am not sure if or how much i elaborated on BIER-TE controller strategies for
bit assignments on the list. And that this could even be a question in BIER.

I didn't want to put this all into the BIER-TE
draft for matter of size, and consistency: For most parts i think in unicast
TE a lot of strategies on PCE controllers are equally not documented because
they are not needed for standardization - for better or worse. I am open
to any suggestions of how to document this if at all.

A simple strategy is like this: consider that you have a large network with
a core and a bunch of regions on the edge. You could assign to each region only
BFR-IDs with the same SI (or subdomain for that matter). When you then need to
replicate  from some region, you would need to send one copy per SI or subdomain.
If you do not want to have all those SI/subdomains on all possible BFIRs, you
could look into using another unicast MPLS label (eg: SR based) that would get you
to the edge-router into a particular area. Otherwise you'd have one remote adjacency
bit for each SI/subdomain that would do the same thing. And if you want to get
more fancy about TE, you would have bits for multiple redundant ingres area
exit routers and exit-area-ingres-routers to steer the traffic with load-splitting.

I mentioned how this could btw. equally be a question for BIER: If you had such
a large multi-are network and you would randomnly assign BFR-IDs to BFERs and end
up having in one region BFER with different SI's, then you would also need to 
send per-SI copies into that region, which would not be traffic-optimal. Aka:
You would also like to assign BFR-ID in SI groups in topological vicnity to maximize
the replication efficiency in BIER if you have such large networks.

Cheers
    Toerless

On Wed, Aug 02, 2017 at 11:39:07AM +0800, hu.fangwei@zte.com.cn wrote:
> Hi,athors of BIER-TE
> 
> I have a comment on BIRE-TE.
> 
> 
> BitPositions are assigned to adjacencies in the BIER-TE architecture instead of BFER in BIER, so it is necessary to have SI in the BIER-TE domain to reduce the Bitstring length.  The issues is that if the transmit adjacency for a  BIER-node doesn't have the given SI value for a BIER-TE packet(the BitString in BIER encapsulation is related to SubDomain,BSL and SI combination), the BIER-TE packet may be dropped in that BIER-node.
> 
> The BIER-TE packet(SI =1 ) will be dropped in the BFR2 in the following figure, for there is no SI=1 entry in the BFR2 BIFT table.  How to solve it? Thanks.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Regards.
> 
> Fangwei.



> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
tte@cs.fau.de