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

[Toerless Eckert <[e-mail]>]

Eric/*:

To add to the thread. Talking with Ice today, he thinks that
it would be a lot more logical to only use sub-domains as the logical
concept to enable multiple bitstrings for BIER-TE. And not SI.
I hope i am correctly restating his explanations and expand on it:

The SI in BIER is automatically assigned from BFR-ID which is
split into loewr-bits = index into bitstring, and SI = which
bitstring. In BIER-TE we do not use BFR-ID for forwarding, and we
will need to "engineer which bitstring to assign each BFER (or
link into it) to. That is also done in BIER with sub-domains.

Adding on to this: if we want to reuse in BIER-TE the BFR-ID
in the BIER header, eg: in support of the MPLS upstream label context
case, that too becomes easier if we do not need to tie the selection
of the BIER-TE bitstring set to the BFR-ID - but if we use
just sub-domain.

If that makes sense, i can accordingly come up with text for the draft.

Cheers
    Toerless

On Wed, Oct 07, 2015 at 03:10:35PM -0700, Toerless Eckert wrote:
> 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
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
Toerless Eckert, [e-mail]