Subject: Re: [Bier] Comment on BIER-TE

From: [email-masked]
Date: Wed, 9 Aug 2017 15:29:48 +0800

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.

原始邮件

发件人： <[email-masked]>;
收件人：胡方伟10075772;
抄送人： <[email-masked]>;
日 期 ：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, [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Aug 2017 19:09:59 +0200

Thanks, Hu

Architecturally, i have tried to stay out of encapsulation discussions and
the BIER-TE arch spec is written exactly like the BIER architecture
in a way that it kinda ignores the encapsulation questions. 
See section 3.3.

Aka: If/after bier-te architecture would be accepted as a WG
item, i hope that the folks working on the encapsulations (incuding
you) will come up with what they cconsider to be the best
supportable encapsulation option.

Cheers
    Toerless

On Wed, Aug 09, 2017 at 03:29:48PM +0800, [email-masked] wrote:
> ????????
> ???????? <[email-masked]>;
> ??????????????10075772;
> ???????? <[email-masked]>;
> ?? ?? ??2017??08??09?? 01:09
> ?? ?? ??Re: [Bier] Comment on BIER-TE
> 

-- 
---
[email-masked]