Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 18 Feb 2020 20:07:04 +0000

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*toerless*bier-te-arch*master*draft-ietf-b
> ier-te-arch-05.1.txt&url2=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*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools.
> 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 [[email-masked]<mailto:[email-masked]>] 
> > > on behalf of Toerless Eckert [[email-masked]<mailto:[email-masked]>]
> > > 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*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > 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*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > 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 <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> I see great value in deterministic networks as well as IOT (with RPL).
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Pascal
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: BIER
> > > > >> > <[email-masked]<mailto:[email-masked]>> On 
> > > > >> > Behalf Of Toerless Eckert
> > > > >> > Sent: mardi 4 juin 2019 02:03
> > > > >> > To: Greg Shepherd 
> > > > >> > <[email-masked]<mailto:[email-masked]>>
> > > > >> > Cc: BIER WG <[email-masked]<mailto:[email-masked]>>
> > > > >> > 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
> > > > >> > > [email-masked]<mailto:[email-masked]>
> > > > >> > > 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
> > > > >> > [email-masked]<mailto:[email-masked]>
> > > > >> > 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
> > > > > [email-masked]<mailto:[email-masked]>
> > > > > 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$>
> > > 
> > > --
> > > ---
> > > [email-masked]<mailto:[email-masked]>
> > > 
> > > _______________________________________________
> > > BIER mailing list
> > > [email-masked]<mailto:[email-masked]>
> > > 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$>
> > 
> > --
> > ---
> > [email-masked]
> 
> --
> ---
> [email-masked]
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4
> 1_jWV3YUA6D$

--
---
[email-masked]

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 18 Feb 2020 12:45:54 -0800

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=
[email-masked]> wrote:

> > > 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.
> >
> > > 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:
> >
> > > > 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".
> >
> > > 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.
> >
> > > 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)?
> >
> > > > 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.
> > >
> > > 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.
> > >
> > > > 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).
> > >
> > > 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.
> >
> > > 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).
> >
> > > > 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.
> > > >
> > > 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:
> > > 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.
> >
> > > 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)?
> >
> > > > 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.
> >
> > > The first (RFC8279) pseudocode was simplified. The second one is
> comprehensive. If not comprehensive, whats a good opposite of simplified ?
> > >
> > > > <
> https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https:
> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) <
> [email-masked]<mailto:[email-masked]>> wrote:
> > > > > >>
> > > > > >> Support:
> > > > > >>
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 18 Feb 2020 21:13:10 +0000

Support

Regards

Hooman

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Tuesday, February 18, 2020 3:07 PM
To: Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch

Hi Toerless,

Thanks!

Jeffrey

--
---
[email-masked]

---

From: Michael Menth <[email-masked]>
Date: Tue, 18 Feb 2020 23:37:46 +0100

support (as co-author)

Michael

