Subject: Re: [Bier] overdue text on BEIR TE

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 00:54:42 +0200

Thanks, Lou

Now i had a bit of other higher priority work interrupting me...for a bit *sigh*.

Thanks for the text.

I did a few fixes in your proposed text to hopefully improve it, as i
noted in the changelog, primarily to condition the specifics of resource
management onto the service to be provided. I hope you agree that
what we're typically talking about are RCSD's thats at least what i
found as the generic classification in the research literature. I for
once think that not necessarily all cases for traffic engineering would need
this, also after talking with Adrien about the wide range of cases described
in  3272bis.

The other  part was the "per BIFT" allocation of resources, where i removed
the "per BIFT" because that is too prescriptive and i fear in all the cases i can
think of wrong. In general, solutions that would require per-hop-per-flow
state-management such as 802.1Qcr would to a good extend run counter to
the goal of stateless per-hop steering & replication of BIER-TE. Maybe there is a
sweet spot for this combination, but more likely the sweet spot would
be in combination with stateless queing such as 802.1Qch or derived solutions
such as the large scale detnet draft. The stateful solution would have
to be hooked off a flow key, wich in general would not be BIFT, and the stateless
would be hooked of also some other packet header field. 

But i hope its fine if we do not have to work out these out-of-scope aspects
in this document but ust make sure he principles outlined in the 2.5 section are
correct and the rest goes into appropriate followup work.

Any fine tuning of the text i hope we can also do during IETF review, because right
now there wouldn't be any further things the WG itself IMHO wants to do.

Cheers
    Toerless

On Tue, Apr 14, 2020 at 08:46:43AM -0400, Lou Berger wrote:
> Hi,
> 
> This is a bit overdue - but I somehow imagine that many will understand life
> hasn't been happening in a normal way recently.
> 
> I suggest the text enclosed below be incorporated into the BEIR TE draft,
> perhaps at the end of section 2 or a new section 3. Please excuse any typos,
> and I'm sure it will need some tweaking to best align with BIER terminology.
> 
> Lou
> 
> PS I'm triple booked during today's interim, but still hope to be there.
> 
> ---------------------------------------------------
> 
> 2.5. Traffic Engineering Considerations
> 
> Traffic Engineering [RFC3272-Bis] provides performance optimization of
> operational IP networks while utilizing network resources economically and
> reliably.  The key elements needed to effect TE are policy, path steering
> and resource management. These elements require support at the
> control/controller level and within the forwarding plane.
> 
> Policy decisions are made within the BIER-TE control plane, i.e., within
> BIER-TE Controllers.  Controllers use policy when composing BitStrings (BFR
> flow state) and BFR BIFT state. The mapping of user/IP traffic to specific
> BitStrings/BEIR-TE flows is made based on policy. The specifics details of
> BIER-TE policies and how a controller uses such are out of scope of this
> document.
> 
> Path steering is supported  via the definition of a BitString. BitStrings
> used in BIER-TE are composed based on policy and resource management
> considerations.  When composing BIER-TE BitStrings, a Controller MUST take
> into account the resources available at each BFR and for each BP.  Resource
> availability is typically provided dynamically via routing protocol
> information, but may also be obtained via the BIER-TE control protocol.  The
> resource usage of an individual BP can be tracked on a Controller based on
> its local accounting and via routing or the BIER-TE control protocol. This
> implies that such information be collected by each BFR.
> 
> Resource management also has implications on the BFR forwarding plane. 
> BIER-TE supporting BFRs  MAY support per BIFT entry resources and resource
> allocation. Example resources include buffers, policing and rate-shaping
> mechanisms which are typically supported via queuing.  This level of
> resource control, while optional, is important in networks that wish to
> support congestion management policies to control or regulate the offered
> traffic to deliver different levels of service and alleviate congestion
> problems, or those networks that wish to control latencies experienced by
> specific traffic flows.
> 
> [RFC3272-Bis] https://tools.ietf.org/html/draft-dt-teas-rfc3272bis
> 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier