Re: [Bier] Questions on draft-eckert-bier-te-arch-01

[Toerless Eckert <[e-mail]>]

Hmm... no good explanation why this mail slipped by me answering until
Greg kicked my back. Sorry for that (only lame explanations *sigh*).

I think Neal alreay sent some responses to you..., adding to those.

On Thu, Aug 27, 2015 at 02:49:17PM -0400, Eric C Rosen wrote:
> According to the draft:
> 
>    Currently, BIER-TE does not support BIER-sub-domains and it does not
>    not use BFR-id.  BIER-TE headers use the same format as BIER headers
>    (BFR-id is set to 0)
> 
> If the BFIR-id field in the BIER header is set to 0, it is impossible 
> for the BIER payload to be an MPLS packet whose label stack begins with 
> an upstream-assigned label.  That's because the BFIR-id provides the 
> context in which the upstream-assigned label is interpreted.
> 
> Is that the intention?  That would seem to mean that BIER-TE cannot be 
> used to support MVPN.

No, this was definitely not the intention. The author who wrote this
(me) wanted to explain that the BFIR-ID is not required for BIER-TE forwarding
itself (it is required for BIER forwarding if i am not mistaken),
and incorrectly wrote "does not support".

And i did not come to think of the benefit/need of BFIR-ID for the
context of upstream assigned inner labels. Thats actually quite nice.
A lot easier than non-BIER MPLS solutions if i remember those correctly.

Neal mentioned also that not assigning a BFIR-ID can help to save bitspace,
which is true in BIER, but if we only use BIER-TE forwarding, it would
not even cost bits.

So, how about the following text suggestion:

| BIER-TE forwarding does not require/use the BFIR-ID. The BFIR-ID can
| still be useful though for coordinated BFIR/BFER functions, such as 
| the context for upstream assigned labels for MPLS payloads in MVPN
| over BIER-TE.
| 
| If the BIER-TE domain is also running BIER, then the BFIR-ID in
| BIER-TE packets can be set to the same BFIR-ID as used with BIER
| packets.
|
| If the BIER-TE domain is not running full BIER or does not
| want to reduce the need to allocate bits in BIER bierstrings for
| BFIR-ID values, then the allocation of BFIR-ID values in BIER-TE packets can
| be done through other mechanisms outside the scope of this document,
| as long as this is appropraitely agreed upon between all BFIR/BFER.

If you don't think there is sufficient benefit to keep the door open
to NOT leverage normal BIER assignment procedures for BFIR-ID, then
i could just drop the third paragraph.. ?

> From section 3.2.4:
> 
> A "local_decap" adjacency passes a copy of the payload of the BIER-TE
> packet to the packets NextProto within the BFR (IPv4/IPv6,
> Ethernet,...).
> 
> These local_decap adjacencies sound an awful lot like BFER-ids. Don't 
> you need one for each BFER?  So the BitString has to have a bit for each 
> BFER and a bit for each link that is along the path to any of the BFERs? 
>  Wouldn't this require that the number of BFERs be much less than the 
> number of bits in the BitString?

I could not find BFER-ID term being used anyplace other than
draft-ietf-bier-isis-extensions-00.xml, so i would not venture to
guess what its semantics is - any pointer i overlooked ?

How many bits do you need for TE ? Thats the key question. Obviously,
you can't get traffic-engineering for free, so you will require more
bits for the same network as with BIER. Which is why the BIER-TE draft
has already some optimizations where TE bits are used more efficiently,
and there are more possible.

Section 4.3 explain how Leaf BFER effectively require no bit
(sorry typo: 4.3:s/BFIR/BFER/, done for -02). Eg: just one bit per link
to leafs, and one shared (local decap) bit for all leafs in the network.

Likewise rings require also only one bit per node (local decap), and
a single shared bit for the ring (Section 4.6) (or even for multiple
rings).

So, maybe as a simple rule of thumb for this first round of bit
optimizations: One Bit per BFER, and one bit for every link without
a BFER on it. And those last-hop links are commonly > 50% of links
(could probably calculate from stats like average ingres:egress #interfaces,
 path-length and the like).

Any suggestion if/what should be added to the draft about this ?

> From section 4.9 of the draft:
> 
>    In a large network, multiple BIFT may be necessary, each one
>    identified by a different SI value in the BIER header.
> 
> Well, the only BIER encapsulation referenced by the draft is the MPLS 
> encapsulation, which does not have an SI value in the BIER header. 
> Probably you need to point out in section 3.3 that the MPLS label needs 
> to be associated with an SI, and modify section 4.9 to say that the SI 
> is inferred from the label.

Ack:

| To support larger networks, multiple bitstrings may be required/beneficial.
| This specification utilizes multiple SI (Set Identifiers) to support this. 
| A BIER-TE packets Set Identifier can either be derived from the context of the BIER-TE 
| packet encapsulation, or it can be part of a particular encapsulations BIER-TE header.
| MPLS BIER encapsulation does not include an SI field in the BIER header,
| so the SI needs to be associated with an MPLS label. Eg: for 10 SI in BIER-TE,
| 10 MPLS labels must be assigned to BIER-TE.</t>

> Even so, I don't really understand how this would work.  In ordinary 
> BIER, the bits identify the BFERs.  If for a particular packet you have 
> more BFERs than bits, you can always make two packets, and send each one 
> to (say) half of the BFERs.  In BFR-TE, the bits identify the links over 
> which the packet must flow.  If a particular packet has to flow over 
> more links than can fit into the BitString, you can't just make two 
> packets, and have each one traverse half the links.   I think this needs 
> a bit more explanation.

As in: How do i minimize the duplication of bit assignments for intermediate
links in the bitstrings of different SI ?

I think thats where a good controllers logic comes into play, or a good
operators ID/SI assignments - and certainly ideas from folks looking more
at this.

The most simple logic is to segment your network into non-overlapping areas, assign
an SI to each area, and effectively unicast a copy from the BFIR to the desired entry
 points in each of the areas. Unicasting eg: via Routed Adjacencies. If the
segments are non-overlapping, you could even get away without routed-adjacencies
at all: The ingres BFR directly maps from the non-BIER side lookup result
into a list of adjacencies, each of which has an IGP label to the segments
BFIR, followed by that segments BIER-TE label (SI 0), followed by the
appropriate BIER-header for that network segment.

> Perhaps it is sub-domains rather than SIs that are needed here.  One 
> could in theory have a sub-domain for each flow, and in that sub-domain 
> you'd only have to assign bit positions needed for that flow.  It seems 
> like it might be challenging though to figure out the least number of 
> sub-domains you actually need for a given set of flows.

I guess i don't really confused about the difference between sub-domain
and SI from the arch document and under which circumstances one is
better than another. Any suggestions welcome.

> BTW, the references need updating.

Am i missing references, or where the numbers of the drafts references
too old, even for the time when i ran the xml2rfc ?

Thanks a lot for the review!

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