Am 18.02.2020 um 21:45 schrieb Greg Shepherd:
> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang
> <zzhang=[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Toerless,
> 
>     Thanks!
>     > **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
>     > *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
>     > > 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.
>     >
>     > > 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:
>     >
>     > > > 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> 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.
>     >
>     > > 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.
>     > >
>     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)?
>     >
>     > > > 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.
>     > >
>     > > 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.
>     > >
>     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).
>     > >
>     > > 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.
>     >
>     > > 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).
>     >
>     > > > 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..
>     > > >
>     > > I think you are still explaining from the misunderstsanding that
>     the ECMP explanations where about routed adjacencies.
>     > >
>     forward_connected adjacencies in the examples. For example, first
>     BIFT picture:
>     > >
>     > >   BIFT entry in BFR1:
>     > > 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.
>     >
>     > > 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
>     > > > 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.
>     >
>     > > > The above sentence reads a bit strange (or lacks some segue)..
>     > >
>     > > > From: BIER [[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>]
>     > > > on behalf of Toerless Eckert [[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>]
>     > > > Hopefully this makes readin the rest of te document smoother..
>     > > >
>     > > > **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
>     > > > **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
>     > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd
>     <[email-masked] <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     > > > > >
>     > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert)
>     <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     > > > > >>
>     > > > > >> Support:
>     > > > > >>
>     > > > > >> > <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>> On
>     > > > > >> > <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     > > > > >> > Cc: BIER WG <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>     > > > > > [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > > > > >
>     <https://urldefense.com/v3/__https://www..ietf.org/mailman/listi>
>     > > > > > nfo/
>     > > > [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > > >
>     > > > BIER@ietf..org <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > > [email-masked] <mailto:[email-masked]>
>     >
>     > --
>     > ---
>     > [email-masked] <mailto:[email-masked]>
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: <[email-masked]>
Date: Wed, 19 Feb 2020 08:49:30 +0800 (CST)

Support.

Thanks,

Sandy

原始邮件

发件人：GregShepherd <[email-masked]>
收件人：Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>;
抄送人：[email-masked] <[email-masked]>;Toerless Eckert <[email-masked]>;
日 期 ：2020年02月19日 04:46
主 题 ：[Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK

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=[email-masked]> wrote:

Hi Toerless,

Thanks!

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> > > 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...
> > > 
> > > The above sentence reads a bit strange (or lacks some segue)...
> > 
> > > Hopefully this makes readin the rest of te document smoother...
> > > 
> > > > >> > > https://urldefense.com/v3/__https://datatracker.ietf.org
> > > > >> > > /doc 
> > > BIER@ietf...org<mailto:[email-masked]>

--
---
[email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Feb 2020 09:12:10 +0800 (CST)

Support.Regards

Ran

原始邮件

Chairs
(Shep)

Hi Toerless,

Thanks!

Jeffrey

--
---
[email-masked]

---

From: <[email-masked]>
Date: Wed, 19 Feb 2020 08:16:50 +0000

Support.
Kind regards, Nils Warnke

Von: BIER <[email-masked]> Im Auftrag von Greg Shepherd
Gesendet: Dienstag, 18. Februar 2020 21:46
An: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]; Toerless Eckert <[email-masked]>
Betreff: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK

Chairs
(Shep)

On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>> wrote:
Hi Toerless,

Thanks!

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https<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
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:*<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
> > > 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..
> > >
> > > From: BIER [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]
> > > on behalf of Toerless Eckert [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]
> > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https<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
> > > **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
> > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> On
> > > > >> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > > > >> > Cc: BIER WG <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org<https://urldefense.com/v3/__https:/datatracker..ietf.org>
> > > > >> > > /doc
> > > > >> > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/>
> > > > >> > > list
> > > > >> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li<https://urldefense.com/v3/__https:/www.ietf.org/mailman/li>
> > > > >> > stin
> > > > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi<https://urldefense.com/v3/__https:/www..ietf.org/mailman/listi>
> > > > > nfo/
> > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > >
> > > BIER@ietf..org<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>
> > > bier
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>

---

From: Mike McBride <[email-masked]>
Date: Wed, 19 Feb 2020 07:54:10 -0800

Support.
mike

On Tue, Feb 18, 2020 at 12:46 PM Greg Shepherd <[email-masked]> wrote:
>> > > > BIER@ietf..org<mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Feb 2020 18:38:38 -0500

Hi,

     I have no issue or objection to the mechanisms being defined in 
this document as much as they go, but I was quite disappointed that 
despite the name of the document and use of 'bier-te'  to see that the 
document doesn't define any traffic engineering support, at least as far 
as the term has been used in IETF RFCs.  In particular it totally lacks 
any discussion of resources usage and/or allocation.  What it currently 
describes certainly provides good and useful path/traffic steering that 
can be used to support policy-based routing.  Basically it does the same 
as what is defined by draft-ietf-spring-segment-routing-policy.

I personally (not speaking for the related WGs that I chair) would 
prefer to see this document be revised  to include resource allocation 
that would allow BIER-TE to support TE usage such as DetNet.  Barring 
such an addition, I'm against publication of this document as is and I 
think the document should be recast and renamed to be aligned with the 
SR example, i.e., BIER routing policy (or path steering).

Lou

On 2/18/20 3:45 PM, Greg Shepherd wrote:
>     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.
>     >
>     > > > 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).
>     > >
>     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".
>     >
>     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.
>     >
>     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
>     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)?
>     >
>     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.
>     > >
>     > > 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.
>     >
>     > > 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.
>     > >
>     MP2P, any router getting a copy will send it to the endpoint of
>     the routed adjacency, causing lots of duplicates.
>     > > >
>     > > I think you are still explaining from the misunderstsanding
>     that the ECMP explanations where about routed adjacencies.
>     > >
>     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.
>     > >
>     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
>     logical ???or??? of all the BPs presented in this BIFT) and then
>     use (packet->bitstring & BIFT.F-BM) as the input to
>     > > 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.
>     > >
>     > > The first (RFC8279) pseudocode was simplified. The second one
>     is comprehensive. If not comprehensive, whats a good opposite of
>     simplified ?
>     > >
>     > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert
>     (pthubert) <[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 20 Feb 2020 04:56:20 +0100

Thanks a lot, Lou

[ Would have been nice if you could have commented a bit earlier. 
  But i can understand how a few years is not enough time ;-P 
  (actually no kidding, i really can.) ]

Originally i had planned to address the explanations you are missing
in this doc in the BIER-TE traffic engineering framework document,
for which i had written the -00 version and presented at TEAS WG, IETF101,
but given how we first wanted to get BIER-TE out as RFC, i let that
expire, and in hindsight it's certainly useful to have a short
section summarizing this in the BIER-TE RFC itself:

So, I just pushed -06 of the draft to address your concerns with
additional explanations.
Summary below, diff here:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt

- Title changed from "Traffic Engineering for..." to "Path Engineering
  for...", but kept name BIER-TE (see below). 

- Added section 1.1 explaining how BIER-TE relates to traffic
  engineering, naming use-cases where its for example beneficial standalone and
  and what it could be combined with for more comprehensive TE solutions,
  but also stating that those integrations are outside the scope of this
  document.

- changed "traffic engineering" term in the whole doc to "path engineering",
  where appropriate.

- Unrelated to you, there was one leftover fix from ietf106 review to rename BIER-TE
  Controller Host to just BIER-TE Controller

Wrt to naming: 

The mayority of customers i talked to only used RSVP-TE for path
engineering, and not for anything more. Several didn't even know it
can do bandwidth reservation. Nobody knew it could do latency
guarantees, because nobody knows an implementation that supports that.
[All reasons btw. why replacing RSVP-TE with SR happened in the industry.]

In any case, the name BIER-TE was selected to reduce confusion
with customers, not to maximize naming correctness in IETF.
Something like "BIER-PE" (Path Engineering) would have
probably confused more than it would have helped.  Think
of the justification for the name BIER-TE not as
"all you need to do TE", but "the variation of BIER to support TE".

Wrt to SR:

SR can actually NOT do the same as BIER-TE. It has no stateless multicast.
All the SR options do really require that you set up multicast trees with
e.g.: replication-SIDs that together form the equivalent of a
multicast tree, like you would have built with RSVP-TE. Except that
the signaling how to build the tree is left for someone else, like
PCECC. (AFAIK, i may not be on top of all details). In BIER-TE,
there is no such per-tree state on transit nodes.

Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs
(e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE.
Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely
harder to parse. 

Cheers
    Toerless

On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote:
> Hi,
> 
>     I have no issue or objection to the mechanisms being defined in this
> document as much as they go, but I was quite disappointed that despite the
> name of the document and use of 'bier-te'  to see that the document doesn't
> define any traffic engineering support, at least as far as the term has been
> used in IETF RFCs.  In particular it totally lacks any discussion of
> resources usage and/or allocation.  What it currently describes certainly
> provides good and useful path/traffic steering that can be used to support
> policy-based routing.  Basically it does the same as what is defined by
> draft-ietf-spring-segment-routing-policy.
> 
> I personally (not speaking for the related WGs that I chair) would prefer to
> see this document be revised  to include resource allocation that would
> allow BIER-TE to support TE usage such as DetNet.  Barring such an addition,
> I'm against publication of this document as is and I think the document
> should be recast and renamed to be aligned with the SR example, i.e., BIER
> routing policy (or path steering).
> 
> Lou
> 

-- 
---
[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Fri, 21 Feb 2020 12:25:46 +0800

Authors, working group,

Inline plz.

> SR example, i.e., BIER routing policy (or path steering).

chair hat off

Personally I agree with Lou, plz add the resource allocation.

chair hat on

mpls wg chairs discussed this, and it is our opinion that this document
should have been at lest flagged in mpls and teas, preferably a cross
wg review should have been organized.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Feb 2020 06:37:06 -0800

(Hope I'm not too late)

I support progressing this work. The document presents a technically sound
solution for the important use case.

Regards,
Greg

On Tue, Feb 18, 2020 at 12:46 PM Greg Shepherd <[email-masked]> wrote:

>> otherwise we'd give each link a separate BP, which would be 6 BP to reach
>> to BFR4...BFR7 from BFR1.
>> > >
>> > > 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).
>> >
>> send it to the endpoint of the routed adjacency, causing lots of
>> duplicates..
>> > > >
>> > > 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.
>> >
>> > > > Because the forwarding is different from BIER forwarding (because
>> of [1] above), we might as well introduce an optimization here ??? for each
>> > > > BIER@ietf..org <[email-masked]><mailto:[email-masked]>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 21 Feb 2020 19:45:42 +0100

Hi Loa,

> Inline plz.
[lou's text...]
> wg review should have been organized.

The BIER-TE architecture was broadly disseminated @IETF101 with presentations
adjusted to the specific WG audience to both TEAS and DetNet. I also
posted a draft about the bier-te framework architecture that ultimately
was meant to go into TEAS and describe for example how bandwidth
resource allocation would happen on a controller in the same way
as it would for example for SR. 

I apologize for not having gone to MPLS, but before 101 i asked around
and was told TEAS was the appropriate place. nobody brought up a suggestion
to go to MPLS.  Note that we did have other WGs/chairs interested in BIER-TE
reach out to BIER-WG by themselves (e.g.: from Roll).  I think the people working 
in SR and having an interest in multicast for example are well aware of
BIER/BIER-TE too.

This is just WG last call, not IETF last call, so i'd certainly be
happy to come @107 to your WG and present on BIER-TE. Let me know.

BIER-TE was from the beginning designed to be the variation of BIER
to support TE, but not the same all-in-one signaling that e.g.: RSVP-TE is. 
If you understand the technology, i think it's clear why the
path engineering and resource management are two orthogonal
components of a modular solution. [ And we all know what happened to
RSVP-TE (all-in-one) when the mayority of users didn't leverage it's 
resource allocation functionality. ]

As you are probably not subscribed BIER mailing list, let me append
at the bottom the reply i sent to  Lou and the list. Pls. read the new
section in the doc, and let me know if you have any further questions.

Cheers
    Toerless

---

Thanks a lot, Lou

Wrt to naming: 

Wrt to SR:

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Fri, 21 Feb 2020 15:01:51 -0500

Hi Toerless ,

Thanks for the super quick response

>    (actually no kidding, i really can.) ]

I raised this as an issue last march - at both the Chair and AD level.  
I thought I made the same point to you privately after one the 
presentations at IETF101, but if you don't remember it, I accept that I 
didn't.

> section summarizing this in the BIER-TE RFC itself:

Well that document seems like a fine place to describe how BIER-RP 
(routing policy) can be used to deliver BIER-TE.

>    for...",

Do we really need a new term to describe here?  I find zero (0) 
instances of Path Engineering in any RFC.  Routing policy (and 
policy-based routing) on the other hand are fairly well established 
terms in the industry.  I think this just sows seeds for future 
confusion on this topic.

Why is "routing policy" not good enough for what is being defining 
here?  I again point out, this is the term being used in SPRING for 
basically the equivalent function/purpose. (Yes the forwarding mechanism 
is different, but the objective is not.)

> but kept name BIER-TE (see below).
>

So this section seems to miss what has been going on in traffic 
engineering / TEAS for the last 5+ years (i.e., controller-based TE 
approaches)  and then goes on describe path steering  in a very brief 
way.  I read this as saying that BIER *could* do TE in the future and 
*can* support routing policy and path steering today.

> - changed "traffic engineering" term in the whole doc to "path engineering",

While this is appreciated, I'm not sure it's helpful.  As stated above, 
I think the introduction of the new PE term is confusing as the 
continued use of BIER-TE.

> [All reasons btw. why replacing RSVP-TE with SR happened in the industry.]

While I'm going to avoid getting into product differentiators and 
marketing, you're not mentioning that even those products and customers 
who didn't support/use per LSP queuing, did available resource 
bookkeeping and even admission control.

> with customers, not to maximize naming correctness in IETF.

umm, the IETF is a standards body not an industry marketing forum, so 
I'm unclear how this point helps your argument.  It seems that you're 
saying that if we call it BIER-TE we can market it in place of existing 
IETF TE solutions - even though it doesn't yet have the TE capability 
covered in draft-eckert-teas-bier-te-framework.

Assuming I'm reading it right, this just confirms to me that the current 
work needs to be renamed and that draft-eckert-teas-bier-te-framework 
will define BIER-TE.

> "all you need to do TE", but "the variation of BIER to support TE".

I'm sorry to say, I'm left more confused by this response and doc update 
than I was before it.

> SR can actually NOT do the same as BIER-TE. It has no stateless multicast.

My point wasn't that BIER=SR, but rather both deliver support for path 
steering and policy based routing.

Thanks for being responsive!

Lou

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 25 Feb 2020 02:57:18 +0100

Hi Lou, round 2.

Here is the github pre-version of -07 of the draft:

https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt

Diff:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt

I would appreciate if you could try to partition your opinions into
things you think MUST be solved before passing the document to IESG (for
IETF/IESG review) and those issues that could then be solved when it is
in IETF/IESG review. For example, i think a final choice of name could
be something that shouldn't block the document to take this step.

If this goes along into IETF107, it would be great if you could find the
time to be at the BIER-WG meeting.

Summary of changes:

1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse
readers of the difference between BIER-PE and BIER-TE.

Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource
allocation mechanisms, and this document only describes BIER-PE.

2. Removed all use of the term "path engineering" from the (explanatory) text,
replaced with path / tree steering or policy in the text (like RFC8402).

3. In result, "Path Engineering" is now solely a name  for the mechanism.
In the same way as SR introduced "Segment Routing" as a name, but explains
what it does with the terms "steering" and "policy".

4. I think a unique new term not already used in before is helpful because
what BIER-PE does is quite unique and new. And reusing an existing term
always brings out more people wanting to argue about the accuracy of how
their pre-existing term is applied.

I hope we can have a deterministic, short latency decision mechanism for
the term. After we've decided on the term, its easy to update the doc
again with that new term (%s/PE/XXX/g).

I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring.

[The main issue with name change now is that we've gotten some followup
work such as YANG model that also refers to BIER-TE meaning BIER-PE, so
that would also need to change name. See below for my reply to that naming
change you said you suggested .]

5. I also refined the section 1.1 that was introduced in -06 to mention
e.g.: PCE.

Specific answers to the mail thread below.

Cheers
    Toerless

On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote:
> I raised this as an issue last march - at both the Chair and AD level.  I
> thought I made the same point to you privately after one the presentations
> at IETF101, but if you don't remember it, I accept that I didn't.

Did you include the authors ? I could not find any email about this.
Also no forwarded emails from AD/chairs i could find. If you still have
a copy, pls. PM. This is annoying...

I do not remember naming issue discussed after IETF101, but i am
sure i was preoccupied with technical issues and might not have
given it too much thought back then. Of course there was a lot of
time since IETF101 to bring up the naming point again...

> Well that document seems like a fine place to describe how BIER-RP (routing
> policy) can be used to deliver BIER-TE.
>
[...]
> 
> Do we really need a new term to describe here?  I find zero (0) instances of
> Path Engineering in any RFC.  Routing policy (and policy-based routing) on
> the other hand are fairly well established terms in the industry.  I think
> this just sows seeds for future confusion on this topic.
> 
> Why is "routing policy" not good enough for what is being defining here?  I
> again point out, this is the term being used in SPRING for basically the
> equivalent function/purpose. (Yes the forwarding mechanism is different, but
> the objective is not.)

SPRING did establish new unique name/terminologies, like "Segment".
As said above, i think its best we do the samegiven how unique this is.

Looking at rfc8402, "steering" and "policy" are used in verbal
explanations, without providing specific terminology for them,
so i did follow that example too.

> So this section seems to miss what has been going on in traffic engineering
> / TEAS for the last 5+ years (i.e., controller-based TE approaches)

I don't think that is a correct assessment. BIER-PE itself requires a
controller to calculate paths / trees. With or without other traffic
engineering components. That component is called the BIER-PE controller and
has been in the draft forever. 

The new section 1.1 added in response to your review relates that
BIER-TE controller to an overall TE controller, using the PCE example
and refrerence to it.

There is really nothing more that a BIER-WG document could or should
do. What this document intended to support is whats necessary and
sufficient to get the forwarding plane implemented/standardized.
Everything else is for independent followup work in TEAS IMHO,
such as reviving the framwork draft.

>  and then goes on describe path steering  in a very brief way.  I read this as
> saying that BIER *could* do TE in the future and *can* support routing
> policy and path steering today.

Even stronger: BIER-PE is always meant to ONLY do that (steering),
any additional TE functions wold come from independent other components.
And simple examples for that are given in section 1.1.

> While this is appreciated, I'm not sure it's helpful.  As stated above, I
> think the introduction of the new PE term is confusing as the continued use
> of BIER-TE.

See above. We can certainly not use "BIER-TE" to mean two different
things, so i hope that concern is resolved.

> While I'm going to avoid getting into product differentiators and marketing,
> you're not mentioning that even those products and customers who didn't
> support/use per LSP queuing, did available resource bookkeeping and even
> admission control.

I think the point is mood now (given how we'll change the name BIER-TE
to a better term). But maybe to better explain: We started calling this
TE so customers would easier understand that this is intended to give
them what they actually use RSVP-TE for (Traffic Steering), and not
necessarily all that RSVP-TE could do beyond that. A central controller 
is assumed to exist in BIER-PE too.

Given how SR also shows how you can be successful in deployment
without betting on 'TE' name recognition, i have no quarrels in
changing the name. As said above, its motly a question of finding
the best term and changing the followup works names too.

> umm, the IETF is a standards body not an industry marketing forum, so I'm
> unclear how this point helps your argument.

It's not am argument or justification, just an explanation. Not only to you,
but also the WG.

> It seems that you're saying
> that if we call it BIER-TE we can market it in place of existing IETF TE
> solutions - even though it doesn't yet have the TE capability covered in
> draft-eckert-teas-bier-te-framework.

...

> work needs to be renamed and that draft-eckert-teas-bier-te-framework will
> define BIER-TE.

Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering
(e.g.: flex-algos), so BIER-PE is only one option for the path-steering
options for BIER-TE. 

> steering and policy based routing.

Yepp, i hope we're in violent agreement.

Cheers
    Toerless

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Feb 2020 13:19:26 -0500

Hi Toerless,

     This revision will mostly remove my objection related to the use of 
TE by the document.  I suspect in section 7.2 you have two instances 
where "traffic" needs to be replaced with "path".  More substantively, I 
think you should delete section 1.1 and leave its subject  matter  to 
eckert-teas-bier-te-framework to be covered/worked out.  If you want to 
keep it, I think there's a longer discussion need on its contents.

FWIW I still think the introduction of the a new term "Path 
Engineering", rather than reusing one of the existing IETF terms for the 
same capability ("routing policy", "policy based routing", "path 
steering") seems  likely to lead to more confusion then if you stuck 
with an established term.  I'll leave this to others to argue.

I think this covers all the detailed discussion points below. If not, 
can you extract the ones you'd like to keep discussing?

Thanks again for the responsiveness to my comments!

Lou

On 2/24/2020 8:57 PM, Toerless Eckert wrote:
> ....
>>>>>       <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]..de>>]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 26 Feb 2020 01:02:06 +0100

Lou, *:

Here is the next and hopefully final github version for your review.
If you can give a thumbsup i will upload to datatracker,
and the WG chairs would also be able to finalize WG last-call.

https://raw.githubusercontent.com/toerless/bier-te-arch/7e996deb1dcd18596d4864c750f6e7541d737e6f/draft-ietf-bier-te-arch.txt

And here the diff to -05, last version before taking input from your review into account.
Given how 1.1 was removed, this seems like the most logical comparison point.

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/7e996deb1dcd18596d4864c750f6e7541d737e6f/draft-ietf-bier-te-arch.txt

Changes to -05 are now easily seen as limited textual:
- Name change BIER-TE to BIER-PE
- Explanations using steering/policy
- [RFC-editor remove note] about name change.
- BIER-TE controller host -> BIER-TE Controller (unrelated to Lou)

Detailled answers, explanations below.

Cheers
    Toerless

On Tue, Feb 25, 2020 at 01:19:26PM -0500, Lou Berger wrote:
> Hi Toerless,
> 
>     This revision will mostly remove my objection related to the use of TE
> by the document.  I suspect in section 7.2 you have two instances where
> "traffic" needs to be replaced with "path".

Fixed

> More substantively, I think you
> should delete section 1.1 and leave its subject  matter  to
> eckert-teas-bier-te-framework to be covered/worked out.  If you want to keep
> it, I think there's a longer discussion need on its contents.

Removed section 1.1 from the text.

I have added to the beginning of 1. an [RFC-editor: pls. remove ] section
explaining the naming change so late in the process to further IETF/IESG
reviewers (if i had just put it into the changelog i fear it will 
be overlooked by reviewers).

For what is worth, i did like the idea of having explanations 
about relationship of BIER-PE to BIER-TE, especially because the
framework is IMHO not yet in a state to serve as a good even draft
reference (it was only pointed to in section 1.1, so also removed
as reference).

How about this: If IESG review wants to have that type of explanation back,
i'll knock on your door to revive and help me fix up that text.

> FWIW I still think the introduction of the a new term "Path Engineering",
> rather than reusing one of the existing IETF terms for the same capability
> ("routing policy", "policy based routing", "path steering") seems  likely to
> lead to more confusion then if you stuck with an established term.  I'll
> leave this to others to argue.

Ok, second time around you're suggesting this, i now owe you an explanation
why i think these terms are technically misleading:
(its a bit long, that why i avoided the explanation in before).

All the established terms you propose come from unicast and
never had a re-definition/re-interpretation for IP multicast.

Using any of these terms in the name would easily lead to
people (especially when not reading the doc) think the
BIER solution here works like in both IP multicast and
BIER in before BIER-PE: By impacting the underlying unicast
(forward) routing (BIER) or RPF (reverse path) routing (IP Multicast). 

Examples: You can use static muRIB routes to steer traffic for
IP Multicast or BIER. You can also use separate IGP (Flex-)topologies
to do the same dynamically. Thats all great stuff to describe in a
BIER-TE framework document (in conjunction with BIER), but that
is also the stuff i do not want BIER-PE to be confused with
because there are technical limitations to those unicast routing policy/
steering approaches when its applied to trees:

Try to use any of the pre-existing mechanisms for unicast routing policy
or path steering with BIER or IP multicast to build steiner trees.
Not generally possible. With BIER-PE, no problem. Same thing with
disjoint trees (even MRT flex-algo's wouldn't achieve the same).

IMHO, the term "Path Engineering" is free of this mis-name-recognition
because it is a new. The name also hints at the fact that this could be
in support of, or a component of traffic engineering. 
And wrt to minimizing the change to the long held name,
the hamming distance is just one character/word. So it's the
'safest/most-conservative/logical' name change this late in the
process.

As i said, i would be happier with a more unique new descriptive
name like "Tree Steering Bitstrings" (BIER-TSB), but i do not feel
like making such a big naming change without more explicit support
by more members of the WG this late in the process. 

> I think this covers all the detailed discussion points below. If not, can
> you extract the ones you'd like to keep discussing?

Still sad about the missed opportunity of fixing this naming 
problem earlier wrt. to the mail you sopposedly sent, and
happy to beat myself up if that ended up being my fault, but
i guess i shouldn't continue to dig into that issue if it would
turn out to be someone else's fault.

Otherwise i am fine.

If you want to give the doc now a thumbs up in response to the last
call, that would be great ;-)

EOF

-- 
---
[email-masked]

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 26 Feb 2020 21:33:17 +0000

Hi Toerless,

> > be something that shouldn't block the document to take this step.

Waiting for the IESG to "name" your technology will definitely result in a much longer delay than sorting out in WG Last Call. You noted, you had presented an earlier version of this document in TEAS, but it is at the time of WG Last Call (per the charter), the TEAS/MPLS/and probably PCE, should have been notified (I included MPLS as you have multiple proposals on use of MPLS labels). I've contacted your BIER Chairs/AD to extend at least a week the Last Call.

On naming, as Lou noted, preference is to align terminology used in other working groups - especially within the routing area. The RFC-editor also recommends careful use of abbreviations - it is expected new abbreviations are added to a list:
https://www.rfc-editor.org/materials/abbrev.expansion.txt

As you can see, PE is already used. And in the Routing Area, for our PE abbreviation, we could say it should have an asterisk😊 Your justification is that "PE" is short similar to "TE", but for the Routing Area, it needs to be either different or maybe add a letter (three letters). If you look thru the list, that's what others have done e.g. in SPRING, they have a new document also using "PE" differently but it's abbreviated "EPE".

As we all enjoy trying to name "something", I checked PCE documents (as you noted in the document, BIER-PE requires SDN/PCE controller). As Lou says - there is no mention of "path engineering" either in PCE documents or any IETF documents. So maybe "PE" in the string is not the best. My 2-cents, how about "SREP-BIER" (Source Routed Engineered Path)? Have fun naming - but please stabilize on a name before hand-off to the IESG - otherwise the IESG will have all the fun.

As BIER-PE requires use of an SDN/PCE controller - here's my early AD comments - please mention this earlier in the document - abstract, intro. e.g. the SPRING document has as the title "centralized" EPE. The centralized controller is the key differentiator for BIER-PE. Also, in section 8, there is no need to be critical of RSVP-TE, we are not trying to market one vs. the other:
"SR aims to enable lightweight path steering via loose source routing. Compared to its more heavy-weight predecessor RSVP-TE, SR does for example not require per-path signaling to each of these hops."

RSVP-TE provides very different capabilities than SR and BIER. With RSVP-TE glasses on, one could say SR and BIER provide very limited capabilities. And both SR and BIER require very heavy-weight SDN controllers. So it just depends where the operator/vendor wants to put their "weight". But it's not for IETF to do the judgement. Same for some of your pro BIER-PE comments vs. SR. SR has it's advantages over BIER too. An RFC is not for marketing one technology vs. another.

Hopefully my working groups (TEAS, MPLS, PCE) are given the "heads-up" soon - I'd prefer discussion during working group last call vs. IETF Last Call or my needing to enter a "Discuss" waiting for their review.

Thanks!
Deborah
(AD hat on)

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of Toerless Eckert
Sent: Tuesday, February 25, 2020 7:02 PM
To: Lou Berger <[email-masked]>
Cc: [email-masked]; [email-masked]; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK

Lou, *:

https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=hbVUmt6ob-Ilgt00kiOlwAOcA68kldlxvO0Lqq-gKxo&e= 

https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D05.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jTvrGagqHgPKneTUpOvNkeYcl7cxDSV32gLk--vyzdQ&e= 

Cheers
    Toerless

Fixed

Otherwise i am fine.

EOF

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ijbHbeNowm8uYigeF3tPQBOSrFL5chyoxfjBXyDOxPg&e= 
> > 
> > Diff:
> > 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D06.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=VMWxCE2IzT007rczFZWwh1CEB3xG48xOj5RifpjIt5s&e= 
> > 
> > > I raised this as an issue last march - at both the Chair and AD level..  I
> > > > > should be recast and renamed to be aligned with the SR example, i..e., BIER
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dte-2Darch_&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jH9x7gacv335Qdcq_btgUNtO3-TQxwLspmfVzbCC9Oo&e= 
> > > > > > 
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__Araw.githubusercontent.com&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=xVAjp721g_El61X8yMyRw3ggZhIQ-SG9Zb-UFpVtOHw&e= >*toerless*bier-te-arch*master*draft-ietf-b
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__Atools.ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ggPrkSBziBxcUV48NKmskrw6fOzU94m3Dk5u67UMcRg&e= >*id*draft-ietf-bier-te
> > > > > >       >
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__Atools.ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ggPrkSBziBxcUV48NKmskrw6fOzU94m3Dk5u67UMcRg&e= >*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools.
> > > > > >       > ietf.org
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=URRMpXM94kB4xSw27o7fG_DV2IOD4kJVE3esjPI_b9g&e= >*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
> > > > > >       > >                   ... .Routers. ....--L2--/
> > > > > >       > >                    ................         |
> > > > > >       about incorrectly plugged HDLC links (such as old T1/T3/....
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__Atools.ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ggPrkSBziBxcUV48NKmskrw6fOzU94m3Dk5u67UMcRg&e= >*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > > > >       > > > tool
> > > > > >       > > > s.ietf.org
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__s.ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=Ox8APr0AU8iMaNjaWNcGYQDfkrhJBNtsAZWRvfmO_ZI&e= >*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > > > >       > > > jC81
> > > > > >       > > >
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__Atools.ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ggPrkSBziBxcUV48NKmskrw6fOzU94m3Dk5u67UMcRg&e= >*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > > > >       > > > tool
> > > > > >       > > > s.ietf.org
> > > > > >       <https://urldefense.proofpoint.com/v2/url?u=http-3A__s.ietf.org&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=Ox8APr0AU8iMaNjaWNcGYQDfkrhJBNtsAZWRvfmO_ZI&e= >*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > > > >       > > > jC81
> > > > > >       > > >
> > > > > >       https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= 
> > > > > > 
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= 
> > 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= 

-- 
---
[email-masked]

_______________________________________________
BIER mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e=

---

From: Michael Menth <[email-masked]>
Date: Thu, 27 Feb 2020 02:28:17 +0100

Hallo Toerless,

würde BIER-SR passen? Wir haben ja intern schon öfter argumentiert, dass
BIER-TE so ähnlich wie SR ist.

VG, Michael

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 27 Feb 2020 09:35:47 +0100

Hi Deborah,

inline

On Wed, Feb 26, 2020 at 09:33:17PM +0000, BRUNGARD, DEBORAH A wrote:
> Waiting for the IESG to "name" your technology will definitely result in a much longer delay than sorting out in WG Last Call.

Ack

> You noted, you had presented an earlier version of this document in TEAS, but it is at the time of WG Last Call (per the charter), the TEAS/MPLS/and probably PCE, should have been notified (I included MPLS as you have multiple proposals on use of MPLS labels). I've contacted your BIER Chairs/AD to extend at least a week the Last Call.

Thanks. I hope that feedback would still have to go all go to BIER, and
not to those other WG mailing lists, right ? Don't want to hunt feedback
across many WG lists. 

> https://www.rfc-editor.org/materials/abbrev.expansion.txt

See below

> As you can see, PE is already used.

a) 461 out of 2651 abbreviations in that doc are overloaded.

b) There is no indication that suffixes of a composite abbreviation have to be unique.

c) We would only want to use BIER-PE as an abbreviation, not PE alone.

   That is btw. why i changed all the occurances of "path engineering" in
   the text to explanatory "steering" or "policy" and only use BIER-PE as a name.

