Re: [Teas] Fwd: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK

[Toerless Eckert <[e-mail]>]

Thanks Lou

For various non-technical issues [1], this document took
unfortunately quite long to get to this stage. 

At IETF101 i presented about BIER-TE in TEAS:

https://datatracker.ietf.org/meeting/101/materials/slides-101-teas-framework-for-traffic-engineering-with-bier-te-forwarding

This was related to the framework draft targeted for TEAS how
to manage the traffic engineering of BIER-TE. That draft is currently
expired because of [1], and after a BIER-TE RFC is out, we'll
revisit how to best continue with that work. Because of Lous
feedback on the BIER mailing list and the non-existance of an
up-to-date TE framework doc for BIER-TE, i also pushed an update -06
of the BIER-TE spec with a short summary of what the framework
was expected to include.

The big building block for a complete statelesss multicast TE solution
that was missing from the framework document is btw the
stateless (hop-by-hop) latency management (cyclic queuing), which
we only posted later (draft-qiang-detnet-large-scale-detnet). 

Cheers
    Toerless

[1] too long to explain here ;-)

On Wed, Feb 19, 2020 at 06:41:12PM -0500, Lou Berger wrote:
> FYI - this may be of interest to some.
> https://mailarchive.ietf.org/arch/browse/bier/
> 
> 
> -------- Forwarded Message --------
> Subject: 	[Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK
> Date: 	Tue, 18 Feb 2020 12:45:54 -0800
> From: 	Greg Shepherd <[e-mail]>
> Reply-To: 	[e-mail]
> To: 	Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>
> CC: 	Toerless Eckert <[e-mail]>, [e-mail] <[e-mail]>
> 
> 
> 
> Thanks Toerless and Jeffrey
> 
> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/
> 
> One more week of WGLC. Please read the latest rev and respond to this thread
> w/wo support.
> 
> Chairs
> (Shep)
> 
> 
> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang
> <zzhang=[e-mail] <mailto:[e-mail]>>
> wrote:
> 
>    Hi Toerless,
> 
>    Thanks!
>    I support moving this to the next stage.
> 
>    Jeffrey
> 
>    On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
>     > Thanks Jeff
>     >
>     > I have now pushed out -05 with the answers and hopefully
>    resolution to
>     > your points in email below.  Biggest addition was a section about
>     > reuse of BPs (without DNR) which came out of the confusion i
>    think the
>     > reuse in the ECMP example raised. I was afraid so far to explan that
>     > as it may not be easy to absorb and ultimately is stuff only
>     > controller developers need to understand, but hopefully useful.
>     > And then of course the summary of BP optimizatins you asked for
>     >
>     > Diff from last version i sent you:
>     >
>     >
>    https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
>     > **Araw.githubusercontent.com
>    <http://Araw.githubusercontent.com>*toerless*bier-te-arch*master*draft-ietf-b
>     > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org
>    <http://Atools.ietf.org>*id*draft-ietf-bier-te
>     >
>    -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH
>     > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$
>     >
>     > full -04 -> 05 diff:
>     >
>     >
>    https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:*
>     > *Atools.ietf.org
>    <http://Atools.ietf.org>*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools.
>     > ietf.org
>    <http://ietf.org>*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
>     > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$
>     >
>     > Comments inline below.
>     >
>     > Cheers
>     >     toerless
>     >
>     > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang
>    wrote:
>     > > I Thought u-turn is the most simple comparison leaf vs.
>    non-leaf BFR.
>     > >
>     > > Zzh> The text in the email is seriously misaligned. Looking at
>    the picture in the diff link, while you gave a U-turn example,
>    though even if BFER2 is not connected to BFR2  but only connected to
>    BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I
>    suppose. That's why I said the first sentence of the above paragraph
>    is enough to define Leaf BFER while the example itself is actually
>    not needed.
>     >
>     > Argh... ok, had to fix two words, BFIR->BFER and left-hand ->
>    right-hand:
>     >
>     > Consider how redundant disjoint traffic can reach BFER1/BFER2 in
>    above
>     > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right
>    hand
>     > side, one traffic copy would be forwarded to BFER1 from BFR1, but
>    the
>     > other one could only reach BFER1 via BFER2, which makes BFER2 a
>     > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding
>     > traffic to BFER2
>     >
>     > > Zzh> Additionally, in left part of the picture you added, if
>    some failure leads to BFR2 to be only reachable via BFER1, then
>    BFER1 is no longer a leaf BFER.
>     >
>     > Added sentence:
>     >
>     > <t>Note that the BFER in the left hand picture are only
>    guaranteed to
>     > be leaf-BFR by fitting routing configuration that prohibits transit
>     > traffic to pass through a PE, which is commonly applied in these
>     > topologies.</t>
>     >
>     > > I assume you don't reassign BPs when links go up and down.
>     >
>     > I didn't want to discuss that option in this document. Its obviously
>     > perfectly feasible, but be yet a big amount of text (especially the
>     > considerations how to do this make-before-break. Future doc.
>     >
>     > > > but subsequent polarization example confuses me. It seems
>    that BP 0:6 is assigned to the routed adjacency BFR10 (which is
>    actually talked about in Section 4.8).
>     > >
>     > > Section 4.7 does not mention "routed" at all, so there are no
>    routed adjacencies at all used in 4.7. So i am not sure what you are
>    confused about.
>     > >
>     > > Zzh> "The BIFT of each BFR are only populated with BPs that are
>    adjacent to the BFR in the BIER-TE topology".
>     >
>     > Correct text from the introduction. Ok.
>     >
>     > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I
>    suppose in BFR4~BFR9 as well even though not drawn), I assumed it's
>    for the "MP2P" routed adjacency to R10; though I then ruled that out
>    - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3.
>     >
>     > Ah. Ok. I thought i could strip down the example to show only the
>     > adjacencies relevant to the following discusion, but seemingly this
>     > can introduce the confusion you have.
>     >
>     > So i completed the example with the BP assignment acoss all
>    nodes, but
>     > added text pointing to a new section further down to discuss the
>     > re-use of BP for which thi picture is also an example.
>     >
>     > (check out the diff, new reuse text to long to copy inline).
>     >
>     > > The whole purpose of the ECMP BPs is of course to save bits,
>    otherwise we'd give each link a separate BP, which would be 6 BP to
>    reach to BFR4...BFR7 from BFR1.
>     > >
>     > > Zzh> The trouble I am having is that the same 0:6 is assigned
>    to different things and it's present on all BFR1/BFR2/BFR3. It is
>    perhaps an intentional smart design but I have not wrapped my mind
>    around it. It's apparently different from the link bundle case, so
>    better separate it out and elaborate it (including the DNR flag that
>    might be needed here - If the packet arrives on BFR1 with 0:6, would
>    the BP reset when it is sent to BFR2/3)?
>     >
>     > Yes, there was the bug of reusing BP 0:6 across sequential BFR along
>     > the path, but now the example correctly reuses separate BP at
>     > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on
>    BFR2/BFR3) and so on.
>     >
>     > Thanks!
>     >
>     > > > 4.8.  Routed adjacencies
>     > > >
>     > > > If I understand it correctly, there is a BP assigned to L1/L2/L3
>     > > > respectively (p2p link), and then there are BPs assigned to
>    MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3
>    interface addresses and loopback addresses on BFR2/3.
>     > >
>     > > Ok that wasn't quite the read i expected. Let me clarify the
>    text/picture:
>     > >
>     > >                    ...............
>     > >          ...BFR1--...           ...--L1-- BFR2...
>     > >                   ... .Routers. ...--L2--/
>     > >          ...BFR4--...           ...------ BFR3...
>     > >                    ...............         |
>     > >                                           LO
>     > >                     Network Area 1
>     > >
>     > > Assume the requirement in the above picture is to explicitly
>    steer traffic flows that have arrived at BFR1 or BFR4 via a shortest
>    path in the routing underlay "network area 1" to one of the
>    following three next segments: (1) BFR2 via link L1, (2) BFR2 via
>    link L2, (3) via BFR3.
>     > >
>     > > To achieve this, both BFR1 and BFR4 are set up with a
>    forward_routed adjacency BitPosition towards an address of BFR2 on
>    link L1, another forward_routed BitPosition towards an address of
>    BFR2 on link L2 and a third forward_routed Bitposition towards a
>    node address LO of BFR3.
>     > >
>     > > Does this clear ip the confusion ?
>     > >
>     > > Zzh> The picture is badly misaligned. I'll wait till 4.7
>    questions are cleared.
>     >
>     > Ok.
>     >
>     > > > If BFR2/3 are also BFERs, then they additionally will have
>    BFER BPs.
>     > > > On BFR1/4, the BIFT entries for the MP2P BPs for the
>    L1/L2/L3/loopback interface addresses of BFR2/3 will use
>    forward_routed(interface/loopback address). For a packet to be
>    decapsulated on a BFER, there is a need for both the BFER BP and
>    another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the
>    former is for decapsulation and the latter is for getting it there).
>     > >
>     > > This is not discussed in this section, but you are right - unless
>     > > BFR2 or BFR3 is a leaf BFR. In that case, it would just
>    leverage the one shared "leaf-BFR" BP, so they do not need a
>    per-BFER BP for local_decap().
>     > >
>     > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key
>    is that we need a BP to get packet to a BFER and then a BP for
>    decapsulation).
>     >
>     > You got it.
>     >
>     > > > If that???s the case, it???s worth point the above out.
>     > >
>     > > Hmm... The logic of BFER BPs is totally independent of the
>    logic of forward_routed adjacency, so i would worry that repeating
>    the explanation of BFER BPs would conflate the forward_routed
>    explanation.
>     > >
>     > > Zzh> It's just that this is a place where all kinds of BPs are
>    used so it's good to have a summary (could be a subsection 4.9).
>     >
>     > Yes, added such a summary. Pls. check.
>     >
>     > > > Actually, the reason that I thought this is MP2P is that 0:6
>    is present on R1, R2, and R3 (and more I assume) in Figure 12, but
>    now I think it can???t be MP2P (so it is not correct to have 0:6
>    present on those routers ??? only the p2p tunnel head/tail should
>    have the BP present in the BIFT). The reason is that if it were
>    MP2P, any router getting a copy will send it to the endpoint of the
>    routed adjacency, causing lots of duplicates.
>     > > >
>     > > > Am I getting this correct?
>     > >
>     > > I think you are still explaining from the misunderstsanding
>    that the ECMP explanations where about routed adjacencies.
>     > >
>     > > I have now expanded the somewhat terse text in the BIFT table
>    pictures, to make it clear that the ECMP is across multipe
>    forward_connected adjacencies in the examples. For example, first
>    BIFT picture:
>     > >
>     > >   BIFT entry in BFR1:
>     > >  ------------------------------------------------------------------
>     > >   | Index |  Adjacencies                  |
>     > >  ==================================================================
>     > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 |
>     > >   |       |        forward_connected(L2, BFR2),                 |
>     > >   |       |        forward_connected(L3, BFR2)}, seed)         
>        |
>     > >  ------------------------------------------------------------------
>     > >
>     > > Of course, an ECMP adjacency can be across any type of
>    adjacencies, but all the text/explanations used forward_connected,
>    and now the pictures show that explicitly.
>     > >
>     > > Zzh> I can understand the multi-link case, but the multi-hop
>    ECMP case (from BFR1 towards BFR10) is confusing me. It would help
>    to give an example how it can be used, WITHOUT worrying about
>    polarization.
>     >
>     > Please check -05 text that has the full set of BIFT listed now:
>     >
>     > There is  really nothing nothing unique in multi-hop ECMP for
>    BIER-TE
>     > that we do not also have in any other ECMP, except the conclusion
>    that
>     > we want to support fast HW hash mechanisms AND allow the
>    controller to
>     > set up non-polarized multi-hop ECMP AND be able to precalculate
>    paths.
>     > Hence the specification of ECMP adjacencies to have a controller
>     > configurable seed.
>     >
>     > Btw: The picture is maybe unnecessarily large because i've used
>    it for
>     > 20 years to explain the same polarization issue for unicast vs
>     > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of
>     > the PIM/mLDP joins), whereas for unicast/BIER only
>     > BFR1...BFR7 are relevant. But being symmetric, the picture makes it
>     > clear its the same problem.
>     >
>     > > >    To inhibit looping in the face of such physical
>    misconfiguration,
>     > > >    only forward_connected adjacencies are permitted to have
>    DNR set, and
>     > > >    the link layer destination address of the adjacency (e.g.  MAC
>     > > >    address) protects against closing the loop.  Link layers
>    without port
>     > > >    unique link layer addresses should not be used with the
>    DNR flag set.
>     > > >
>     > > > It???s not clear how link layer address helps?
>     > >
>     > > I have expanded this to
>     > > "link layer port unique unicast destination address"
>     > >
>     > > Aka: MPLS or ethernet have unique link layer destination
>    destination addresses (label or destination MAC). If you think about
>    incorrectly plugged HDLC links (such as old T1/T3/... links), they
>    only have 2 generic addresses, if i remember 1 or 3 in the HDLC
>    frame. So when you misplug one of those p2p cables wrong, the
>    packets would be incrrectly received by the wrong receiver node and
>    then DNR could cause persistent loops only solved by TTL.
>     > >
>     > > Zzh> "Consider in the ring picture that link L4 from BFR3 is
>    plugged into the L1 interface of BFRa" - still not sure how
>    label/mac helps here. I suppose the ring topology is
>    discovered/verified by the control plane and when the miscalling
>    happens then the ring will not include the BFR1/BFR2 part and BFR3
>    will not have the DNR set? If ring discovery/varication is not done
>    then perhaps we should point out that RPF based on link layer
>    address is needed - the key is RPF (which needs unique link layer
>    address)?
>     >
>     > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast.
>    RPF
>     > is just a problem for receiver originated joins like in PIM/mLDP,
>    but
>     > not unicast/bier(-te)/RSVP-TE.
>     >
>     > Forward_connected is just like a unicast subnet adjacency to a
>    direct
>     > neighbor: Interface and L2 addresss of the destination.
>     >
>     > The controller (could be a human) "assumes" a particular physicial
>     > topology, from telemetry/knowledge/whatever. It then calculates the
>     > desired BIER-TE topology and pushes it down. This topology is
>    meant to
>     > be loop free of course wrt to the configured adjacencies.
>     > In this BIER-TE topology, BFR3 will have a BP with the
>     > forward_connected(L4, MAC-of-BFR2) adjacency.
>     >
>     > If the cable connecting to L4 is miswired, then BFR3 would still
>    send
>     > the packets to the MAC address of BFR2, but given how the cable
>     > connects to some other node, these packets will be discarded by that
>     > node. because they're just L2 unicast packets.
>     >
>     > I think this is equally true when we have normal BIER/MPLS enacp.
>     > Those packets too are addressed to the unicast MAC address of the
>     > neighbor.
>     >
>     > Now, if/when he controller recognizes that the physical topology has
>     > changed, thats a completely different story and not addressed here.
>     > Given how we assumed this was a cabling mistake, the controller
>    would
>     > probably only complain about the miswiring to operations but be
>    happy
>     > that the forwarding plane just makes packets fail instead of
>    loop. If
>     > this was a planned change process, then it will be similarily
>     > convoluted as it would today be with rewiring cables in an
>     > SR-MPLS/SRv6 topology and updating SIDs.
>     >
>     > > > Because the forwarding is different from BIER forwarding
>    (because of [1] above), we might as well introduce an optimization
>    here ??? for each BIFT, calculate the F-BM of the BIFT itself (the
>    logical ???or??? of all the BPs presented in this BIFT) and then use
>    (packet->bitstring & BIFT.F-BM) as the input to
>    GetFirst/NextBitPosition(). That should skip many bits.
>     > >
>     > > Right. But i explicitly removed those optimizations (i had them
>    in older draft versions) because the whole idea of this picture is
>    solely the comparison with figure 4 of RFC8279.
>     > >
>     > > Zzh> I think it's worth point that optimization out; you can
>    mark it optional if you want to emphasize the similarity to BIER
>    forwarding, but since BIER forwarding does do the maskoff step, it
>    is very efficient while BIER-TE forwarding does not it the maskoff
>    step so this optimization is important.
>     >
>     > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM
>     > rules [1] and [2] and added following paragraph:
>     >
>     > <t>In BIER, the order of BPs impacts the result of forwarding
>    because of [1].
>     > In BIER-TE, forwarding is not impacted by the order of BPs. It is
>     > therefore possible to further optimize forwarding than in BIER. For
>     > example parallelizing forwarding across multiple FPE cores or
>     > distributed linecards does only need to examine an arbitrary
>    subset of
>     > BP and not evaluate the dependency between BPs.</t>
>     >
>     > > >    The following pseudocode is comprehensive:
>     > > >
>     > > > The above sentence reads a bit strange (or lacks some segue).
>     > >
>     > > I hope not, but maybe best left to a native english speaker
>    (RFC-editor).
>     > >
>     > > The first (RFC8279) pseudocode was simplified. The second one
>    is comprehensive. If not comprehensive, whats a good opposite of
>    simplified ?
>     > >
>     > > Zzh> Perhaps "The above simplified pseudocode is elaborated
>    further as following"?
>     > > Zzh> Jeffrey
>     >
>     > Done.
>     >
>     > Thanks a lot.
>     >
>     >
>     > >
>     > > > ________________________________________
>     > > > From: BIER [[e-mail]
>    <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>]
>     > > > on behalf of Toerless Eckert [[e-mail]
>    <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>]
>     > > > Sent: Tuesday, July 09, 2019 23:38
>     > > > To: Mike McBride
>     > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert)
>     > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
>     > > >
>     > > > Thanks, Mike
>     > > >
>     > > > The authors also reviewed the document and concluded that it was
>     > > > really hard to get into the document context because of too many
>     > > > forward dependencies. We tried to fix this by adding two
>    hopefully
>     > > > good & basic examples into the Introduction section and using
>    them
>     > > > to also add a better definition of the term "BIER-TE
>    Topology" in the Introduction.
>     > > > Hopefully this makes readin the rest of te document smoother.
>     > > >
>     > > > Also improved text of Abstract and refined text compariing
>    BIER-TE with SR.
>     > > >
>     > > >
>    https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
>     > > > **Atools.ietf.org
>    <http://Atools.ietf.org>*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
>     > > > tool
>     > > > s.ietf.org
>    <http://s.ietf.org>*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
>     > > > jC81
>     > > >
>    c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh
>     > > > $
>     > > >
>    <https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https:
>     > > > **Atools.ietf.org
>    <http://Atools.ietf.org>*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
>     > > > tool
>     > > > s.ietf.org
>    <http://s.ietf.org>*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
>     > > > jC81
>     > > >
>    c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX
>     > > > $>
>     > > >
>     > > > Cheers
>     > > >     Toerless
>     > > >
>     > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote:
>     > > > > How about three? I support.
>     > > > > mike
>     > > > >
>     > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd
>    <[e-mail] <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>> wrote:
>     > > > > >
>     > > > > > We cannot take two 'yes' votes and WG consensus.
>     > > > > > Please, read and respond. If you don't support, then
>    please vote as much publicly right here.
>     > > > > >
>     > > > > > Thanks,
>     > > > > > Greg
>     > > > > >
>     > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert)
>    <[e-mail]
>    <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>> wrote:
>     > > > > >>
>     > > > > >> Support:
>     > > > > >>
>     > > > > >> I see great value in deterministic networks as well as
>    IOT (with RPL).
>     > > > > >>
>     > > > > >> All the best,
>     > > > > >>
>     > > > > >> Pascal
>     > > > > >>
>     > > > > >> > -----Original Message-----
>     > > > > >> > From: BIER
>     > > > > >> > <[e-mail]
>    <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>> On
>     > > > > >> > Behalf Of Toerless Eckert
>     > > > > >> > Sent: mardi 4 juin 2019 02:03
>     > > > > >> > To: Greg Shepherd
>     > > > > >> > <[e-mail]
>    <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>>
>     > > > > >> > Cc: BIER WG <[e-mail]
>    <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>>
>     > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
>     > > > > >> >
>     > > > > >> > +1
>     > > > > >> > Obviously support as co-author.
>     > > > > >> >
>     > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg
>    Shepherd wrote:
>     > > > > >> > > Please read and respond to this thread w/ or w/o
>    support.
>     > > > > >> > >
>     > > > > >> > >
>    https://urldefense.com/v3/__https://datatracker..ietf.org
>     > > > > >> > > /doc
>     > > > > >> > >
>    /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s
>     > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$
>     > > > > >> > >
>    <https://urldefense.com/v3/__https:/datatracker.ietf.org/
>     > > > > >> > > doc/
>     > > > > >> > >
>    draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx
>     > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$>
>     > > > > >> > >
>     > > > > >> > > Vote ends 5 June 2019.
>     > > > > >> > >
>     > > > > >> > > Thanks,
>     > > > > >> > > Shep
>     > > > > >> > > (chairs)
>     > > > > >> >
>     > > > > >> > > _______________________________________________
>     > > > > >> > > BIER mailing list
>     > > > > >> > > [e-mail]
>    <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>
>     > > > > >> > >
>    https://urldefense.com/v3/__https://www.ietf.org/mailman/
>     > > > > >> > > list
>     > > > > >> > >
>    info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE
>     > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$
>     > > > > >> > >
>    <https://urldefense.com/v3/__https:/www.ietf.org/mailman/
>     > > > > >> > > list
>     > > > > >> > >
>    info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b
>     > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$>
>     > > > > >> >
>     > > > > >> > _______________________________________________
>     > > > > >> > BIER mailing list
>     > > > > >> > [e-mail]
>    <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>
>     > > > > >> >
>    https://urldefense.com/v3/__https://www.ietf.org/mailman/li
>     > > > > >> > stin
>     > > > > >> >
>    fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4
>     > > > > >> > l_qd
>     > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$
>     > > > > >> >
>    <https://urldefense.com/v3/__https:/www.ietf.org/mailman/li
>     > > > > >> > stin
>     > > > > >> >
>    fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW
>     > > > > >> > 4nrq
>     > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$>
>     > > > > >
>     > > > > > _______________________________________________
>     > > > > > BIER mailing list
>     > > > > > [e-mail] <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>
>     > > > > >
>    https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
>     > > > > > nfo/
>     > > > > >
>    bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX
>     > > > > > F0Kw
>     > > > > > ZD82cJLDFFNT2WVXWX$
>     > > > > >
>    <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listi
>     > > > > > nfo/
>     > > > > >
>    bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju
>     > > > > > 8UCL
>     > > > > > OgiuXc8Y_6sKn2KoAT$>
>     > > >
>     > > > --
>     > > > ---
>     > > > [e-mail] <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>
>     > > >
>     > > > _______________________________________________
>     > > > BIER mailing list
>     > > > [e-mail] <mailto:[e-mail]><mailto:[e-mail]
>    <mailto:[e-mail]>>
>     > > >
>    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>     > > > bier
>     > > >
>    __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82
>     > > > cJLD
>     > > > FFNT2WVXWX$
>     > > >
>    <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
>     > > > bier
>     > > >
>    __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu
>     > > > Xc8Y
>     > > > _6sKn2KoAT$>
>     > >
>     > > --
>     > > ---
>     > > [e-mail] <mailto:[e-mail]>
>     >
>     > --
>     > ---
>     > [e-mail] <mailto:[e-mail]>
>     >
>     > _______________________________________________
>     > BIER mailing list
>     > [e-mail] <mailto:[e-mail]>
>     >
>    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
>     >
>    __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4
>     > 1_jWV3YUA6D$
> 
>    --
>    ---
>    [e-mail] <mailto:[e-mail]>
> 
>    _______________________________________________
>    BIER mailing list
>    [e-mail] <mailto:[e-mail]>
>    https://www.ietf.org/mailman/listinfo/bier
> 

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


-- 
---
[e-mail]