Re: [Bier] Comment on BIER-TE

[Toerless Eckert <[e-mail]>]

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, [e-mail] wrote:
> 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.
> 
> 
> 
> ????????
> 
> ???????? <[e-mail]>;
> ??????????????10075772;
> ???????? <[e-mail]>;
> ?? ?? ??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, [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
> 
> 
> -- 
> ---
> [e-mail]
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
> 
> 

> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
[e-mail]