d) Of course i would get BIER-PE registered when being in RFC-editor
   state like i have done in the past in other RFCs.

e) How about SR first meaning Source Routing and then being
   overloaded with Segment Routing ? And if Segment Routing
   was a valid new term (as it has more flexibility than
   Source Routing), why then not allow Path Engineering as
   a new term for us ?
   
e) SR in abbrv.expansion.txt:

   SR         - sender report (SR)
   No "Source Routing", "Segment Routing", no SR-MPLS,
   No SRH from RFC6554, No consideration for disambiguating
   RFC6554 SRH from SRv6 SRH, ... NADA! (not even NADA/RFC8698)

I know your and Lou's comments wrt. naming are well meaning,
but given those and other (below) realities i hope it is not too rude for
me to say that its perceived on my end a bit more like selective hazing.

Can we please turn this around and you help us in actually selecting a good name ?

> And in the Routing Area, for our PE abbreviation, we could say it should have an asterisk????

Sure, please talk with RFC editor to get it added to the doc.

But asterix does not say anything about whether or not there
is a conflict when reusing another abbreviation in a suffix
of a longer name. Maybe when you get the asterisk, ask the RFC
editor about that. There are no prior cases of this in the
doc, so not possible to derive case law from the existing abbreviations.

>Your justification is that "PE" is short similar to "TE", but for the Routing Area, it needs to be either different or maybe add a letter (three letters). If you look thru the list, that's what others have done e.g. in SPRING, they have a new document also using "PE" differently but it's abbreviated "EPE".

