Re: [Bier] Comment on BIER-TE

hu.fangwei@zte.com.cn Wed, 09 August 2017 07:30 UTC

Return-Path: <hu.fangwei@zte.com.cn>
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 AB6DE132399 for <bier@ietfa.amsl.com>; Wed, 9 Aug 2017 00:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 UsELxezgZNwC for <bier@ietfa.amsl.com>; Wed, 9 Aug 2017 00:30:32 -0700 (PDT)
Received: from zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A11275FD for <bier@ietf.org>; Wed, 9 Aug 2017 00:30:31 -0700 (PDT)
X-scanvirus: By SEG_CYREN AntiVirus Engine
X-scanresult: CLEAN
X-MAILFROM: <hu.fangwei@zte.com.cn>
X-RCPTTO: <bier@ietf.org>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20170809153010
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 9 Aug 2017 07:30:10 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id v797Tmwp072155; Wed, 9 Aug 2017 15:29:48 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn)
To: tte@cs.fau.de
Cc: bier@ietf.org
MIME-Version: 1.0
X-KeepSent: 1897B7B0:611FEA95-48258177:0027423E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF1897B7B0.611FEA95-ON48258177.0027423E-48258177.00292EBC@zte.com.cn>
From: hu.fangwei@zte.com.cn
Date: Wed, 09 Aug 2017 15:29:48 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 9.0.1FP7|August 17, 2016) at 2017-08-09 15:29:39, Serialize complete at 2017-08-09 15:29:39
Content-Type: multipart/alternative; boundary="=_alternative 00292EBC48258177_="
X-MAIL: mse01.zte.com.cn v797Tmwp072155
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/XoqtwCqfgEW9nzFTzvJO6cGcdm4>
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: Wed, 09 Aug 2017 07:30:34 -0000

Hi,Toerless

I have a suggestion for the issue: we can modify the BIER-TE packet 
encapsulation as following:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            BIFT-id                    | TC  |S|     TTL       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Nibble |  Ver  |  BSL  |              Entropy                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |OAM|B|Rsv|    DSCP   |   Proto   |          BFIR-id            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             BitString  Sub-TLVs (variable)                    |
       +-                                                             -+
       |                                                               |
       +---------------------------------------------------------------+

We replace "BitString" by "BitString Sub-tlv" to carry several SIs 
information in the same packet. If there are several SIs for the BIER-TE 
flow, we will fill the same number of "Bitstring Sub-TLV".

 The BitString Sub-tlv format is as following:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               BIFT-id                 |       Rsv           |N|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 BitString  (variable)                         |
       +-                                                             -+
       |                                                               |

The benefits for this encapsulation are:
(1) Avoiding the packet loss in BIER-TE.
(2) Reducing the data packet duplication for the BIER/BIER-TE node. It can 
also be used for BIER. If we use this encapsulation for BIER data packet, 
it is not necessary to duplicate several copies for different SIs.


Regards
Fangwei.



原始邮件

发件人: <tte@cs.fau.de>;
收件人:胡方伟10075772;
抄送人: <bier@ietf.org>;
日 期 :2017年08月09日 01:09
主 题 :Re: [Bier] Comment on BIER-TE

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

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