[ SPRING is the WG working on sender report (SR) ?  (sorry, could not resist) ]

draft-ietf-spring-segment-routing-central-epe - "Egres Peer Engineering"

To me its primarily a good reference that other work is not contested
when combining the word engineering with other words beside "Traffic"
whereas this is contested when i am prosing to do it for the BIER work.

> As we all enjoy trying to name "something",

Not when the baby has a name for 5 years and that then gets contested.

> I checked PCE documents (as you noted in the document, BIER-PE requires SDN/PCE controller).

BIER-PE does not require a PCE according to RFC 4655, RFC 4657. That is
a highly desirable option when you want to use BIER-PE for Traffic Engineering,
but it is explicitly not scoped in this document so as to not encumber
the document or constrain the applicability of its technology.

The document has early on in section 2 the mandatory dependencies
of BIER-PE, which includes the "BIER-PE Controller" as a concept
as abstract as possible, and the document does explain what that
BIER-TE controller needs to do without expecting any PCE arch
TE definition . Such a BIER-PE controller could in one instance
be an operator using CLI.

I had another explanation in section 1.1 i added/proposed for Lou,
stating how the "BIER-PE controller" would be a new function within
a larger PCE if BIER-PE was used in a traffic engineering / PCE
framework, but Lou said i should rather remove that section 1.1,
which i did, so i think he is fine with waiting for the BIER-TE
framework draft to define how the BIER-PE controller relates to a PCE.

> As Lou says - there is no mention of "path engineering" either in PCE documents or any IETF documents. So maybe "PE" in the string is not the best.

There was also no mention in IETF or PCE documents of "Segment Routing"
before it was invented, and SR likely meant something else, so what is the point ?

>My 2-cents, how about "SREP-BIER" (Source Routed Engineered Path)?

See above on the SR confusion. Also note that the bigger common
technology here is not 'source routing', but BIER, so that should be the prefix.

Also, see below.

> Have fun naming.

See above. 

> but please stabilize on a name before hand-off to the IESG - otherwise the IESG will have all the fun.

What would really help the authors and the WG to finalize on a name 
would be for you and Lou go beyond explaining what we should NOT choose
as a name to what we are allowed to choose as names. Otherwise
we could as well have the poor WG circle around this block multiple time.

So please with sugar and whipped creme topping, let us know
what will be permitted.  Lou said we should re-use existing terms,
i told him why using ONLY those would not well represent the
unique novelty of BIER-PE but lead to confusion with unicast
semantics (and besides: see SR and anybody else choosing new names
for equal good reasons).

BIER-PE is an easy compromise that i think makes everybody
equally but only little unhappy. If not then then please
comment on the following list which i hope would be 
sufficiently broad for the WG to select a name from:

BIER-ET  - Explicit Trees
BIER-EET - Explicit Engineered Trees
BIER-BET - Bit Engineered Trees
BIER-BST - Bit Steered Trees
BIER-TrE - Tree engineering     
BIER-ET  - Engineered Trees
BIER-ST  - Steered Trees

BIER-ASB - Adjacency Steering Bits   (adjacencies are how bits in BIER-PE are defined)
BIER-AB  - Adjacency Bits  
BIER-SB  - Steering Bits             (overloads with "Source Block" - never heard)

[ I prefer terms with Tree, because thats the unique distinction
  to paths, and highlight the multicast specific characteristic. ]

> As BIER-PE requires use of an SDN/PCE controller - here's my early AD comments - please mention this earlier in the document - abstract, intro. e.g. the SPRING document has as the title "centralized" EPE.

I answered this alredy above.

> RSVP-TE provides very different capabilities than SR and BIER. With RSVP-TE glasses on, one could say SR and BIER provide very limited capabilities.  And both SR and BIER require very heavy-weight SDN controllers. So it just depends where the operator/vendor wants to put their "weight". 

> But it's not for IETF to do the judgement.
> An RFC is not for marketing one technology vs. another.

The goal of the text was not to make non-technical judgements about the overall TE
systems or to market SR, but simply to provide a technical explanation of
the aspects of SR that relate to BIER-PE and relate that to RSVP-TE given
how RSVP-TE/P2MP is also the equivalent alternative for BIER-PE:

  SR : RSVP-TE   ~=   BIER-TE : RSVP-TE/P2MP

But:
"predecessor" is an imprecise qualification. I just thought
about the timeline, not the possible misinterpretation that SR
would/could/should 1:1 superceed RSVP-TE. Also, the verbage of heavy 
vs. lightweight is not correctly constrained to the technical
point of comparison (on-transit-hop heavyness of path steering).

I propose to change that sentence accordingly:

"SR supports through the use of source-routing strict and loose hop path steering across transit hops that is lightweight on those transit hops because it does not require per-hop/per-flow signaling to and forwarding plane state on those transit hops. In comparison, RSVP-TE and RSVP-TE/P2MP do require such per-hop/per-flow transit-hop signaling and forwarding plane state "

I think this is now technically precise and limited to the necessary
comparison in this context. If you still have concerns,
pls. let me know why, ideally with proposed text that would solve
those concerns. I think it is important to explain the
relevant technical aspects that where the core reasons for doing
BIER-PE, especially in comparison to existing solutions.

[ Btw: If memory serves me well, the whole PCE architecture was introduced first
  by recognizing that you could not use RSVP-TE in situations with
  multi-headend resource contention without a central/coordinated PCE
  efficiently, and then implementations managed to build those PCE fairly
  lightweight into headend routers. Technically i would therefore disagree
  with your contentions that PCE need to be very heavy-weight and that
  RSVP wouldn't need them but only SR/BIER-PE. But definitely this
  BIER-PE document is not the place to have that argument. A later BIER-TE framework
  document nevertheless would IMHO be more useful to adopters and operators
  if it had such technical description - without judgement and marketing,
  just the facts! ]

> Hopefully my working groups (TEAS, MPLS, PCE) are given the "heads-up" soon - I'd prefer discussion during working group last call vs. IETF Last Call or my needing to enter a "Discuss" waiting for…

I did see Lou sending mail to TEAS and DetNet and Lea to MPLS, did you send to PCE ?. 

I do of course welcome feedback from any group, but i am not worried
about MPLS or PCE. There are no changes on the MPLS encap side, and
as explained above, mapping BIER-PE into the PCE framework is
also subject to followup work (like i think it was for SR as well).

Thanks a lot. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 27 Feb 2020 21:37:02 +0000

Toerless,

A couple of high level comments:

I've seen you mention 5-years lifetime of the draft a couple of times as rationalization not to change. Publication is not based on lifetime of a draft. Authors/WG need to be open to change especially during WG last call (when collaborating with other working groups in an Area and the document has not been shared over "lifetime"), IETF Last Call (especially other Area Directorate reviews), and, of course, IESG review. As you have been an author many times, I think you are very familiar with the churn. I just want to remind for the benefit of others as I've seen many new authors frustrated when their document becomes a working group document and there is churn.

It's always difficult to interpret personal comments over email - even those meant with the best intention or to amuse. Best is to keep to technical discussion. E.g. comments such as " but given those and other (below) realities i hope it is not too rude for me to say that its perceived on my end a bit more like selective hazing" and " to the mail you sopposedly sent" may be interpreted very differently by the intended person or others on the mailing list than what you meant. As I was doing this email, I see you already responded to Lou explaining. For me, "selective hazing" is a rather strong reaction to someone commenting. We want to encourage folks to comment, not discourage. And it's not to you, it's the document. We all have different styles of writing, but on the lists, best is to keep it technical.

On the document:

As you say yourself, current abbreviations are overloaded. Which is why when new ones are proposed, the preference is to not keep overloading (in this case, "PE") if more accurate abbreviations can be identified. This document is defining replication and forwarding based on a precalculated path. I was not questioning the use of the term "engineering" for something other than TE, I was questioning the naming of this BIER mechanism as "engineering". I haven't seen replication/forwarding referred to as "engineering". If you and the working group think the best name is "engineering" - let it stand for now. Most important for me (as AD for TEAS) was that you removed "TE" as that was inaccurate. Again, just because it has been 5 years, now is the time to improve, once a document is published, it is for a lifetime. I just noted your email asking input on the naming - thanks - that's good - we can see what folks think.

Your suggested revision for the sentence comparing with RSVP-TE is much better.

I understand when you use the term controller, it is not necessarily a PCE. What I was asking (especially as an operator) was to include in the abstract and intro sentences on the difference of BIER and BIER-PE. This sentence in section 1.3 "BIER-PE replaces in-network autonomous path calculation by explicit paths calculated off-path by the BIER-PE Controller" would be very helpful in understanding the technology earlier in the document. In the abstract, suggest a sentence "BIER-PE differs from BIER in the use of explicit paths calculated off-path by a controller."

A new comment - if you intend this mechanism to be supported by BIER hardware (section 3.2) - you probably want to get support for this document to be an update of RFC8279?

Thanks,
Deborah

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Thursday, February 27, 2020 3:36 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; [email-masked]; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK

Hi Deborah,

inline

Ack

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_materials_abbrev.expansion.txt&d=DwIDAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=yX_6NAhGb01k0I5mGk47ecTvjnxrstlW9R1Vjdlxy_Y&s=MqqVe6A0srzY2l9XMurr7U__uZcGjMjqTWAw6bMDew8&e= 

See below

   

   SR         - sender report (SR)

Also, see below.

See above. 

BIER-ET  - Explicit Trees

But:

Thanks a lot. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 Feb 2020 02:06:37 +0100

> I've seen you mention 5-years lifetime of the draft a couple of times as rationalization not to change. Publication is not based on lifetime of a draft. Authors/WG need to be open to change especia…

Completely agreed. I only mentioned the age in response to your 
claim that i would have fun and in combination that this is not
a technical issue, and that it is annoying that this issue was "lost"
(if that is the right word) for 2 years where it could have easily
been addressed. That in combinations makes up for a very non-fun situation.
> It's always difficult to interpret personal comments over email - even those meant with the best intention or to amuse. Best is to keep to technical discussion. E.g. comments such as " but given th…

Completely agree on the non-discouragement and technical
discussion.  These specific (naming/abreviation) comments
came from a 2xWG chair and an AD, where therefore
(maybe mis-)perceived by me to be less comments but more
expression of strong rules/reqiremens/process that i saw
not equally being applied elsewhere, and when they started
to look to me as as not being helping for the document technically
anymore, that made me quite discouraged and hence the reply.

I will remove "hazing" from my list of useful colloquialisms.

Supposedly was the wrong word. I do believe that Lou sent the email.
Personally i have been hit so many times with email delivery problems
that i tried to factor that possibility into my sentence, but
confused supposedly with presumably. 

I try to be verbally insensitive on the receiving side. E.g:
I did not comment on you attributing my text "marketing" and
"judgement", even though it sounded as if it could have been
meant disparagingly (there are disparaging terms like "IMTF" going
around for example).  It did help me to improve the text and
thats all that matters to me.

> On the document:
> 
> As you say yourself, current abbreviations are overloaded. Which is why when new ones are proposed, the preference is to not keep overloading (in this case, "PE") if more accurate abbreviations can be identified. This document is defining replication and forwarding based on a precalculated path. I was not questioning the use of the term "engineering" for something other than TE, I was questioning the naming of this BIER mechanism as "engineering".. I haven't seen replication/forwarding referred to as "engineering". If you and the working group think the best name is "engineering" - let it stand for now. Most important for me (as AD for TEAS) was that you removed "TE" as that was inaccurate. Again, just because it has been 5 years, now is the time to improve, once a document is published, it is for a lifetime. I just noted your email asking input on the naming - thanks - that's good - we can see what folks think.

The 5 year discuss died in the previous paragraphs, no need to revive it.

I immediately agreed to Lou's suggestion to change the name from TE because
that was IMHO a sound ask. Even though i received in private suggestions not
to go down this (perceived) rathole this late in the process.

I pointed you to the fact that the ESE example you made is yet another
one, where "engineering" is used in a context different to "Traffic".
Even though i don't know what Peer Engineering means. But Engineering
is always a good generic term for something convoluted/involved IMHO
(where a simpler more specific term does not fit).

How would you even characterize the components of Traffic Engineering ?
To me i would tell a non-technical person its about the combination
of path engineering, bandwidth reservations and buffer management
(for latency). Aka: To me Traffic Engineering inherits the term engineering
from what we do with paths plus managing the traffic (bandwidth, latency).

Is there any better or even official explanation for the use of the
word "Engineering" in TE ? 

> Your suggested revision for the sentence comparing with RSVP-TE is much better.

Thanks. It actually helped to revisit that sentence because i forgot to
include a sentence included mentioning of RSVP-TE/P2MP. Will include that too.

> I understand when you use the term controller, it is not necessarily a PCE. What I was asking (especially as an operator) was to include in the abstract and intro sentences on the difference of BIE…

Thanks, i totally didn't get that from your first comment,
suggested text always helps. Will add.

> A new comment - if you intend this mechanism to be supported by BIER hardware (section 3.2) - you probably want to get support for this document to be an update of RFC8279?

No, i don't think thats necessary or useful. Think for example
if RSVP would have been defined for MPLS on the IGP/LDP shortest
path, then RSVP-TE would still not have been (IMHO) an update to
that RSVP/MPLS base spec, but an extension of the same framework /
alternative.

(the comparison may not be perfect but i hope it makes the point).

Aka: You can continue to implement and use BIER
without BIER-PE, and if you choose to also support BIER-TE, there
are hopefully sufficiently well limited forwarding plane details 
that need to be supported in addition to what's required for BIER
(at least for the basic subset of BIER-PE), that's why there are
those forwarding plane comparisons.

Cheers
    Toerless

> > > > >    and then goes on describe path steering  in a very brief way..  I read this as
> > > > > > > >       > I didn't want to discuss that option in this document.. Its
> > > > > > > >       obviously
> > > > > > > >       > >                    ................
> > > > > > > >       > >                    .................         |
> > > > > > > >       > > >    address) protects against closing the loop..  Link layers
> > > > > > > >       without port
> > > > > > > >       > Ok. I simplified the text comparison BIER/BIER-TE wrt.. to the FBM
> > > > > > > >       <mailto:[email-masked]><mailto:bier-bounces@ietf..org
> > > > > > > >       <mailto:[email-masked]><mailto:bier-bounces@ietf..org
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= 

-- 
---
[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Sat, 29 Feb 2020 17:25:48 +0800

Toerless, et.al.,

I think 2 (or maybe 3 discussions are mixed.

1. Soliciting input on
    a) which working that will progress the document; and
    b) which working that should be kept in the loop

I don't have any serious concerns over this part of the process,
as a note I'd like to add the the MPLS wg is chartered to do
Traffic Engineering work in the packet domain. Indicating that
MPLS should be kept in the loop and the work flagged to MPLS around
IETF 101.

2. The content of the document
    I see convergence on this and think that if this discussion is
    allowed conclude the issues (most resource allocation) will be
    resolved.
    The number of people from the MPLS wg that are subscribed to
    the bier-list is sufficient to bring MPLS wg point of views
    into the discussions.
    One development I don't want to see is that we start using
    concepts that have been established and used for a long time
    in other wg's to be used for something different in other wg's.

3. What should happen at wglc.
    When the wglc call is started and closed, the working groups
    that have en interest in the documnent should be notified. If
    the overlap is substantial we should consider last call the
    document in more than one wg.
    I have not seen this happen for this document,

/Loa

--